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

7.6.1 Things to Do

We begin this section with a discussion of some design points that should be incorporated
if possible into your initial design. These are suggested practices that are not required by
Direct3D, but that have been found to be helpful in the authors' experiences with the API.

Variable Levels of Threading
The first topic is to ensure that your application/rendering framework is not locked into a
particular number of threads. This is important for several reasons. First, there is no way to
know how many CPU cores an end user's system will have, so it makes sense to dynami-
cally decide the number of threads to create and use. If possible, this should be extended to
allow the number of threads to be selectable at runtime, to allow for future possible opti-
mizations for switching additional threads on or off as the rendering workload needs them.
The second reason for using a variable number of threads is related to debugging
your programs. If you are not receiving the final rendered frame that you want, this could
be due to the multithreaded rendering itself (or more precisely, to how it is being used). To
help minimize debugging time, it is extremely advantageous to be able to switch among
the following setups:

Multi-threaded, deferred context rendering: Multiple threads are used with deferred
contexts to generate command lists, which are then rendered on the immediate context.

• Single-threaded, deferred context rendering: A single thread is used with a deferred

context to generate command lists, which are then rendered on the immediate context.

• Full single-threaded rendering: A single thread is used with only the immediate con-

text to directly render without generating command lists.

These various mixtures allow for isolating rendering issues between a regular ren-
dering error, an incorrect state setting due to the multiple contexts being used, and data
contention between multiple threads of execution. This type of flexibility is assisted by the
fact that the immediate and deferred contexts outwardly appear identical. Therefore, if the
rendering system batches are incorporated into objects that can be passed to a thread for
processing, then each thread would require one context to do the processing. The rendering
framework could then decide dynamically at runtime how many threads to use, and which
types, and then pass the rendering work to the corresponding objects.

Using PIX

Some additional considerations are needed when using PIX for debugging and analyzing
your application. PIX is a very useful tool that can let you inspect what your program has