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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #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; 02 October 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

                    Working...
                    X