Directx11 tutorial (13) d3d11 pipeline (1)

Starting from this tutorial, we pause coding. First, let's take a look at the d3d11 pipeline. These pipelines do not involve specific hardware, but focus on understanding the pipeline implementation that supports d3d11.

References:

Http://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-graphics-pipeline-2011-part-1/

Through the previous tutorial, we know that to draw a triangle with d3d11, we need to do the following steps:

 

These steps will eventually be executed on the d3d11 hardware. The approximate data flow from calling the d3d11 API to the final execution on the d3d11 hardware is shown in the figure below:

The first is our application (APP). By calling the d3d11 API function, it creates resources (such as vertex buffering), sets the status (such as the deep template status), and calls the drawindex function.

D3d runtime will track the status we set, verify whether the function parameters are correct, verify the shader code and the shader link library, and then transmit the output of these calls to the driver UMD, to some extent, we can regard d3d runtime as a wrapper, which is an interface between the application and UMD.

 

UMD (User Mode Driver) refers to the user mode driver. It is actually a dynamic link library (DLL) that runs completely on the CPU. Its main functions include:

1. shader Compilation

Before d3d runtime transfers the shader to UMD, some verification work will be done, such as whether the shader code syntax is correct, and whether the number of sampler sets exceeds the maximum limit.

In UMD, the shader code is eventually compiled into hardware-related code and transmitted to video memory. The shader parameter is transmitted to the const buffer in video memory.

Currently, both AMD and NV are drivers that support different generations of graphics cards. Therefore, the shader code is usually first compiled into Ir (intermediate code) and then compiled into a specific hardware-related shader assembly language.

2. UMD can implement certain memory management functions.

For example, creating textures and allocating space for textures (UMD manages the memory mainly including the system memory that the GPU can access and the video memory that the CPU can directly access. These memories are called Remote Access Memory ).

3. Schedule transmission between system memory and mapped video memory.

4. convert all the states of the application and perform the Drawing operation into a hardware understanding.

Generally, the hardware abstraction layer in UMD is used to convert packet related to hardware. The packet type mainly includes the hardware register setting packet and drawcall packet, then write packet into the command buffer (or DMA buffer). These buffers are first copied to the remote buffer and finally transmitted to the indirect ring buffer on the GPU side.

5. Based on the format used when the vertex buffer and index buffer are created, the vertex buffer and index buffer are directly put into video memory by UMD (the format is set to be directly created in video memory, similar to VBO in OpenGL) or delayed loading (created in system memory), video memory is passed in only when the GPU actually reads data.

We know that texture images are usually in linear format, while in GPUs we usually use the Z tile format, and in UMD we do not convert the texture address, instead, the GPU transmits the specific tile mode to the GPU based on the input parameters. The GPU performs the swizzle operation on the Texture Based on the tile mode. Z order related knowledge can be seen on the wiki page http://en.wikipedia.org/wiki/Z-order_curve

Texture swizzle knowledge see: http://www.cnblogs.com/mikewolf2002/archive/2012/03/11/2390097.html

GPU manufacturers are willing to write more functions into UMD, because it is only a DLL, which is easy to debug and can implement multi-threaded operations (such as one thread to compile shader and one thread to process texture ), even if UMD crashes, it will not cause a blue screen of the system, because it is essentially different from our common application.

Finally, let's look at the concept of a context switch: Our GPUs not all run on the console, but only correspond to one app. Multiple apps may access the GPU through time slice rotation, when context switch and context switch are involved, we need to save the GPU status set by the current app and the GPU data executed so that the OS can switch to this app again, resume the operation of the app.

KMD (Kernel Mode Driver) refers to the kernel mode driver. KMD is responsible for directly dealing with hardware and may have multiple UMD instances in the system, but KMD can only have one. Once KMD crashes, a blue screen error may occur in the operating system. The main functions of KMD include:

1. When multiple applications use GPUs, KMD manages applications through slice time-based operations.

For example, if you perform physical memory operations on an app in one time slice, initialize the GPU for another app in another time slice, and set the display mode, you need to switch between different apps by context switch, response interruption.

2. For copyrighted video content, KMD creates a special path between the player and GPU to prevent the user-mode code from dumping the video content.

3. Now KMD is all thin. Its most important function is to manage the command buffer used by hardware and allocate memory.

The remote buffer used by UMD is allocated by KMD. Indirect ring buffer is also allocated by KMD. It is located in video memory and will be transmitted to the command processor unit of the GPU.

The ring buffer is a ring queue, its simple implementation can refer to: http://fgiesen.wordpress.com/2010/12/14/ring-buffers-and-queues/

The following is a simple driver that I drew based on my own understanding. It may not be correct, but it should mean that:

[Correct, Mike laolong-Wolf: the figure above is based on the OpenGL driver picture, and there is a dxgi layer for d3d11, which is responsible for interaction with KMD. The application sends the function to d3d11 runtime, which interacts with UMD. UMD generates GPU-executed commands, which are usually embodied in packet. Dxgi is usually used to process underlying hardware interfaces, such as adpater and switching chains used in d3d11, and pack them for application use. In addition, we can see that, applications can also directly access dxgi. For example, some non-d3d programs use GDI to draw images, that is, directly passing commands to dxgi. Windows 7 driver is Windows display driver model (wddm), which can be virtualized GPU resources and transparent to applications]