It's been two years since the rivals presented their latest offering. If you read the former article and have just started reading this one, I presume you are still waiting for 'the thing' that makes the PS2 as powerful as it seemed back then. Now, let me introduce a very important set of components Sony fitted in the Emotion Engine, the Vector Processing Units or 'VPU'.
Architecture
A Vector Processing Unit is a small independent processor designed to operate on vectors, in particular, vectors made of four floats. These processors are so fast that they spend only one cycle per operation, which can be extremely convenient for geometry processing. Though they exhibit similar unstandardised behaviour to the CPU's FPU.
Moving on, VPUs are made of the following components:
- Some Vector Unit Memory or 'VU Mem': Used as a working space for the Vector Unit. It stores values to be operated and/or the results of previous operations.
- A Vector Unit: The core of the processor. It contains some memory (called Micro Memory) to store a program (called Microprogram) that instructs the unit on how to operate on the data found in 'VU Mem'.
- The unit implements a 64-bit ISA, and the execution unit is split into two parallel sub-units. The first one multiplies or adds floats, while the other one divides floats or operates on integers. This enables to process both floats and integers concurrently.
- A Vector Interface: Automatically decompresses vertex data coming from main memory in a format that the Vector unit can understand. The interface can also transfer microprograms to Micro Memory.
Functionality
To start working, the vector unit needs to be 'kickstarted'. For this, the main CPU is in charge of supplying the microcode.
There are two VPUs fitted in the Emotion Engine, but they are arranged differently, giving way to different uses and optimisations.
Vector Processing Unit 0
Architecture of the Vector Processing Unit 0 (VPU0).
The first VPU, the VPU0, is positioned between the CPU and the other vector unit (VPU1). It serves as an 'assistant' to the main CPU.
The VPU0 has two modes of operation:
- Micromode: This is the 'traditional' mode. The VPU independently executes 'microinstructions' from a microprogram stored in Micro Memory.
- Macromode: The VPU0 becomes the 'COP2' of the main CPU and executes 'macro-instructions' received from the main CPU through a dedicated 128-bit bus.
- Macro-instructions provide the same functionality as microinstructions, but use different opcodes. Nonetheless, the VPU's execution unit is no longer split (meaning it can only execute one instruction at a time).
- While this mode doesn't make full utilisation of all the components of the VPU0, it still speeds up the CPU's vector operations. Moreover, in terms of development, a co-processor is easier to program than an independent unit (something PC programmers will find helpful).
The VPU0's memory map also has access to some of the other VPU's registers and flags, presumably to check its state or quickly read the results of some operations done by it.
Vector Processing Unit 1
Architecture of VPU1.
The second VPU found, the VPU1, is an enhanced version of the VPU0, with quadruple the amount of Micro Memory and VU memory. Moreover, this unit includes an additional component called Elementary Function Unit (EFU), which speeds up the execution of exponential and trigonometric functions.
The VPU1 is located between the VPU0 and the Graphics Interface (the 'gate' to the GPU), so it includes additional buses to feed geometry to the GPU as quickly as possible (and without requiring the main bus).
On the other hand, and due to its location, the VPU1 only operates in Micromode.
It's obvious that this VPU was designed for trigonometric operations and may serve as a pre-processor for the GPU. Hence, it's often put in charge of delivering the well-known Display Lists.
Infinite worlds
A useful model that can be exploited with these units is procedural generation. In other words, instead of building the scene using hard-coded geometry, let the VPUs generate it using algorithms. In this case, the VPU computes mathematical functions to produce geometry data (i.e. triangles, lines, quadrangles, etc.), which is then interpreted by the GPU and ultimately used to draw the scene.
Compared with using explicit data, procedural content is well suited to parallelised tasks: it frees up bandwidth, requires very little storage, and is dynamic (programmers adjust parameters to achieve different results) . Many areas can highly benefit from this technique:
- Complex surfaces (e.g. spheres and wheels).
- World rendering (e.g. terrains, particles, trees).
- Bézier curves, a very popular type of equation in computer graphics used to draw curves. These are turned into a Bézier patch (explicit geometry) and support different degrees of precision based on the level of detail required.
On the other side, procedural content may struggle with animations and, if the algorithm is too complex, the VPUs might not generate the geometry in time.
To sum up, procedural rendering is not a novel technique, but thanks to the VPUs, it opens the door to further optimisation and richer graphics. Nonetheless, its implementation is not simple and Sony R&D published various papers describing different approaches for use on their console .
You define the workflow
With these new additions, programmers now have plenty of flexibility when designing their graphics engines. To assist with this, Sony devoted additional resources to devising and documenting efficient pipeline designs. The following are examples of graphics pipelines optimised for different types of workloads :
Parallel pipeline design.
Serial pipeline design.
In the first example, the Parallel design, the CPU is combined with the VPU0 in Macromode to produce geometry in parallel with the VPU1. The CPU/VPU0 group makes full use of Scratchpad and cache to avoid using the main bus, which the VPU1 relies on to fetch data from main memory. In the end, both rendering groups concurrently send their respective Display Lists to the GPU.
The second example, the Serial design, proposes a different approach, with the CPU/VPU0 group working as a preprocessor for the VPU1. The first stage fetches and processes all the geometry that the VPU1 subsequently turns into Display Lists.
So far, these have been examples from a theoretical point of view, but to explain a more 'practical' implementation, I'm going to refer to a video Jon Burton published regarding the development of one of their PS2 games .
Crash Bandicoot: The Wrath of Cortex (2001). Particles make up the candle flame and the light coming from the window glass.
The former director of Traveller's Tales explained how his team achieved a particle system fully encapsulated within the VPU1. In a nutshell, the VPU1 focused on reading a pre-populated database from its VU memory. This enabled to calculate the coordinates of particles at any given time, without depending on any other component. Finally, the processed data was transformed into Display Lists and sent straight away.
With this approach, the CPU was significantly offloaded, allowing it to carry out other tasks like AI and physics.
There are many more examples out there, but to sum things up: it is now up to the programmer to find the optimal setup, and that is a good thing.