From: Daniel Stone <daniel@fooishbar.org> To: Tomek Bury <tomek.bury@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Nicolas Dufresne <nicolas@ndufresne.ca>, Daniel Vetter <daniel.vetter@ffwll.ch>, xorg-devel <xorg-devel@lists.x.org>, Maling list - DRI developers <dri-devel@lists.freedesktop.org>, "wayland-devel @ lists . freedesktop . org" <wayland-devel@lists.freedesktop.org>, Discussion of the development of and with GStreamer <gstreamer-devel@lists.freedesktop.org>, Jason Ekstrand <jason@jlekstrand.net>, Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>, ML mesa-dev <mesa-dev@lists.freedesktop.org>, Dave Airlie <airlied@gmail.com>, "open list:DMA BUFFER SHARING FRAMEWORK" <linux-media@vger.kernel.org> Subject: Re: Plumbing explicit synchronization through the Linux ecosystem Date: Mon, 16 Mar 2020 16:04:32 +0000 [thread overview] Message-ID: <CAPj87rM-kmKH6yJZE5vbiQv3KTKXsywe88Na6sGm+Guew++ZfA@mail.gmail.com> (raw) In-Reply-To: <CAO1ALzmghMQo31noEBW_0gVzJp=BZrNaNtXE+86TR0hR86Y1Jw@mail.gmail.com> Hi, On Mon, 16 Mar 2020 at 15:33, Tomek Bury <tomek.bury@gmail.com> wrote: > > GL and GLES are not relevant. What is relevant is EGL, which defines > > interfaces to make things work on the native platform. > Yes and no. This is what EGL spec says about sharing a texture between contexts: Contexts are different though ... > There are similar statements with regards to the lack of > synchronisation guarantees for EGL images or between GL and native > rendering, etc. This also isn't about native rendering. > But the main thing here is that EGL and Vulkan differ > significantly. Sure, I totally agree. > The eglSwapBuffers() is expected to post an unspecified > "back buffer" to the display system using some internal driver magic. > EGL driver is then expected to obtain another back buffer at some > unspecified point in the future. Yes, this is rather the point: EGL doesn't specify platform-related 'black magic' to make things just work, because that's part of the platform implementation details. And, as things stand, on Linux one of those things is implicit synchronisation, unless the desired end state of your driver is no synchronisation. This thread is a discussion about changing that. > > If you are using EGL_WL_bind_wayland_display, then one of the things > > it is explicitly allowed/expected to do is to create a Wayland > > protocol interface between client and compositor, which can be used to > > pass buffer handles and metadata in a platform-specific way. Adding > > synchronisation is also possible. > Only one-way synchronisation is possible with this mechanism. There's > a standard protocol for recycling buffers - wl_buffer_release() so > buffer hand-over from the compositor to client remains unsynchronised > - see below. That's not true; you can post back a sync token every time the client buffer is used by the compositor. > > > The most troublesome part was Wayland buffer release mechanism, as it only involves a CPU signalling over Wayland IPC, without any 3D driver involvement. The choices were: explicit synchronisation extension or a buffer copy in the compositor (i.e. compositor textures from the copy, so the client can re-write the original), or some implicit synchronisation in kernel space (but that wasn't an option in Broadcom driver). > > > > You can add your own explicit synchronisation extension. > I could but that requires implementing in in the driver and in a > number of compositors, therefore a standard extension > zwp_linux_explicit_synchronization_v1 is much better choice here than > a custom one. EGL_WL_bind_wayland_display is explicitly designed to allow each driver to implement its own private extensions without modifying compositors. For instance, Mesa adds the `wl_drm` extension, which is used for bidirectional communication between the EGL implementations in the client and compositor address spaces, without modifying either. > > In every cross-process and cross-subsystem usecase, synchronisation is > > obviously required. The two options for this are to implement kernel > > support for implicit synchronisation (as everyone else has done), > That would require major changes in driver architecture or a 2nd > mechanisms doing the same thing but in kernel space - both are > non-starters. OK. As it stands, everyone else has the kernel mechanism (e.g. via dmabuf resv), so in this case if you are reinventing the underlying platform in a proprietary stack, you get to solve the same problems yourselves. Cheers, Daniel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Stone <daniel@fooishbar.org> To: Tomek Bury <tomek.bury@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, xorg-devel <xorg-devel@lists.x.org>, "open list:DMA BUFFER SHARING FRAMEWORK" <linux-media@vger.kernel.org>, Maling list - DRI developers <dri-devel@lists.freedesktop.org>, "wayland-devel @ lists . freedesktop . org" <wayland-devel@lists.freedesktop.org>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Jason Ekstrand <jason@jlekstrand.net>, ML mesa-dev <mesa-dev@lists.freedesktop.org>, Nicolas Dufresne <nicolas@ndufresne.ca>, Discussion of the development of and with GStreamer <gstreamer-devel@lists.freedesktop.org> Subject: Re: Plumbing explicit synchronization through the Linux ecosystem Date: Mon, 16 Mar 2020 16:04:32 +0000 [thread overview] Message-ID: <CAPj87rM-kmKH6yJZE5vbiQv3KTKXsywe88Na6sGm+Guew++ZfA@mail.gmail.com> (raw) In-Reply-To: <CAO1ALzmghMQo31noEBW_0gVzJp=BZrNaNtXE+86TR0hR86Y1Jw@mail.gmail.com> Hi, On Mon, 16 Mar 2020 at 15:33, Tomek Bury <tomek.bury@gmail.com> wrote: > > GL and GLES are not relevant. What is relevant is EGL, which defines > > interfaces to make things work on the native platform. > Yes and no. This is what EGL spec says about sharing a texture between contexts: Contexts are different though ... > There are similar statements with regards to the lack of > synchronisation guarantees for EGL images or between GL and native > rendering, etc. This also isn't about native rendering. > But the main thing here is that EGL and Vulkan differ > significantly. Sure, I totally agree. > The eglSwapBuffers() is expected to post an unspecified > "back buffer" to the display system using some internal driver magic. > EGL driver is then expected to obtain another back buffer at some > unspecified point in the future. Yes, this is rather the point: EGL doesn't specify platform-related 'black magic' to make things just work, because that's part of the platform implementation details. And, as things stand, on Linux one of those things is implicit synchronisation, unless the desired end state of your driver is no synchronisation. This thread is a discussion about changing that. > > If you are using EGL_WL_bind_wayland_display, then one of the things > > it is explicitly allowed/expected to do is to create a Wayland > > protocol interface between client and compositor, which can be used to > > pass buffer handles and metadata in a platform-specific way. Adding > > synchronisation is also possible. > Only one-way synchronisation is possible with this mechanism. There's > a standard protocol for recycling buffers - wl_buffer_release() so > buffer hand-over from the compositor to client remains unsynchronised > - see below. That's not true; you can post back a sync token every time the client buffer is used by the compositor. > > > The most troublesome part was Wayland buffer release mechanism, as it only involves a CPU signalling over Wayland IPC, without any 3D driver involvement. The choices were: explicit synchronisation extension or a buffer copy in the compositor (i.e. compositor textures from the copy, so the client can re-write the original), or some implicit synchronisation in kernel space (but that wasn't an option in Broadcom driver). > > > > You can add your own explicit synchronisation extension. > I could but that requires implementing in in the driver and in a > number of compositors, therefore a standard extension > zwp_linux_explicit_synchronization_v1 is much better choice here than > a custom one. EGL_WL_bind_wayland_display is explicitly designed to allow each driver to implement its own private extensions without modifying compositors. For instance, Mesa adds the `wl_drm` extension, which is used for bidirectional communication between the EGL implementations in the client and compositor address spaces, without modifying either. > > In every cross-process and cross-subsystem usecase, synchronisation is > > obviously required. The two options for this are to implement kernel > > support for implicit synchronisation (as everyone else has done), > That would require major changes in driver architecture or a 2nd > mechanisms doing the same thing but in kernel space - both are > non-starters. OK. As it stands, everyone else has the kernel mechanism (e.g. via dmabuf resv), so in this case if you are reinventing the underlying platform in a proprietary stack, you get to solve the same problems yourselves. Cheers, Daniel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-03-16 16:05 UTC|newest] Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-11 17:31 Plumbing explicit synchronization through the Linux ecosystem Jason Ekstrand 2020-03-11 17:31 ` Jason Ekstrand 2020-03-11 19:21 ` Jason Ekstrand 2020-03-11 19:21 ` Jason Ekstrand 2020-03-11 20:18 ` Nicolas Dufresne 2020-03-11 20:18 ` Nicolas Dufresne 2020-03-16 10:20 ` Laurent Pinchart 2020-03-16 10:20 ` Laurent Pinchart 2020-03-16 12:55 ` Tomek Bury 2020-03-16 13:01 ` Laurent Pinchart 2020-03-16 13:01 ` Laurent Pinchart 2020-03-16 13:34 ` Tomek Bury 2020-03-16 13:34 ` Tomek Bury 2020-03-16 14:19 ` Daniel Stone 2020-03-16 14:19 ` Daniel Stone 2020-03-16 15:33 ` Tomek Bury 2020-03-16 15:33 ` Tomek Bury 2020-03-16 16:03 ` Tomek Bury 2020-03-16 16:03 ` Tomek Bury 2020-03-16 16:04 ` Jason Ekstrand 2020-03-16 16:04 ` Jason Ekstrand 2020-03-17 8:01 ` Simon Ser 2020-03-17 8:01 ` Simon Ser 2020-03-17 14:38 ` Jason Ekstrand 2020-03-17 14:38 ` Jason Ekstrand 2020-03-16 16:04 ` Daniel Stone [this message] 2020-03-16 16:04 ` Daniel Stone 2020-03-16 17:11 ` Tomek Bury 2020-03-16 17:11 ` Tomek Bury 2020-03-16 15:06 ` Jason Ekstrand 2020-03-16 15:06 ` Jason Ekstrand 2020-03-16 21:15 ` Laurent Pinchart 2020-03-16 21:15 ` Laurent Pinchart 2020-03-16 22:02 ` Jason Ekstrand 2020-03-16 22:02 ` Jason Ekstrand 2020-03-17 15:33 ` Nicolas Dufresne 2020-03-17 15:33 ` Nicolas Dufresne 2020-03-17 16:27 ` Jason Ekstrand 2020-03-17 16:27 ` Jason Ekstrand 2020-03-17 17:12 ` [Mesa-dev] " Jacob Lifshay 2020-03-17 17:12 ` Jacob Lifshay 2020-03-17 17:18 ` Jason Ekstrand 2020-03-17 17:18 ` Jason Ekstrand 2020-03-19 10:34 ` Daniel Vetter 2020-03-19 10:34 ` Daniel Vetter 2020-03-17 17:21 ` Lucas Stach 2020-03-17 17:21 ` Lucas Stach 2020-03-17 17:59 ` Jacob Lifshay 2020-03-17 17:59 ` Jacob Lifshay 2020-03-17 18:14 ` Lucas Stach 2020-03-17 18:14 ` Lucas Stach 2020-03-18 0:16 ` Jacob Lifshay 2020-03-18 0:16 ` Jacob Lifshay 2020-03-18 2:08 ` Jason Ekstrand 2020-03-18 2:08 ` Jason Ekstrand 2020-03-18 5:20 ` Jacob Lifshay 2020-03-18 5:20 ` Jacob Lifshay 2020-03-18 6:34 ` Jason Ekstrand 2020-03-18 6:34 ` Jason Ekstrand 2020-03-18 7:27 ` Jacob Lifshay 2020-03-18 7:27 ` Jacob Lifshay 2020-03-18 10:05 ` Michel Dänzer 2020-03-18 10:05 ` Michel Dänzer 2020-03-18 13:54 ` Nicolas Dufresne 2020-03-18 13:54 ` Nicolas Dufresne 2020-03-19 10:37 ` Daniel Vetter 2020-03-19 10:37 ` Daniel Vetter 2020-03-19 15:45 ` Adam Jackson 2020-03-19 15:45 ` Adam Jackson 2020-03-17 18:21 ` Nicolas Dufresne 2020-03-17 18:21 ` Nicolas Dufresne 2020-03-19 10:42 ` Daniel Vetter 2020-03-19 10:42 ` Daniel Vetter 2020-03-17 17:34 ` [Mesa-dev] " Lucas Stach 2020-03-17 17:34 ` Lucas Stach 2020-03-16 23:41 ` Roman Gilg 2020-03-16 23:41 ` Roman Gilg 2020-03-17 3:37 ` Jason Ekstrand 2020-03-17 3:37 ` Jason Ekstrand 2020-03-17 7:53 ` Jonas Ådahl 2020-03-17 7:53 ` Jonas Ådahl 2020-03-11 23:02 ` Adam Jackson 2020-03-11 23:02 ` Adam Jackson 2020-03-12 15:46 ` Jason Ekstrand 2020-03-12 15:46 ` Jason Ekstrand 2020-03-13 1:37 ` Alexander E. Patrakov 2020-03-13 1:37 ` Alexander E. Patrakov 2020-03-14 2:02 ` [Mesa-dev] " Marek Olšák 2020-03-16 2:49 ` Jason Ekstrand 2020-03-16 3:50 ` Marek Olšák 2020-03-16 9:57 ` Michel Dänzer 2020-03-16 9:57 ` Michel Dänzer 2020-03-16 18:33 ` Marek Olšák 2020-03-17 10:01 ` Michel Dänzer 2020-03-17 10:01 ` Michel Dänzer 2020-03-17 17:13 ` Marek Olšák 2020-03-19 10:51 ` Daniel Vetter 2020-03-19 10:51 ` Daniel Vetter 2020-03-19 19:54 ` Marek Olšák 2020-03-20 8:50 ` Michel Dänzer 2020-03-20 8:50 ` Michel Dänzer
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=CAPj87rM-kmKH6yJZE5vbiQv3KTKXsywe88Na6sGm+Guew++ZfA@mail.gmail.com \ --to=daniel@fooishbar.org \ --cc=airlied@gmail.com \ --cc=bas@basnieuwenhuizen.nl \ --cc=daniel.vetter@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=gstreamer-devel@lists.freedesktop.org \ --cc=jason@jlekstrand.net \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-media@vger.kernel.org \ --cc=mesa-dev@lists.freedesktop.org \ --cc=nicolas@ndufresne.ca \ --cc=tomek.bury@gmail.com \ --cc=wayland-devel@lists.freedesktop.org \ --cc=xorg-devel@lists.x.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.