The Rendering Pipeline - Practical Rendering and Computation with Direct3D 11 - page 118

operations on data passed to them. A useful analogy to this concept is to consider how a
regular function works in C++. You first pass the function a predefined list of parameters.
It then processes the data and returns the result as its output. The body of the function rep-
resents the operations that the fixed function stage implements, while the input parameters
are the available configurations and the actual input data. We can't change the function
body, but we can control what options are used during processing of the input data.
Some examples of this type of fixed functions in previous generations of Direct3D
include the ability to change the vertex culling order (which is now a portion of the raster-
izer stage), selecting a depth test function (now a portion of the output merger stage), and
setting the alpha blending mode (also a portion of the output merger stage). This focus
on a single functional area is primarily due to performance considerations. If a particular
pipeline stage is designed for a specific task, it can usually be optimized to perform that
task more efficiently than a general purpose solution could.
In Direct3D 9, changing the state of these fixed function stages was performed by
calling an API function for each individual setting that was to be changed. This required
many API calls to be performed to configure a particular processing setup for each stage.
Depending on the scene contents and the rendering configuration, the number of API calls
could easily add up and begin to cause performance problems. Direct3D 10 introduced
the concept of state objects to replace these individual state settings. A state object is used
to configure a complete functional state with a single API call. This significantly reduces
the number of API calls required to configure a state and also reduces the amount of error
checking required by the runtime. Direct3D 11 follows this state object paradigm. The ap-
plication must describe the desired state with a description structure, and then create a state
object from it, which can be used to control the fixed-function pipeline stages.
The requirement to create a complete state all at once moves state validation from
the runtime API calls to the state creation methods. If incompatible states are configured
together, an error is returned at creation time. After creation, the state object is immutable
and cannot be modified. Thus, there is no way to set an invalid state for the fixed function
pipelines, which effectively removes the validation burden from the state-setting API calls.
Overall, this system of using state objects to represent the pipeline state allows for a more
streamlined pipeline configuration, with only minimal application interactions required.
3.1.2 Programmable Pipeline Stages
The programmable pipeline stages comprise the remaining stages of the pipeline. The
word programmable here means that these stages can execute programs written in the
High Level Shading Language (HLSL). Using the same C++ analogy from above, the
programmable stages allow you to define the required input parameters and the body of the
function. In fact, the programs that run in these stages are authored as functions in HLSL.