[PATCH] drm/syncobj: add sync obj wait interface. (v6)

[Christian König]

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.