Programmable Pipeline

In Microsoft?Direct3D?for Microsoft DirectX?9.0, procedural models are used for specifying the behavior of the vertex transformation and lighting pipeline and the pixel texture blending pipeline.

• Integration of Vertex Shaders into the Geometry Pipeline
• Integration of Pixel Shaders into the Graphics Pipeline
• Programmable Stream Model
• Vertex Shaders
• Pixel Shaders

There are many advantages to a program model-based syntax for specifying the behavior of the hardware.

First, a procedural model allows a more general syntax for specifying common operations. Fixed-function, as opposed to programmable, application programming interfaces (APIs) must define modes, flags, and so on for an increasing number of operations that need to be expressed. Further, with the increasing power of the hardware - more colors, more textures, more vertex streams, an so on - the token space for the operations multiplied by the data inputs becomes complex. A programmability model, on the other hand, enables even simple operations such as getting the right color and right texture into the right part of the lighting model in a more direct fashion. You do not have to search through all the possible modes; you just have to learn the computer architecture and specify the desired algorithm to be performed.

For example, the following well-known features can be supported.

• Basic geometry transformations
• Simple lighting models
• Vertex blending for skinning
• Vertex morphing (tweening)
• Texture transforms
• Texture generation
• Environment mapping

Second, a procedural model provides an easy mechanism for developing new operations. There are many operations that developers find they need that are not supported in current APIs. In most cases, this is not due to limitations in the capabilities of the hardware but rather to restrictions in the APIs. In general, these operations are also simpler and therefore faster than trying to extract the same behavior by contorting a fixed function API to an extent beyond its designer's expectations.

Examples of new features expected to be commonly implemented include the following:

• Matrix Palette Skinning. Character animation with 8-10 bones per mesh.
• Anisotropic Lighting. Lighting that currently can be done only at the cost of textures for look-up tables.
• Membrane Shaders. Shaders for balloons, skin, and so on (1/cos(eye DOT normal)).
• Kubelka-Munk Shaders. Shaders that take into account light that penetrates the surface.
• Procedural Geometry. Compositing meshes with procedural ones (spheres) to simulate muscles moving under the skin.
• Displacement Mapping. Modifying a mesh with a wave pattern or hump that can be tiled/repeated.

Third, a procedural model provides for scalability and evolvability. Hardware capabilities are continuing to evolve rapidly, and programmatic representations can help adapt the API because they scale very well. New features and capabilities can be easily exposed in an incremental way by the following operations.

• Adding new instructions
• Adding new data inputs
• Adding new capabilities from the fixed-function to the programmable portion of the pipeline

Code is the representation that has the best scaling properties for representing complexity. Further, the amount of code that must change inside Direct3D is very small for new features added to the programmable shaders.

Fourth, a procedural model offers familiarity. Software developers understand programming better than they do hardware. An API that truly caters to software developers should map hardware functionality into a code paradigm.

Fifth, a procedural model follows in the footsteps of a photo-real rendering heritage. There has been a tradition of using programmable shaders in high-end photo-real rendering for many years. In general, this area is unconstrained by performance, so programmable shaders represent the ultimate no-compromise goal for rendering technologies.

Lastly, a procedural model enables direct mapping to the hardware. Most current 3-D hardware, at the vertex processing stage at least, is actually fairly programmable. The programmability through the API enables the application to map directly to this hardware. This enables you to manage the hardware resources according to their requirements. With a limited set of registers or instructions that can be run, it is difficult to make a fixed-function implementation that can have all its features enabled independently. If you turn on too many features that require a shared resource, they can stop working in unexpected ways. The programmable API model follows in the DirectX tradition of eliminating this problem by letting the application developer talk directly to the hardware, making any such limitations transparent.