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

7.5 Potential Usage Scenarios
The discussion of the multithreading behavior of the Direct3D 11 interfaces up to this
point has focused on what they are capable of from a technical standpoint, and on how they
function. Now we can take a look at a few situations where these tools could be used in a
rendering application. We will look at potential cases where the use of multithreading can
improve the performance of a given task, and will touch on several design considerations
for designing a new rendering system.
7.5.1 Multithreaded Terrain Paging
We will start with how to apply Direct3D 11's multithreading capabilities to a terrain pag-
ing system. A page is a term for a memory management technique that uses more memory
than is physically available on a computer. As data is needed, it can be paged in to a system
memory block, replacing whatever page is already there. When paging is used to manage
the data is needed at any given time, more data can be used than fits into the physical sys-
tem memory. When designing a terrain paging system, the focus is typically on providing
your scene with a very large space that can be explored. Because the scene data is often
quite large, it is normally not possible to directly create all of the resources needed to hold
all of the terrain data. So, that data must be paged into and out of a resource at runtime,
piece by piece, based on the current location of the viewer. This provides a good use case
for the multithreaded systems that have been discussed, since it can use both parallel re-
source creation and as parallel draw submission.
Such a system could use worker threads during startup and runtime. Each of these
threads would be assigned a deferred context to use for the duration of the application, and
would also have a reference to the device. Since we would likely have more terrain pages
than CPU cores, the threads would have to be assigned in some repeating pattern to man-
age a given terrain page. At startup, each worker thread could start loading one terrain page
from disk. It could then use the device's free threaded buffer resource creation method to
allocate a vertex buffer and initialize it with the loaded terrain data. Since terrain loading
is happening in parallel, the startup speed would likely be limited only by the available I/O
bandwidth, which would vary, depending on what media is being used to store the data.
For example, the hard disk, DVD drive, or network storage might all be used, each with
different access characteristics. In addition, since resources can be created in parallel to
rendering operations, the application can simultaneously start rendering a startup screen or
debriefing message while the terrain pages are being loaded and created.
During runtime, each worker thread could generate a command list that configures
the rendering pipeline with the appropriate shaders, resources (such as textures or constant