D3D12 Graphics Programming

Significant improvements in D3D 11 to D3D 12

The programming model of Direct3D 12 is very different from Direct3D 11. In Direct3D 12, applications and hardware are much closer, which has never been before. This makes d3d12 faster and more efficient than ever before. But the cost of speed and efficiency increases is that more tasks need to be done in the application than D3d11,direct3d 12.

• Explicit synchronous processing
• Physical Memory Residency Management
• command lists and command sets (commands list and commands bundle)
• Describe the heap and descriptor descriptor
• Migrating from D11 to D12
• Related Topics

Direct3D a return to low-level programming; It gives you + control over the graphical elements of your games and apps by introducing these new features:objects to represent the overall state of the pipeline, command lists and bundles for work submission, and descriptor heaps and tabl Es for resource access.

Your app has increased speed and efficiency with Direct3D, but you is responsible for more tasks than your were with Di Rect3D 11.

Explicit Synchronization

• in direct3d 12, CPU-GPU synchronization are now the explicit responsibility of the app and are no longer implicitly Performed by the runtime, as it's in direct3d 11. This fact also means the no automatic checking for pipeline hazards are performed by direct3d 12, so again the is th E apps responsibility.
• in direct3d 12, apps is responsible for pipelining data updates. That's, the "Map/lock-discard" pattern in direct3d 11 must was performed manually in Direct3d 12. In Direct3d 11, if the GPUs are still using the buffer when you callid3d11devicecontex T::map with
• In Direct3D, all dynamic updates (including constant buffers, dynamic vertex buffers, dynamic textures, and so on) is Explicitly controlled by the app. These dynamic updates include any required GPU fences or buffering. The app is responsible for keeping the memory available until it's no longer needed.
• Direct3D uses Com-style reference counting only for the lifetimes of interfaces (by using the weak reference model of D Irect3d tied to the lifetime of the device). All resource and description memory lifetimes is the sole responsibly of the app to maintain for the proper duration, and is not reference counted. Direct3D uses reference counting to manage the lifetimes of interface dependencies as well.

Physical Memory Residency Management

A Direct3D application must prevent race-conditions between multiple queues, multiple adapters, and the CPU threads. D3D12 no longer synchronizes the CPU and GPU, nor supports convenient mechanisms for resource renaming or multi-buffering. Fences must be used to avoid multiple processing units from over-writing memory before another processing unit finishes U Sing it.

The Direct3D application must ensure data is resident on memory while the GPU reads it. Memory used by each object is made resident during the creation of the object. Applications which call these methods must use fences to ensure the GPU doesn ' t access objects which has been evicted.

Resource barriers is another type of synchronization needed, used to synchronize Resource and subresource transitions at A very granular level.

Refer to Memory Management in Direct3D 12.

Pipeline State Objects

Direct3d 11 allows pipeline state manipulation through a large set of independent objects. For example, input assembler-state, pixel shader-state, rasterizer-state, and output-merger state can-all is independently Modified. This design provides a convenient and relatively high-level representation of the graphics pipeline, but it doesn ' t utiliz E The capabilities of modern hardware, primarily because the various states is often interdependent. For example, many GPUs combine pixel shader and output merger state to a single hardware representation. But because the direct3d 11 API allows these pipeline stages to be set separately, the display driver can ' t resolve I Ssues of pipeline state until the state is finalized, which "t until draw time. This scheme delays hardware state setup, which means extra overhead and fewer maximum draw calls per frame.

Direct3D addresses this scheme by unifying much of the pipeline state to immutable pipeline state objects (PSOs), whi CH is finalized upon creation. Hardware and drivers can then immediately convert the PSO to whatever Hardware native instructions and state is require D-to-execute GPU work. You can still dynamically change which PSO are in use, but to does so, the hardware only needs to copy the minimal amount of pre-computed state directly to the hardware registers, rather than computing the hardware state on the fly. By using PSOs, the draw call overhead are reduced significantly, and many more draw calls can occur per frame. For more information on PSOs, seemanaging graphics pipeline state in Direct3D 12.

Command lists and bundles

In Direct3D One, all work submission are done via the immediate context, which represents a single stream of commands that G O to the GPU. To achieve multithreaded scaling, games also havedeferred contexts available to them. Deferred contexts in Direct3D one-to-one don ' t map perfectly to hardware, so relatively little work can is done in them.

Direct3D introduces a new model for work submission based on command lists that contain the entirety of information nee Ded to execute a particular workload on the GPU. Each new command lists contains information such as which PSO to use, what texture and buffer resources is needed, and the Arguments to all draw calls. Because each command list was self-contained and inherits no state, the driver can pre-compute all necessary GPU commands U P-front and in a free-threaded manner. The only serial process necessary are the final submission of command lists to the GPU via the command queue.

In addition to command lists, Direct3D-also introduces a second level of work Pre-computation:bundles. Unlike command lists, which is completely self-contained and is typically constructed, submitted once, and discarded, BU Ndles provide a form of state inheritance that permits reuse. For example, if a game wants to draw the character models with different textures, one approach was to record a command lis T with sets of identical draw calls. But another approach was to ' record ' one bundle that draws a single character model and then ' play back ' the bundle twice on T The He command list using different resources. In the latter case, the display driver only have to compute the appropriate instructions once, and creating the command lis T essentially amounts to the Low-cost function calls.

For more information on command lists and bundles, see work submission in Direct3D 12.

Descriptor Heaps and tables

Resource binding in direct3d 11 are highly abstracted and convenient, but leaves many modern hardware capabilities Underutilized. In direct3d 11, games Createslots at various shader stages in the pipeline. Shaders, in turn, read data from those explicit bind slots, which is fixed at draw time. This model means that whenever a game would draw using different resources, it must re-bind different views to different SL OTS, and call draw again. This case also represents overhead the can is eliminated by fully utilizing modern hardware capabilities.

Direct3d 12 changes the binding model to match modern hardware and significantly improves performance. Instead of requiring standalone resource views and explicit mapping to slots, DIRECT3D 12 provides a descriptor heap into which games create their various resource views. This scheme provides a mechanism for the GPU to directly write the Hardware-native Resource Description (descriptor) to me Mory Up-Front. To declare which resources is to being used by the pipeline for a particular draw call, games specify one or more descriptor Tables that represent sub-ranges of the full descriptor heap. As the descriptor heap has already been populated with the appropriate hardware-specific descriptor data, changing Descrip Tor tables is an extremely low-cost operation.

In addition to the improved performance offered by descriptor heaps and tables, Direct3D also allows resources to be dy namically indexed in shaders, which provides unprecedented flexibility and unlocks new rendering techniques. As an example, modern deferred rendering engines typically encode a material or object identifier of some kind to the inte Rmediate G-buffer. In Direct3D, these engines must is careful to avoid using too many materials, as including too many in one g-buffer can Significantly slow down the final render pass. With dynamically indexable resources, a scene with a thousand materials can is finalized just as quickly as one with only Ten.

For more information about descriptor heaps and tables, see Resource binding, and Differences in the binding Model from Di Rect3D 11.

Porting from Direct3D 11

Porting from Direct3D a involved process, described in Porting from Direct3D one to Direct3D 12. Also refer to the range of options inworking with Direct3D One, Direct3D and DIRECT2D.

D3D12 Graphics Programming