Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Unknown Lamer posted about a year and a half ago | from the hit-the-fraglimit dept.

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

cancel ×

71 comments

Another cavet (0, Troll)

Anonymous Coward | about a year and a half ago | (#42808553)

Quake 3 is old as shit. Time for a relevant benchmark.

Re:Another cavet (0)

dugancent (2616577) | about a year and a half ago | (#42808887)

Mr. Coward is not incorrect.

Have Mercy! (-1)

Anonymous Coward | about a year and a half ago | (#42809323)

Been humpin' on your mom all day!

Have Mercy! (1)

Anonymous Coward | about a year and a half ago | (#42812095)

Been humpin' on your mom all day!

Re:Another cavet (2)

GrumpySteen (1250194) | about a year and a half ago | (#42809955)

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.

Re:Another cavet (2, Informative)

Anonymous Coward | about a year and a half ago | (#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 :)

--libv

Wow (-1)

Anonymous Coward | about a year and a half ago | (#42808595)

That is the most useless article I think I've ever seen!

Re:Wow (0)

Anonymous Coward | about a year and a half ago | (#42810621)

That's the most useless comment i've ever seen!

Re:Wow (1)

greenfruitsalad (2008354) | about a year and a half ago | (#42811143)

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

Not much in this driver? (3, Interesting)

TejWC (758299) | about a year and a half ago | (#42808625)

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

Re:Not much in this driver? (1)

drinkypoo (153816) | about a year and a half ago | (#42809013)

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.

Re:Not much in this driver? (0)

Anonymous Coward | about a year and a half ago | (#42810261)

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.

Re:Not much in this driver? (0)

Anonymous Coward | about a year and a half ago | (#42811551)

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

Re:Not much in this driver? (3, Informative)

Anonymous Coward | about a year and a half ago | (#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.

Re:Not much in this driver? (0)

Anonymous Coward | about a year and a half ago | (#42818861)

Thank you and keep up the good work!

2% isn't "faster", it's a measurement error (1, Insightful)

Anonymous Coward | about a year and a half ago | (#42808671)

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.

Re:2% isn't "faster", it's a measurement error (4, Interesting)

gmack (197796) | about a year and a half ago | (#42809397)

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.

Re:2% isn't "faster", it's a measurement error (0)

Anonymous Coward | about a year and a half ago | (#42816375)

The Linux people created a free driver that ran a lot faster than the binary driver letting NVIDIA to abandon their driver.

FIFY

Re:2% isn't "faster", it's a measurement error (1)

Khyber (864651) | about a year and a half ago | (#42809761)

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

Re:2% isn't "faster", it's a measurement error (3, Informative)

Anonymous Coward | about a year and a half ago | (#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

Re:2% isn't "faster", it's a measurement error (2, Informative)

Anonymous Coward | about a year and a half ago | (#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:2% isn't "faster", it's a measurement error (0)

Anonymous Coward | about a year and a half ago | (#42818301)

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.

Re:2% isn't "faster", it's a measurement error (1)

Anonymous Coward | about a year and a half ago | (#42819729)

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

Re:2% isn't "faster", it's a measurement error (0)

Anonymous Coward | about a year and a half ago | (#42818291)

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

Re:2% isn't "faster", it's a measurement error (0)

Anonymous Coward | about a year and a half ago | (#42818403)

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.

Re:2% isn't "faster", it's a measurement error (1)

Anonymous Coward | about a year and a half ago | (#42820095)

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 (3, Funny)

zAPPzAPP (1207370) | about a year and a half ago | (#42808693)

if (Quake3) show_fps += 30;

Re:Optimized Code (1, Redundant)

CastrTroy (595695) | about a year and a half ago | (#42808737)

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.

Re:Optimized Code (4, Funny)

serviscope_minor (664417) | about a year and a half ago | (#42808847)

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?

Re:Optimized Code (1)

yabos (719499) | about a year and a half ago | (#42811207)

Quiet, you

Re:Optimized Code (1)

mikael (484) | about a year and a half ago | (#42813513)

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

Re:Optimized Code (0)

Anonymous Coward | about a year and a half ago | (#42818351)

Unfortunately that block of text confirms that this is exactly what's happening.

Re:Optimized Code (1)

Anonymous Coward | about a year and a half ago | (#42821353)

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 (1)

GeekWithAKnife (2717871) | about a year and a half ago | (#42808697)

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.

Anyone make an informed guess as to... (0)

Anonymous Coward | about a year and a half ago | (#42808719)

Cost / performance comparison for thunderbolt OpenCL devices based on the mali t604?

Re:Anyone make an informed guess as to... (1)

WilyCoder (736280) | about a year and a half ago | (#42808757)

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

Re:Anyone make an informed guess as to... (0)

Anonymous Coward | about a year and a half ago | (#42809011)

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.

Re:Anyone make an informed guess as to... (1)

WilyCoder (736280) | about a year and a half ago | (#42809159)

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.

Re:Anyone make an informed guess as to... (0)

Anonymous Coward | about a year and a half ago | (#42809381)

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.

Re:Anyone make an informed guess as to... (1)

WilyCoder (736280) | about a year and a half ago | (#42810451)

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.

Re:Anyone make an informed guess as to... (0)

Anonymous Coward | about a year and a half ago | (#42809475)

ARM have OpenCL drivers [arm.com] , 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...

Re:Anyone make an informed guess as to... (1)

aztracker1 (702135) | about a year and a half ago | (#42809673)

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

Re:Anyone make an informed guess as to... (1)

Khyber (864651) | about a year and a half ago | (#42809941)

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

Re:Anyone make an informed guess as to... (1)

WilyCoder (736280) | about a year and a half ago | (#42810533)

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.

Re:Anyone make an informed guess as to... (0)

Anonymous Coward | about a year and a half ago | (#42810895)

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"

Re:Anyone make an informed guess as to... (1)

WilyCoder (736280) | about a year and a half ago | (#42811033)

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.

Re:Anyone make an informed guess as to... (0)

Anonymous Coward | about a year and a half ago | (#42811467)

Yet the SDK is? [arm.com] 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?

Re:Anyone make an informed guess as to... (2)

WilyCoder (736280) | about a year and a half ago | (#42812045)

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/ [arm.com]

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

Re:Anyone make an informed guess as to... (0)

Anonymous Coward | about a year and a half ago | (#42812313)

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 [insignal.co.kr] 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?

Re:Anyone make an informed guess as to... (1)

WilyCoder (736280) | about a year and a half ago | (#42813449)

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.

Re:Anyone make an informed guess as to... (0)

Anonymous Coward | about a year and a half ago | (#42814075)

Thank you for the info. Bad day or not, rest assured that I understand perfectly [macrumors.com] how frustrating [intel.com] the situation with the drivers must be.

Re:Anyone make an informed guess as to... (0)

Khyber (864651) | about a year and a half ago | (#42809915)

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

Re:Anyone make an informed guess as to... (1)

Khyber (864651) | about a year and a half ago | (#42817163)

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

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

Got a problem, people?

Re:Anyone make an informed guess as to... (0)

Anonymous Coward | about a year and a half ago | (#42810457)

Please do notice that cheap 7" tablet in the video. It's a tad hard to miss.

--libv

Hmmm (1)

AdmV0rl0n (98366) | about a year and a half ago | (#42808775)

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.

Re:Hmmm (1)

citizenr (871508) | about a year and a half ago | (#42810303)

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

2 whole percent? (4, Interesting)

abigsmurf (919188) | about a year and a half ago | (#42808777)

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?

Re:2 whole percent? (1)

Bigby (659157) | about a year and a half ago | (#42809325)

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.

Re:2 whole percent? (1)

drinkypoo (153816) | about a year and a half ago | (#42809619)

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.

Re:2 whole percent? (1)

Anonymous Coward | about a year and a half ago | (#42810347)

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 (3, Informative)

Hsien-Ko (1090623) | about a year and a half ago | (#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

Re:Texture switching (1)

Khyber (864651) | about a year and a half ago | (#42809971)

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

Re:Texture switching (1)

BitwizeGHC (145393) | about a year and a half ago | (#42811103)

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.

Re:Texture switching (1)

Hsien-Ko (1090623) | about a year and a half ago | (#42818265)

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

Well done Luc (-1)

Anonymous Coward | about a year and a half ago | (#42809801)

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.

Re:Well done Luc (0, Informative)

Anonymous Coward | about a year and a half ago | (#42810105)

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

--libv

Re:Well done Luc (1)

rephlex (96882) | about a year and a half ago | (#42818111)

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

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 (1)

Anonymous Coward | about a year and a half ago | (#42820333)

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

Great progress, and thanks for working on this! (2, Insightful)

Anonymous Coward | about a year and a half ago | (#42810083)

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!

TYPO IN TITLE? (0)

Anonymous Coward | about a year and a half ago | (#42811641)

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?

In a word... (0)

Anonymous Coward | about a year and a half ago | (#42812151)

Humiliation!

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...