"Translate" Import changes from Direct3D one to Direct3D 12

Translator: Lin Gong

Source: the binary life of wood and wood

Reprint please specify the author and source, thank you!

This is one of the Direct3D 12 documents published by Microsoft, this translation is left as a learning record memo, the level is limited, mistakes are unavoidable, but also look haihan. 　

The original link is https://msdn.microsoft.com/en-us/library/windows/desktop/dn899194 (v=vs.85). aspx

Significant changes in Direct3D 12 to Direct3D 11

Direct3D  12 is a huge subversion of the DIRECT3D 11 programming model. DIRECT3D 12 allows applications to be closer to the hardware floor than ever before. By approaching the bottom, the direct3d 12 is much faster and more efficient. However, the speed and efficiency of your application using direct3d 12 comes at a cost that you are responsible for more work than using DIRECT3D 11.

Direct3D 12 is the return of the underlying programming. By introducing these new features, it gives you more control over the graphics elements in games and applications: objects that represent the overall state of the pipeline, the command list and bundles for task submissions, and the descriptor heap/table for resource access.

Direct3D vs Direct3D 11 trade-offs

Using Direct3D 12 The speed and efficiency of your application has been improved, but you are responsible for doing more work with Direct3D 11.

l in Direct3D 12, CPU-GPU synchronization is explicitly performed by the application and is no longer implicitly executed by the runtime, as in Direct3D 11. This also means that Direct3D 12 does not have an automatic check of the pipeline hazard, so this becomes the responsibility of the application.

l in Direct3D 12, the application is responsible for pipeline data updates. In Direct3D 11."Map/lock-discard" mode in Direct3D The  12 must be done manually. In Direct3d 11, when you call Id3d11devicecontext::map with the D3d11_map_write_discard identity, the runtime returns a pointer to a new memory chunk in place of the old buffered data. This allows the GPU to use the old data while the application is populating the data with new buffers. The application does not require additional memory management. The old buffers are automatically destroyed or reused after the GPU is used.

!--[if!supportlists]-->l   "!--[Endif]--> in direct3d 12, all dynamic updates (including constant buffer,dynamic vertex buffer,dynamic textures, etc.) Explicitly controlled by the application. These dynamic updates include any requested gpu fence and buffer. It is the responsibility of the application to ensure that the memory is valid before it is exhausted.

!--[if!supportlists]-->l   "!--[Endif]-->DIRECT3D 12 only uses the COM-style reference count for the life cycle of the interface (associated to the device lifecycle through the weak reference model of Direct3D). All resource and Description memory lifecycles are the responsibility of the application to ensure proper time to live, and none of them use reference counting. DIRECT3D 11 also uses reference counts to manage interface-related objects.

Pipeline Status Object

DIRECT3D11 allows you to manipulate the pipeline state using a collection of independent objects. For example, the input assembler State,pixel shader State,rasterizer State and the output merge state can be modified independently. This design provides a convenient and relatively high-level graphical pipeline representation. But not the ability to take advantage of modern hardware. Primarily, various state are usually interrelated. For example, many GPUs combine pixel shader and output merger state into a single hardware representation. However, because the Direct3D one API these pipeline stage states are set separately, the display driver cannot determine the pipeline status until the state is finalized, and this will wait until the drawing time. This planning delays the state setting of the hardware, which means additional overhead and less DP per frame.

Direct3D 12 resolves this problem by unifying most of the pipeline states into an immutable pipeline state object (PSOs), which is determined by the time PSOs is created. Hardware and drivers can immediately transform the PSO into a hardware local instruction and state to drive the GPU to work. You can still dynamically switch the use of the PSO. To do this, the hardware simply copies the minimum estimated state to the hardware register, rather than the real-time computing hardware state. The overhead is significantly reduced by using PSOS,DP, and then there can be more DP per frame. For more information about PSOs, seemanaging graphics Pipeline State in Direct3D. .

command lists and collections (bundles)

Direct3D In  11, all task submissions are done through Immediate context, and Immediate context represents a flow of instruction to the GPU. To implement multi-threading, the game also has deferred context to use. Deferred context in direct3d 11 are not perfectly mapped to hardware, so they can do a limited amount of things.

Direct3D  12 introduces a task submission model that gives a list of commands. The command list contains all the information needed to perform a specific job on the GPU. Each command list contains information about which PSO is used, what texture and buffer resources are required, and all DP parameters. Because each command list is self-contained and has no State inheritance. The driver can pre-compute all the required GPU commands and is in a free-threaded (free-threaded) manner. The only processing that needs to be done next is to finally commit the command list to the GPU through the command queue.

In addition to the list of commands, DIRECT3D 12 also introduces a two-level task pre-calculation method: Bundle. Unlike command lists, full self-contained, generic constructs, commits once and then discarded, bundles provide some form of state inheritance to allow reuse. For example, if the game wants to draw two character models with a different texture. One way is to record two identical sets of DP with a list of commands. Another way is to record a bundle that draws a single role model and then "replay" the bundle two times on the command list with different resources. In the latter case, the display driver only needs to calculate the corresponding instruction once, and the Create command list is essentially the equivalent of two low overhead function calls.

For more information on command lists and bundles, see Work submission in Direct3D 1 2 .

description heap and table (descriptor heap and table)

Direct3D Resource bindings in  11 are highly abstract and convenient, leaving many of the modern hardware capabilities not being exploited. In Direct3d 11, the game creates a view object for the resource, and then binds the views to a slot in a different shader stage in the pipeline. The shader then reads the data from the explicitly bound  slot, which are fixed at the time of drawing. This model means that whenever a game is drawn with a different resource, it must rebind the different views to a different slot, and then call the draw function again. This situation also shows that the extra overhead can be eliminated by fully leveraging the hardware capabilities.

Direct3D  12 changed the binding model to match modern hardware and significantly improved performance. and requires a separate resource view and an explicit binding to the slot instead, DIRECT3D 12 provides a descriptor heap to create different resources in the game. This scenario provides a mechanism for the GPU to pre-write directly to the hardware local resource description (descriptor) to memory. Because Descriptor heap has been populated with appropriate hardware-specific descriptor data, changing descriptor table is a fairly low-cost operation

except by descriptor Performance gains from  heap and table. DIRECT3D 12 also allows resources to be dynamically indexed in shader, which provides unprecedented flexibility and opens the door to new rendering techniques. For example, the modern deferred rendering engine typically encodes a certain form of material or object identifier into the middle of a g-buffer. In direct3d 11, these engines must be careful to avoid using too many materials, because having too much in one g-buffer can greatly affect the speed of the final render pass. With resources that can be dynamically indexed, a scene with thousands of textures can end up as fast as a scene with only 10 textures.

For more information on Descriptor Head and table, see Resource Binding .

"Translate" Import changes from Direct3D one to Direct3D 12