Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Quake Linux

Open Source ARM Mali Driver Runs Q3A Faster Than the Proprietary Driver 71

An anonymous reader writes "The lima driver project, the open source reverse engineered graphics driver for the ARM Mali, now has Quake 3 Arena timedemo running 2% faster than the ARM Binary driver." There's a video showing it off. Naturally, a few caveats apply; the major one is that they don't have a Free shader compiler and are forced to rely on the proprietary one from ARM, for now.

This discussion has been archived. No new comments can be posted.

Open Source ARM Mali Driver Runs Q3A Faster Than the Proprietary Driver

Comments Filter:
  • Texture switching (Score:4, Informative)

    by Hsien-Ko ( 1090623 ) on Wednesday February 06, 2013 @11:44AM (#42808873)
    Quake III Arena has a ton of it. Not even its models are well paged, like the rocket which uses around 4 different textures alone. The only things atlased are console text, menu text and lightmaps, so it's not a very efficient data set for OpenGL ES to begin with
  • by Anonymous Coward on Wednesday February 06, 2013 @01:09PM (#42809993)

    The numbers are in the blog post, which you haven't bothered to look at.

    This is an ARM Cortex A8, running at 1GHz, with a Mali-400MP1 at 320MHz, and with 1GB DDR3 at 360MHz. Timedemo is fully consistent, every time. 46.2 for the binary opengles1 driver, 47.2 for the open source driver.

    We are getting close to a shader compiler of our own, yesterday we had our first stab at compiling the few shaders needed for q3a, it failed though, but we are creeping closer on this insane and massive task of reverse engineering a binary GPU driver.

    -- libv

  • by Anonymous Coward on Wednesday February 06, 2013 @01:13PM (#42810065)

    Furthermore, this blog extensively explains how well the hardware behaves and how this 2% is mostly due to the fact that the prototype driver has less checking to do than a proper driver. No special tricks were used, especially none which are Q3A specific, this is how fast the hardware is, and we succeeded in using it just as efficiently as the binary driver, which is unbelievably significant for a reverse engineered graphics driver.

  • Re:Well done Luc (Score:0, Informative)

    by Anonymous Coward on Wednesday February 06, 2013 @01:16PM (#42810105)

    Hehe :) Wait until the video of my FOSDEM talk is online, that will bring out their friendliest side again :)


  • Re:Another cavet (Score:2, Informative)

    by Anonymous Coward on Wednesday February 06, 2013 @01:23PM (#42810211)

    We are vastly overcommitted on the fragment shader, and we also have limited CPU cycles to spare on this hw. Bodyparts flying is dragging us down significantly :) Having said that, our average FPS is in the mid-40s, just that lima is 47.2 and the binary is 46.2 :)


  • by Anonymous Coward on Wednesday February 06, 2013 @08:00PM (#42815347)

    Hey there, I'm Connor Abbott, the lima compiler guy. No, porting from GLES1 to GLES2 was not necessary, it was just to debug a performance issue. While it is true that the demo uses the binary compiler, we *do* have the knowledge to write our own shaders - it's just the compiler that's lacking, and maybe my laziness :). For fragment shaders, we could pretty easily write our own shaders in assembly, it just hasn't been done yet (when I get around to it ;) ). For vertex shaders, we can't write anything in assembly because the assembly is so complex and impossible to write by hand - we need to implement at least part of a proper compiler in order to get it working, which is what I'm working on right now. So all the information is out there, it's just the code that has to be written and we're working on it.

The trouble with the rat-race is that even if you win, you're still a rat. -- Lily Tomlin