• Jason Ekstrand's avatar
    drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4) · 00dae4d3
    Jason Ekstrand authored
    This API is entirely unnecessary and I'd love to get rid of it.  If
    userspace wants a single timeline across multiple contexts, they can
    either use implicit synchronization or a syncobj, both of which existed
    at the time this feature landed.  The justification given at the time
    was that it would help GL drivers which are inherently single-timeline.
    However, neither of our GL drivers actually wanted the feature.  i965
    was already in maintenance mode at the time and iris uses syncobj for
    everything.
    
    Unfortunately, as much as I'd love to get rid of it, it is used by the
    media driver so we can't do that.  We can, however, do the next-best
    thing which is to embed a syncobj in the context and do exactly what
    we'd expect from userspace internally.  This isn't an entirely identical
    implementation because it's no longer atomic if userspace races with
    itself by calling execbuffer2 twice simultaneously from different
    threads.  It won't crash in that case; it just doesn't guarantee any
    ordering between those two submits.  It also means that sync files
    exported from different engines on a SINGLE_TIMELINE context will have
    different fence contexts.  This is visible to userspace if it looks at
    the obj_name field of sync_fence_info.
    
    Moving SINGLE_TIMELINE to a syncobj emulation has a couple of technical
    advantages beyond mere annoyance.  One is that intel_timeline is no
    longer an api-visible object and can remain entirely an implementation
    detail.  This may be advantageous as we make scheduler changes going
    forward.  Second is that, together with deleting the CLONE_CONTEXT API,
    we should now have a 1:1 mapping between intel_context and
    intel_timeline which may help us reduce locking.
    
    v2 (Tvrtko Ursulin):
     - Update the comment on i915_gem_context::syncobj to mention that it's
       an emulation and the possible race if userspace calls execbuffer2
       twice on the same context concurrently.
    v2 (Jason Ekstrand):
     - Wrap the checks for eb.gem_context->syncobj in unlikely()
     - Drop the dma_fence reference
     - Improved commit message
    
    v3 (Jason Ekstrand):
     - Move the dma_fence_put() to before the error exit
    
    v4 (Tvrtko Ursulin):
     - Add a comment about fence contexts to the commit message
    Signed-off-by: default avatarJason Ekstrand <jason@jlekstrand.net>
    Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210708154835.528166-8-jason@jlekstrand.net
    00dae4d3
i915_gem_context.c 53.9 KB