Am 11.07.2017 um 17:43 schrieb Jason Ekstrand: > On Tue, Jul 11, 2017 at 12:17 AM, Christian König > <deathsimple at vodafone.de <mailto:deathsimple at vodafone.de>> wrote: > > [SNIP] > > If we ever want to share fences across processes > (which we do), > then this needs to be sorted in the kernel. > > That would clearly get a NAK from my side, even > Microsoft forbids > wait before signal because you can easily end up in > deadlock situations. > > Please don't NAK things that are required by the API > specification and > CTS tests. > > There is no requirement for every aspect of the Vulkan API > specification > to be mirrored 1:1 in the kernel <-> userspace API. We have to > work out > what makes sense at each level. > > > Exactly, if we have a synchronization problem between two > processes that should be solved in userspace. > > E.g. if process A hasn't submitted it's work to the kernel it > should flush it's commands before sending a flip event to the > compositor. > > > Ok, I think there is some confusion here on what is being proposed. > Here are some things that are *not* being proposed: > > 1. This does *not* allow a client to block another client's GPU work > indefinitely. This is entirely for a CPU wait API to allow for a > "wait for submit" as well as a "wait for finish". Yeah, that is a rather good point. > 2. This is *not* for system compositors that need to be robust > against malicious clients. I can see the point, but I think the kernel interface should still be idiot prove even in the unlikely case the universe suddenly stops to produce idiots. > The expected use for the OPAQUE_FD is two very tightly integrated > processes which trust each other but need to be able to share > synchronization primitives. Well, that raises a really important question: What is the actual use case for this if not communication between client and compositor? > Could we do this "in userspace"? Yes, with added kernel API. we > would need some way of strapping a second FD onto a syncobj or > combining two FDs into one to send across the wire or something like > that, then add a shared memory segment, and then pile on a bunch of > code to do cross-process condition variables and state tracking. I > really don't see how that's a better solution than adding a flag to > the kernel API to just do what we want. Way to complicated. My thinking was rather to optionally allow a single page to be mmap()ed into the process address space from the fd and then put a futex, pthread_cond or X shared memory fence or anything like that into it. Regards, Christian. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170712/57c2d9c4/attachment-0001.html>
