Defining the Programmable Pipeline

Prior to the release of DirectX 8 a few years ago, the only way for you to render any 3D graphics using DirectX was by using the fixed-function pipeline. The fixed-function pipeline is essentially a set of rules and behaviors that govern how a particular type of data is rendered by the system. For example, a directional light is always calculated by taking the dot product of the normal and light direction. That is just the way it is designed, and there were no options to change it.

With more powerful graphics hardware coming out, it became apparent that something more robust would be required. The fixed-function pipeline was serving its purpose well, but it would be unrealistic to assume it could handle every possible case that a developer might want to use. What was needed was a way to allow the developer to execute some arbitrary code on the vertices or pixels that would be rendered, preferably inside the graphics hardware.

With DirectX 8, the first notion of this programmable pipeline was released to the public, and developers finally had the opportunity to expand beyond the realms of the fixed-function pipeline. Small programs called vertex shaders could be executed against the vertices that were going to be rendered. Other types of these programs, pixel shaders, were designed to be executed against every pixel in the scene.

One of the first problems developers noticed with this new technology was that it was pretty esoteric. The language used to write these shader programs closely resembled assembly language, making the code required to run them more elaborate than some developers wanted. Another issue was the limited amount of instruction slots on the hardware at the time. Given that these programs were going to be running on the graphics cards themselves, the card would allow only a small number of "instructions" to be executed for any one program. This setup was particularly bad for the pixel shader programs.

With the release of DirectX 9, many of these issues were addressed. It introduced a new language, HLSL, a simple C-like language that would be compiled directly into the real shader code. With more familiar syntax and a powerful compiler, HLSL made writing complex shaders much simpler than it had been with the DirectX 8 release.

Another big change was the addition of new shader models. In the DirectX 8 release, the vertex and pixel shader models were 1.x, where 1 was the major version and .x was the minor version. Vertex shaders had versions 1.0 and 1.1 in the DirectX 8 releases, and pixel shaders went from 1.0 through 1.4. With the DirectX 9 release, the shader models were increased to be supported all the way through versions 2.x and 3.x. Each new model increases the number of instructions that can be used and the intrinsic instructions in the shaders themselves.

Construction Cue

The 3.x shader models were available at the release of DirectX 9, but there was no hardware yet capable of running these shaders. The Radeon 9700 was the first card capable of running 2.0 shaders, and although all the top cards today support the 2.0 shader model, as of this writing, only one publicly announced card supports the 3.0 shader model.