Coming Soon: An Open-Source, Reverse-Engineered Mali GPU Driver 47
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?"
It's a big challenge to reverse engineer (Score:2, Redundant)
When vendors decide to keep everything to themselves and leave the users out in the cold, the only way to get in is by reverse engineer
But it is hard
It is especially hard when one has to deal with updated microcodes for each subsequent release of the product
Kudos for those who try to crack the Radeon !
Re:It's a big challenge to reverse engineer (Score:5, Insightful)
Re: (Score:2, Interesting)
This is not a problem in linux land, and this is precisely why everything is going over to gallium3d etc.
When it comes down to it all programmable gpus provide similar functionality, shader units, etc etc, galluim3d serves as the abstraction layer so all of the higher level stuff goes on top.
In the end all you need for the driver is the low level workings of it to provide a state tracker to the abstraction layer that it understands, the rest is already done (or in the process of already being done). Code r
Re:It's a big challenge to reverse engineer (Score:5, Interesting)
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...
Re: (Score:1)
Add to that, most modern GPUs also have a variety of coprocessors for things like H.264 decoding...
This is not true at all for ARM systems. Actually quite the opposite. The Mali 400 is a 3d graphics core *only*. It renders images to a memory buffer and is not even capable of presenting that image on a display. That is the job of the display controller which on your avarage SoC would not be designed by ARM. A PC GPU would normally have dedicated memory, a 3D core, a 2D blitter (on older hardware), a video block and a display controller all integrated on a graphics card. In an ARM SoC all those parts could
Re: (Score:2)
most modern GPUs also have a variety of coprocessors for things like H.264 decoding.
Why is that? They should have plenty of general-purpose silicon for doing it in software. (Mobile devices would be an exception because dedicated hardware is more power-efficient.) In fact, why don't we just write ffmpeg etc. in OpenCL and get this over with?
Re: (Score:2)
Having it in dedicated silicon is more power efficient than doing it on the general purpose shaders. It may also be faster and/or produce better quality depending on whether the workload is suited to the shaders' architecture or not.
propreitary (Score:2, Insightful)
I know they keep the drivers proprietary to keep their special 3d chip tricks to themselves, but can't you just feed it tables of vectors and vectors and be done with it? Why do you need such a low level access that apparantly shows all their company secrets?
Before all you say performance! My question would be , really?
Re:propreitary (Score:5, Informative)
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.
Re: (Score:2)
writing good compilers is hard and costs lots of money
And GPU companies, by and large, suck at it. Qualcomm has recently been hiring as many people as they can with compiler experience, but neither AMD nor nVidia has a particularly impressive compiler team. Intel does... but they don't work on their GPU stuff.
Re: (Score:1)
Not that i would trust Intel, or the rest for that matter, at creating a generic compiler.
Seems the Intel compiler ends up defaulting code back to 386 if the cpu do not provide the right "id".
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
But I agree - having a commercially backed DSP target is good for the compile framework. Easier to add possible Mali support in the future.
Re: (Score:3)
Re:propreitary (Score:5, Insightful)
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: (Score:3)
Re: (Score:2)
The reason for keeping the instruction set secret is that sure as hell you don't want to get stuck with it.
Why would you be stuck with it? You're stuck with x86 because it was the target for compiled code decades ago. No one is going to be distributing binary code for the latest nVidia or AMD code, at the most they're going to be distributing some kind of IR like PTX, or Gallium IR. Each generation of AMD and nVidia GPU has a different instruction set, and distributing code in binary form for every GPU would be insane (especially since even ones that share an instruction set often have different performance c
Intel, AMD and nVidia need the competition (Score:2)
Intel, AMD and nVidia need the competition, from the outside.
Especially Intels complacency in the CPU space is worrisome.
The GPU hardware arena still is outpacing anyone's expecations, so it is really really good with this open-source initiative.
Kudos!!!
The way I saw it (Score:2)
The way I saw it:
Intel is a tremendous contributor the the open source world!
Intel, due the lacklustre performance of AMD CPU performance holds back on its releases of multiple CPUs; think of the two(!) inactive cores in the latest series. Not, because they think AMD are good guys, but Intel's CPU are so much better they could have readily killed off AMD, using bad tactics used by other comapnies. But, Intel are intelligent people, unlike many other's in the industry. Intel keeps the competition at a safe d
This is good news (Score:4, Informative)
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: (Score:2)
Also go read up on Wayland and why it's being developed.
Because in the open source community, if you discover a problem, you can fix it?
Re: (Score:3)
Also go read up on Wayland and why it's being developed.
To bring the future of GUIs (such as remote display, etc) to Linux?
Re: (Score:2)
Also go read up on Wayland and why it's being developed.
To bring the future of GUIs (such as remote display, etc) to Linux?
I hope you're trolling. [wikipedia.org]
Re: (Score:2)
They better have power saving support (Score:1)
If this thing ever wants to be more than a curiosity for some hobbyist who has a religious opposition to closed-source drivers, then these drivers had better be competitive in getting the GPU into power-saving mode. That's an even bigger deal than performance in some ways, because if the open source drivers kill your battery even faster than it already dies on most smartphones, it won't be too popular.
Already partially open source? (Score:2, Informative)
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 [malideveloper.com]
Re: (Score:2)
Mali-400 will be a huge effort to reverse engineer, but what hope is there for the next generation with OpenCL and DirectX.