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

← Back to Stories (view on slashdot.org)

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

Posted by Unknown on Wednesday February 6, 2013 @03:08AM 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.

71 comments

Min score:

Reason:

Sort:

Another cavet by Anonymous Coward · 2013-02-06 03:18 · Score: 0, Troll

Quake 3 is old as shit. Time for a relevant benchmark.
1. Re:Another cavet by dugancent · 2013-02-06 03:45 · Score: 0
  
  Mr. Coward is not incorrect.
  
  --
  SJWs are the new boogeyman. -Me
2. Re:Another cavet by GrumpySteen · 2013-02-06 05:06 · 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.
3. Re:Another cavet by Anonymous Coward · 2013-02-06 05:23 · 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
Not much in this driver? by TejWC · 2013-02-06 03:24 · 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 · 2013-02-06 03:55 · 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 · 2013-02-06 05:26 · Score: 0
  
  It seems like they really didn't make much of an actual driver and just off-loaded most of the work to the shaders
  Sure, there's more work to be done, but this demonstrates a lot of progress since last year when they had just gotten around to write textured triangles to the framebuffer.
  They are initializing the chip, loading in shaders, and feeding it a continuous stream of draw commands, data and textures. The shader compiler and the rest of the "actual driver" are loosely coupled by design.
  If I understand correctly, that leaves them with a well-known interface for the compiler that needs to be implemented, and a framework for loading the output of the open-source and closed compilers side by side and comparing the output and performance.
3. Re:Not much in this driver? by Anonymous Coward · 2013-02-06 06:55 · Score: 0
  
  What exactly do you expect an 'actual driver' to do?
  Be a piece of software which connects the operating system to the device and issue valid bus-level commands to it,
  resulting in the device being usable to the operating system?
  Sounds like a 'driver' to me..
  If I make an emulator, it's not 'not an emulator' until it can generate binaries to run under the emulator..
4. Re:Not much in this driver? by Anonymous Coward · 2013-02-06 12:00 · 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.
5. Re:Not much in this driver? by Anonymous Coward · 2013-02-06 23:30 · Score: 0
  
  Thank you and keep up the good work!
2% isn't "faster", it's a measurement error by Anonymous Coward · 2013-02-06 03:28 · 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 · 2013-02-06 04:26 · 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 · 2013-02-06 04:53 · 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 · 2013-02-06 05:09 · 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 · 2013-02-06 05:13 · 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 · 2013-02-06 14:01 · Score: 0
  
  The Linux people created a free driver that ran a lot faster than the binary driver letting NVIDIA to abandon their driver.
  FIFY
6. Re:2% isn't "faster", it's a measurement error by Anonymous Coward · 2013-02-06 21:02 · Score: 0
  
  which you haven't bothered to look at
  Correct. I can smell bullshit, I don't need to taste it.
  As (you?) post below: due to the fact that the prototype driver has less checking to do than a proper driver
  So you made it faster by removing checks that Q3A doesn't need. That's called cheating. I said it's highly unlikely you made an actual general faster solution, and I was right.
  OK, so "measurement error" may not be the correct choice of words - the point is not that it's not consistent across runs, but that it's insignificant.
  insane and massive task
  You said it. There already is a working driver for that hardware. And it's just as fast as yours (modulo game-specific tweaks).
7. Re:2% isn't "faster", it's a measurement error by Anonymous Coward · 2013-02-06 21:06 · Score: 0
  
  succeeded in using it just as efficiently as the binary driver
  Story headline is "Open Source ARM Mali Driver Runs Q3A Just As Efficiently As The Proprietary Driver"?
  Read it again.
8. Re:2% isn't "faster", it's a measurement error by Anonymous Coward · 2013-02-06 21:26 · Score: 0
  
  measurement error may not be the correct choice of words
  Scratch that. It is the correct choice of words.
  Measurement errors take two forms. Random errors, which you hope sum to zero, and systematic errors. You may have zero random errors but you have whopping great systematic errors which are caused by your driver's incompleteness. Let me take a wild guess what you cheaped out on - CPU/GPU synchronization? Yeah, well that stuff costs you even when it's not needed, I'm afraid. Regardless, until your driver has the same functionality as the "proper" driver, your measurements will have systematic errors, and the magnitude of these is probably at least 10%. So, 2% is within measurement error.
