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