Am 10.07.2017 um 17:52 schrieb Jason Ekstrand:
On Mon, Jul 10, 2017 at 8:45 AM, Christian König
<[email protected] <mailto:[email protected]>> wrote:
Am 10.07.2017 um 17:28 schrieb Jason Ekstrand:
On Wed, Jul 5, 2017 at 6:04 PM, Dave Airlie <[email protected]
<mailto:[email protected]>> 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.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
