Graphics Reference
In-Depth Information
15.7.1.1 Rasterizing Stage
Most of the complexity that we would like such an API to abstract is in the raster-
izing stage. Under current algorithms, rasterization is most efficient when imple-
mented with only a few parameters, so this stage is usually implemented as a
fixed-function
unit. In hardware this may literally mean a specific circuit that
can only compute rasterization. In software this may simply denote a module that
accepts no parameterization.
15.7.1.2 Vertex and Pixel Stages
The per-vertex and per-pixel operations are ones for which a programmer using
the API may need to perform a great deal of customization to produce the desired
image. For example, an engineering application may require an orthographic pro-
jection of each vertex instead of a perspective one. We've already changed our
per-pixel shading code three times, to support Lambertian, Blinn-Phong, and
Blinn-Phong plus shadowing, so clearly customization of that stage is important.
The performance impact of allowing nearly unlimited customization of vertex and
pixel operations is relatively small compared to the benefits of that customization
and the cost of rasterization and output merging. Most APIs enable customization
of vertex and pixel stages by accepting callback functions that are executed for
each vertex and each pixel. In this case, the stages are called
programmable
units.
A pipeline implementation with programmable units is sometimes called a
programmable pipeline.
Beware that in this context, the pipeline
order
is in
fact fixed, and only the
units
within it are programmable. Truly programmable
pipelines in which the order of stages can be altered have been proposed [SFB
+
09]
but are not currently in common use.
For historical reasons, the callback functions are often called
shaders
or
pro-
grams.
Thus, a
pixel shader
or “pixel program” is a callback function that will be
executed at the per-pixel stage. For triangle rasterization, the pixel stage is often
referred to as the
fragment
stage. A fragment is the portion of a triangle that over-
laps the bounds of a pixel. It is a matter of viewpoint whether one is computing the
shade of the fragment and sampling that shade at the pixel, or directly computing
the shade at the pixel. The distinction only becomes important when computing
visibility independently from shading.
Multi-sample anti-aliasing
(
MSAA
)isan
example of this. Under that rasterization strategy, many visibility samples (with
corresponding depth buffer and radiance samples) are computed within each pixel,
but a single shade is applied to all the samples that pass the depth and visibility
test. In this case, one truly is shading a fragment and not a pixel.
15.7.1.3 Output Merging Stage
The output merging stage is one that we might like to customize as consumers
of the API. For example, one might imagine simulating translucent surfaces by
blending the current and previous radiance values in the frame buffer. However,
the output merger is also a stage that requires synchronization between poten-
tially parallel instances of the pixel shading units, since it writes to a shared frame
buffer. As a result, most APIs provide only limited customization at the output
merge stage. That allows lockless access to the underlying data structures, since
the implementation may explicitly schedule pixel shading to avoid contention at
the frame buffer. The limited customization options typically allow the program-
mer to choose the operator for the depth comparison. They also typically allow
a choice of compositing operator for color limited to linear blending, minimum,
and maximum operations on the color values.
