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

["Michel Dänzer" <michel@daenzer.net>]

On 11/07/17 06:09 AM, Jason Ekstrand wrote:
> On Mon, Jul 10, 2017 at 9:15 AM, Christian König
> <deathsimple@vodafone.de <mailto:deathsimple@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@vodafone.de <mailto:deathsimple@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@gmail.com <mailto:airlied@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?


>>     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.


> That makes it very hard for people like me to get their jobs done. :-)

Jason, that's uncalled for. Christian is also just doing his job here.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel