Coming Soon: An Open-Source, Reverse-Engineered Mali GPU Driver

An anonymous reader writes "Next month at FOSDEM there will be an announcement of a fully open-source and reverse-engineered ARM Mali graphics driver for Android / Linux. This driver, according to Phoronix, is said to support OpenGL ES and other functionality from reverse engineering the official ARM Linux driver. Will this mark a change for open-source graphics drivers on ARM, just as the Radeon did for x86 Linux?"

Comments

Re:propreitary

[airlied]

You haven't looked at 3D programming in 15 years then?

Its just like a CPU, you build shader programs, and optimsing the shader programs requires compilers and writing good compilers is hard and costs lots of money.

Also the other reason is patent infringement, they are all infringing on everyone, just like the rest of the mobile space, so they don't want to make it that easy to show off what they are doing.

Though neither of these reasons are really valid but lawyers and crap engineers like to keep themselves looking good.

This is good news

[DarkOx]

Thanks to this effort we are much closer to being able to run a traditional GNU/X.org userland on these devices if desired. Just work out the details of the radio hardware and it should be possible to roll your own mobile distro pretty soon without having to be hardware expert

Re:propreitary

[TheRaven64]

Increasingly, GPUs are just general-purpose processors that are optimised for a very different set of algorithms to CPUs (i.e. stream-based access to memory instead of lots of locality of reference, primarily floating-point vector data instead of integer data, and few branches instead of about one every 7 instructions on average for CPUs). This means that a GPU driver is increasingly just a compiler. There is a lot less of a reason to keep the details of the hardware instruction set secret, because, as with something like ARM or x86, the valuable bit is how it's implemented, not the instruction set itself. This also means that there's a lot of incentive to keep the in-house drivers secret, because the difference between a bad compiler and a good one can easily be a factor of two in terms of performance with real code and sometimes a lot more.

Re:It's a big challenge to reverse engineer

[TheRaven64]

Add to that, most modern GPUs also have a variety of coprocessors for things like H.264 decoding. These are quite often licensed as IP cores from a third party, so a company like nVidia or AMD may not even legally be allowed to provide you with their programming interfaces. To make life even more fun for reverse engineers, they don't document where they licensed these coprocessor cores from anywhere, so it's generally very hard to work out who to contact with a request for documentation. This is why open source drivers tend to miss off some of the features of the proprietary ones: once you've reverse engineered the GPU, there's still a load of other stuff left...

Re:It's a big challenge to reverse engineer

[Kjella]

Add to that, most modern GPUs also have a variety of coprocessors for things like H.264 decoding. These are quite often licensed as IP cores from a third party

Not coprocessors but third party ASICs, particularly for multimedia en/decoding and HDMI audio. That it may be third party IP is only half the problem though, as I understand it AMD's Unified Video Decoder (UVD) is their own yet it's still a paperweight under the open source drivers because of DRM issues. Same with HDMI audio, they're required to provide a Protected Audio Path in order to play BluRays and such. In fact it's also a risk when releasing shader information because part of the H.264 decoding process happens in shaders, at least on AMD and part of the reason the open source driver doesn't get to share more with the proprietary driver.

That said, there's extremely much that could be done without more information too. As I understand it all the shader information to implement OpenGL 4.2 and OpenCL for Evergreen and Northern Islands (AMD HD 5xxx and 6xxx series) is out there, but both Mesa and the drivers need huge amounts of work. The current version of Mesa only supports OpenGL 2.1 but Mesa 8 is supposed to bring OpenGL 3.0 support, OpenCL is still only in proof of concept stages. That should "only" take a hundred full time developers or so, not any more specs. Right now the few that have plenty just keeping up with the huge architecture changes between generations...