Dissecting DirectX 10

Posted at: Monday 23rd July 2007 by Stuart Andrews

Stuart Andrews takes a journey through a DirectX 10 3D graphics pipeline, and explains how GPU architecture has changed since the DirectX 9 days.

Secondly, DirectX 10 enables the results from vertex or geometry shaders to be 'streamed out' on their way to the pixel shaders and re-used by other vertex or geometry shaders. Finally, DirectX 10 uses what's called a unified shader architecture; this means that it doesn't divide its shader units into discrete vertex shaders, pixel shaders and geometry pipelines; it just has shader units, full stop.

Meet the workforce

This last aspect is particularly important. If you think of ATi's R580 GPU as a production line, eight workers handled vertex duties, and passed the vertex data to a setup engine. From there, it went to four teams of 12 workers that handled the pixel shaders, with each team controlled by what ATi called an ultra-threaded dispatch processor. This 'line manager' ensured that if a pixel unit was waiting for, say, texture data to arrive, its current job could be swapped out for another task, and no pixel unit was idle for long.

In DirectX 10, instead of eight vertex units and 48 pixel units, there are unified banks of general-purpose Arithmetic Logic Units (ALUs). For the R600, these are arranged in four clusters of 16 shader units, each consisting of five ALUs; this makes a grand total of 320 shader units. Nvidia's G80 GeForce 8800 GTX arranges its 128 stream processors into eight clusters of 16, although there isn't a direct comparison, as Nvidia's stream processors and ATi's shader units don't perform exactly the same tasks.

The ALUs also differ from what we're accustomed to seeing in previous-generation GPUs. Firstly, they're designed with scalar rather than vector operation as the dominant model. What does this mean? Well, while a scalar operation works on only one data object at a time, a vector operation can work on several. However, vector operations can be broken down into successive scalar operations and, by 'unpacking' them in this way, you can ensure that these instructions are processed more efficiently.

You could liken this to five workers on a production line who screw wheels on to toy vehicles, with each vehicle taking a minute to complete. Three out of four minutes they have to do cars, meaning that four of the workers are working hard while one is doing nothing. Every fourth minute, however, they get a tricycle, meaning that two of them are left twiddling thumbs. However, if you break down the tasks from three cars and a tricycle into just car wheels and tricycle wheels, and assign the latter task to the worker that's normally idle, all your workers are busy all of the time. It also takes one minute less to carry out the job.

Taking the scalar approach enables the GPU to operate with a similar level of efficiency. This results in higher performance, and you no longer need to ask games programmers or shader compilers to pre-'vectorize' their instructions in order to make the game run at optimal speed.

Secondly, not all ALUs are created equal. In the Radeon HD 2900XT, each shader unit consists of five ALUs. Four of them are designed to handle the basic scalar and vector maths operations that form the meat and drink of standard shader work. One of these, however, is a sort of super-ALU. It can't quite do everything that the regular ALUs can, but it can perform a range of 'transcendental' operations', as ATi's head of European Developer Relations, Richard Huddy, calls it.