If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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

10-02-2013, 09:20 AM

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

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.

Comment

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.

Comment

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

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

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.