At the end of February, Broadcom announced the release of full documentation for the VideoCore IV graphics core, and a complete source release of the graphics stack for the BCM21553 cellphone chip. To celebrate, we offered a $10k prize to the first person to port this codebase to the BCM2835 application processor that sits at the heart of the Raspberry Pi, and to get Quake 3 (which already runs on the Pi) running on the newly open ARM driver, rather on the closed-source VPU driver. Our hope was that the ported driver would be a helpful reference for anyone working on a Mesa/Gallium3D driver for VideoCore IV.

Hands up if you spent far too long playing this when you were young.

I’m delighted to say that we have a winner. Simon Hall is a longtime Pi hacker, who also produced the first ARMv6-accelerated copies-and-fills library back in 2012 and wrote the DMA kernel module that we integrate in our Raspbian releases. The prize couldn’t have gone to a more fitting recipient.

So, without further ado, here are Simon’s instructions for getting the driver up and running.

SETTING UP THE DEVICE

You will need:

a Raspberry Pi, preferably a 512MB version, with the latest Raspbian

a network connection

a monitor capable of displaying 1080p

an SD card, at least 8GB (10GB is recommended)

We need plenty of space to build the kernel. Compiling will take around 12 hours, so it is helpful to overclock the Pi for this task. We also require the latest firmware, and the necessary packages we’re going to use to build the code.

Note: We’re going to use gcc 4.7, as the code generated is 10% faster than with 4.6. 4.8 is 10% faster still, but this is not available on Raspbian. If you cross-compile you can get better frame times.

Enter the raspi-config utility with:

sudo raspi-config

Expand the filesystem, set the overclock to at least medium (900 MHz), and reboot. Now perform an update with:

sudo rpi-update

and reboot again. We need to install several packages. Enter the following command to do this:

First of all you must ensure that you have the Quake 3 Arena data files on your Pi. You require the ‘point release’ pak files installed. There are various ways to do this but you could either transfer them from another machine with SCP, or copy them across on a USB stick. Copy the files into a folder called ‘baseq3′. This should now contain pak files numbered from 0 to 8 (eg pak1.pk3).

If you wish to play the game after a reboot, you must run the following commands to re-load the necessary files:

cd ~/dma
./install.sh

If you see multi-second pauses of the game, this is because the system is paging to swap! You can see this by running top at the same time, and watch the swap usage jump during a spike. Close some running programs to alleviate this problem. Running the game without gdb and loading minimal kernel modules will prevent swapping.

I think the RPi will make a better streaming device than the Apple TV … with the new driver even more optimised in a few months the RaspBMC build will be even more snappier .. (not that it already isnt :P )

I’d imagine as not everybody who would want to compile the new kernel wants to set up a cross-compiler although I’d imagine that it would be a lot faster to cross-compile. And the instruction for the pi would be the same for everyone whereas cross-compiling would have lots of different instructions.

I imagined a world in which there were no OS X or Windows users to worry about, this is not the case.

I have a cross toolchain set up for ARMv5, in fact, I have it by accident(I’ve never used it). Just now I confirmed that it works perfectly out of the box though.
If only it could be this way on OS X and Windows.

This is a really exciting first step for a fully FOSS graphics stack on the Raspberry Pi (and a great achievement for Simon Hall), but there’s a way to go before we’d want to ship this as the default. If the kernel patch can be made minimally invasive and toggleable at runtime, I for one would be interested in providing it as a switchable option for people wanting to experiment. Of course a bigger question is what direction should FOSS graphics on Raspberry Pi (VideoCore IV) take. Is the best way to continue development of the BCM21553 code generously open sourced by Broadcom or would it be better to use it as a reference for integration of VideoCoreIV support for Mesa/Gallium?

See my reply above regarding ‘integration into Raspbian’ (I speak about the Foundation Raspbian image you get from the downloads page). This graphics driver will only be used by applications using OpenGL ES, just like the current VideoCore IV graphics driver.

I always try to provide an upgrade path for people with older images. If it needs anything more than an apt-get update/upgrade it will be documented on the blog post announcing the image (possibly by me dropping by the comments).

Perhaps, perhaps not. Note that the graphics stack has moved from the Videocore vector/scaler processor which runs at 250Mhz, to the Arm at 700Mhz. But the ARM is also running all the GUI, apps etc. So the likelihood is that this stuff might be slower once the workload is taken in to account – you are now not taking advantage of the videocore CPU to run stuff in parallel.

This is an important point. This is an important milestone for FOSS graphics on the Raspberry Pi, but for the reason James states you’re likely to see some performance degradation. Very likely stability regressions as well. This isn’t something that’s going to directly benefit the end user right now, but is obviously super helpful for anybody wanting to further develop the driver or indeed a Mesa/Gallium VC4 driver.

