Graphics Reference
In-Depth Information
context pipeline state is reset to the default pipeline state after the command list is created.
If the passed parameter is set to true, the deferred context pipeline state is preserved be-
yond the FinishCommandList() invocation. This is depicted in Figure 7.7.
The differences between these two options determine the pipeline state with which
the deferred context's next command list starts out with. This allows the application to
control the starting state of the command list, and potentially shares the cost of setting that
state initially across several command lists if the same settings are always used.
7.4.3 Performance Considerations
With some level of control over whether a context either retains or resets its pipeline state, it
is helpful to consider a few situations in which it would be potentially advantageous to use
these different behaviors. The primary considerations depend on the size of the command
lists being used, as well as on the command-list execution strategy that the application will
use. If the application is generating many small command lists within a single frame, and
those command lists all share some common pipeline states, then a net reduction in the
number of calls to set the deferred context pipeline state can be achieved by maintaining
the state between calls to FinishCommandList(). Conversely, if the subsequent command
lists that are being generated are very long or don't share common states, then there is
likely little or no benefit to maintaining the context state between command lists.
The immediate context state propagation depends somewhat more on the frequency
of command list execution. In general, it is faster for the immediate context to return to a
default pipeline state than it is to both save its state prior to execution and then restore it
afterwards. With this in mind, we can see that if many command lists will be executed in a
row, there is no reason to propagate the state since the command list is executed in a fresh
default pipeline state. It wouldn't make any sense to save and restore the original state if it
isn't used in between command list executions. On the other hand, if the immediate context
is used for normal rendering in between command list executions, then it may make sense
to restore its state after executions. Of course, this also depends on how many of the states
are common before and after the command list is used, so there is no general rule to deter-
mine which technique is better suited for a particular rendering sequence. This is a decision
best left up to profiling and testing later on in the development cycle.
One final point to consider regarding the use of a previously set state relates to debug-
ging of rendering operations. In this case, if an application inadvertently relies on a state
that is set in some other portion of the rendering code then it is quite possible that a change
to the rendering code of one object could affect the state of other objects that occur later in
the rendered frame. In general, it is good practice to minimize these types of dependencies,
especially if the rendering code is data-driven instead of hard coded. At the very least, it
is a good idea to occasionally run the rendering code with no state propagation active to
determine if these dependencies exist.
Search WWH ::




Custom Search