9. Re:2% isn't "faster", it's a measurement error by Anonymous Coward · 2013-02-07 02:21 · 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
10. Re:2% isn't "faster", it's a measurement error by Anonymous Coward · 2013-02-07 02:59 · 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.
Optimized Code by zAPPzAPP · 2013-02-06 03:31 · Score: 3, Funny

if (Quake3) show_fps += 30;
1. Re:Optimized Code by CastrTroy · 2013-02-06 03:34 · 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 · 2013-02-06 03:43 · 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 · 2013-02-06 06:33 · Score: 1
  
  Quiet, you
4. Re:Optimized Code by mikael · 2013-02-06 09:09 · 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 · 2013-02-06 21:13 · Score: 0
  
  Unfortunately that block of text confirms that this is exactly what's happening.
6. Re:Optimized Code by Anonymous Coward · 2013-02-07 05:06 · 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
The next step by GeekWithAKnife · 2013-02-06 03:31 · 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.
Anyone make an informed guess as to... by Anonymous Coward · 2013-02-06 03:32 · Score: 0

Cost / performance comparison for thunderbolt OpenCL devices based on the mali t604?
1. Re:Anyone make an informed guess as to... by WilyCoder · 2013-02-06 03:36 · Score: 1
  
  Sure, I will have your answer ready next fucking century when that type of hardware is available.
2. Re:Anyone make an informed guess as to... by Anonymous Coward · 2013-02-06 03:55 · Score: 0
  
  How are things in 1999? Since then we've standardized on multi-core CPUs and offloaded processing for certain tasks to the GPU using CUDA and OpenCL. We also have a technology called thunderbolt which currently handles 4 lanes of PCIe. While most GPUs use 8 or 16 lanes, 4 lanes via thunderbolt is viable for compute bound tasks right now.
3. Re:Anyone make an informed guess as to... by WilyCoder · 2013-02-06 04:06 · 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.
4. Re:Anyone make an informed guess as to... by Anonymous Coward · 2013-02-06 04:23 · Score: 0
  
  Uh, just search for "Mali OpenCL" and you'll find that T604 has passed OpenCL full profile conformance, so such a driver certainly exists.
  Since there are no Linux devices with it and Android etc. doesn't support OpenCL none ship with OpenCL of course.
  However that's not a "in 10 years" thing.
5. Re:Anyone make an informed guess as to... by Anonymous Coward · 2013-02-06 04:32 · Score: 0
  
  ARM have OpenCL drivers, how else could they have submitted the part to Khronos for full profile conformance testing?
  Please send your answer over 56kbps dial up via serial port, you may have calmed down by the time we read it. I (for my part) will copy and paste it to a text file on the thunderbolt RAID enclosure under my desk. Also, if you could send some cave paintings...
6. Re:Anyone make an informed guess as to... by aztracker1 · 2013-02-06 04:46 · 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
7. Re:Anyone make an informed guess as to... by Khyber · 2013-02-06 05:03 · Score: 0
  
  "While most GPUs use 8 or 16 lanes, 4 lanes via thunderbolt is viable for compute bound tasks right now."
  Not really, seeing as many newer applications are so poorly coded that they need every gigabit of bandwidth possibly available.
  We moved from AGP to PCI-E, didn't even saturate the AGP 8X bandwidth, suddenly, everything runs like shit on AGP.
  Should have stuck with AGP and let CPUs take up the slack. Even today's newest CPU can't compete with the power of a GPU using the same power/TDP.
  All it takes is the right programming.'
  I've got an entire research facility running from a Tualatin PIII, including light controls, nutrient buffer controls, nutrient flow controls, nutrient filtration, pH buffering/monitoring, etc. all in real-time, and it ALMOST lags the hardware for controlling 10K+ hydroponics channels and lighting systems.
  Learn how to code and utilize hardware, people.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
