[PATCH 0/4] dma-buf: Add an API for exporting sync files (v8)

[Jason Ekstrand]

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 at jlekstrand.net> 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 at amd.com>
> Cc: Michel Dänzer <michel at daenzer.net>
> Cc: Dave Airlie <airlied at redhat.com>
> Cc: Bas Nieuwenhuizen <bas at basnieuwenhuizen.nl>
> Cc: Daniel Stone <daniels at collabora.com>
>
> 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
>