Microsoft DirectX 12 Preview: What Can Players and Developers Expect?


The new version of DirectX 12, frankly speaking, was delayed. DirectX 11 was introduced back in October 2009 - more than four years ago. For comparison, the path from DirectX 10 to DirectX 11 took about three years. Let's note right away: DirectX 12 was just announced at the Game Developers Conference in San Francisco - the first games based on DX 12 will appear no earlier than the end of 2015. By this time, Microsoft may be on time to release Windows 9, no matter what name this OS ultimately receives.

In general, to the question “Where can I download DirectX 12?” no answer yet. There are only certain prospects as to what the new version of the API will bring to developers and us gamers. In the meantime, the announcement of DirectX 12 should be considered as a signal that active work on the development of DirectX continues. Previously, the lack of visible activity on the part of Microsoft led to the fact that some people even questioned the release of new versions of DirectX. We are talking about last year's interview with Roy Taylor, AMD Vice President of Global Channel Sales, to heise.de. Although such statements should be taken, as they say, “with a pinch of salt,” especially in light of AMD’s own Mantle initiative (more about it in our review and testing of AMD Mantle). Be that as it may, Microsoft decided to remind about DirectX and act.

Unlike previous iterations, the new release is focused not on graphical effects and support for new GPU hardware functions, but on optimizing the DirectX software stack for existing hardware. AMD has convincingly demonstrated that in some respects DirectX 11 is a bottleneck that limits system performance. Specifically: DirectX 11 is ineffective with a large number of draw calls. We explored this issue in our AMD Mantle review, which showed some pretty impressive results under similar conditions.

With DirectX 12, CPU efficiency is expected to increase by 50% compared to DX11. At least this result was obtained using a closed version of 3DMark 2011, ported to DX12. Microsoft names several factors that made this possible.

⇡#Multi-threaded execution of driver instructions

Profiling results from the same benchmark demonstrate more efficient distribution of CPU load across multiple threads. The diagram shows that four threads now distribute operations not only of the 3DMark program itself, but also of the graphics card driver - we are talking about a component executed in User Mode.

In addition, if you look closely at the diagram, you will notice that when using DirectX 12, the graphics driver component in Kernel Mode disappears. We are talking about a low-level Direct3D subsystem, which includes a video memory manager, a GPU scheduler, and a miniport driver, which the GPU manufacturer must provide for direct access to hardware functions.

DirectX 11

DirectX 12

Thus, the entire Direct3D kitchen has now completely moved to User Mode. In itself, such a step will have a negative impact on performance, but, in theory, it should be compensated for by more efficient multithreading, as well as the absence of a context change between User Mode and Kernel Mode.

Download DirectX 12 for free

ApplicationOSFormatVersionSizeLoading
DirectX 12Windows 10x32 - x64online installer2.06 Mb
DirectX 12Windows 11x32 - x64online installer2.03 Mb
DirectX 12Windows 7x32 - x64online installer2.02 Mb
DirectX 12Windows XPx32 - x64online installer2.01 Mb

Attention!! DirectX 12 is installed by default in Windows 10, if for any reason you need to update this module, this is only possible with an online installer, there are no more forced installation packages, the program will check and, if necessary, download and install the latest DirectX packages.

⇡#Pipeline State Objects

In addition, Microsoft directly worked on the draw calls problem that Mantle solves so successfully. This required a major overhaul of the Direct3D graphics pipeline. A little education about how rendering is done in Direct3D is needed here. There are several stages of the pipeline, which at an abstract level represent the stages of image preparation. The important thing is that the stages, contrary to what they may seem, are not executed one after another in real time. The DirectX runtime component is required to determine the pipeline state, which is a set of states of each stage, that is, the parameters of the operations that the GPU performs during the rendering process, and resources - the data on which operations will be performed (textures, vertices, etc.) Further). Only when all this is put together is a draw call made - a call that starts rendering the object. And then the miniport driver of the GPU, in turn, translates the pipeline state into a set of instructions for the GPU in a language it understands (hardware state).

