From: Jason Ekstrand <jason@jlekstrand.net> To: Jacob Lifshay <programmerjake@gmail.com> Cc: Lucas Stach <dev@lynxeye.de>, 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>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Discussion of the development of and with GStreamer <gstreamer-devel@lists.freedesktop.org>, ML mesa-dev <mesa-dev@lists.freedesktop.org>, Nicolas Dufresne <nicolas@ndufresne.ca>, "open list:DMA BUFFER SHARING FRAMEWORK" <linux-media@vger.kernel.org> Subject: Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem Date: Tue, 17 Mar 2020 21:08:36 -0500 [thread overview] Message-ID: <CAOFGe94gmWZOA7sB0jDXoZyj=i1id25gR2-kX87GA+fB=AJ2RQ@mail.gmail.com> (raw) In-Reply-To: <CAC2bXD5+KwBXBo-qHWkGw+=cH_AytwS=jeDGbskXcmO0rfsREw@mail.gmail.com> On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay <programmerjake@gmail.com> wrote: > > On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach <dev@lynxeye.de> wrote: > > > > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay: > > > I think I found a userspace-accessible way to create sync_files and > > > dma_fences that would fulfill the requirements: > > > https://github.com/torvalds/linux/blob/master/drivers/dma-buf/sw_sync.c > > > > > > I'm just not sure if that's a good interface to use, since it appears > > > to be designed only for debugging. Will have to check for additional > > > requirements of signalling an error when the process that created the > > > fence is killed. It is expressly only for debugging and testing. Exposing such an API to userspace would break the finite time guarantees that are relied upon to keep sync_file a secure API. > > Something like that can certainly be lifted for general use if it makes > > sense. But then with a software renderer I don't really see how fences > > help you at all. With a software renderer you know exactly when the > > frame is finished and you can just defer pushing it over to the next > > pipeline element until that time. You won't gain any parallelism by > > using fences as the CPU is busy doing the rendering and will not run > > other stuff concurrently, right? > > There definitely may be other hardware and/or processes that can > process some stuff concurrently with the main application, such as the > compositor and or video encoding processes (for video capture). > Additionally, from what I understand, sync_file is the standard way to > export and import explicit synchronization between processes and > between drivers on Linux, so it seems like a good idea to support it > from an interoperability standpoint even if it turns out that there > aren't any scheduling/timing benefits. There are different ways that one can handle interoperability, however. One way is to try and make the software rasterizer look as much like a GPU as possible: lots of threads to make things as asynchronous as possible, "real" implementations of semaphores and fences, etc. Another is to let a SW rasterizer be a SW rasterizer: do everything immediately, thread only so you can exercise all the CPU cores, and minimally implement semaphores and fences well enough to maintain compatibility. If you take the first approach, then we have to solve all these problems with letting userspace create unsignaled sync_files which it will signal later and figure out how to make it safe. If you take the second approach, you'll only ever have to return already signaled sync_files and there's no problem with the sync_file finite time guarantees. --Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Ekstrand <jason@jlekstrand.net> To: Jacob Lifshay <programmerjake@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>, 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: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem Date: Tue, 17 Mar 2020 21:08:36 -0500 [thread overview] Message-ID: <CAOFGe94gmWZOA7sB0jDXoZyj=i1id25gR2-kX87GA+fB=AJ2RQ@mail.gmail.com> (raw) In-Reply-To: <CAC2bXD5+KwBXBo-qHWkGw+=cH_AytwS=jeDGbskXcmO0rfsREw@mail.gmail.com> On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay <programmerjake@gmail.com> wrote: > > On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach <dev@lynxeye.de> wrote: > > > > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay: > > > I think I found a userspace-accessible way to create sync_files and > > > dma_fences that would fulfill the requirements: > > > https://github.com/torvalds/linux/blob/master/drivers/dma-buf/sw_sync.c > > > > > > I'm just not sure if that's a good interface to use, since it appears > > > to be designed only for debugging. Will have to check for additional > > > requirements of signalling an error when the process that created the > > > fence is killed. It is expressly only for debugging and testing. Exposing such an API to userspace would break the finite time guarantees that are relied upon to keep sync_file a secure API. > > Something like that can certainly be lifted for general use if it makes > > sense. But then with a software renderer I don't really see how fences > > help you at all. With a software renderer you know exactly when the > > frame is finished and you can just defer pushing it over to the next > > pipeline element until that time. You won't gain any parallelism by > > using fences as the CPU is busy doing the rendering and will not run > > other stuff concurrently, right? > > There definitely may be other hardware and/or processes that can > process some stuff concurrently with the main application, such as the > compositor and or video encoding processes (for video capture). > Additionally, from what I understand, sync_file is the standard way to > export and import explicit synchronization between processes and > between drivers on Linux, so it seems like a good idea to support it > from an interoperability standpoint even if it turns out that there > aren't any scheduling/timing benefits. There are different ways that one can handle interoperability, however. One way is to try and make the software rasterizer look as much like a GPU as possible: lots of threads to make things as asynchronous as possible, "real" implementations of semaphores and fences, etc. Another is to let a SW rasterizer be a SW rasterizer: do everything immediately, thread only so you can exercise all the CPU cores, and minimally implement semaphores and fences well enough to maintain compatibility. If you take the first approach, then we have to solve all these problems with letting userspace create unsignaled sync_files which it will signal later and figure out how to make it safe. If you take the second approach, you'll only ever have to return already signaled sync_files and there's no problem with the sync_file finite time guarantees. --Jason _______________________________________________ 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-18 2:08 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 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 [this message] 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='CAOFGe94gmWZOA7sB0jDXoZyj=i1id25gR2-kX87GA+fB=AJ2RQ@mail.gmail.com' \ --to=jason@jlekstrand.net \ --cc=daniel.vetter@ffwll.ch \ --cc=dev@lynxeye.de \ --cc=dri-devel@lists.freedesktop.org \ --cc=gstreamer-devel@lists.freedesktop.org \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-media@vger.kernel.org \ --cc=mesa-dev@lists.freedesktop.org \ --cc=nicolas@ndufresne.ca \ --cc=programmerjake@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.