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

multiple threads, because of the frequent synchronization forced through the API. For this
reason, the general advice when using these APIs was to only interact with the API from
a single thread, often referred to as the rendering thread. This lets a program use general
multithreading for other areas of the program, but restricts all rendering operations to being
performed from a single serial thread of execution.
7.2.1 Resource Creation
The topic of resource creation spreads across a wide variety of tasks, all of which must
interact with the Direct3D 11 API to create API resources. This includes the simple ob-
ject creation tasks such as shader objects and pipeline state objects, and also extends to
device memory based resources such as buffers and textures. To gain an insight into how
multithreading can help with this type of operation, we can consider a few use cases from
traditional serial execution applications.
A simple application structure can create all of the API based resources that it needs
at startup, and then simply use the loaded resources during the execution of the applica-
tion. Since we are considering serial execution of these tasks, the application must create
all of its resources before proceeding into its normal operation. Depending on the number
of resources to create, and how complex they are to load, this can lead to a significant time
period during which the user is waiting to use the program. Resources such as textures
require reading texture data from the hard disk, which can introduce delays for each read
request. Other types of resources, such as shader objects, require some processing to be
performed on them before they are ready to use. In the case of a shader, the source code
for the shader must be compiled before the shader object is created by the API. When there
are many of these tasks to perform, the net effect can produce a significant overall delay.
In more complex application structures, it is common for the application to require
more resources than can fit into memory. A flight simulator provides a typical scenario, in
which there is simply too much data to naively create resources for the entire run of the pro-
gram. In this scenario, the terrain and world object data must be dynamically loaded into
memory depending on where the viewer currently is within the scene. This means reading
the data from hard disk (or perhaps over a network connection) during the execution phase
of the program. Depending on how large the amount of data to be loaded is, this can cause
a short-term reduction in the frame rate of an application, which is very objectionable for
the user.
If a user has a multicore CPU, the impact of these two issues can be somewhat re-
duced in some cases. As described above, in recent modern iterations of Direct3D, the APIs
can be used in a multithreaded environment even though they don't directly support mul-
tithreading themselves. This means that in situations where a delay is caused by reading
from the hard disk, a program could create and use a secondary thread to load the desired