Quake III bounty: we have a winner

http://www.raspberrypi.org/archives/6561

by benn_88 • 12 years ago

288 82 12 years ago

Luc• 12 years ago

How very cool. I didn't see any mention of the frames per second that can be expected other than the 133 FPS in the screenshot, but I assume that's not from a Raspberry Pi!

buro9• 12 years ago

The screenshot comes from here:

http://blogs.wefrag.com/cedzekill3r/2010/04/24/fps-engine-id...

Definitely not a Pi.

johnchristopher• 12 years ago

Haha, is that the day HN meets NoFrag ? :)

rangibaby• 12 years ago

IIRC it was highly possible to get 60FPS even on old hardware ~10 years ago.

Macuyiko2• 12 years ago

I remember playing Quake III on a 450Mhz with 60FPS. So yes, it might well be possible.

Cyph0n• 12 years ago

That is so damn cool! I need to get started on my Gameboy Color emulator.

fit2rule• 12 years ago

Very cool - hope this becomes a template for other companies as to how to properly handle open sourcing the various important parts of the stack in the future. Seems like this is a very smart move by Broadcom - as demonstrated by the community response, which is mostly positive.

zanny• 12 years ago

Intel / AMD should be the template - actually hiring FOSS hackers to make you a proper driver for whole-stack support.

It is nice that they released an older chips driver code, it is better than nothing (and better than just programming manuals) but we have companies like Qualcomm with the Atheros driver, Intel with their wifi, gpu, and ethernet drivers, and AMD with their chipsets, gpus, etc all contributing engineers in the kernel to make foss drivers, and we shouldn't give any company too much credit for doing any less than the same.

hrjet2• 12 years ago

It is nice, but a little late for many people. Couple of years back when I was investigating the RaPi for building a video recorder, the lack of open video drivers prevented me (and apparently many in the forums) from integrating camera modules. I ended up using the TI boards, which have open source stacks since a long time now.

beagle32• 12 years ago

The RPi video core driver might not be fully open, but it has a usable camera API and video compression API.

Which boards are those? I didn't find a single board that had an open video driver - not Allwinner based ones, not Beagle Bone Black (no encoding/decoding hardware at all).

baldfat• 12 years ago

Quote "Very cool - hope this becomes a template for other companies as to how to properly handle open sourcing the various important parts of the stack in the future."

I DON'T it was A) Not a driver (They should have made the driver and released it B) Use the actual chipset not one removed chipset and have people hack on it for money.

xedarius3• 12 years ago

Shocking that the PI can produce 133 fps and my 27" iMac Quad core monster gets a random and feable 70-90fps.

Nice work though Simon.

Kliment• 12 years ago

That image is not from a Pi

xedarius3• 12 years ago

Fair enough.

Macuyiko2• 12 years ago

If you're only getting 70-90 FPS there must be something badly broken with your iMac. The thing should be able to run at 125 FPS (capped) on high res without breaking a sweat.

xedarius3• 12 years ago

Yeah I agree, I did quite a bit of looking into it as well. In bootcamp I was able to manage a solid 125fps, yet when in OSX it varied between 70-90.

Although I performed many tests I was never able to get the bottom of it.

Amadiro• 12 years ago

Check if your iMac defaults to software rendering for some reason.

raverbashing4• 12 years ago

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

Or, you know, use a cross-compiler?

warsheep• 12 years ago

You probably already know this, but setting up a cross-compiler toolchain is a super annoying task, and is very dependent on the distro you're using. I'm sure the author knows about cross-compiling, but he probably preferred clear instructions that work for any RPi user.

There might be even stronger reasons to not use cross-compilers such as weird bugs or compiler version compatibility issues.

pjc502• 12 years ago

Indeed. Either you give distro-specific instructions (long) or you make people build a gcc cross-compiler from scratch (also long) or you gloss over that bit (prone to failure).

Many Pi users' only linux system is the Pi.

raverbashing4• 12 years ago

"You probably already know this, but setting up a cross-compiler toolchain is a super annoying task"

Yes, I agree 100%, building a cross-compiler is a very complicated task.

But I think with the weight of the Raspberry Pi projects this should have been easier. This is a good project http://buildroot.uclibc.org but unfortunately it's very unstable.

captainmuon• 12 years ago

I wonder why its so hard? I once built a modern gcc + glibc in my home directory on an older linux (to be able to run modern programs), and it was mostly "relocatable" or "portable" (what I mean is that you could copy it around and run it from other directories).

Couldn't somebody build a full cross-compiler toolchain as "relocatable" binaries, depending on an older kernel, and then just offer that as a binary download to run on most recent distributions? It's not a typical way to distribute a linux application, but it should work in principle.

jevinskie• 12 years ago

I use crosstool-ng to do the heavy lifting for me. [0] But lately I've been trying out musl-cross to get nice, self-contained static binaries. [1]

[0] http://crosstool-ng.org/

[1] https://bitbucket.org/GregorR/musl-cross

akerl_• 12 years ago

I'm not familiar with the fine print, but given the nature of the challenge it certainly seems a lot cooler to me that it can be done fully by the Raspberry Pi.

j-b• 12 years ago

From the article: "If you cross-compile you can get better frame times."

bluedino• 12 years ago

You've got twelve hours. Today's 4/6/8 core CPU's with an SSD can build a Linux kernel in what, 5 minutes tops?

I built one on an old Xeon in something like 4 minutes and it took 3x as long to upload/download the files to the system I wanted to use it on than it did to build it.

Nanzikambe• 12 years ago

