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

[jinzumkei]

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.
Uh most games nowadays use D3D.

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.
If you write a flexible enough rendering engine this wont matter so much.

3) Carmack says so. ;-)
yeah, ok. good reason

4) New features actually go through a standards process, meaning that they get more documentation than just "whatever Microsoft feels like telling you".
Which also means it takes long YEARS for a new version to come out, how long have we been waiting on OpenGL 2.0? Some cool things have come out since and OpenGL is always playing catch now.

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.
Graphics Programming is a portable skill, I've never met a good graphics programmer who couldnt switch between the two on the fly. Honestly if you can only do graphics in 1 or the other that's pretty worthless.

I'm sorry the whole DX vs OGL war is really old and really lame, Neither are a "god-send". They are both tools, use the one that is best for the job.

Re:It uses OpenGL

[Haeleth]

[Retained Mode] was stupid to begin with, yet Microsoft kept pushing it version after version. I know it was still there at least as high as DirectX 5.0.

Look, you're welcome to hate Microsoft if you choose, but your memory is rather inaccurate.

Get this: Retained mode was not meant for games. Microsoft never "pushed" it for games. Immediate mode was always there for games to use. Games were always supposed to use immediate mode.

It's been a while since I read the documentation for ancient DirectX versions, but IIRC it actually said, right there, quite explicitly, in the documentation, that retained mode was not meant for high-performance graphics and that games should use immediate mode.

The idea of retained mode was that it provided a much simpler interface. It was intended for use by multimedia applications that did not require the power and flexiblity of immediate mode, but just wanted to throw a few 3D meshes on screen and move them about a bit, without all the hassle of coding all the data structures and transformations by hand. It didn't catch on, and it eventually died, but it wasn't stupid by any means, and something very similar will be making a comeback in Windows Vista.

At least, I say it wasn't stupid. Maybe it was stupid. I don't see how providing a simplified API for simple applications, and a complex API for complex applications, is "stupid", but then I use Microsoft software out of choice, so clearly I don't hate Microsoft badly enough yet for me to be able to judge their decisions objectively.

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)

Re:8 Threads?

[astromog]

What I find interesting about the question of "What can I do with 8 threads?" is that most people seem to assume that you can only have one graphics thread. Why not have 2? Or 3? Or 6? The Emotion Engine's core design is based around having two parallel programmable units handling graphics at the same time, for example one animates the surface of a lake while the other makes the pretty refracted light patterns on the bottom. Yes, it's nastier to program than standard single-thread-for-each-task programming, but it makes for a very powerful architecture when used properly. Similar things can be done with other parts of a game, and if you design your data layout and flow correctly you minimise the need for synchronisation. You could draw your frame with 7 parallel threads, then flip all the SPEs over to handle the physics, input, etc update for the next frame. It's all just a matter of thinking about how you design your game.

SPE overhead

[ClamIAm]

As game developers use the 7 SPE chips more, I wonder how much of the main CPU's time will be taken up by things like managing threads and packing up work for the SPEs. It's almost similar to an operating system, where the main CPU would almost be like a kernel, managing memory and allowing different threads to talk to each other.

(If the OS analogy is flawed, sorry).

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.