IGT: https://patchwork.freedesktop.org/series/90433/ Mesa (Vulkan WSI): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037 Ideally, it'd be nice to see a RADV MR and maybe even radeonsi before we really land on it. However, I think it's proved out well enough in ANV to at least land the first three. --Jason On Thu, May 20, 2021 at 2:00 PM Jason Ekstrand <jason@xxxxxxxxxxxxxx> wrote: > > This is mostly a re-send of v8 only with a fourth patch which contains the > sync file import ioctl that I had in the original series. I've not updated > the IGT tests yet for sync file import. This resend is mostly intended to > aid in discussions around implicit sync in general. I'll write up some IGT > tests if there is serious interest in patch 4. I can also update the Mesa > MR to use it for Vulkan. > > ------------------------------------------- > > Modern userspace APIs like Vulkan are built on an explicit > synchronization model. This doesn't always play nicely with the > implicit synchronization used in the kernel and assumed by X11 and > Wayland. The client -> compositor half of the synchronization isn't too > bad, at least on intel, because we can control whether or not i915 > synchronizes on the buffer and whether or not it's considered written. > > The harder part is the compositor -> client synchronization when we get > the buffer back from the compositor. We're required to be able to > provide the client with a VkSemaphore and VkFence representing the point > in time where the window system (compositor and/or display) finished > using the buffer. With current APIs, it's very hard to do this in such > a way that we don't get confused by the Vulkan driver's access of the > buffer. In particular, once we tell the kernel that we're rendering to > the buffer again, any CPU waits on the buffer or GPU dependencies will > wait on some of the client rendering and not just the compositor. > > This new IOCTL solves this problem by allowing us to get a snapshot of > the implicit synchronization state of a given dma-buf in the form of a > sync file. It's effectively the same as a poll() or I915_GEM_WAIT only, > instead of CPU waiting directly, it encapsulates the wait operation, at > the current moment in time, in a sync_file so we can check/wait on it > later. As long as the Vulkan driver does the sync_file export from the > dma-buf before we re-introduce it for rendering, it will only contain > fences from the compositor or display. This allows to accurately turn > it into a VkFence or VkSemaphore without any over- synchronization. > > Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037 > IGT tests: https://lists.freedesktop.org/archives/igt-dev/2021-March/029825.html > > Cc: Christian König <christian.koenig@xxxxxxx> > Cc: Michel Dänzer <michel@xxxxxxxxxxx> > Cc: Dave Airlie <airlied@xxxxxxxxxx> > Cc: Bas Nieuwenhuizen <bas@xxxxxxxxxxxxxxxxxxx> > Cc: Daniel Stone <daniels@xxxxxxxxxxxxx> > > Christian König (1): > dma-buf: add dma_fence_array_for_each (v2) > > Jason Ekstrand (3): > dma-buf: add dma_resv_get_singleton_rcu (v4) > dma-buf: Add an API for exporting sync files (v9) > RFC: dma-buf: Add an API for importing sync files (v6) > > drivers/dma-buf/dma-buf.c | 94 +++++++++++++++++++++++ > drivers/dma-buf/dma-fence-array.c | 27 +++++++ > drivers/dma-buf/dma-resv.c | 122 ++++++++++++++++++++++++++++++ > include/linux/dma-fence-array.h | 17 +++++ > include/linux/dma-resv.h | 3 + > include/uapi/linux/dma-buf.h | 25 ++++++ > 6 files changed, 288 insertions(+) > > -- > 2.31.1 >
