Page 1 of 2 12 LastLast
Results 1 to 10 of 16

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

  1. #1
    Join Date
    Jan 2007
    Posts
    14,305

    Default 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. #2
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    313

    Default

    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 at 10:35 AM.

  3. #3
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    906

    Default

    I agree to keep it out of mesa until we get a FOSS shader compiler.

  4. #4
    Join Date
    Mar 2008
    Posts
    205

    Default

    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.

  5. #5
    Join Date
    May 2010
    Posts
    57

    Default

    Quote 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?

  6. #6
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    313

    Default

    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.

  7. #7

    Default

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

    Quote 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?

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

  8. #8
    Join Date
    Jan 2009
    Posts
    1,296

    Default

    Quote 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?

  9. #9
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    313

    Default

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

  10. #10
    Join Date
    Jul 2012
    Posts
    4

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •