i
i
i
i
i
i
i
i
Chapter 2
The Graphics
Rendering Pipeline
“A chain is no stronger than its weakest link.”
—Anonymous
This chapter presents what is considered to be the core component of real-
time graphics, namely the graphics rendering pipeline, also known simply
as the pipeline. The main function of the pipeline is to generate, or ren-
der, a two-dimensional image, given a virtual camera, three-dimensional
objects, light sources, shading equations, textures, and more. The ren-
dering pipeline is thus the underlying tool for real-time rendering. The
process of using the pipeline is depicted in Figure 2.1. The locations and
shapes of the objects in the image are determined by their geometry, the
characteristics of the environment, and the placement of the camera in
that environment. The appearance of the objects is affected by material
properties, light sources, textures, and shading models.
The different stages of the rendering pipeline will now be discussed and
explained, with a focus on function and not on implementation. Implemen-
tation details are either left for later chapters or are elements over which
the programmer has no control. For example, what is important to some-
one using lines are characteristics such as vertex data formats, colors, and
pattern types, and whether, say, depth cueing is available, not whether
lines are implemented via Bresenham’s line-drawing algorithm [142] or via
a symmetric double-step algorithm [1391]. Usually some of these pipeline
stages are implemented in non-programmable hardware, which makes it
impossible to optimize or improve on the implementation. Details of basic
draw and fill algorithms are covered in depth in books such as Rogers [1077].
While we may have little control over some of the underlying hardware, al-
gorithms and coding methods have a significant effect on the speed and
quality at which images are produced.
11
i
i
i
i
i
i
i
i
12 2. The Graphics Rendering Pipeline
Figure 2.1. In the left image, a virtual camera is located at the tip of the pyramid (where
four lines converge). Only the primitives inside the view volume are rendered. For an
image that is rendered in perspective (as is the case here), the view volume is a frustum,
i.e., a truncated pyramid with a rectangular base. The right image shows what the
camera “sees.” Note that the red donut shape in the left image is not in the rendering
to the right because it is located outside the view frustum. Also, the twisted blue prism
in the left image is clipped against the top plane of the frustum.
2.1 Architecture
In the physical world, the pipeline concept manifests itself in many different
forms, from factory assembly lines to ski lifts. It also applies to graphics
rendering.
A pipeline consists of several stages [541]. For example, in an oil
pipeline, oil cannot move from the first stage of the pipeline to the second
until the oil already in that second stage has moved on to the third stage,
and so forth. This implies that the speed of the pipeline is determined by
the slowest stage, no matter how fast the other stages may be.
Ideally, a nonpipelined system that is then divided into n pipelined
stages could give a speedup of a factor of n. This increase in performance
is the main reason to use pipelining. For example, a ski chairlift contain-
ing only one chair is inefficient; adding more chairs creates a proportional
speedup in the number of skiers brought up the hill. The pipeline stages
execute in parallel, but they are stalled until the slowest stage has finished
its task. For example, if the steering wheel attachment stage on a car as-
sembly line takes three minutes and every other stage takes two minutes,
the best rate that can be achieved is one car made every three minutes; the
otherstagesmustbeidleforoneminutewhilethesteeringwheelattach-
ment is completed. For this particular pipeline, the steering wheel stage is
the bottleneck, since it determines the speed of the entire production.
This kind of pipeline construction is also found in the context of real-
time computer graphics. A coarse division of the real-time rendering pipe-
line into three conceptual stages—application, geometry,andrasterizer—is
shown in Figure 2.2. This structure is the core—the engine of the rendering
i
i
i
i
i
i
i
i
2.1. Architecture 13
Figure 2.2. The basic construction of the rendering pipeline, consisting of three stages:
application, geometry, and the rasterizer. Each of these stages may be a pipeline in
itself, as illustrated below the geometry stage, or a stage may be (partly) parallelized,
as shown below the rasterizer stage. In this illustration, the application stage is a single
process, but this stage could also be pipelined or parallelized.
pipeline—which is used in real-time computer graphics applications and is
thus an essential base for discussion in subsequent chapters. Each of these
stages is usually a pipeline in itself, which means that it consists of several
substages. We differentiate between the conceptual stages (application, ge-
ometry, and rasterizer), functional stages, and pipeline stages. A functional
stage has a certain task to perform but does not specify the way that task
is executed in the pipeline. A pipeline stage, on the other hand, is executed
simultaneously with all the other pipeline stages. A pipeline stage may also
be parallelized in order to meet high performance needs. For example, the
geometry stage may be divided into five functional stages, but it is the im-
plementation of a graphics system that determines its division into pipeline
stages. A given implementation may combine two functional stages into one
pipeline stage, while it divides another, more time-consuming, functional
stage into several pipeline stages, or even parallelizes it.
It is the slowest of the pipeline stages that determines the rendering
speed, the update rate of the images. This speed may be expressed in
frames per second (fps), that is, the number of images rendered per second.
It can also be represented using Hertz (Hz), which is simply the notation for
1/seconds, i.e., the frequency of update. The time used by an application
to generate an image usually varies, depending on the complexity of the
computations performed during each frame. Frames per second is used to
express either the rate for a particular frame, or the average performance
over some duration of use. Hertz is used for hardware, such as a display,
which is set to a fixed rate. Since we are dealing with a pipeline, it does
not suffice to add up the time it takes for all the data we want to render
to pass through the entire pipeline. This, of course, is a consequence of
the pipeline construction, which allows the stages to execute in parallel.
If we could locate the bottleneck, i.e., the slowest stage of the pipeline,
and measure how much time it takes data to pass through that stage, then
i
i
i
i
i
i
i
i
14 2. The Graphics Rendering Pipeline
we could compute the rendering speed. Assume, for example, that the
bottleneck stage takes 20 ms (milliseconds) to execute; the rendering speed
then would be 1/0.020 = 50 Hz. However, this is true only if the output
device can update at this particular speed; otherwise, the true output rate
will be slower. In other pipelining contexts, the term throughput is used
instead of rendering speed.
E
XAMPLE:RENDERING SPEED. Assume that our output device’s maximum
update frequency is 60 Hz, and that the bottleneck of the rendering pipeline
has been found. Timings show that this stage takes 62.5 ms to execute.
The rendering speed is then computed as follows. First, ignoring the output
device, we get a maximum rendering speed of 1/0.0625 = 16 fps. Second,
adjust this value to the frequency of the output device: 60 Hz implies that
rendering speed can be 60 Hz, 60/2=30Hz,60/3=20Hz,60/4=15Hz,
60/5 = 12 Hz, and so forth. This means that we can expect the rendering
speed to be 15 Hz, since this is the maximum constant speed the output
device can manage that is less than 16 fps.
As the name implies, the application stage is driven by the applica-
tion and is therefore implemented in software running on general-purpose
CPUs. These CPUs commonly include multiple cores that are capable
of processing multiple threads of execution in parallel. This enables the
CPUs to efficiently run the large variety of tasks that are the responsi-
bility of the application stage. Some of the tasks traditionally performed
on the CPU include collision detection, global acceleration algorithms, an-
imation, physics simulation, and many others, depending on the type of
application. The next step is the geometry stage, which deals with trans-
forms, projections, etc. This stage computes what is to be drawn, how
it should be drawn, and where it should be drawn. The geometry stage
is typically performed on a graphics processing unit (GPU) that contains
many programmable cores as well as fixed-operation hardware. Finally,
the rasterizer stage draws (renders) an image with use of the data that
the previous stage generated, as well as any per-pixel computation de-
sired. The rasterizer stage is processed completely on the GPU. These
stages and their internal pipelines will be discussed in the next three sec-
tions. More details on how the GPU processes these stages are given in
Chapter 3.
2.2 The Application Stage
The developer has full control over what happens in the application stage,
since it executes on the CPU. Therefore, the developer can entirely de-
termine the implementation and can later modify it in order to improve
i
i
i
i
i
i
i
i
2.3. The Geometry Stage 15
performance. Changes here can also affect the performance of subsequent
stages. For example, an application stage algorithm or setting could de-
crease the number of triangles to be rendered.
At the end of the application stage, the geometry to be rendered is
fed to the geometry stage. These are the rendering primitives, i.e., points,
lines, and triangles, that might eventually end up on the screen (or what-
ever output device is being used). This is the most important task of the
application stage.
A consequence of the software-based implementation of this stage is
that it is not divided into substages, as are the geometry and rasterizer
stages.
1
However, in order to increase performance, this stage is often
executed in parallel on several processor cores. In CPU design, this is called
a superscalar construction, since it is able to execute several processes at
the same time in the same stage. Section 15.5 presents various methods
for utilizing multiple processor cores.
One process commonly implemented in this stage is collision detection.
After a collision is detected between two objects, a response may be gen-
erated and sent back to the colliding objects, as well as to a force feedback
device. The application stage is also the place to take care of input from
other sources, such as the keyboard, the mouse, a head-mounted helmet,
etc. Depending on this input, several different kinds of actions may be
taken. Other processes implemented in this stage include texture anima-
tion, animations via transforms, or any kind of calculations that are not
performed in any other stages. Acceleration algorithms, such as hierar-
chical view frustum culling (see Chapter 14), are also implemented here.
2.3 The Geometry Stage
The geometry stage is responsible for the majority of the per-polygon and
per-vertex operations. This stage is further divided into the following func-
tional stages: model and view transform, vertex shading, projection, clip-
ping, and screen mapping (Figure 2.3). Note again that, depending on the
implementation, these functional stages may or may not be equivalent to
pipeline stages. In some cases, a number of consecutive functional stages
form a single pipeline stage (which runs in parallel with the other pipeline
stages). In other cases, a functional stage may be subdivided into several
smaller pipeline stages.
1
Since a CPU itself is pipelined on a much smaller scale, you could say that the
application stage is further subdivided into several pipeline stages, but this is not relevant
here.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.