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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
