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

Jason Ekstrand <jason@xxxxxxxxxxxxxx> · Mon, 10 Jul 2017 14:09:42 -0700

On Mon, Jul 10, 2017 at 9:15 AM, Christian König <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>
            wrote:

                    Am
                      10.07.2017 um 17:28 schrieb Jason Ekstrand:

                          On Wed, Jul 5, 2017
                            at 6:04 PM, Dave Airlie <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

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

            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.  That makes it very hard for people like me to get their jobs done. :-)

Now, as for whether or not it's a good idea.  First off, we do have timeouts an a status querying mechanism so an application can just set a timeout of 1s and do something if it times out.  Second, if the application is a compositor or something else that doesn't trust its client, it shouldn't be using the OPAQUE_FD mechanism of Vulkan semaphore/fence sharing anyway.  For those scenarios, they can require the untrusted client to use FENCE_FD (sync file) and they have all of the usual guarantees about when the work got submitted, etc.

Also, I'm more than happy to put this all behind a flag so it's not the default behavior.

--Jason

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel