Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by Unknown on from the hit-the-fraglimit dept.

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.

13 of 71 comments (clear)

  1. Not much in this driver? by TejWC · · Score: 3, Interesting

    Based on the article, it seems like they first ported Q3A from OpenGL ES1 to OpenGL ES2, and then they used the closed source shader compiler to do most of the work (OpenGL ES2 forces most of the code to be in the form of shaders). It seems like they really didn't make much of an actual driver and just off-loaded most of the work to the shaders (I could be wrong though).

    1. Re:Not much in this driver? by Anonymous Coward · · Score: 3, Informative

      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.

  2. Optimized Code by zAPPzAPP · · Score: 3, Funny

    if (Quake3) show_fps += 30;

    1. Re:Optimized Code by serviscope_minor · · Score: 4, Funny

      It's happened in the past that certain drivers have claimed better performance while at the same time completely ignoring certain things they were supposed to be doing in order to get the framerate up. Do the frames end up looking exactly the same with both drivers? What exactly is making it faster. Did they improve a specific part which only helps for Q3A demo files and doesn't actually make any difference when playing a real game.

      All interesting questions. If only there was a long block of text which covered those points. I've never heard such of a thing though. But, I'm going to coin a new term, "TFA" to refer to the hypothetical object.

      Anyone with me on this?

      --
      SJW n. One who posts facts.
  3. 2 whole percent? by abigsmurf · · Score: 4, Interesting

    So it's a value that's well within random fluctuation levels? Meanwhile, how's the reliability, memory usage, compatibility, performance outside of that single game?

  4. Texture switching by Hsien-Ko · · Score: 3, Informative

    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

  5. Re:2% isn't "faster", it's a measurement error by gmack · · Score: 4, Interesting

    Quite often binary drivers are written by people who, either ported the code from other Operating Systems, or must maintain the code in such as way as to be able to share the code base with operating systems having different driver models. A pure free driver can lose a lot of cruft and can often have things like memory management better tuned for the system or interact with the hardware in more efficient ways.

    The NVIDIA Ethernet driver from a few years back was a good example of that. The Linux people created a free driver that ran a lot faster than the binary driver forcing NVIDA to abandon their driver.

  6. Re:Another cavet by GrumpySteen · · Score: 2

    The frame rate dropped into the mid-40s during some parts of the Quake 3 timedemo. What you consider a relevant benchmark would be a useless slideshow. Old benchmarks are quite suitable for demonstrating what you can expect from low-powered hardware.

  7. Re:2% isn't "faster", it's a measurement error by Anonymous Coward · · Score: 3, Informative

    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

  8. Re:2% isn't "faster", it's a measurement error by Anonymous Coward · · Score: 2, Informative

    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.

  9. Great progress, and thanks for working on this! by Anonymous Coward · · Score: 2, Insightful

    Your work is appreciated!

    Ignore all the idiots who hate their lives that lurk around /. criticizing every accomplishment of others. /. is starting to suck. Your work though is great!

  10. Re:Another cavet by Anonymous Coward · · Score: 2, Informative

    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 :)

    --libv

  11. Re:Anyone make an informed guess as to... by WilyCoder · · Score: 2

    Posted Today, 11:40 AM
    Hi JimV

    Currently the only developer board I am aware of with an OpenCL compatible Mali GPU is the Arndale board. Drivers for this board would have to come from Insignal, but I am not sure what the current status of this support is. The demos themselves will run on desktop however, if you modify the platform.mk in the root directory to use gcc rather than a cross compiler. Provided the necessary libraries are installed on the host machine, the demos will run. The Nexus 10 tablet also contains an OpenCL compatible Mali GPU, however the Android SDK does not currently expose this functionality.

    Thanks,
    Chris

    http://forums.arm.com/index.php?/topic/16523-any-way-to-actually-use-the-mali-opencl-sdk-boards-with-drivers/

    In other words, you're still not running CL on mobile devices yet. Have a nice day, and herp a fucking derp.