Compiling a vanilla kernel on x86 hardware is one thing, building an ARM kernel is quite another in terms of performance, or at least that's been my experience.

To give you an idea of how bad the difference is, to compile the Linux kernel in defconfig, using 2 distcc boxes each with AMD FX8320 3.5ghz (8 core) + 32gb ram + 1gb LAN. The x86 stuff boot off RAID1+0, the the PI obviously off its sdcard, here's what happens:

  * Compile for armv6 on pi host + distcc compile farm: 19 min 11 sec
  * Compile for armv6 on qemu host + distcc compile farm: 29 min 36 sec
  * Compile for armv6 on x86_64 hardware + cross toolchain + distcc compile farm: 1 min 59 sec
  * Compile for x86_64 defconfig on off-the-shelf x86_64 hardware (also fx8320) + distcc compile farm: 1 min 31 sec

That's compiling "linux-3.6.9999-raspberrypi.tar.bz2" with -j20 across the board. I realise there's a number of problems with this "test" - obviously the last two are unfair, the PIs laughable shared bandwidth across network & usb gimp it horribly. I have no idea why qemu is so bad though, I pointed it at an img taken from a running PI vOv and I've probably done a million other things wrong getting the numbers.

But to anyone intending to compile armv6 crap on a pi or qemu based compile farm: unless it's a one off thing or your time is worthless, don't do it. Invest the time getting crossdev, crosstool-ng etc + dist cc working properly. I only bothered because I was looking for a better way to build stuff for Android and used the setup as a testbed.

PlaneSploit• 12 years ago

They explicitly recommend using a cross-compiler.

spiritplumber• 12 years ago

Maybe it's because I'm a tub of noob (EE here, I only write code when my hardware demands it) but setting up crosscompiling the Android kernel was physically painful, and it's one of the best-documented things out there.

mdwrigh22• 12 years ago

Cross compiling the Android kernel is fairly straightforward. Download the whole Android source tree, source build/envsetup.sh, lunch the target you want, export ARCH=arm, SUBARCH=arm, CROSS_COMPILE=arm-eabi- and then build away in the kernel repository. Honestly, the easiest cross-compiling I've had to do this side of Go.

aray• 12 years ago

Just to separate the problems:

Building a cross-compiling toolchain is hard. Totally understand that. Android [0] and Linaro [1] both provide pre-made pre-tested builds you can just pull and use. I recommend using them.

Building the kernel itself. As mdwrigh2 pointed out, this is actually pretty easy. Also the kernelnewbies community is here to help!

[0] http://s.android.com/source/building-kernels.html

[1] https://launchpad.net/linaro-toolchain-binaries

icefox• 12 years ago

An alternative to a cross compiler is to just use distributed compilation and set the current box to 0 so all jobs get distributed to other faster x86 boxes. In the past I regularly used this to build arm on a x86 and more fun building for OSX ppc on x86. ./configure and basic make stuff occur on the "slow" arm/ppc, but the actual build jobs are sent out to the farm for building.

dave1010uk• 12 years ago

This is really great! I'd be interested to know what framerate the Pi can output at 1080p.

Someone ported Quake 3 to ARMv6 Symbian smartphones in 2008 [0]. I remember running this on a Nokia E90 Communicator and the framerate was over 15fps most of the time.

[0] http://koti.mbnet.fi/hinkka/Download.html

DanBC3• 12 years ago

The competition rules said at least 20 fps, which seems playable.

fooqux• 12 years ago

I used to run Doom 2 on my 386sx. Doom 2 required a math co-processor, which the sx didn't have, so I had to use a TSR which emulated one, slowing my CPU down even more. It probably ran at 1-2 FPS, but it was "playable" enough for me to spend countless hours playing it. Ahhh, memories...

So yeah, 20 FPS is definitely what I would call playable. ;)

shinratdr• 12 years ago

On an N95 I remember it running even better than that. That port was actually amazing, and it even supported a full KB & Mouse via Bluetooth.

ekianjo• 12 years ago

Not sure about the Pi, but the Pandora which has similar ARM class of hardware can run Quake 3 at 25-30+ fps in 800*480 resolution. The GPU of the Pi may be more powerful while its CPU is weaker.

mk3• 12 years ago

What interests me is what are implications for general computing performance while using GUI/xServer on raspbian or raspBMC? As I was told rPi has ridiculously powerful GPU compared to processor, but basically it's unusable due to lack of proper driver support. With such quantity of Raspberry Pis sold one would expect more support from Broadcom.

dannypgh• 12 years ago

Not sure if you saw http://www.raspberrypi.org/archives/6299 but even before then I'm not sure I would imply that Broadcom hasn't been supportive. The thing was designed by someone employed full-time as a Broadcom engineer, after all.

chmullig• 12 years ago

Such quantity? It's like 2 million units. That's roughly equivalent to a mildly popular android phone model.

Pxtl• 12 years ago

I don't know much about the q3 infrastructure - does Q3 use DLL mods or some kind of bytecode? I'm curious if this means that all the Q3-based standalone games - OpenArena, Smokin' Guns, Q3Rally, etc. can get a RasbPi distribution, that would breathe some new life into those old projects.

dmead• 12 years ago

you've got the option. IIRC, q3 itself generally runs bytecode blobs rolled by ID and compiled with their speical tool to that does quakeC -> qvm. q3 based games generally have compiled dll or .so files that may or may not make external OS or library calls.

source: i cloned orange smoothie pro for jk3

Quake III bounty: we have a winner

Related Stories