It's been two years since the rivals presented their latest offering. If you read the former article and 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 vectors, in particular, vectors made of four floats. These processors are so fast that they only spend one cycle per operation, which can be extremely convenient for geometry processing. Though they exhibit similar unstandardised behaviour to the CPU's FPU.
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 needed 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) which instructs the unit on how to operate the data found in 'VU Mem'.
- It 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 integers. This enables to operate both floats and integers concurrently.
- A Vector Interface: Automatically decompresses vertex data coming from main memory in a format the Vector unit can understand. This unit 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 VPU0.
The first VPU, the VPU0, is positioned between the CPU and the other vector unit (VPU1). It provides an 'assisting' role to the main CPU.
The VPU0 has two modes of operation:
- Micromode: This is the 'traditional mode'. The VPU will independently execute '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 have the same functionality as microinstructions but use different opcodes. Nonetheless, the VPU 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 simplicity, a co-processor is easier to program than an independent unit (something PC programmers will find helpful).
The memory map of the VPU0 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 the other VPU.
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 or '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 the geometry to the GPU as quickly as possible and without using the main bus.
On the other side 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 famous Display Lists.
Infinite worlds
A useful approach 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 the geometry which is then interpreted by the GPU (i.e. triangles, lines, quadrangles, etc) and ultimately used to draw the scene.
Compared to using explicit data, procedural content is ideal for parallelised tasks, it frees up bandwidth, requires very little storage and it's dynamic (programmers can set 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 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 VPU might not generate the geometry at the required time.
To sum up, procedural rendering is not a new technique, but thanks to the VPUs, it opens the doors to further optimisations and richer graphics. Nonetheless, is not a simple technique to implement and Sony R&D published various papers describing different approaches to use on their console .
You define the workflow
With these new additions, programmers now have a lot of flexibility to design their graphics engines. To assist with this, Sony spent additional resources to devise and document 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 utilisation 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 where the CPU/VPU0 group works as a preprocessor for the VPU1. The first stage will fetch and process all the geometry that the VPU1 will subsequently turn into Display List.
These have been so far examples from the 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 the candle flame and the light coming from the window glass.
The former director of Travellers 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, the database was used to calculate the coordinates of particles at any given time without depending on any other component. The result of the operation could be transformed into Display Lists and sent right 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.