Am 11.07.2017 um 04:36 schrieb Michel Dänzer: > On 11/07/17 06:09 AM, Jason Ekstrand wrote: >> On Mon, Jul 10, 2017 at 9:15 AM, Christian König >> <deathsimple at vodafone.de <mailto:deathsimple at vodafone.de>> wrote: >> >> 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 >>> <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. >> >> >> Which doesn't work cross-process so... > Surely it can be made to work by providing suitable kernel APIs to > userspace? Well, that's exactly what Jason proposed to do, but I'm not very keen of that. >>> 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. We can attach something to the fd making it possible for an X shared memory fence to be transported with it if that makes live easier. This way the waiter implementation can still chose what to do and/or wait async for the client to have it's flushes completed etc... Regards, Christian.
