Graphics Reference
In-Depth Information
color arithmetic, determine whether and how the fragment values affect or replace
corresponding pixel values.
Three of the pipeline stages—the vertex, primitive, and fragment processing
stages—are application-programmable. A (typically) simple program, specified
by the application using a C-like language, is assigned to the fragment processing
stage, where it is executed on each fragment. Likewise, programs are specified and
assigned to the vertex and primitive processing stages, where they operate on indi-
vidual vertices and primitives. Floating-point arithmetic, logical operations, and
conditional flow control are supported by each programmable processing stage,
as are indexing of global data and filtered sampling (i.e., interpolation) of tex-
ture images, both stored in memory. The remaining stages—the vertex, primitive,
and fragment generation stages and the pixel operations stage—are referred to
as fixed-function stages, because they cannot be programmed by the application.
(They can, however, be configured by various modal specifications.)
Modern graphics architectures support two types of commands, those that
specify state (the majority) and those that cause rendering to occur. Thus, drawing
is a two-step process: 1) Set up all the required state, and then 2) run the pipeline
to cause drawing to happen.
3
Vertex data and topology, texture images, and the
application-specified programs for the processing stages are all large components
of pipeline state. In addition, modal state associated with each fixed-function stage
determines the details of its operation (e.g., aliased or antialiased rasterization at
the fragment generation stage). Figure 38.3 emphasizes
drawing,
rather than state
setup, both by omitting modal state and by indicating read-only access to bulk
memory state (e.g., texture images).
Certain properties of the graphics pipeline architecture have great significance
for both graphics applications and GPU implementations. One such property is
read-only access, during drawing operation, of all bulk memory state other than
the output image. (Writing greatly complicates
coherence,
the requirement that
memory state values appear consistent to all the processors in a parallel sys-
tem [see Section 38.7.2].) Perhaps even more significant is the requirement for
in-order operation. This applies both to drawing (fragments must reach the out-
put image in the order that their corresponding triangles were specified) and to
state changes (drawing activated prior to a state change cannot be affected by that
change, and drawing specified after must be). GPU implementors struggle might-
ily with in-order drawing, while read-only bulk state (state such as texture memory
that cannot be modified during rendering operation) simplifies their task. Con-
versely, application developers are constrained by read-only state semantics, but
they are supported by in-order drawing semantics. The art of architecture design
includes identifying such conflicts and making the best tradeoffs. If either con-
stituency is entirely happy with the architecture, it probably isn't right. This is so
important that we embody it in a principle.
T
HE DESIGN TRADEOFF PRINCIPLE
:
The art of architecture design includes
identifying conflicts between the interests of implementors and users, and mak-
ing the best tradeoffs.
3. Early OpenGL interfaces blurred this distinction by providing commands that both
specified vertex state and resulted in drawing. This is what is usually meant by the
term “immediate-mode” rendering, as discussed in Chapter 16.
