AMD Proposing Redesign For How Linux GPU Drivers Work - Explicit Fences Everywhere

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • jrch2k8
    Senior Member
    • Jun 2009
    • 2095

    #11
    Originally posted by marios View Post
    I think moving more and more stuff entirely to user space (avoid system calls) is the way to go. This means that the hardware should be designed with that in mind. High performance networks also try to bypass the kernel as much as possible.
    There is a reason this is not easy, the performance hit is massive and the security implications are not trivial either

    Comment

    • tildearrow
      Senior Member
      • Nov 2016
      • 7099

      #12
      Wouldn't this open the door for more race conditions (which could lead to unexpected behavior like hangs or crashes)?

      Personally I wish the driver was made stable first (the warning hiding fiasco was enough to turn me down)...

      Comment

      • Azrael5
        Senior Member
        • Jul 2012
        • 1954

        #13
        So which is the conclusion?

        Comment

        • Quackdoc
          Senior Member
          • Oct 2020
          • 5096

          #14
          I would love to see this, of course the assumes the current drivers will be maintained until the new ones are stable, which is likely anyway. always glad to see new innovation

          Comment

          • dh04000
            Senior Member
            • Aug 2012
            • 892

            #15
            Didn't the EGLStreams API require explitic fences?

            I seem to remember it being said years ago during the whole GBM vs EGLStream turf war that GBM was better because it didn't have that hard requirement.

            Comment

            • dh04000
              Senior Member
              • Aug 2012
              • 892

              #16
              Some old discussion on explicit fences here: https://bugs.freedesktop.org/show_bug.cgi?id=97353

              Compared to Android where they are required and is mentioned how EGLStreams already implemented it.

              Comment

              • wizard69
                Senior Member
                • Sep 2009
                • 2236

                #17
                Interesting proposal. Like all such offerings it needs plenty of vetting time. Personally; consideration should be given to making this a more generalized solution. That is why not create a generalized structure that can also support AI/ML coprocessing hardware and similar subsystems that might be executing multiple threads.

                On the other hand more performance is always a good thing. However we need to make sure that AMD and Intel are onboard and maybe even some of the ARM SoC designers. The reality is software could be impacting future hardware and future hardware could go in a direction that undermines such design changes. I'm not one for industry conferences but this really seems to have very long term implications and needs everybody on board.

                Comment

                • tildearrow
                  Senior Member
                  • Nov 2016
                  • 7099

                  #18
                  When I hear "GBM", it makes me think of a buffer manager that is not tied to any graphics API and therefore one can use GBM with OpenGL or Vulkan (or even DirectX, who knows).

                  When I hear "EGLStreams" it makes me think you can only use OpenGL with it.

                  Comment

                  • smitty3268
                    Senior Member
                    • Oct 2008
                    • 6966

                    #19
                    Originally posted by discordian View Post
                    Next they will propose some library to replace GBM, so the kernel actually has a chance to pick the best fitting synchronization.
                    Then 5 years after they get that working for everyone NVidia will mention they have some better solution that everyone else should switch to instead.

                    Comment

                    • smitty3268
                      Senior Member
                      • Oct 2008
                      • 6966

                      #20
                      Originally posted by Azrael5 View Post
                      So which is the conclusion?
                      It's ongoing. I suggest reading the discussion on the mailing list if you are interested.

                      If not, the TLDR is that this whole thing is a giant mess and extremely complicated, and will likely take a lot of discussion to figure out and then years to port over all the different components involved. Parts of Marek's original proposal seem non-controversial, but other parts have been deemed significantly misguided, at least by parts of the community. Everyone seems to think "something" needs to be done, though, it's just a matter of figuring out what and how to do it.

                      Comment

                      Working...
                      X