On Mon, Jun 27, 2016 at 01:18:59PM -0700, Chad Versace wrote: > On Mon 27 Jun 2016, Chad Versace wrote: > > Let the hight 32 bits of drm_i915_gem_execbuffer2::rsvd1 contain an > > input and/or output fence fd, whose presence is controlled by flags. > > Also add I915_PARAM_HAS_FENCE_FD. > > > > Signed-off-by: Chad Versace <chad.versace@xxxxxxxxx> > > --- > > include/uapi/drm/i915_drm.h | 24 ++++++++++++++++++++++-- > > 1 file changed, 22 insertions(+), 2 deletions(-) > > Oops. git-send-email stripped the notes to the patch. Here's the notes: > > This RFC proposes a uapi that integrates execbuf with Android sync fds. Of > course, this is *only* an RFC because other devs are working on the i915 > internals, and this patch depends on that work. Why not just use the earlier patches for the uAPI as well? > Why am I sending an RFC this early? I will soon begin prototyping Intel's > Mesa implementation of EGL_ANDROID_native_fence_sync, and that prototype will > be easier to write if I have a rough expectation of i915's eventual fence fd > uapi. > > Please provide feedback: Does this roughly look like the uapi that the i915 > devs expect? Not quite. You have to use separate in/out dwords (i.e. rsvd2) in order to ensure that we don't overwite the in-fence when dealing with error paths (i.e. so that userspace can feed in the same execbuf parameters following EINTR, and you don't have confusion between in/out parameters). You have to also mark the ioctl as writing the new structures which is an ABI break and so requires a new identifier (otherwise you break userspace passing in the args from read-only memory). Playind devil's advocate, an alternative to every driver implementing their own fence extension for execbuf/cmdsubmit would be to add support for explicit sync_fences to be added via dmabuf. (Instead of setting the fence on the execbuf, you would set the fence on the batch buffer obj, or surface of interest - though for CreateSync, it would have to be the batch. Extracting the fence is then supplied by querying the batch buffer dmabuf. It's not as explicit, but I suspect such uABI will be added to dmabuf and will be required to be supported in the driver to handle implicit fencing between PRIME anyway.) -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
