MultiQuake - Quake for Mellanox TILE-Gx CPUs

Nils L. Corneliusen
5 May 2014 - 4 Aug 2016


As always, writing code for the Tilera Mellanox TILE-Gx36 CPU is pretty cool: 36 cores, lots of cache and a very simple interface to make things run in parallel. As I've already ported Doom to the TILE64 and TILE-Gx, let's see if Quake will run on it too. Well, not just one, but a screenful, each on a separate core.

The Quake source code for Quake is available from GitHub. It's easy to get it to compile and run by using the sys_null.c/vid_null.c etc. driver files and then edit them as needed. It's gonna run natively on the TILE-Gx this time, so I skipped using the SDL port, which is available here.


MultiQuake 2

I've added a main_tilegx.c file that does the parallelization and reads command line arguments to control the number of cores, scale factor and output. To pass arguments to the Quakes, please modify the quake_main function in sys_tilegx.c. Should probably merge those two files, but I already had a similar main_tilegx.c in the Doom port that I could recycle.

Output is done via an external viewer. A file, /tmp/quakescreen, is mmap'ed as a width*height*4 buffer which the viewer converts to the correct format and sends to the output. This viewer is copyrighted, so I can't supply the code for that. A minor problem is that there's no frame synchronization apart from the Quake internal timer stuff. This doesn't seem to be a big issue; it runs very smoothly on the Cisco SX80.

The GitHub version does have one jarring bug: If screen size is different from 320x200, it'll crash when the player is under water. So, to avoid that, I made some custom TILE-Gx based scaling routines in vid_tilegx.c. The annoying part is that this'll scale everything, including GUI and fonts. However, the fun part is running many Quakes, and then the scaling won't be used. I tried adding EPX routines for 2x and 3x scaling. While they were nice in Doom, they're not as nice in Quake. Oh well, the code's there, so either use it or don't.

Input is done by remote control. Yeah, it's terrible, but I got no keyboard driver on this box. If/when it's added, some more remapping must be done in sys_tilegx.c. Console output is mostly disabled. The amount of output is staggering when there's 30 running at once. Now it just prints out which demo is playing on which core. Since there's only 3 demos in the shareware version, one is picked at random and a delay is added at the start to keep things running a bit out of sync.

Some other minor fixes have been done here and there, mostly to get gcc to stop spamming useless warnings. I hardcoded gamma and viewsize; search for "fix:" since I never found out how to override the defaults.

So, does it work?

MultiQuake Top

Oh yes! 30 running at the same time; 60ish percent load per core. Core 33 is running the output driver, so ignore that.

MultiQuake 1

Enough talk, where's the code?

Source code (zip archive):

I removed all unused files from the directory, so it's reasonably compact. If you find a bug, send me a diff or tell me about it and I'll make a new release.

Note: Please add -m32 to the makefile, otherwise it'll crash when starting single player. Guess it wasn't totally 64-bit safe.