Benefits of the Windows Display Driver Model (WDDM)
Creating display drivers is easier using the Windows Display Driver Model (WDDM), available starting with Windows Vista, as opposed to using the Windows 2000 Display Driver Model (XDDM), because of the following enhancements. In addition, WDDM drivers contribute to greater operating system stability and security because less driver code runs in kernel mode where it can access system address space and possibly cause crashes.
The Microsoft Direct3D runtime and Microsoft DirectX graphics kernel subsystem perform more of the display processing (that is, more code is in the runtime and subsystem as opposed to the drivers). This includes code that manages video memory and schedules direct memory access (DMA) buffers for the GPU. For more information, see Video Memory Management and GPU Scheduling.
Surface creation requires fewer kernel-mode stages.
Surface creation on operating systems earlier than Windows Vista requires the following successive kernel-mode calls:
Surface creation in WDDM requires only the CreateResource user-mode display driver call, which in turn calls the pfnAllocateCb function. A call to the kernel-mode DxgkDdiCreateAllocation function then occurs.
Calls that create and destroy surfaces and that lock and unlock resources are more evenly paired.
Video memory, system memory, and managed surfaces are handled identically in WDDM. Operating systems prior to Windows Vista handled these components in subtly different ways.
Shader translation is performed in the user-mode portion of the display drivers.
This approach eliminates the following complexities that occur when shader translation is performed in kernel mode:
- Hardware models that do not match device driver interface (DDI) abstractions
- Complex compiler technology that is used in the translation
Because the shader processing occurs completely per process and hardware access is not required, kernel-mode shader processing is not required. Therefore, shader translation code can be processed in user mode.
You must write try/except code around user-mode translation code. Translation faults should cause a return to application processing.
Background translation (that is, translation code that runs in a separate thread from other display-processing threads) is easier to write for user mode.