If I understand correctly, this patch preserves the kernel's current implicit fencing, even when an input fence fd is given to execbuffer. I'm convinced that's the right approach. If userspace does want to disable the implicit fencing during an execbuffer, then it should disable that explicit fencing through an *explicit* knob. I believe the kernel should not interpret the presence of an in fence fd in execbuffer as that knob. If it did, then using this feature from GL/EGL userspace would be unwieldy. In other words, I like this. Patch 14 gets my Acked-by: Chad Versace <chadversary@xxxxxxxxxxxx> On Mon 14 Nov 2016, Chris Wilson wrote: > Now that the user can opt-out of implicit fencing, we need to give them > back control over the fencing. We employ sync_file to wrap our > drm_i915_gem_request and provide an fd that userspace can merge with > other sync_file fds and pass back to the kernel to wait upon before > future execution. > > Testcase: igt/gem_exec_fence > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > --- > drivers/gpu/drm/i915/Kconfig | 1 + > drivers/gpu/drm/i915/i915_drv.c | 3 +- > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 54 +++++++++++++++++++++++++++--- > include/uapi/drm/i915_drm.h | 35 ++++++++++++++++++- > 4 files changed, 86 insertions(+), 7 deletions(-) _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
