<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 11, 2017 at 12:17 AM, Christian König <span dir="ltr"><<a href="mailto:deathsimple@vodafone.de" target="_blank">deathsimple@vodafone.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Am 11.07.2017 um 04:36 schrieb Michel Dänzer:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 11/07/17 06:09 AM, Jason Ekstrand wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Mon, Jul 10, 2017 at 9:15 AM, Christian König<br> <<a href="mailto:deathsimple@vodafone.de" target="_blank">deathsimple@vodafone.de</a> <mailto:<a href="mailto:deathsimple@vodafone.de" target="_blank">deathsimple@vodafone.d<wbr>e</a>>> wrote:<br> <br> Am 10.07.2017 um 17:52 schrieb Jason Ekstrand:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Mon, Jul 10, 2017 at 8:45 AM, Christian König<br> <<a href="mailto:deathsimple@vodafone.de" target="_blank">deathsimple@vodafone.de</a> <mailto:<a href="mailto:deathsimple@vodafone.de" target="_blank">deathsimple@vodafone.d<wbr>e</a>>> wrote:<br> <br> Am 10.07.2017 um 17:28 schrieb Jason Ekstrand:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Wed, Jul 5, 2017 at 6:04 PM, Dave Airlie<br> <<a href="mailto:airlied@gmail.com" target="_blank">airlied@gmail.com</a> <mailto:<a href="mailto:airlied@gmail.com" target="_blank">airlied@gmail.com</a>>> wrote:<br> [SNIP]<br> So, reading some CTS tests again, and I think we have a<br> problem here. The Vulkan spec allows you to wait on a fence<br> that is in the unsignaled state.<br> </blockquote> At least on the closed source driver that would be illegal as<br> far as I know.<br> <br> <br> Then they are doing workarounds in userspace. There are<br> definitely CTS tests for this:<br> <br> <a href="https://github.com/KhronosGroup/VK-GL-CTS/blob/master/external/vulkancts/modules/vulkan/synchronization/vktSynchronizationBasicFenceTests.cpp#L74" rel="noreferrer" target="_blank">https://github.com/KhronosGro<wbr>up/VK-GL-CTS/blob/master/<wbr>external/vulkancts/modules/<wbr>vulkan/synchronization/vktSync<wbr>hronizationBasicFenceTests.<wbr>cpp#L74</a><br> <<a href="https://github.com/KhronosGroup/VK-GL-CTS/blob/master/external/vulkancts/modules/vulkan/synchronization/vktSynchronizationBasicFenceTests.cpp#L74" rel="noreferrer" target="_blank">https://github.com/KhronosGr<wbr>oup/VK-GL-CTS/blob/master/<wbr>external/vulkancts/modules/<wbr>vulkan/synchronization/vktSync<wbr>hronizationBasicFenceTests.<wbr>cpp#L74</a>><br> <br> You can't wait on a semaphore before the signal operation is<br> send down to the kerel.<br> <br> <br> We (Intel) deal with this today by tracking whether or not the<br> fence has been submitted and using a condition variable in<br> userspace to sort it all out.<br> </blockquote> Which sounds exactly like what AMD is doing in it's drivers as well.<br> <br> <br> Which doesn't work cross-process so...<br> </blockquote> Surely it can be made to work by providing suitable kernel APIs to<br> userspace?<br> </blockquote> <br></div></div> Well, that's exactly what Jason proposed to do, but I'm not very keen of that.<span class=""><br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If we ever want to share fences across processes (which we do),<br> then this needs to be sorted in the kernel.<br> </blockquote> That would clearly get a NAK from my side, even Microsoft forbids<br> wait before signal because you can easily end up in deadlock situations.<br> <br> Please don't NAK things that are required by the API specification and<br> CTS tests.<br> </blockquote> There is no requirement for every aspect of the Vulkan API specification<br> to be mirrored 1:1 in the kernel <-> userspace API. We have to work out<br> what makes sense at each level.<br> </blockquote> <br></span> Exactly, if we have a synchronization problem between two processes that should be solved in userspace.<br> <br> 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.<br> </blockquote></div><br></div><div class="gmail_extra">Ok, I think there is some confusion here on what is being proposed. Here are some things that are *not* being proposed:<br><br></div><div class="gmail_extra"> 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".<br></div><div class="gmail_extra"> 2. This is *not* for system compositors that need to be robust against malicious clients.<br><br></div><div class="gmail_extra">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. One of the things they need to be able to do (as per the Vulkan API) with those synchronization primitives is a "wait for submit and finish" operation. I'm happy for the kernel to have separate APIs for "wait for submit" and "wait for finish" if that's more palatable but i don't really see why there is such a strong reaction to the "wait for submit and finish" behavior.<br><br></div><div class="gmail_extra">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.<br></div></div>