1. From XDDM to WDDM: An Inevitable Evolution
Before Windows Vista, display drivers used the XDDM (Windows 2000 Display Driver Model). Under the XDDM model, the driver ran almost entirely in kernel mode, and any minor crash would directly lead to a system "Blue Screen of Death" (BSoD).
The introduction of WDDM (Windows Display Driver Model) was not only to support the Aero desktop effects but also represented a major architectural refactoring:
- Stability: Most of the logic was moved to the User Mode Driver (UMD), leaving only the most critical hardware interaction logic in the Kernel Mode Driver (KMD).
- Performance: Introduced true GPU scheduling and video memory management.
- Multitasking: Supports multiple applications using GPU resources concurrently without interfering with each other.
2. WDDM Architecture Core: The Boundaries of Power Between UMD and KMD
A modern WDDM driver consists of two core components, each with its own responsibilities:
User Mode Driver (UMD)
- Nature: A DLL loaded by the Direct3D Runtime.
- Core Responsibilities:
- Translates API calls (such as D3D12 Draw Calls) into command streams (Command Buffers) that the hardware can understand.
- Performs high-level state management and shader compilation.
- Development Guidance: The UMD is the most logically complex and frequently changed part of the driver, but it does not directly touch hardware registers.
Kernel Mode Display Miniport Driver (KMD)
- Nature: A system service that communicates with
Dxgkrnl.sys. - Core Responsibilities:
- Resource Management: Manages video memory segments and page tables.
- Hardware Scheduling: Submits commands generated by the UMD to the hardware queue.
- Display Management: Controls display output (VidPN) and handles interrupts.
- Development Guidance: The KMD must be extremely stable, as it runs in Ring 0.
3. Engineering Design Philosophy: "The OS Owns the Policy, the Driver Owns the Implementation"
This is the most core philosophy in WDDM development.
- The OS (Dxgkrnl) owns the policy: The operating system decides when to switch tasks, when to lower the frequency for power saving, and when to swap resources to system memory due to insufficient video memory (Eviction).
- The Driver (KMD) owns the implementation: The driver tells the OS what capabilities (Caps) the hardware has and executes the specific instructions. For example, the OS tells the driver "please move this memory block to VRAM," and the driver is responsible for writing the specific registers to complete the transfer.
4. The WDDM 2.0 Watershed: The Shift in Video Memory Management Focus
In WDDM 1.x, video memory management used the "Patch Location List" model. Before the driver submitted a command, the OS had to scan the entire command buffer and fill in the physical addresses. This became a bottleneck in the context of large-scale parallelism and GPU virtualization.
WDDM 2.0 (Windows 10+) introduced GPU Virtual Addressing (GPUVA):
- Each process has an independent GPU address space: Just like CPU virtual memory, the UMD uses virtual addresses and no longer relies on dynamic patching by the OS.
- Residency Model: The driver no longer needs to list all dependent resources each time a command is submitted, but uses
MakeResidentto inform the OS which resources must be in video memory. This greatly reduces kernel transition overhead and is the foundation for the high performance of Direct3D 12.
5. Developer Advice: How to Start Your WDDM Journey
- Clarify the DDI version: In
DriverEntry, make sure to correctly declare yourDXGKDDI_INTERFACE_VERSION. For modern development, it is recommended to support at least WDDM 2.0. - Focus on Mandatory DDIs: Not all DDIs need to be implemented. For basic rendering,
DxgkDdiCreateAllocation,DxgkDdiSubmitCommand, andDxgkDdiBuildPagingBufferare your three core functions. - Understand Asynchronicity: The GPU is asynchronous. When you submit a command, it merely enters a queue. Never synchronously wait for the GPU to complete within the driver, otherwise, it will cause the entire system to stutter.
Top comments (0)