Vertexbuffer.com

The invention of the GPU revolutionized the way we make video games. The early GPUs performed only raster operations, which mean that they were only pixel renders. When transform and lighting ( TnL ) cards hit the market, we had to rethink our game engines. As the GPU developed, our engines, originally designed to work on one processor, had to now work with two processors. The shift was painful for many, and remnants of our old mentality still exist in some engines today.

It is important to understand the pipelined nature of a graphics card. The journey from a three vertex triangle to a rendered pixel on screen is a deeply pipelined path through your graphics card. This pipelined architecture

We can separate the modern graphics card into three high-level stages: the application stage, which actually takes place on the CPU, the geometry stage, and the rasterization stages.

Application Stage

The application stage doesn’t actually occur on the GPU, but it’s where everything starts. The CPU and GPU represent a producer consumer model. The CPU produces triangles and commands, the GPU consumes them. When we first create triangles, we do so on the CPU and in system memory. Using the graphics API, we create vertex buffers, textures and other resources. These graphics resources are stored in system memory and transferred to the GPU when the graphics card needs the resources for rendering.

The application stage also generates commands and sends them to the graphics pipeline for processing. The graphics card acts as a parallel processing stage machine. These commands are queued by the drivers similar to the way micro-ops are stored in the instruction pool during the execution stage of the CPU. These commands control the settings that determine how our scene will render.

For example, let’s examine some commands we must use to draw a triangle primitive. Common primitives are points, lines, squares, and triangles. One command we may want to set, allows for the GPU to apply a texture to the triangle. Another command that we could set allows us to make the triangle semi-transparent. Another command that we could set allows us to push a matrix to the GPU so that the triangle is in the scene in the correct position.

The application stage creates all of our resources at load time or in between missions. Creating graphics resources at any other time is not efficient. Commands are sent every frame. When we create the resources, they are stored in system memory. The drivers control when the resources will transfer across the graphics bus to video memory.

Geometry Stage

The geometry stage is responsible for converting 3D triangles into 2D triangles. When an object is on screen and ready for rendering, the geometry stage fetches the vertex stream from video memory. If it doesn’t exist in video memory, it must fetch it by pulling the data across your graphics bus. When the geometry stage fetches the vertices, they are translated and lit according to the values you have either specified using the commands of your API.

If you graphics card supports HOS, or Higher Order Surfaces, the card can add extra vertices in the geometry stage with little overhead. Graphics APIs allow you to choose a tessellation type and the card will perform these operations for you. This technique is not a commonly used approach in many engines, but the future for using techniques similar to this are very promising. Expect to see procedurally generated vertices as a major feature in DirectX 10 (specifically the geometry shaders)

If your graphics card supports vertex shaders, they will execute at this stage. If you chose to use a vertex shader over the fixed function pipeline, you will be responsible for transforming and lighting the triangles in your shader.

By translating your vertices, the output from the vertex pipelines is 2D triangles that fit in your screen. They are ready to pass to the rasterization stage.

Rasterization Stage

The rasterization stage is a 2D stage where pixel information generates the final buffer for rendering and flipping to the front buffer where the user can view the output.

The first section of the rasterization stage, is the rasterizer. In this section, triangles are “filled in” the way you do with a crayon in a coloring book.

After the rasterizing the triangles, each pixel passes through the fragment shader. Fragment shaders combine already existing pixel with the texture supplied by the application stage. If the application programmer chose to use a pixel shader, this is where it executes, and the user is responsible for blending the texture and material colors.

After the pixel passes through the fragment shader, we are ready to combine it with the frame buffer. The frame buffer is a buffer that will contain the image that we will present to the user. In this stage the pixel will blend with the pixel that is already at that position. If the new pixel is in front of the current pixel, it will replace it. It the pixel contains an alpha channel, it will blend with pixel according to the users specification.

The frame buffer is often a limitation, especially at high resolutions. In a later reading, we will learn how to test the frame buffer to see if your application is frame buffer bandwidth limited.