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

Christian König deathsimple at vodafone.de
Mon Jul 10 16:15:38 UTC 2017


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>


More information about the amd-gfx mailing list