Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Graphics Open Source Linux

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?"
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by walshy007 ( 906710 ) on Saturday January 21, 2012 @09:41AM (#38773484)

    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 re-use, it is useful.

  • by Kjella ( 173770 ) on Saturday January 21, 2012 @10:44AM (#38773772) Homepage

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

"The pathology is to want control, not that you ever get it, because of course you never do." -- Gregory Bateson