Windows Display Driver Model (WDDM) Operation Flow
The following diagram shows the flow of Windows Display Driver Model (WDDM) operations that occur from when a rendering device is created to when the content is presented to the display. The sequence in the sections that follow describes the operation flow in more detail.
Creating a Rendering Device
After an application requests to create a rendering device, the display miniport driver receives a DxgkDdiCreateDevice call. The display miniport driver initializes direct memory access (DMA) by returning a pointer to a filled DXGK_DEVICEINFO structure in the pInfo member of the DXGKARG_CREATEDEVICE structure.
In the CreateDevice call, the user-mode display driver must explicitly call the pfnCreateContextCb function to create one or more contexts—GPU threads of execution on the newly created device. The Direct3D runtime returns information in the pCommandBuffer and CommandBufferSize members of the D3DDDICB_CREATECONTEXT structure to initialize the command buffer.
Creating Surfaces for a Device
After an application requests to create surfaces for the rendering device, the Direct3D runtime calls the user-mode display driver's CreateResource function.
The display miniport driver receives a DxgkDdiCreateAllocation call, which indicates the number and types of allocations to create. DxgkDdiCreateAllocation returns information about the allocations in an array of DXGK_ALLOCATIONINFO structures in the pAllocationInfo member of the DXGKARG_CREATEALLOCATION structure.
Submitting the Command Buffer to Kernel Mode
After an application requests to draw to a surface, the Direct3D runtime calls the user-mode display driver function related to the drawing operation, for example, DrawPrimitive2.
To submit the command buffer to kernel-mode, the Direct3D runtime calls either the user-mode display driver's Present or Flush function. Also, the user-mode display driver submits the command buffer if the command buffer is full.
The display miniport driver receives a call to the DxgkDdiPresent function if pfnPresentCb was called, or the DxgkDdiRender or DxgkDdiRenderKm function if pfnRenderCb was called. The display miniport driver validates the command buffer, writes to the DMA buffer in the hardware's format, and produces an allocation list that describes the surfaces used.
Submitting the DMA Buffer to Hardware
The Microsoft DirectX graphics kernel subsystem calls the display miniport driver's DxgkDdiBuildPagingBuffer function to create special purpose DMA buffers, known as paging buffers, that move the allocations specified in the allocation list to and from GPU-accessible memory.
NoteDxgkDdiBuildPagingBuffer is not called for every frame.
The DirectX graphics kernel subsystem calls the display miniport driver's DxgkDdiSubmitCommand function to queue the paging buffers to the GPU execution unit.
The DirectX graphics kernel subsystem calls the display miniport driver's DxgkDdiPatch function to assign physical addresses to the resources in the DMA buffer.
The DirectX graphics kernel subsystem calls the display miniport driver's DxgkDdiSubmitCommand function to queue the DMA buffer to the GPU execution unit. Each DMA buffer submitted to the GPU contains a fence identifier, which is a number. After the GPU finishes processing the DMA buffer, the GPU generates an interrupt.
The display miniport driver is notified of the interrupt in its DxgkDdiInterruptRoutine function. The display miniport driver should read, from the GPU, the fence identifier of the DMA buffer that just completed.
The display miniport driver should call the DxgkCbNotifyInterrupt function to notify the DirectX graphics kernel subsystem that the DMA buffer completed. The display miniport driver should also call the DxgkCbQueueDpc function to queue a deferred procedure call (DPC).