[Intel-gfx] [PATCH v2 0/2] drm/i915: timeline semaphore support

Chris Wilson chris at chris-wilson.co.uk
Thu Jun 27 10:43:19 UTC 2019


Quoting Lionel Landwerlin (2019-06-27 11:39:24)
> On 27/06/2019 13:21, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-06-27 09:03:37)
> >> Hi,
> >>
> >> This revision gets rid of the synchronous wait. We now implement the
> >> synchronous wait as part of the userspace driver. A thread is spawned
> >> for each engine and waits for availability of the syncobjs before
> >> calling into execbuffer.
> > Why would you do that? It's not like the kernel already has the ability
> > to serialises execution asynchronously...
> > -Chris
> >
> Maybe I didn't express myself well.
> 
> There is a requirement from the Vulkan spec that we should be able to 
> queue a workload depending on fences that haven't materialized yet.
> 
> 
> The last revision implemented that in the i915 by blocking in the 
> execbuffer until the input fences had all materialized.

My point was that the syncobj seqno itself could be expressed as a proxy
fence that was replaced with the real fence later. (And that we
previously had code to do exactly that :( i915 would listen to the
proxy fence for its scheduling and so be signaled by the right fence
when it was known. That will be a few orders of magnitude lower latency,
more if we can optimise away the irq by knowing the proxy fence ahead of
time.
-Chris


More information about the Intel-gfx mailing list