The last stage contributes to the overall object rendering time (remember, this and all of the above procedures are still running on the CPU). And if there are a lot of objects on the screen, then the notorious draw calls problem arises, when CPU performance becomes a bottleneck. AMD Mantle, being a low-level API, reduces the pipeline preparation time for issuing a draw call simply due to the absence of the stage of translating pipeline state into hardware state. Although who knows what other optimizations AMD included in Mantle. The Mantle SDK along with detailed documentation is not yet publicly available.

Direct3D 12 is still a high-level API, relatively indifferent to the hardware it renders on (the GPU only reports the features it supports). It solves the problem differently. Instead of passing the entire pipeline state to the driver at the time of the draw call, the states of many individual stages of the pipeline are combined into several larger objects - PSO (Pipeline State Objects), which are formed independently and given to the driver immediately. Thus, without waiting for a draw call, the driver can immediately convert PSO into hardware instructions and almost send the latter to the GPU registers (this point is not entirely clear in the source on MSDN). In addition, consolidation of objects representing the states of pipeline stages allows the driver to more quickly resolve dependencies between the latter. If in the process of preparing for a draw call any of the PSOs has changed, it is also necessary to recalculate only the corresponding instructions, and not the entire hardware state.

It is also not entirely clear why a separate representation of the pipeline state should lead to a dramatic reduction in the preparation time for a draw call. One way or another, the translation of pipeline state into hardware state still consumes CPU time. Perhaps early preparation of individual PSOs will somehow help resolve dependencies faster when preparing the hardware state, as they write about on MSDN. Perhaps the advantage will be obtained by executing the Direct3D runtime component and the GPU driver on different threads.

Brief description of the graphical pipeline

At the core of the graphics library are drawing functions that run the graphics pipeline, a hardware and software tool for rendering 3D graphics. The hardware component is represented by the video adapter, the software component is the driver. The graphics pipeline can be thought of as a black box that is divided into stages and performs the necessary transformations. The contents of this black box may vary. The conversions performed depend on the purpose of the graphics system, cost, level of versatility required, and many other factors. Also, a specific video adapter is a complex mechanism, the operating rules of which are often known only directly to the manufacturer.

So, today the process of visualizing a three-dimensional scene looks in general terms as follows.

Vertex Transformation

Each vertex has a specific set of attributes such as position, color, texture coordinates, normal vector or all vectors from tangent space and possibly some others. Vertex transformation is the first stage of the graphics pipeline. At this stage, the input data are the attributes of a specific vertex, on which mathematical transformations are performed. These operations include transforming vertex position, generating and transforming texture coordinates, calculating lighting for each individual vertex, and any other operations that need to be performed at the vertex level. Each vertex is processed in parallel with other vertices on the available graphics accelerator cores. The main result of the vertex program is to transform coordinates from model space into a special clip space.

Construction of primitives and rasterization

The input data of this stage is the transformed vertices, as well as information about their connection. From this data, geometric primitives are assembled. The result is a sequence of triangles, lines or dots. These primitives can be cut off by planes defined in the program. Also at this stage the back triangles of objects can be discarded. These triangles are determined by the direction in which the vertices are traversed (clockwise or counterclockwise). Which traversal direction corresponds to the rear triangle is specified via the graphics API. Polygons that have been clipped may become rasterized.

Texturing and coloring

At this stage, the necessary interpolation is carried out on the attributes of primitives rasterized into a set of fragments, as well as a sequence of mathematical transformations and texturing operations, which determines the final color of each fragment. Also at this stage, a new depth can be determined or even the exclusion of a fragment from the frame buffer.

Per-fragment operations

At this stage, a number of fragment-by-segment tests are carried out, such as a scissor test, a stencil test, and a depth test. These tests determine the final appearance, color, and depth of the fragment before updating the screen buffer. If any test fails, the fragment is not updated. After the tests, a blending operation is performed that combines the final fragment color with the current pixel color, and the final result is written to the screen buffer. The blending operation is performed at this stage because the texturing and coloring stages do not have access to the screen buffer.

A more detailed pipeline structure can be found in the DirectX 11 specification (the DiretcX 12 document only covers changes from the previous version)

⇡#Command lists, bundles

DirectX 12 also introduces a new model for managing GPU load using command lists. In the DirectX 11 model this term already exists. The API provides two types of device context: immediate context and deferred context. In the first case, commands are directly sent to the GPU driver, in the second, lists of commands are written, which can then be played back in the immediate context. What's new in DX12 is that the Direct3D 11 GPU driver can pre-compute low-level instructions based on various instruction lists.

