Slashdot Mirror
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?"
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.
It is about the ability to correct bugs, the ability to improve and maintain the software, even when the company decides linux is not a target anymore (Like Nvidia did for its Optimus technology). Also, authorizing a binary blob to be executed on your machine whith no ability to check what happens in it is a security problem. There could be backdoors in these drivers.
The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
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
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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.
I am TheRaven on Soylent News
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...
I am TheRaven on Soylent News
PTX is already a high-level abstraction, but if you use it directly then you are basically stuck with your code only working on nVidia GPUs (or, on a subset of recent nVidia GPUs, depending on which PTX features you use). If you write assembly directly for any given GPU, then you lose portability. This means that 99% of developers won't, because no one will buy a game that requires a specific make and model of GPU (unless it happens to be a model used in a console). For some categories of user, however, that doesn't matter. If you are running a simulation on a 1,000-node cluster of nVidia GPUs and tweaking the assembly can make it 10% faster, then that's the equivalent of buying 100 more nodes for your cluster: a huge saving. The cost in terms of portability is pretty low, because you're probably going to rewrite the code before you get a different cluster anyway.
I am TheRaven on Soylent News
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...
Live today, because you never know what tomorrow brings
As far as I can tell, ARM already provides GPLv2 implementations for the 2D parts of the driver, so what's new here is the 3D stack.
http://www.malideveloper.com/developer-resources/drivers/open-source-mali-gpus-linux-exadri2-and-x11-display-drivers.php