GPGPU & LLVM

The LLVM group has just got a new logo, a modernized version of the 'dragon book' dragon. But the real exciting news I saw on GPGPU.org is a project 'GPUocelot'. This program will translate compiled PTX programs (produced by nVidias CUDA) via the just-in-time LLVM compiler to any targeted backend, meaning for example a PS3 CELL processor. All you need to do is add an AMD backend to LLVM, and hey-presto, instant CUDA-for-ATI. That could potentially put a dent into OpenCL's plans..

The papers from the High Performance Graphics conference are also out, one that caught my eye was Understanding the Efficiency of Ray Traversal on GPUs, not really because I thought the paper was fundamentally groundbreaking, but because it explained a few neat tricks on nVidias part, in particular, a good explanation of persistant threads in CUDA for breaking down non-uniform workloads from a global pool. (eg: They used it on a per-ray basis, so that fast and slow rays don't "block" each other.)

Virgin Airlines

Virgin airlines canceled my flight.
Needless to say I'm pretty annoyed.
They informed the passengers in the most elegant of ways, they changed the sign from "boarding" to "canceled".
Nice work.

Never flying virgin again, I think the extra $30 for Qantas is well worth it, I mean, you get a free meal too right?

Fracture Physics

Eric Parker from Pixelux and James O’Brien have just released their paper Real-Time Deformation and Fracture in a Game Environment. It's an interesting read, and reveals some of the details behind the impressive Pixelux engine. Basically they use tetrahedral finite elements and just make it look like it has more detail than the physics really has. Still, seems to work pretty well.

Of note from the demoscene world is h4vok by Archee which features fractures in 4k, nicely timed to music. Very impressive.

Groundwater Flow on GPU

I am presently developing a proof-of-concept groundwater flow GPU program. The algorithm works similar to a finite differences algorithm, or many kernel-based image processing systems.

Initially I just ported the code over to CUDA, and thanks to having done this a few times before the CPU version I wrote was easy to transfer. A good time saver is to use macros to index arrays, etc. This makes it easy to swap in __mul24, or tex2D etc. later.

The next step was to use shared memory to buffer the input data, this gave the biggest performance boost. Finally I did some arithmetic optimizations for another small gain.

On the advice of a friend I tried re-structuring the GPU program to use 'aprons' similar to the 'Separable Convolution' SDK sample, and tried restructuring read/writes. This all made almost no difference at all, so it seems that the 'sweet-spot' can be hit quite quickly as soon as you have done the obvious shared memory and arithmetic optimizations. The overall structure of the program seems to make little difference.

A common bit of advice is to leverage the texture units on the GPU's, but a simple modification of the 'Texture-based Separable Convolution' sample program, reveals it is infact almost twice as slow as the non-texture based. Seems like the texturing unit speedups are a bit of a myth.

Benchmarking the program has been a bit of a problem, since it is very dependent on the type of GPU you have, and the problem size. If I process a few hundred thousand nodes, the speedup is around 15x over the CPU, but when I move to processing tens of millions of nodes, the speedup is over 20x. Processing the same data on a slightly older GPU will only give a 4x speedup (Compute 1.0).

All in all I've found it extremely difficult to give an overall answer on the performance gain of the GPU. It seems to be highly dependent on the problem size (the bigger the better - thank god!) and the GPU technology (this is going to make porting the software to multiple GPUs a pain!).

MAGIC 2010

Do you remember the DARAP Grand Challenge? Well now the Australian DSTO is holding its own challenge, the Multi Autonomous Ground-robotic International Challenge (MAGIC 2010), with a total of $1.6 million US in prize money. The goal is to use a multi-robot team to perform "intelligence, surveillance and reconnaissance mission in a dynamic urban environment."

The MAGIC requires entrants to complete the following tasks:
(i) Accurately and completely explore and map the challenge area;
(ii) correctly locate, classify and recognise all simulated threats; and
(iii) complete all phases within 3.5 hours.

The final event is scheduled to take place during the week of November 8, 2010, somewhere in South Australia.

I'm putting together a team from WA, if you are interested let me know.
The participants conference is in Adelaide next week. See you there!

15 ton Wiimote robot

Apparently the Transmin software team are famous now. Simon Wittber and Dan Adams modified our grapple control system to work with the Wiimote.

There is a video out on youtube:


I haven't seen it on the usual sites I watch, but I guess I'm reading the wrong stuff..

Simple bootloader

Writing your own OS is something every computing person should do at some point. The first step is of course writing a boot loader. This is actually very easy to do under linux.

With a fresh install of ubuntu, make sure you have GCC and related goodies, the other things you will probably want are nasm, and virtual machine like QEMU. Installing these in ubuntu is as simple as:

sudo apt-get install nasm
sudo apt-get install qemu

(you may need to modify your /etc/apt/sources.list - any core ubuntu mirror will do, I used au.archive.ubuntu.com/ubuntu)

Now you probably want to try qemu out before going further, so grab freedos:
http://www.freedos.org/freedos/files/ and grab an iso, I got fdbasecd.iso

Now we create a virtual hard drive to install freedos on to: (do this in the same dir as the iso)

qemu-img create -f raw freedos.img 100M

And then we just boot up qemu:

qemu -localtime freedos.img -cdrom fdbasecd.iso -boot d

Freedos install is a bit obtuse, you need to format the drive to FAT16, exit the formatter, then again to FAT32, but I just pretty much just went with the defaults for everything, afterall, this is just for testing. At then end, you should have a working DOS prompt.

Now that we have QEMU working and we know it, let's try our own boot loader:

[BITS 16]  ; 16 bit code generation
[ORG 0x7C00]  ; ORGin location is 7C00

;Main program
main:   ; Main program label

mov ah,0x0E  ; This number is the number of the function in the BIOS to run.
   ;  This function is put character on screen function
mov bh,0x00  ; Page number (I'm not 100% sure of this myself but it is best
   ;  to leave it as zero for most of the work we will be doing)
mov bl,0x07  ; Text attribute (Controls the background and foreground colour
   ;  and possibly some other options)
   ;  07 = White text, black background.
   ; (Feel free to play with this value as it shouldn't harm 
   ;  anything)
mov al,65  ; This should (in theory) put a ASCII value into al to be 
   ;  displayed. (This is not the normal way to do this)
int 0x10  ; Call the BIOS video interrupt.

jmp $   ; Put it into a coninuous loop to stop it running off into
   ;  the memory running any junk it may find there.

; End matter
times 510-($-$$) db 0 ; Fill the rest of the sector with zeros
dw 0xAA55  ; Boot signature

Save the code to loader.asm, and assemble it with:

nasm loader.asm

Then, we can run our wonderful loader with:

qemu loader