Multithreaded Rendering - Practical Rendering and Computation with Direct3D 11 - page 358

command list is submitted for replaying by calling ExecuteCommandList() on the imme-
diate context or another deferred context. So the general paradigm for using command lists
is that they are generated by a deferred context, then are either consumed by the immedi-
ate context or applied to another deferred context, which effectively inserts that list into
another list's stream of operations.
After a command list has been used, it is disposed of by calling its Release () method.
However, determining when a command list should be released is up to the developer.
Even though the command list itself is immutable, there is no limit to the number of times
it can be executed. This introduces some interesting possibilities with respect to caching
particular subsets of calls into command lists and permanently reusing them throughout
the duration of the application. Later in this chapter, we will see several different levels of
granularity for command lists, which can take advantage of this property.
This discussion also requires us to provide a distinction between static and dynamic
states for a given object rendering sequence. A static state is any pipeline configuration that
doesn't change from frame to frame, while dynamic states do change in some way over
time. Examples of static states could be something like the blend state, a vertex shader, or
a texture. Examples of dynamic states would be any transformation matrices that change
from frame to frame, and any other state that doesn't remain the same over time. Typically,
every object rendering requires some combination of both static and dynamic states. At
first, this concept of reusing command lists may seem somewhat unusable, since you would
normally want to render an object in a different location in each frame, because the camera,
or the object itself, is moving. This would require new transformation matrices to be gener-
ated and uploaded for use with the vertex shader, which would seem to be incompatible
with reusing command lists, which are immutable.
However, a command list records the states that are set on the deferred context. To use
the example of transformation matrices from above, the application would bind a constant
buffer (constant buffer A) that contains the transformation matrices to the vertex shader.
Once the command list has been generated with the FinishCommandList() method, the
specific constant buffer bound to the vertex shader cannot be changed in the command
list. This means that there is no way to bind a different constant buffer (constant buffer B)
in its place. However, you can modify the contents of constant buffer A to contain the
desired transformation matrices, without requiring a new command list. This is the same
concept as passing function arguments by value or by reference in C/C++. The command
list essentially records a pointer to a particular resource, while the value that it points to
can be changed independently of the command list. This lets you inject dynamic state into
command lists, even though the command list itself cannot change. To summarize this idea,
the command list cements the resources that are bound in its API call sequence — but it
does not cement the contents of those resources. This concept is depicted graphically
in Figure 7.3.