James – When you say “the graphics stack has moved from the Videocore vector/scaler processor which runs at 250Mhz, to the Arm at 700Mhz”, do you mean the local graphics-data structures/variables (including those declared static) that are used to make calls into OGLES, etc., or something else? I haven’t waded through all of the GPU docs yet, so it’s not clear to me yet what’s where in a typical Python program that’s making OGLES calls (e.g., Pi3D) and if that differs from the C OGLES examples in /opt/vc/src/hello_pi. This could have some very interesting ramifications, although it also suggests a 256 MB Pi might need a bit more care and feeding if the GPU has 128+ MB allocated and there’s some fat, lazy stuff sitting in ARM CPU RAM, especially if swapping is disabled. Thanks! The Other James ; )

Now let’s all buy even more RaspberryPis to convince Broadcom that opening the specs was a smart move.
On a related note, as nobody seems to have mentioned it yet, if you do have multiple Pis you should be able to use distcc to build the kernel in some fraction of the 10h time that it would take on a single Pi. While I haven’t built the Pi’s kernel like this, I have built other kernels with a mix of distcc and cross-compilers on a bunch of machines each with different CPU architectures.
The instructions for using distcc are actually quite simple and it shouldn’t take more than 10 to 20 minutes to read up on it and set it up properly. A quick search turned up instructions for doing this on Gentoo, but it should be the same for all Linux platforms:http://www.gentoo-wiki.info/HOWTO_Compile_Kernel_With_Distcc_and_CCache
That page also includes setting up ccache, which is a method of caching compiled object files so that they don’t have to be recompiled the next time you run a make and the original source file wasn’t modified. It’s useful if you’re changing the source, but most readers here won’t be doing that. It could still be useful if/when the upstream git tree is updated, though, as it will save you from having to do a lot of recompilation (though you may want to have more than the recommended 10Gb storage space if you’re caching compiled files with ccache).

Yes, it does. We’re not developing a version of Android here (it doesn’t fit with our educational mission), but this enables the community that wants Android to develop for the Pi themselves, where previously the closed drivers prevented them doing that work.

This is brilliant. You’ve just published something that sparked an interest in the RPi from my fourteen year old. I, simply, asked him “Would you like your RPi to run Quake?” and got a positive answer.

With a list of tasks I can take checkpoints to see how he’s going.

When it comes to the 10 hour task we’ll leave that running over night.

The Pi has always been able to run Quake3, using the closed source Videocore drivers. It was one of the first things I did with my 256mb first release version Pi. It runs quite admirably at 1080p (and that was with soft-float, before Raspbian, I’m sure it runs a bit better now)

Argh! While I generally like immersive designs, this new design for the site is painful, unprofessional, and very off-putting. If I may suggest, perhaps have the site use the old theme, and make this theme an option or an Easter Egg. When designing a home page, keep in mind that people will be visiting who aren’t interested in the Pi, but just want to know what its about. Assume your audience is stupid and you’ll have a very successful design. Assume your audience is educated and knowledgeable and everything falls to bits. I’m in college for this sort of thing, and this is an excelent example of what NOT to do.

Ummmm, I don’t want to be the one who said, “The Emperor isn’t wearing any clothes!”, but I think that in the process of “upgrading” the kernel, Simon blew out all of our GPUs!!! Mine refuses to show anything but Christmas-colored Courier in 12-point anymore! For this we need parallel pipelines???

GREAT FUN, FOLKS!!! First, they release the Pi on the world, then they get Broadcom to allow open-sourcing of the GPU driver, and now this. What’s next, Zork … in 3-D lettering??? :lol:

If you insert any of the standard emoticons such as :lol: ( : lol : without spaces ), it appears that the text of the emoticon is suppressed (by WordPress?) and, of course, there is no graphic icon displayed. Now, watch and see that the :lol: above is displayed, just to mess with me! Here’s a test of all of the emoticons, in case some of them aren’t suppressed: :D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:

I was wondering why the name Simon Hall was so familiar, and then I realised he was the guy that ported Quake and Quake II to the DS way back! Absolute legend in the DS homebrew community, and seems to have a bit of a thing for porting Quake :D

Yes. If you use this driver. I am not aware of it being included by default in any repos or with Raspbian, correct me if I’m wrong anyone. I would really like to see a more official way to do this for future use :)

In the mean time the next chance I get I will be compiling this and loading it on my Pi. Thanks Broadcom, Raspberry Pi Foundation and Simon for liberating the Pi! :D

So I followed everything and built the kernel just fine. When I compiled the dmaer.c it built fine but I’m getting an error running the install.sh in ~/DMA. I’m not in front of my pi right now. But the v3d (I think is what it is) module is not correct or won’t start. And checking the Kern.log I’m definitely not getting the same as the example output. Any ideas?

Nice job. Though it does not meet the requirements set out in the original request.

The original challenge required a fully open source implementation. Using the Linux kernel and the ID Software engine both restrict the source do to the limits of the GPL and thus this is not a FULLY OPEN SOURCE implementation. This is a well done restricted Open Source implementation though.

I do look forward to someone completing the challenge as originally outlined.