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

Christian König <deathsimple@xxxxxxxxxxx> · Wed, 12 Jul 2017 09:39:25 +0200



    Am 11.07.2017 um 17:43 schrieb Jason
      Ekstrand:

    
          On Tue, Jul 11, 2017 at 12:17 AM,
            Christian König <deathsimple@xxxxxxxxxxx>
            wrote:

            [SNIP]

                
                           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.

            
        Ok, I think there is some confusion
          here on what is being proposed.  Here are some things that are
          *not* being proposed:

          
         1. This does *not* allow a client to
          block another client's GPU work indefinitely.  This is
          entirely for a CPU wait API to allow for a "wait for submit"
          as well as a "wait for finish".

        
    Yeah, that is a rather good point.

    
         2. This is *not* for system
          compositors that need to be robust against malicious clients.

        
    I can see the point, but I think the kernel interface should still
    be idiot prove even in the unlikely case the universe suddenly stops
    to produce idiots.

    
        The expected use for the OPAQUE_FD is
          two very tightly integrated processes which trust each other
          but need to be able to share synchronization primitives.

        
    Well, that raises a really important question: What is the actual
    use case for this if not communication between client and
    compositor?

    
        Could we do this "in userspace"?  Yes,
          with added kernel API.  we would need some way of strapping a
          second FD onto a syncobj or combining two FDs into one to send
          across the wire or something like that, then add a shared
          memory segment, and then pile on a bunch of code to do
          cross-process condition variables and state tracking.  I
          really don't see how that's a better solution than adding a
          flag to the kernel API to just do what we want.

        
    Way to complicated.

    
    My thinking was rather to optionally allow a single page to be
    mmap()ed into the process address space from the fd and then put a
    futex, pthread_cond or X shared memory fence or anything like that
    into it.

    
    Regards,

    Christian.

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