From: Daniel Vetter <daniel@ffwll.ch>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: Jason Ekstrand <jason@jlekstrand.net>,
Chenbo Feng <fengc@google.com>,
daniels@collabora.com, daniel.vetter@ffwll.ch,
jajones@nvidia.com, linux-kernel@vger.kernel.org,
Greg Hackmann <ghackmann@google.com>,
linaro-mm-sig@lists.linaro.org, hoegsberg@google.com,
dri-devel@lists.freedesktop.org, jessehall@google.com,
airlied@redhat.com, christian.koenig@amd.com,
linux-media@vger.kernel.org
Subject: Re: [PATCH 3/3] RFC: dma-buf: Add an API for importing and exporting sync files (v5)
Date: Wed, 30 Sep 2020 11:55:42 +0200 [thread overview]
Message-ID: <20200930095542.GY438822@phenom.ffwll.local> (raw)
In-Reply-To: <64eed158-22a8-10a7-7686-c972f8542649@daenzer.net>
On Wed, Sep 30, 2020 at 11:39:06AM +0200, Michel Dänzer wrote:
> On 2020-03-17 10:21 p.m., Jason Ekstrand wrote:
> > Explicit synchronization is the future. At least, that seems to be what
> > most userspace APIs are agreeing on at this point. However, most of our
> > Linux APIs (both userspace and kernel UAPI) are currently built around
> > implicit synchronization with dma-buf. While work is ongoing to change
> > many of the userspace APIs and protocols to an explicit synchronization
> > model, switching over piecemeal is difficult due to the number of
> > potential components involved. On the kernel side, many drivers use
> > dma-buf including GPU (3D/compute), display, v4l, and others. In
> > userspace, we have X11, several Wayland compositors, 3D drivers, compute
> > drivers (OpenCL etc.), media encode/decode, and the list goes on.
> >
> > This patch provides a path forward by allowing userspace to manually
> > manage the fences attached to a dma-buf. Alternatively, one can think
> > of this as making dma-buf's implicit synchronization simply a carrier
> > for an explicit fence. This is accomplished by adding two IOCTLs to
> > dma-buf for importing and exporting a sync file to/from the dma-buf.
> > This way a userspace component which is uses explicit synchronization,
> > such as a Vulkan driver, can manually set the write fence on a buffer
> > before handing it off to an implicitly synchronized component such as a
> > Wayland compositor or video encoder. In this way, each of the different
> > components can be upgraded to an explicit synchronization model one at a
> > time as long as the userspace pieces connecting them are aware of it and
> > import/export fences at the right times.
> >
> > There is a potential race condition with this API if userspace is not
> > careful. A typical use case for implicit synchronization is to wait for
> > the dma-buf to be ready, use it, and then signal it for some other
> > component. Because a sync_file cannot be created until it is guaranteed
> > to complete in finite time, userspace can only signal the dma-buf after
> > it has already submitted the work which uses it to the kernel and has
> > received a sync_file back. There is no way to atomically submit a
> > wait-use-signal operation. This is not, however, really a problem with
> > this API so much as it is a problem with explicit synchronization
> > itself. The way this is typically handled is to have very explicit
> > ownership transfer points in the API or protocol which ensure that only
> > one component is using it at any given time. Both X11 (via the PRESENT
> > extension) and Wayland provide such ownership transfer points via
> > explicit present and idle messages.
> >
> > The decision was intentionally made in this patch to make the import and
> > export operations IOCTLs on the dma-buf itself rather than as a DRM
> > IOCTL. This makes it the import/export operation universal across all
> > components which use dma-buf including GPU, display, v4l, and others.
> > It also means that a userspace component can do the import/export
> > without access to the DRM fd which may be tricky to get in cases where
> > the client communicates with DRM via a userspace API such as OpenGL or
> > Vulkan. At a future date we may choose to add direct import/export APIs
> > to components such as drm_syncobj to avoid allocating a file descriptor
> > and going through two ioctls. However, that seems to be something of a
> > micro-optimization as import/export operations are likely to happen at a
> > rate of a few per frame of rendered or decoded video.
> >
> > v2 (Jason Ekstrand):
> > - Use a wrapper dma_fence_array of all fences including the new one
> > when importing an exclusive fence.
> >
> > v3 (Jason Ekstrand):
> > - Lock around setting shared fences as well as exclusive
> > - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
> > - Initialize ret to 0 in dma_buf_wait_sync_file
> >
> > v4 (Jason Ekstrand):
> > - Use the new dma_resv_get_singleton helper
> >
> > v5 (Jason Ekstrand):
> > - Rename the IOCTLs to import/export rather than wait/signal
> > - Drop the WRITE flag and always get/set the exclusive fence
> >
> > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
>
> What's the status of this? DMA_BUF_IOCTL_EXPORT_SYNC_FILE would be useful
> for Wayland compositors to wait for client buffers to become ready without
> being prone to getting delayed by later HW access to them, so it would be
> nice to merge that at least (if DMA_BUF_IOCTL_IMPORT_SYNC_FILE is still
> controversial).
I think the missing bits are just the usual stuff
- igt testcases
- userspace using the new ioctls
- review of the entire pile
I don't think there's any fundamental objections aside from "no one ever
pushed this over the finish line".
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2020-09-30 9:55 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-25 23:58 [PATCH] RFC: dma-buf: Add an API for importing and exporting sync files Jason Ekstrand
2020-02-26 9:16 ` Christian König
2020-02-26 10:05 ` Daniel Vetter
2020-02-26 15:28 ` Jason Ekstrand
2020-02-26 16:46 ` Bas Nieuwenhuizen
2020-02-27 8:28 ` Christian König
2020-03-03 19:10 ` Jason Ekstrand
2020-03-04 8:34 ` Christian König
2020-03-04 16:27 ` Jason Ekstrand
2020-03-04 16:41 ` Jason Ekstrand
2020-03-05 13:06 ` Christian König
2020-03-05 15:54 ` Jason Ekstrand
2020-03-09 16:21 ` Christian König
2020-03-11 3:43 ` Jason Ekstrand
2020-02-26 18:09 ` [PATCH] RFC: dma-buf: Add an API for importing and exporting sync files (v2) Jason Ekstrand
2020-03-03 19:03 ` [PATCH] RFC: dma-buf: Add an API for importing and exporting sync files (v3) Jason Ekstrand
2020-03-03 19:05 ` Jason Ekstrand
2020-03-11 3:43 ` [PATCH 1/3] dma-buf: add dma_fence_array_for_each (v2) Jason Ekstrand
2020-03-11 3:43 ` Jason Ekstrand
2020-03-11 3:43 ` [PATCH 2/3] dma-buf: add dma_resv_get_singleton (v2) Jason Ekstrand
2020-03-11 3:43 ` Jason Ekstrand
2020-03-11 3:43 ` [PATCH 3/3] RFC: dma-buf: Add an API for importing and exporting sync files (v4) Jason Ekstrand
2020-03-11 3:43 ` Jason Ekstrand
2020-03-11 13:18 ` Christian König
2020-03-12 15:57 ` Jason Ekstrand
2020-03-13 10:33 ` Christian König
2020-03-17 21:21 ` [PATCH 3/3] RFC: dma-buf: Add an API for importing and exporting sync files (v5) Jason Ekstrand
2020-09-30 9:39 ` Michel Dänzer
2020-09-30 9:55 ` Daniel Vetter [this message]
2021-03-15 21:11 ` Jason Ekstrand
2021-03-15 21:30 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200930095542.GY438822@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@redhat.com \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniels@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=fengc@google.com \
--cc=ghackmann@google.com \
--cc=hoegsberg@google.com \
--cc=jajones@nvidia.com \
--cc=jason@jlekstrand.net \
--cc=jessehall@google.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=michel@daenzer.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).