Announcement

Collapse
No announcement yet.

Lima Driver Has Some Speed Wins, But Will Not Be Mainlined

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Lima Driver Has Some Speed Wins, But Will Not Be Mainlined

    Phoronix: Lima Driver Has Some Speed Wins, But Will Not Be Mainlined

    The Lima graphics driver for open-source ARM Mali GPU support on Linux has some performance advantages of ARM Holdings' binary blob, but there's no upstream interest in having the driver mainlined in Mesa...

    http://www.phoronix.com/vr.php?view=MTQ3NDg

  • #2
    This quick turn around time, and the (future) ability to run against several common mesa versions will benefit a lot of users. Most of whom have had a hard enough time already getting a working system on their ARM SoC, although we do try to make it relatively easy for folks at linux-sunxi.org.

    My limare code shows that the hardware has about 60% more performance to offer over the available X11 binaries (which are not official - arm does not officially release any binary drivers), we should be able to attain that. Since glmark2-es2 (those tests that are already working) and es2gears is consistently 6% faster than the X11 binary, and i am not doing job interleaving yet in mesa (which is the reason why my limare code is that much faster) we know how to get to a 59% increase over the binary. Remember, limare also runs Q3A timedemo just over 6% faster than the framebuffer binary does.

    Finally, about using the binary shader compiler. This is an intermediate and debugging step. We intend to hook the open-gpu-tools work into the mesa glsl compiler as a next step to get a fully free mesa driver. OGT already can generate runnable shaders with hand-generated input today, and can already power Q3A.

    This mesa code will be made public once i get the last few niggles worked out with glmark2-es2.

    Things are looking good!
    Last edited by libv; 10-02-2013, 10:35 AM.

    Comment


    • #3
      I agree to keep it out of mesa until we get a FOSS shader compiler.
      ## VGA ##
      AMD: X1950XTX, HD3870, HD5870
      Intel: GMA45, HD3000 (Core i5 2500K)

      Comment


      • #4
        Definitely tells you that the ARM guys aren't software folks. They did enough just to get things out the door and not much else beyond that.

        Comment


        • #5
          Originally posted by BO$$ View Post
          Of course it won't be mainlined. They will support Mir. Everybody hates Canonical so supporting Mir is a red flag. The level of politics in Linux world is astonishing! You say Mir and you get banned.
          WTF are you talking about?

          Comment


          • #6
            I do not intend to do the legwork for mir or wayland support, but i definitely will not refuse patches which add support for what is bound to be a large userbase.

            Comment


            • #7
              Originally posted by libv View Post
              This quick turn around time, and the (future) ability to run against several common mesa versions will benefit a lot of users. Most of whom have had a hard enough time already getting a working system on their ARM SoC, although we do try to make it relatively easy for folks at linux-sunxi.org.

              My limare code shows that the hardware has about 60% more performance to offer over the available X11 binaries (which are not official - arm does not officially release any binary drivers), we should be able to attain that. Since glmark2-es2 (those tests that are already working) and es2gears is consistently 6% faster than the X11 binary, and i am not doing job interleaving yet in mesa (which is the reason why my limare code is that much faster) we know how to get to a 59% increase over the binary. Remember, limare also runs Q3A timedemo just over 6% faster than the framebuffer binary does.

              Finally, about using the binary shader compiler. This is an intermediate and debugging step. We intend to hook the open-gpu-tools work into the mesa glsl compiler as a next step to get a fully free mesa driver. OGT already can generate runnable shaders with hand-generated input today, and can already power Q3A.

              This mesa code will be made public once i get the last few niggles worked out with glmark2-es2.

              Things are looking good!
              That sounds good.

              Originally posted by darkbasic View Post
              I agree to keep it out of mesa until we get a FOSS shader compiler.
              Are you volunteering to write it?

              Originally posted by bnolsen View Post
              Definitely tells you that the ARM guys aren't software folks. They did enough just to get things out the door and not much else beyond that.
              You just described how embedded software design works.

              Comment


              • #8
                Originally posted by libv View Post
                This quick turn around time, and the (future) ability to run against several common mesa versions will benefit a lot of users. Most of whom have had a hard enough time already getting a working system on their ARM SoC, although we do try to make it relatively easy for folks at linux-sunxi.org.

                My limare code shows that the hardware has about 60% more performance to offer over the available X11 binaries (which are not official - arm does not officially release any binary drivers), we should be able to attain that. Since glmark2-es2 (those tests that are already working) and es2gears is consistently 6% faster than the X11 binary, and i am not doing job interleaving yet in mesa (which is the reason why my limare code is that much faster) we know how to get to a 59% increase over the binary. Remember, limare also runs Q3A timedemo just over 6% faster than the framebuffer binary does.

                Finally, about using the binary shader compiler. This is an intermediate and debugging step. We intend to hook the open-gpu-tools work into the mesa glsl compiler as a next step to get a fully free mesa driver. OGT already can generate runnable shaders with hand-generated input today, and can already power Q3A.

                This mesa code will be made public once i get the last few niggles worked out with glmark2-es2.

                Things are looking good!
                Hi. Would xcb threading allow for the job interleaving?

                Comment


                • #9
                  Originally posted by liam View Post
                  Hi. Would xcb threading allow for the job interleaving?
                  No idea, Siarhei Siamashka has some ideas with dri2 already, but wait and see until this "slow" version is working enough for a public release. I already expect to get inundated with bug reports and fixes as is You can happily try out possible solutions then, as the hw side is fully known.

                  Comment


                  • #10
                    Mainlining

                    With the proclamation that there is no intent on mainlining lima, is this indefinitely? Or just at this current point? What would be the roadmap to get lima mainline?

                    I'm just looking forward to a future where cheap Android devices from china could be running a fully fledged linux desktop environment. Mali seems to be the most prevalent gpu going round on cheap SoCs at the moment.

                    Comment


                    • #11
                      Originally posted by pierce View Post
                      With the proclamation that there is no intent on mainlining lima, is this indefinitely? Or just at this current point? What would be the roadmap to get lima mainline?
                      It will Just Work when using the right packages, and you will get an updated driver quickly and easily.

                      Originally posted by pierce View Post
                      I'm just looking forward to a future where cheap Android devices from china could be running a fully fledged linux desktop environment. Mali seems to be the most prevalent gpu going round on cheap SoCs at the moment.
                      This you can already have on sunxi hw, but lima will make it even easier and better.

                      Comment


                      • #12
                        Oh, those 6-10% gains on glmark2-es2 is with 4x MSAA enabled, as i currently have this hardwired to on (as the hw is designed so that it gets 4xMSAA almost for free). Lima will give everyone the ability to enable 4xMSAA _all_ the time. A potential 60% performance gain under X11 while enjoying 4xMSAA, how nice is that

                        Comment


                        • #13
                          Originally posted by libv View Post
                          Oh, those 6-10% gains on glmark2-es2 is with 4x MSAA enabled, as i currently have this hardwired to on (as the hw is designed so that it gets 4xMSAA almost for free). Lima will give everyone the ability to enable 4xMSAA _all_ the time. A potential 60% performance gain under X11 while enjoying 4xMSAA, how nice is that
                          Any OEM's interested? (So that Lima lands as fully supported out-of-the-box on shipping hw.)

                          Did You checked Dolphin recent blog post? It seams some code is shared between Mali and Ardreno binary blobs. Seen it in open source code?

                          (Oh! And did You think about exposing very good debug info in Your driver via KHR_debug so that actual app devs have reason for pushing for Lima drivers as default?)
                          Last edited by przemoli; 10-05-2013, 03:39 PM.

                          Comment


                          • #14
                            Originally posted by przemoli View Post
                            Did You checked Dolphin recent blog post? It seams some code is shared between Mali and Ardreno binary blobs. Seen it in open source code?
                            I believe that was intended as a joke because they both had the same bug. I really doubt the mali and adreno blobs actually share some code.

                            Comment


                            • #15
                              Originally posted by robclark View Post
                              I believe that was intended as a joke because they both had the same bug. I really doubt the mali and adreno blobs actually share some code.
                              Dunno if this is the case but some closed source drivers are based on mesa, so it may be true that some drivers share code.

                              Comment

                              Working...
                              X