Follow Slashdot blog updates by subscribing to our blog RSS feed


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:
  • propreitary (Score:2, Insightful)

    by it0 ( 567968 )

    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)

      by airlied ( 135423 ) on Saturday January 21, 2012 @08:28AM (#38773288) Homepage

      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.

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

        • by hitmark ( 640295 )

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

        • Qualcomm just submitted their Hexagon backend to LLVM, btw.
          • Ah, nice. I saw they were hiring people for that about 6-8 months ago, and followed some of the progress. I didn't see the code had actually made it in. It's the first DSP back end to be contributed to LLVM, so it will probably be quite useful to other DSP makers as a reference. It will also be interesting to see if TI follows with a C64x back end - currently the only compilers for this DSP family (present in most of the OMAP series) are proprietary.
            • Not first DSP, but possibly first vendor-backed one. LLVM has (or had at least recently) a blackfin backed, and quick googling shows at least two c64x off-tree backend projects for LLVM.

              But I agree - having a commercially backed DSP target is good for the compile framework. Easier to add possible Mali support in the future.

    • by Yvanhoe ( 564877 )
      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.
    • Re:propreitary (Score:5, Insightful)

      by TheRaven64 ( 641858 ) on Saturday January 21, 2012 @08:57AM (#38773350) Journal

      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.

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


  • This is good news (Score:4, Informative)

    by DarkOx ( 621550 ) on Saturday January 21, 2012 @08:44AM (#38773322) Journal

    Thanks to this effort we are much closer to being able to run a traditional GNU/ 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

  • by Anonymous Coward

    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.

  • by Anonymous Coward

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

"For a male and female to live continuously together is... biologically speaking, an extremely unnatural condition." -- Robert Briffault