8. Re:Anyone make an informed guess as to... by Khyber · 2013-02-06 05:06 · 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.
9. Re:Anyone make an informed guess as to... by WilyCoder · 2013-02-06 05:38 · 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.
10. Re:Anyone make an informed guess as to... by Anonymous Coward · 2013-02-06 05:38 · Score: 0
  
  Please do notice that cheap 7" tablet in the video. It's a tad hard to miss.
  --libv
11. Re:Anyone make an informed guess as to... by WilyCoder · 2013-02-06 05:44 · 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.
12. Re:Anyone make an informed guess as to... by Anonymous Coward · 2013-02-06 06:11 · Score: 0
  
  If you actually read the link you posted you would learn that the CL driver you speak of is NOT AVAILABLE.
  This is not my understanding of the situation as described by the ARM representative.
  
  "we deliver the source code directly to licensees"
13. Re:Anyone make an informed guess as to... by WilyCoder · 2013-02-06 06:23 · 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.
14. Re:Anyone make an informed guess as to... by Anonymous Coward · 2013-02-06 06:49 · Score: 0
  
  Yet the SDK is? Unlike the SDK, the driver has obviously been available for some time. Samsung licensing and distributing it is another matter.
  So... PCIe daughterboard or thunderbolt peripheral for widespread OpenCL software development using this chip?
15. Re:Anyone make an informed guess as to... by WilyCoder · 2013-02-06 07:27 · 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.
16. Re:Anyone make an informed guess as to... by Anonymous Coward · 2013-02-06 07:48 · Score: 0
  
  Have a nice day, and herp a fucking derp.
  I've heard of speak like a pirate day, is speak like a 12 year old day some new thing?
  Could you explain what libclcoreArm.bc is?
  I have not mentioned mobile devices, only the processor. How is the throughput on mobile I/O connectors these days? Anywhere near fast enough for it to be feasible to interface one to a workstation as an external OpenCL peripheral?
17. Re:Anyone make an informed guess as to... by WilyCoder · 2013-02-06 09:04 · 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.
18. Re:Anyone make an informed guess as to... by Anonymous Coward · 2013-02-06 09:58 · Score: 0
  
  Thank you for the info. Bad day or not, rest assured that I understand perfectly how frustrating the situation with the drivers must be.
19. Re:Anyone make an informed guess as to... by Khyber · 2013-02-06 16:16 · 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.
Hmmm by AdmV0rl0n · 2013-02-06 03:37 · 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 · 2013-02-06 05:28 · 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.
2 whole percent? by abigsmurf · 2013-02-06 03:39 · 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 · 2013-02-06 04:19 · 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 · 2013-02-06 04:42 · 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 · 2013-02-06 05:30 · 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
Texture switching by Hsien-Ko · 2013-02-06 03:44 · 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 · 2013-02-06 05:08 · 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 · 2013-02-06 06:27 · 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 · 2013-02-06 20:56 · 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
Great progress, and thanks for working on this! by Anonymous Coward · 2013-02-06 05:14 · 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!
Re:Well done Luc by Anonymous Coward · 2013-02-06 05:16 · Score: 0, Informative

Hehe :) Wait until the video of my FOSDEM talk is online, that will bring out their friendliest side again :)
--libv
Re:Wow by Anonymous Coward · 2013-02-06 05:49 · Score: 0

That's the most useless comment i've ever seen!
Re:Wow by greenfruitsalad · 2013-02-06 06:29 · Score: 1

and you've just degraded it to the second most useless.
TYPO IN TITLE? by Anonymous Coward · 2013-02-06 07:00 · Score: 0

Why does the title say "Mali" when it's called "lima"? Is this a clever freudian slip designed to promote the immoral and imperious AFRICOM takeover of Mali by US and NATO?
Have Mercy! by Anonymous Coward · 2013-02-06 07:30 · Score: 1

Been humpin' on your mom all day!
In a word... by Anonymous Coward · 2013-02-06 07:34 · Score: 0

Humiliation!
Re:Well done Luc by rephlex · 2013-02-06 20:23 · 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.
Re:Well done Luc by Anonymous Coward · 2013-02-07 03:31 · 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