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

[phoronix]

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

[libv]

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!

[darkbasic]

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

[bnolsen]

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.

[nzjrs]

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?

[libv]

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.

[ryao]

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.

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

Are you volunteering to write it?

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.

[liam]

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?

[libv]

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.

[pierce]

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.