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

in the new version of the device. This new, leaner device retains resource creation respon-
sibilities, but it has given up the direct management of the pipeline to the device context.
This change in responsibilities is described in great detail in Chapters 1-3.
However, this was not just a splitting of responsibilities. The split was made along
the lines where there are different multithreaded requirements for the functionality. The
resource creation methods have been implemented as free-threaded, which means that
similar to thread-safe, they can be called simultaneously from multiple threads, but an im-
portant difference is that that the methods now don't use the heavyweight synchronization
primitives. Instead, they are designed to be reentrant, so that there are no dependencies be-
tween multiple invocations of a given method. This lets the device perform object creation
on multiple threads without the artificial serialization that was used to provide thread safety
in previous versions of Direct3D.
With resource creation now available in a true multithreaded environment, and with
minimal overhead introduced by the implementation technique, Direct3D 11 has provided
facilities to allow parallel loading of resources with very straightforward implementations.
Now, the same thread that has loaded a resource from disk can directly create a texture or
buffer resource with the loaded data. This minimizes the amount of communication needed
between threads and reduces the complexity of these types of operations.
7.3.2 The Device Context
The other half of functionality that has been split off from the device has been put into
its own interface, called the device context. The device context comes in two flavors: the
immediate context and the deferred context. We will discuss both of these objects, which
implement the same interface, in the following sections.
The Immediate Context
The immediate context represents more or less the pipeline draw submission abilities from
previous iterations of Direct3D's device interface — it provides the gateway for an applica-
tion to directly interface with the GPU. The pipeline state setting methods are sent to the
driver as soon as they are called, and are executed more or less "immediately" (in reality,
this may not be immediate, because of driver implementations that use a buffer to queue up
operations, but it is as close to immediate as the application can get).
This new interface has been implemented to be thread-unsafe, meaning that it doesn't
use synchronization primitives, and that it hasn't been designed to intrinsically allow mul-
tiple threads to simultaneously use it. This is essentially the opposite of the multithreading
behavior exhibited by the device, which is frep-threaded. Why would this be implemented
in such a thread-unfriendly way? The answer is that this is actually a very thread-friendly