[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