Inside the PlayStation3

NO, NOT THE CAR
NVIDIA’s RSX chip supplies the PS3 with 3D acceleration and audio. On the sound side, the PS3 uses a version of NVIDIA’s excellent Soundstorm technology, the same one that vanished from the company’s desktop chipsets a few years ago. While Sony has not confirmed this as fact, given that the device’s audio outputs lead out from the RSX chip, it’s a safe bet.

As for graphics, RSX is based on the G70 architecture, or NV47 as it was also known. The original specification for the 3D subsystem called for a 550MHz core with 256MB of GDDR3 at 700MHz (1.4GHz effective), 28 pixel pipes and eight vertex pipes. In order to improve yields, Sony deactivated four of the pixel pipes and reduced the clocks to 500MHz and 650MHz respectively, essentially transforming RSX into a faster clocked 7800 GTX. The fixed allocation of shader pipelines means that, unlike the AMD R600-based chip in the Xbox 360, RSX cannot dynamically allocate its pipes and is not a unified architecture. We don’t know how this will affect performance in the future, but it does damage the impression of the PS3 being a futureproofed console, at least in the arena of 3D acceleration.

A 3D chip is not enough to make games – developers require an application programming interface, or API, to communicate with the hardware. Sony, not wanting to create its own API and teach developers how to use it – a significant departure for a company dedicated to creating proprietary specifications – chose to go with the widely available and popular OpenGL.

OpenGL, originally developed by Silicon Graphics for its workstations, is one of the two big 3D APIs in the industry, the other being Microsoft’s Direct3D. Microsoft, being a direct competitor with its Xbox 360, removed Direct3D as a choice, leaving OpenGL as Sony’s only avenue.

Armed with OGL, Sony had both the hardware and the software to transform the PS3 into a video game console.



PROBLEMS OF THE DEEPLY BEDDED
Yes, Sony went with OpenGL, but not the desktop version – used in Doom 3 and the original Half-Life – that we in the PC world are familiar with. According to a 2006 presentation by Sony Computer Entertainment’s Mike Weiblen for the Khronos Group, which oversees the OpenGL standard, the PS3 uses its own version of OpenGL ES – the embedded system version of the API – called ‘PSGL’. By embedded systems, we mean PDAs, mobile phones and similar devices.

If at this point you’re wondering why Sony would chose a 3D API designed for devices with negligible graphics demands for a high-performance video game console, don’t worry, we were surprised as well.

Sony’s main reason for using OpenGL ES as a foundation was that vanilla OpenGL was bloated with legacy APIs that would never see the light of a phosphor tube on the PS3. Problem was OpenGL ES 1.0, the particular revision PSGL is based on, did not have a programmable pipeline and hence relied on fixed functions in the 3D API. Without changes, OpenGL ES represented the Stone Age of 3D acceleration.

But Sony did make changes. In fact, it wrote its own programmable pipeline into the specification – a huge undertaking, but a necessary one. It seems the prospect of adding a free-form pipeline was more appealing than carving swathes of code from the chunky desktop OpenGL. To code the shaders, Sony naturally went with Cg, NVIDIA’s high level shader language (HLSL).

During the development of PSGL, the Khronos Group released OpenGL ES 2.0, introducing a programmable pipeline into the specification. Unfortunately, it came too late to be used for PSGL.

CODE ACHES
We mentioned earlier that the PPC in Cell is an in-order execution processor. This means that the processing pipeline is required to wait for all the information for a command before it can execute it, while an out-of-order processor can execute other commands in the interim. Essentially, as long as code branching is kept to a minimum and the processor does not have to constantly wait for results, then it should not stall.

Mike Acton, a developer for High Moon Studios believes it is ‘critical’ that code be as branchless as possible, according to his presentation at the 2006 Austin Game Conference. Acton also stressed in the presentation that data access patterns have to be as efficient as possible to maximise the low-latency, high-bandwidth design of Cell.

While a good compiler – which turns human-readable code into machine language – can do a lot of the work in optimising a program, only the developer knows their code intimately enough to make the most worthwhile refinements, truly placing the success of the PS3 in their hands.

Even with good code, tapping into Cell’s massive parallelism and utilising each SPE to its fullest is the key to getting the best out of the chip, but even with the proliferation of dual and quad-core CPUs in the desktop PC space, multi-threading remains a daunting proposition for developers.

‘I think there are some programmers who are very enthusiastic about moving to multi-core while others are more tentative,’ explains D’Amora. ‘Generally speaking, most programmers have had little experience with high degrees of parallelism in their applications because historically workstation and server microprocessors have been single core or at best dual processor systems. That being the case much of the code – and algorithms – were based on a single threaded model. Multithreaded versions may require a re-think of the algorithms let alone a port of the code. This takes some time, but the performance benefits are substantial.’