In addition to lists of commands, Direct3D 12 introduced another entity - bundles. A Bundle is a set of commands that can be executed repeatedly in combination with different resources - for example, to render identical objects with different textures. In this case, the driver is only required to prepare instructions for the GPU once.

What can we get for all this?

After all this verbiage, many readers may be wondering what conclusions we can draw after the official presentation of DX12 Ultimate. The reality is that on paper all of these changes are a step in the right direction

for what will be the key for this generation:
taking advantage of the enormous hardware resources
that the Xbox Series X will have, and the future of Turing and RDNA2; But like everything in this world, without sufficient support from developers, we will never be able to see the corresponding results.

0 0 votes

Article rating

⇡#Compatibility, conclusions

Unlike previous versions, DirectX 12 will not lose compatibility with existing GPUs that support DirectX 11. NVIDIA has already announced that DX12 will be adopted by processors based on the Fermi, Kepler and Maxwell architecture. AMD guarantees compatibility for GPUs based on GCN architecture, Intel - for Iris and Iris Pro graphics in Haswell chips. DirectX 12 is also expected to be ported to Xbox One.

However, information has appeared about some additional functions of DirectX 12, which will still require hardware modifications to the GPU. Overall, this uncertainty, coupled with the long wait times for the first games to support DirectX 12, can be seen as a sign that API development is still at a very early stage. This assumption is also supported by the topic of optimizing CPU usage, which combines DX12 and AMD Mantle, introduced relatively recently - last fall.

Naturally, DirectX 12 casts a shadow on the future of the AMD initiative, which started quite successfully and is gaining momentum, receiving support in popular game engines (Frostbite 3, the next version of CryEngine). Perhaps it was AMD that motivated Microsoft by drawing attention to the shortcomings of DirectX 11, but in one and a half to two years Mantle will no longer be the only API that makes it possible to avoid them. However, DirectX 12 compatibility is not limited to video adapters based on the GCN architecture. Still, it’s too early to bury Mantle, because AMD has a lot of time to win the loyalty of developers. Additionally, there is no guarantee that DirectX 12 will ultimately be as effective as Mantle. Regardless, DX12 is still not a low-level API like Mantle, which automatically gives the latter a performance advantage. It is too early to make assumptions on this issue until the first results of publicly available benchmarks have appeared.

Variable speed shading

Variable rate shading is another feature that was already present in DX12. Shaders tell the system what the color, brightness, and contrast of each pixel should be. However, this process can be computationally expensive, and this is where variable rate shading occurs. It shades important parts of the game scene at full resolution, while less important objects use less GPU power for shading.

Imagine yourself driving a car in the future of Forza Horizon or another racing game, for example. It is important that you see the car in front of you in every detail, but so that a tree or fence passing by does not require the same treatment.

Here's how NVIDIA described it:

“The algorithms developed by the developers identify pixels that the player cannot easily see and pixels that are infrequently changed or updated, and use VRS to reduce the speed at which they are rendered (darkened). For example, black pixels in the shadow do not differ when the shading speed is reduced. So, by reducing the shading rate of multiple pixels per frame, the workload on the GPU is reduced, which improves performance."

The overall effect shouldn't be noticeable to a gamer, but it makes the computer run much more efficiently. The increased efficiency promises even better visuals and better gaming performance overall.

How to use

Let us immediately note that we are talking about an offline installer. This means that DX installation does not require an Internet connection. You only need to download the archive from our website, and for further actions you do not need a network connection. You can copy the file to an external drive and install the software on any device in the absence of the Internet. Installation is carried out in a few simple steps:

  1. Downloading and unpacking the archive.
  2. Run the installer as administrator.
  3. Waiting for files to be unpacked.
  4. Reboot your computer.

It is not possible to completely remove and reinstall DirectX from scratch from the Windows 10 operating system, so to fix errors you need to install this version and update the OS to the latest update.

Rating
( 2 ratings, average 5 out of 5 )
Did you like the article? Share with friends:
For any suggestions regarding the site: [email protected]
Для любых предложений по сайту: [email protected]