
March 20, at the conference GDC 2014, the announcement of the next version of DirectX 12 was held. The main core of DirectX is Direct3D, which is where the most critical components of gaming applications are created. The development team made a number of changes to Direct3D, as a result of which the speed and efficiency of many graphical operations increased. These changes allow you to create more detailed scenes and achieve full exploitation of the capabilities of modern GPUs. But these opportunities will appear not only in the "high-end" gaming computers. Direct3D 12 will work on all Microsoft devices. Phones, tablets, laptops, desktops and of course, Xbox One, all of them will allow you to use the API Direct3D 12.
What makes Direct3D 12 better than previous versions? First and foremost, this is a lower level of abstraction of equipment. This allows games to significantly improve streamline scalability and GPU utilization. In addition, games will benefit from descriptor tables and pipeline status objects. Of course, this is not all, Direct3D includes a set of new features for the render pipeline, which can significantly increase the efficiency of transparency calculations, collision detection and geometric culling.
It goes without saying that an API is good only when there are tools that help it to use it effectively. DirectX 12 will contain a number of excellent tools for Direct3D immediately after the release of DirectX 12 to light.
Yes, not to forget - DirectX 12 will work on many existing video cards.
')
Is this a marketing ploy?
The development team read a lot of comments on Twitter and forums where the question is often asked - is this really a technological update or did the marketing department just get the budget for promotion of the new index to the version? All that you read below comes directly from the team that has been developing DirectX for 20 years.
It is our job to create an API, and we worked together with our partners, software and hardware manufacturers, in order to prove significant improvements in Direct3D 12 performance. Those new products that are included in Direct3D 12 are not hacks of any micro benchmarks. The numbers we received are based on commercial games and recognized benchmarks tested on the alpha version. The screenshots you see were made on real Direct3D 12 applications with real implementation of runtime and Direct3D 12 drivers.
3DMark - in-line scaling + 50% CPU utilization
If you are an avid gamer, you probably know about
3DMark . This is a great tool for assessing performance on a wide range of devices and hardware. 3DMark running on Direct3D 11 allows you to use stream scaling, but due to some overlays associated with runtime and drivers, there is a idle waiting time for threads and cores. After transferring 3DMark to Direct3D 12, we saw two significant improvements - a 50% increase in CPU utilization and an improvement in the distribution of work between threads.

Direct3d11 
Direct3D 12

Forza Motorsport 5 Tech Demo - Console Efficiency on PC
Forza Motorsport 5 is an example of a game that squeezes the most out of XboxOne. Under the hood, Forza is a low-level API for interacting with the graphics subsystem of the console. Traditionally, this level of efficiency is achievable only on a unified gland. Now this possibility, even in the alpha version, is on the computer, and even on the phone. When porting graphics core code based on Direct3D 11.1, the Turn 10 team achieved the same level of optimization on the PC, all thanks to the features of Direct3D 12.

Where did this performance come from?
Direct3D 12 departs from the old programming model Direct3D 11, allowing the application to be much closer to the hardware than ever before. We reviewed a significant number of areas of the API, key ones of which are mechanisms for representing states of the pipeline, methods for sending tasks and access to resources.
Pipeline Status Objects
Direct3D11 allows you to manipulate the states of the pipeline through a large set of cross objects. For example, the state of the input assembler, the state of the pixel shader, the state of the rasterizer and the state of the output mixer, all of which can be changed independently. This mechanism provides a convenient, relatively high-level presentation of the graphics pipeline, but unfortunately, it does not fit well with modern hardware. Primarily due to the fact that there are interdependencies between many states. For example, many GPUs combine the state of a pixel shader and output mixer into one hardware representation. The Direct3D 11 API allows you to change their state independently, but the driver cannot allow it until you know that the status is over, and this is not possible before the start of the drawing. This leads to delays in setting the state of the iron, means costs and fewer draw calls per frame.
Direct3D 12 solves this problem by unifying most of the state of the pipeline into an immutable pipeline state object (CCL), which is fixed immediately after its creation. This allows the hardware and the driver to immediately turn the USC into the corresponding hardware instructions, and the state is necessary for the performance of the GPU. At the same time, you can dynamically choose which USC should be used at the moment. Now it only remains to copy a small amount of a pre-calculated state into the hardware registers, instead of calculating the hardware state on the fly. This means significantly less overhead between draw calls, and more draw calls per frame.
Packages and command lists
In Direct3D 11, all tasks are sent using the immediate context, which represents one series of commands sent to the GPU. For multi-threaded performance scaling, games use deferred contexts, but, as in the case of USC, deferred contexts do not correspond to the real state of things in hardware.
Direct3D 12 provides a new model for sending jobs, based on command lists. They contain all the necessary information for execution in the GPU. The command list includes USC, texture and buffer resources, as well as arguments for the draw command. Due to the fact that the list of commands is autonomous and does not contain a state, the driver can calculate in advance the necessary GPU commands in an independent stream. All that is needed is the serialization process in the final sending of the list of commands to the GPU which is done through the command queue, and this process is very effective.
In addition to the command lists, Direct3D 12 includes a mechanism for secondary precomputation using packets. Unlike command lists, which are completely autonomous, and usually created, are sent for execution, and then destroyed, packages provide some form of state independence and imply reuse. For example, if the game needs to display two models of characters with different textures, one approach would be to write a list of teams with two sets of identical draw calls. Another approach is to write one package that will draw one character, and then “rewind” the package twice in the list of commands using different resources. In the latter case, the driver needs to calculate instructions only once, and creating a list of commands is essentially equal to two function calls with a low cost.
Heap and table descriptors
The snapping of resources in Direct3D 11 is well-abstracted and quite convenient, but at the same time many of the features of modern hardware remain out of work. In Direct3D 11, the game creates “presentation” objects, then binds these representations to “slots” at various stages of the shader in the pipeline. Shaders, in turn, read data from these explicitly attached slots, which are fixed at the time of rendering. Such a model means that if a game needs to be rendered using a different set of resources, it is necessary to rebind views to other slots and re-invoke drawing. This is another example of overhead that can be eliminated by fully utilizing the advanced capabilities of iron.
Direct3D 12 changes the binding model to match current capabilities and significantly increases performance. Instead of requiring stand-alone resource views and explicit slot mapping, Direct3D 12 provides a bunch of descriptors where the game creates its own resource views. This mechanism allows the GPU to directly and in advance write the hardware representation of the resource description into memory. To declare which resource will be used in the pipeline for a particular draw call, the game indicates one or more descriptor tables that represent the sub-range of the full heap of descriptors. Since this heap is pre-loaded with the necessary hardware-specific data, changing the descriptor table is a very cheap operation.
In addition to the improvements associated with the descriptor heap and tables, Direct3D 12 allows you to dynamically index resources in shaders. This provides unprecedented flexibility and opens the way to new render techniques. For example, modern render engines based on the deferred approach often encode a material or object identifier of some type into a preliminary g-buffer. In Direct3D11, such engines should be careful in using too many materials, since the inclusion of multiple g-buffers can significantly reduce the speed of the final draw of the draw. Together with dynamically indexed resources, a scene with thousands of materials can be finalized as quickly as with ten.
Want to be one of the first?
If you are a professional game developer and assume that Direct3D 12 can speed up the performance of your application, you can apply
for participation in a preliminary familiarization program .