The Art of PS3 Programming

The Guardian Gamesblog has a longish piece talking with Volatile Games, developers of the title Possession for the PS3, about what it's like to make a game for Sony's next-gen console. From the article: "At the end of the day it's just a multi-processor architecture. If you can get something running on eight threads of a PC CPU, you can get it running on eight processors on a PS3 - it's not massively different. There is a small 'gotcha' in there though. The main processor can access all the machine's video memory, but each of the seven SPE chips has access only to its own 256k of onboard memory - so if you have, say, a big mesh to process, it'll be necessary to stream it through a small amount of memory - you'd have to DMA it up to your cell chip and then process a little chunk, then DMA the next chunk, so you won't be able to jump around the memory as easily, which I guess you will be able to do on the Xbox 360."

Comments

It uses OpenGL

[AKAImBatman]

Apparently, the machine's use of Open GL as its graphics API means that anyone who's ever written games for the PC will be intimately familiar with the set-up.

As a programmer, I can attest to OpenGL being a God-send. Not only are programmers intimately familiar with the technology, but it was designed from the beginning with portability in mind. Direct3D, OTOH, tends to follow Microsoft's practices of hiding what's really going on behind the scenes. It's been a little while since I've bothered with Direct3D, but one of Microsoft's biggest features used to be their own SceneGraph known as "Retained Mode". For some reason, Microsoft believed that everyone would want to use their Scenegraph only and damn technological progress. Most programmers who were in the know immediately bypassed this ridiculousness and went straight for the "Immediate Mode" APIs, which weren't as well documented. (Thanks Microsoft)

Wikipedia has a comparison of Direct3D vs. OpenGL here: http://en.wikipedia.org/wiki/Direct3D_vs._OpenGL

Other than that, a computer is a computer, and game programming has always required a strong knowledge of how computers operate. So it's not too surprising that it would be "just like any other programming +/- a few gotchas".

Re:It uses OpenGL

[amliebsch]

Thee article you cite to doesn't really support your conclusion of OpenGL being a "god-send." Instead, the article seems to conclude that at this stage, for all intents and purposes, the two APIs are functionally equivalent.

Re:It uses OpenGL

[AKAImBatman]

Thee article you cite to doesn't really support your conclusion of OpenGL being a "god-send."

OpenGL is a God-send for a couple of reasons, IMHO:

1) The API is well known by developers, and has remained stable from version to version. This reduces the amount of R&D and training that need to be done for a game.

2) Use of OpenGL allows for portable code. While you can't completely get away with writing the same code between a PC version and a Console version, much of the rendering engine at least has a chance of getting reused.

3) Carmack says so. ;-)

4) New features actually go through a standards process, meaning that they get more documentation than just "whatever Microsoft feels like telling you".

5) DirectX is a non-portable skill. It ties you to Windows and the X-Box(s). OpenGL "ties" you to the Gamecube, Windows, PS2, PS3, Linux, Macintosh, etc.

That's my opinion, for what it's worth. That and 50 cents will get you a cup of coffee, so take it as you will.

Re:Yet another reason

[BillBrasky]

Keep in mind that all the "extra" cores are special-purpose cores that can only execute code specifically written for them. They are not general-purpose cores so you can run 16 applications simultaneously. Also consider that the CPUs for the new consoles are targeted at consoles and not multitasking operating systems with lots of context switching. There's also the roadmap issue. Sure, this one processor will be available, but what about speed bumps and future generations?

Re:8 Threads?

[Dr. Manhattan]

I'm still baffled into how you can efficiently break up a game into 8 threads.

TFA says they are contemplating a job-queue organization, with cores taking jobs as they become available. Provided the size of the 'jobs' are limited so they fit comfortably within the overall time it takes to calculate a frame, it should work fairly well. A lot of physical-simulation problems are close to 'embarassingly parallel', anyway.

Re:8 Threads?

[karnal]

One thing to think about though, regarding threading.

Just because you have critical sections in one thread that may have to hang out waiting for another thread, doesn't mean that at some point in time the two threads can't execute simultaneously while not needing data from one another. At times like that, you get speedup (especially since you have seperate cores/processing units/whatever)

Missing the point.

[Anonymous Coward]

A lot of people seem to be approaching the concept of the Cell processor improperly. The chip itself is not designed for the "Design a game in 8 threads" approach people seem to be thinking of. It's designed based on a forman/worker metaphore. The main chip handles the work of figuring out what comes next, the SPE's do the heavy lifting.

Don't think
Processor 1 = AI
Processor 2 = Physics
Processor 3 = ...
etc.

Instead picture the main CPU going through a normal game loop (simplified here)
Step 1: Update positions
Step 2: Check for collisions
Step 3: Perform motion caluclations
Step 4: AI

At the beginning of each step the main CPU farms out the work to the SPE's. So, you have a burst of activity in the SPE's for each step, thun a lull as the main core figures out what to do next.