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

Christian König <deathsimple@xxxxxxxxxxx> · Mon, 10 Jul 2017 18:15:38 +0200



    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.

    
            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
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel