Am 10.07.2017 um 17:52 schrieb Jason Ekstrand: > On Mon, Jul 10, 2017 at 8:45 AM, Christian König > <deathsimple at vodafone.de <mailto:deathsimple at vodafone.de>> wrote: > > Am 10.07.2017 um 17:28 schrieb Jason Ekstrand: >> On Wed, Jul 5, 2017 at 6:04 PM, Dave Airlie <airlied at gmail.com >> <mailto:airlied at gmail.com>> wrote: >> [SNIP] >> So, reading some CTS tests again, and I think we have a problem >> here. The Vulkan spec allows you to wait on a fence that is in >> the unsignaled state. > > At least on the closed source driver that would be illegal as far > as I know. > > > Then they are doing workarounds in userspace. There are definitely > CTS tests for this: > > https://github.com/KhronosGroup/VK-GL-CTS/blob/master/external/vulkancts/modules/vulkan/synchronization/vktSynchronizationBasicFenceTests.cpp#L74 > > You can't wait on a semaphore before the signal operation is send > down to the kerel. > > > We (Intel) deal with this today by tracking whether or not the fence > has been submitted and using a condition variable in userspace to sort > it all out. Which sounds exactly like what AMD is doing in it's drivers as well. > 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. Regards, Christian. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170710/4334a7c0/attachment.html>
