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.

44 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 drinkypoo · · Score: 1

      That sounds like a feature to me, so long as all the pieces are there. I'd sure love a completely-open-to-the-microcode platform, but what I need is something sufficiently open for there to continue to be drivers.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. 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. 2% isn't "faster", it's a measurement error by Anonymous Coward · · Score: 1, Insightful

    AIUI the FOSS codebase is based on reverse-engineering the binary driver. So, there would be almost no reason to expect it to be faster. There may be some CPU time saved if they can create the command buffer quicker than the binary driver manages, but it's highly unlikely they can create a general solution that makes the GPU time reduce, since they're going to have to send the same commands to the hardware anyway. A better shader compiler might achieve something but ... they don't have that.

    Ergo, 2% is a measurement error. The open source driver is not faster.

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

    2. Re:2% isn't "faster", it's a measurement error by Khyber · · Score: 1

      "There may be some CPU time saved if they can create the command buffer quicker than the binary driver manages, but it's highly unlikely they can create a general solution that makes the GPU time reduce, since they're going to have to send the same commands to the hardware anyway"

      Or, they don't have to send the same commands, and have implemented a wrapper that actually works more efficiently than the native graphics code.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    3. 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

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

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

      2% is significant. Other tests run up to a third faster (spinning companion cube) now. I am sure that when i get my hands on a more powerful mali and a more powerful CPU, the numbers will improve. But for now, we are faster, but only by a small bit, and this is a massive victory for free software in itself.

      --libv

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

      Thanks man, you really know how to spur people on. Manyears of hard labour, all done in spare time, and there is this to show for it, and all you can do is complain that it is only 2% faster.

      I hope you feel real good about yourself now.

      --libv.

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

    if (Quake3) show_fps += 30;

    1. Re:Optimized Code by CastrTroy · · Score: 1, Redundant

      Without much analysis done on the actual output, this is a very relevant statement. 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.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    2. 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. Re:Optimized Code by yabos · · Score: 1

      Quiet, you

    4. Re:Optimized Code by mikael · · Score: 1

      Sometimes the driver uses special optimized paths depending on the name of the executable. That was known in the past, so they could optimize for benchmarks and games. Even certain configurations of GL function calls were faster than others eg. glDrawArrays

      http://www.spec.org/gwpg/gpc.static/Rulesv16.html

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
    5. Re:Optimized Code by Anonymous Coward · · Score: 1

      Yes, and no. We are more aggressive in scheduling jobs. This might be completely legal, and it might be that the falanx guys decided that the higher cpu overhead and increased context switching was too much for lower power, and single, ARM cores. This does get us the 2% increase in framerate, and gains us insanely more for other, less PP intensive, tests. Like 30%. And this for comparable CPU usage, which in case of the spinning companion cube is around 10%.

      The reduced cpu usage is most definitely because we do not check as extensively. We could actually reduce cpu usage a bit more, but there is nothing that we would prove with that. Mesa is the next big test, and we now know that if we end up slower, Mesa (and/or our mesa implementation) is the problem.

      -- libv

  4. The next step by GeekWithAKnife · · Score: 1

    Either take the original code open source for the benefit of all or hire the open source team before someone else does cause they obviously rock.

    --
    A 'singular oddity' is an event that cannot be explained and only happens when you are alone.
  5. Re:Anyone make an informed guess as to... by WilyCoder · · Score: 1

    Sure, I will have your answer ready next fucking century when that type of hardware is available.

  6. Hmmm by AdmV0rl0n · · Score: 1

    While its quite nice to have a quake III bench, and be on a mobile platform that in fact means some great fun could be had amongst friends, its an old bench, and an old game.
    It used to be something Amiga people benched against in later years to try to implicate an idea on relevance.

    Having capable GPU's in mobile stuff (Hi Intel Atom based netbooks!) is a great idea. All for it, and you have to love the low cost of the platforms making it available to more people.

    --
    We`re all equal .. Just some of us are less equal than others.
    1. Re:Hmmm by citizenr · · Score: 1

      While its quite nice to have a quake III bench, and be on a mobile platform that in fact means some great fun could be had amongst friends, its an old bench, and an old game.

      and yet it is the best looking usable game on tablets/phones right now :)

      --
      Who logs in to gdm? Not I, said the duck.
  7. 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?

    1. Re:2 whole percent? by Bigby · · Score: 1

      It isn't within random fluctuation levels. I would assume the tests were run with a large enough sample size to make random fluctuations statistically insignificant. Just that 2% is not a significant change for gaming. If we were in the world of high frequency trading, 2% would be worth billions.

    2. Re:2 whole percent? by drinkypoo · · Score: 1

      So it's a value that's well within random fluctuation levels?

      Now compare it to the performance before this update, and get back to us on whether it's news, at least to people who care about this chip.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    3. Re:2 whole percent? by Anonymous Coward · · Score: 1

      The news is that there _is_ an open source, reverse engineered, driver which is matching the binary driver in performance. Matching as there really is little more to gain from this hardware without hacking Q3A itself. This is as fast as the hardware is, and we actually manage to use it just as well as the binary driver, without any Q3A specific hacks.

      --libv

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

    1. Re:Texture switching by Khyber · · Score: 1

      >mfw models and textures shouldn't be shit on a more modern system like an ARM core.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    2. Re:Texture switching by BitwizeGHC · · Score: 1

      This is probably because Q3 had to work on Voodoo cards, which had very limited texture sizes (256x256 I think? something dumb...) and so you couldn't atlas textures to the extent that you do on today's GPUs.

      --
      N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
    3. Re:Texture switching by Hsien-Ko · · Score: 1

      It wasn't due to texture size limits or the Voodoo. One 256x128 could fit everything an ammo box or rocket needed.

      Q3Test was worse in this regard, the Railgun model used around 12 textures

  9. Re:Anyone make an informed guess as to... by WilyCoder · · Score: 1

    Oh thanks for that insightful post, I had no idea that multicore CPUs existed and we can do GPGPU with CUDA and CL!

    Attention dumbass: I was referring to the lack of CL drivers for mobile GPUs. The Mali T604 does not yet have a CL driver. There are no consumer available mobile GPUs that ship with CL drivers.

    And then on top of that, the OP wanted a CL device based on the T604 to be driven over Thunderbolt. LOL! Like I said, I will get back to you in 10 years when that shit is actually available for purchase.

  10. Re:Anyone make an informed guess as to... by aztracker1 · · Score: 1

    My 56k dialup keeps saying CONNECT 38400, and dropping off.. I have the serial port set to 9600 8N1 since I read somewhere that is standard... I don't know why it's so slow and unreliable.. I did by a US Robotics Windows Modem for my Windows 95 desktop... It's super awesome and place Duke Nukem 3D way better than plain old DOS...

    --
    Michael J. Ryan - tracker1.info
  11. Re:Anyone make an informed guess as to... by Khyber · · Score: 1

    "I have the serial port set to 9600 8N1 since I read somewhere that is standard... I don't know why it's so slow and unreliable.."

    Your ATH string is fucked. Perhaps you should look up some old BBS documentation to get up to speed.

    "It's super awesome and plays Duke Nukem 3D way better than plain old DOS..."

    FTFY.

    --
    Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
  12. 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.

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

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

  15. Re:Anyone make an informed guess as to... by WilyCoder · · Score: 1

    That's wonderful that a driver exists in a lab somewhere, I'm very happy for you. But they've had that for years now. Those drivers are STILL not in the market. I would love to be wrong as I have the cash to make a purchase.

    But no mobile device out there has a working CL driver that developers like myself can use. Not even the arndale board (which uses T604) has a working driver.

    Getting Samsung or some other ARM licensee to then put the T604 (or any other mobile GPU for that matter) into a thunderbolt interface is a fool's errand. Its a nice idea, but it gives the impression of you not being down in the trenches doing mobile GPU work.

    Go ahead and post some links of products that are available to purchase that have a ImgTech or Mali or Tegra or Adreno GPU that supports OpenCL and has drivers available. Android or vanilla linux, doesn't matter. I dare you to find one.

  16. Re:Anyone make an informed guess as to... by WilyCoder · · Score: 1

    ARM having drivers doesn't do anything for me as a developer if I cannot use said drivers. If you actually read the link you posted you would learn that the CL driver you speak of is NOT AVAILABLE.

  17. Re:Anyone make an informed guess as to... by WilyCoder · · Score: 1

    If you actually give a shit and aren't just trolling me, then the arndaleboard.org forums will demonstrate that the driver is not yet available.

  18. Re:Wow by greenfruitsalad · · Score: 1

    and you've just degraded it to the second most useless.

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

  20. Have Mercy! by Anonymous Coward · · Score: 1

    Been humpin' on your mom all day!

  21. Re:Anyone make an informed guess as to... by WilyCoder · · Score: 1

    That is an android library that has no API exposed. I'm sure google is working hard on getting us there, but currently its not yet done. The arndale CL driver that will come first is the vanilla linux version.

    To answer your question, I am not sure. I don't know if any mobile SoC has I/O fast enough to feed the 4 PCIe lanes needed for thunderbolt. It would be cool if there was, but honestly id rather use a desktop GPU over thunderbolt for CL work...

    Sorry for being a jerk, was having a really bad day. Thanks for the mali CL sdk link, I am downloading it now.

  22. Re:Anyone make an informed guess as to... by Khyber · · Score: 1

    hey, look, I get modded down for stating a fact.

    http://tinypic.com/player.php?v=2il1ydc&s=7

    Got a problem, people?

    --
    Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
  23. Re:Well done Luc by rephlex · · Score: 1

    Hey Luc, why not drop round the Raspberry Pi forum and tell them about this. As you know they are a friendly bunch of guys and will want to offer you their congratulations.

    For the benefit of those who don't realize it, this is sarcasm. Read this and see both Eben and Liz Upton at their "charming" best and you'll understand: http://www.raspberrypi.org/archives/2221

    It's a pity the mainstream media haven't mentioned these sorts of events which have occurred numerous times on their forums. The Raspberry Pi Foundation and the Raspberry Pi apologists ought to brace themselves though, the PR bubble and hype surrounding the Pi won't last forever. Eventually reality will prevail.

  24. Re:Well done Luc by Anonymous Coward · · Score: 1

    Yeah. I am bracing myself already for when the rpi trolls learn about the content of my talk. They seem worse than some /. users ;)

    --libv