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

There is a wide diversity of different resources at our disposal when considering
how to structure an algorithm, and each type has different use cases. In general, resources
are split into two groups—textures and buffers. Textures are roughly split by their dimen-
sion, and can be created to have one-dimensional, two-dimensional, and three-dimensional
forms. Buffers are somewhat more uniform and are always considered one-dimensional
(although in some cases they are actually O-dimensional, such as a single data point). Even
so, there is a good variety of different buffer types, including vertex and index buffers,
constant buffers, structured buffers, append and consume buffers, and byte address buffers.
Each of these resource types (both textures and buffers) provides a different us-
age pattern, and we will explore all of their variants in more detail in Chapter 3, "The
Rendering Pipeline." However, there are some common overall concepts regarding the use
of resources with the pipeline which we can discuss now. In general, there are two differ-
ent domains for using resources—one is from C/C++, and the other is from HLSL. C/C++
is primarily concerned with creating resources and binding/unbinding them to the desired
locations. HLSL is more concerned with actually manipulating and using the contents of
the resources. We will see this distinction throughout the topic.
A resource must be bound to the pipeline in order to be used. When a resource is
bound to the pipeline, it can be used as a data input, an output, or both. This primarily
depends on where and how it is bound to the pipeline. For example, a vertex buffer bound
as an input to the input assembler is clearly an input, and a 2D texture bound to the output
merger stage as a render target is clearly an output. However, what if we wanted to use the
contents of the output render target in a subsequent rendering pass? It could also be bound
to a pixel shader as a texture resource to be sampled during the next rendering operation.
To help the runtime (and the developer!) determine the intended use of a resource,
the API provides the concept of resource views. When a particular resource can be bound
to the pipeline in several different types of locations in the pipeline, it must be bound with
a resource view that specifies how it will be used. There are four different types of resource
views: a render target view, a depth stencil view, a shader resource view, and an unordered
access view. The first two are used for binding render and depth targets to the pipeline, re-
spectively. The shader resource view is somewhat different, and allows for resources to be
bound for reading in any of the programmable shader stages. The unordered access view is
again somewhat different and allows a resource to be bound for simultaneous random read
and write access, but is only available for use in the compute shader and pixel shader stages.
There are still other resource binding types that don't require a resource view for binding to
the pipeline. These are typically for resources that are created for a single purpose, such as
vertex buffers, index buffers, or constant buffers, and the resource usage is not ambiguous.
With so many options and configuration possibilities, it can seem somewhat daunt-
ing when you are first learning about what each resource type can do and what it can be
used for. However, as you will see later in the topic, this configurability of the resources
provides significant freedom and power for designing and implementing new algorithms.