Overview of Direct3D 11 - Practical Rendering and Computation with Direct3D 11 - page 6

The entry point to the rendering pipeline is the input assembler stage. This stage is
responsible for reading input data from resources and then "assembling" vertices for use
later in the pipeline. This allows for multiple vertex buffers to be used and also provides the
ability to use instanced rendering (described in more detail in Chapter 3). In addition, the
connectivity of the vertices is also determined, based on the input resources and the desired
rendering configuration. The assembled vertices and primitive connectivity information
are then passed down the pipeline.
The vertex shader stage reads the assembled vertex data from the input assembler
stage and processes a single vertex at a time. This is the first programmable stage in the
pipeline, and it applies the current vertex shader program to each input vertex. It cannot
create or destroy vertices; it can only process the vertices that are given to it. In addition,
every vertex is processed in isolation—the information from one vertex shader invocation
is never accessible in another invocation. The primary responsibility of the vertex shader
used to be to project the vertex positions into clip space, but the addition of the tessellation
stages (discussed next) has somewhat changed this. In general, any operation that must be
performed on every vertex of the input model should be performed in the vertex shader.
The next three stages are recent additions to the pipeline to accommodate hardware
tessellation, and they must all be used together. The hull shader stage receives primitives
from the vertex shader and is responsible for two different actions. First, the hull shader
provides a function that is only run once per primitive to determine a set of tessellation
factors. These factors are used by the tessellator stage to know how finely to tessellate or
split up the current primitive. The second action that the hull shader stage must perform is
executed once for each control point in the desired output control patch configuration. In
essence, it must create the control points that will be later be used by the domain shader
stage to create the actual tessellated vertices that will eventually be used in rendering.
When the tessellation stage receives its data from the hull shader, it uses one of sev-
eral algorithms to determine an appropriate sampling pattern for the current primitive type.
Depending on the tessellation factors (from the hull shader), as well as its own configura-
tion (which is actually specified in the hull shader as well), it will determine which points
in the current primitive need to be sampled in order to tessellate the input primitive into
smaller parts. The output of the tessellation stage is actually a set of barycentric coordinates
that are passed along to the domain shader.
The domain shader takes these barycentric coordinates, in addition to the control
points produced by the hull shader, and uses them to create new vertices. It can use the
complete list of control points generated for the current primitive, textures, procedural al-
gorithms, or anything else, to convert the barycentric "location" for each tessellated point
into the output geometry that is passed on to the next stage in the pipeline. This flexibility in
deciding how to generate the resulting geometry from the tessellator stages' amplified out-
put provides significant freedom to implement many different types of tessellation algorithms.
The geometry shader stage resides in the next pipeline location. As its name implies,
the geometry shader operates on a geometric level. In practice, this means that it operates