Recent from talks
Nothing was collected or created yet.
Windows Display Driver Model
View on WikipediaWindows Display Driver Model (WDDM,[1] initially LDDM as Longhorn Display Driver Model and then WVDDM in times of Windows Vista) is the graphic driver architecture for video card drivers running Microsoft Windows versions beginning with Windows Vista.[2]
It is a replacement for the previous Windows 2000 and Windows XP display driver model XDDM/XPDM[3] and is aimed at enabling better performance graphics and new graphics functionality and stability.[2] Display drivers in Windows Vista and Windows 7 can choose to either adhere to WDDM or to XDDM.[4] With the removal of XDDM from Windows 8, however, WDDM became the only option.[5] In Windows 9x, the VxDDM (VxD display driver model), the WDMDM (WDM display driver model), and the VxD plus WDM hybrid DDM can be used; In Windows 2000 and Windows XP, the XDDM/XPDM is based on WDM.
WDDM provides the functionality required to render the desktop and applications using Desktop Window Manager, a compositing window manager running on top of Direct3D. It also supports new DXGI interfaces required for basic device management and creation. The WDDM specification requires at least Direct3D 9-capable video card and the display driver must implement the device driver interfaces for the Direct3D 9Ex runtime in order to run legacy Direct3D applications; it may optionally implement runtime interfaces for Direct3D 10 and higher.
Features enabled by the WDDM
[edit]WDDM drivers enable areas of functionality which were not uniformly provided by earlier display driver models. These include:
Virtualized video memory
[edit]In the context of graphics, virtualization means that individual processes (in user mode) cannot see the memory of adjacent processes even by means of insertion of forged commands in the command stream. WDDM drivers allow video memory to be virtualized,[6] and video data to be paged out of video memory into system RAM or into page file. In case the video memory available turns out to be insufficient to store all the video data and textures, currently unused data is moved out to system RAM or to the disk. When the swapped out data is needed, it is fetched back. Virtualization could be supported on previous driver models (such as the XP Driver Model) to some extent, but was the responsibility of the driver, instead of being handled at the runtime level.
Scheduling
[edit]The runtime handles scheduling of concurrent graphics contexts.[7] Each list of commands is put in a queue for execution by the GPU, and it can be preempted by the runtime if a more critical task arrives and if it has not begun execution. This differs from native threads on the CPU where one task cannot be interrupted and therefore can take longer than necessary and make the computer appear less responsive. A hybrid scheduling algorithm between native and light threads with cooperation between the threads would achieve seamless parallelism. It is important to note that scheduling is not a new concept but it was previously the responsibility of individual driver developers. WDDM attempts to unify the experience across different vendors by controlling the execution of GPU tasks.
Cross-process sharing of Direct3D surfaces
[edit]A Direct3D graphics surface is the memory area that contains information about the textured meshes used for rendering a 2D or 3D scene. WDDM allows Direct3D surfaces to be shared across processes.[8] Thus, an application can incorporate a mesh created by another application into the scene it is rendering. Sharing textures between processes before WDDM was difficult, as it would have required copying the data from video memory to system memory and then back to video memory for the new device.
Enhanced fault-tolerance
[edit]

If a WDDM driver hangs or encounters a fault, the graphics stack will restart the driver.[2][9] A graphics hardware fault will be intercepted and if necessary the driver will be reset.
Drivers under Windows XP were free to deal with hardware faults as they saw fit either by reporting it to the user or by attempting to recover silently. In some cases when the display driver can be safely stopped, Windows XP may instead alert about the display driver crash, while also disabling the video driver, thus switching down the screen resolution to 640x480 with only 16 colors. With a WDDM driver, the screen resolution will most likely be unaffected; all hardware faults cause the driver to be reset and the user will be notified by a popup; this unifies the behavior across vendors.
Previous drivers were fully implemented in kernel mode, whereas WDDM is implemented partly in user mode. If the user mode area fails with an unrecoverable error, it will, at the most, cause the application to quit unexpectedly instead of producing a blue screen error as it would in previous driver models.
WDDM also allows the graphics hardware to be reset and users to update drivers without requiring a reboot.[2]
Limitations
[edit]The new driver model requires the graphics hardware to have Shader Model 2.0 support at least, since the fixed function pipeline is now translated to 2.0 shaders. However, according to Microsoft as of 2009, only about 1–2 percent of the hardware running Windows Vista used the XDDM,[10] with the rest already WDDM capable. It also requires some other hardware features; consequently some SM 2.0-supporting hardware such as the Intel GMA 900 fails the WDDM certification.[11]
One of the limitations of WDDM driver model version 1.0 is that it does not support multiple drivers in a multi-adapter, multi-monitor setup. If a multi-monitor system has more than one graphics adapter powering the monitors, both the adaptors must use the same WDDM driver. If more than one driver is used, Windows will disable one of them.[12] This is a limitation from when Windows Vista was codenamed Windows "Longhorn".[13] WDDM 1.1 does not have this limitation.[14]
WDDM 1.0/1.1 does not allow some modes that were previously handled by the driver such as spanning mode (stretching the desktop across two monitors)[15][16] although Dual View is still available.[12][17]
Need for a new display driver model
[edit]One of the chief scenarios that the Windows Display Driver Model enables is the Desktop Window Manager. Since the desktop and application windows managed by DWM are Direct3D applications, the number of open windows directly affects the amount of video memory required. Because there is no limit on the number of open windows, the video memory available may prove insufficient, necessitating virtualization. As the window contents that DWM composes into the final desktop are generated by different processes, cross-process surface sharing is necessary. Also, because there can be other DirectX applications running alongside DWM on the DWM-managed desktop, they must be able to access the GPU in a shared manner, necessitating scheduling.
Though this is true for Microsoft's implementation of a composited desktop under Windows Vista, on the other hand, a composited desktop need not theoretically require a new display driver model to work as expected. Successful implementations of composited desktops were done before Windows Vista on other platforms such as Quartz, Compiz, WindowFX. The approach that Microsoft attempted was to try to make sure WDDM was a unified experience across different GPUs from multiple vendors by standardizing their features and performance. The software features missing from other driver models could be made immaterial by extensions or if a less restrictive or simply different driver model were in place.
History
[edit]WDDM 1.0
[edit]Windows Vista introduced WDDM 1.0 as a new display driver architecture designed to be better performing, more reliable, and support new technologies including HDCP. Hybrid Sleep, which combines hibernation and sleep mode functionality for enhanced stability in the event of power failure, also requires WDDM.[2][why?]
WDDM 1.1
[edit]Windows 7 supports major additions to WDDM known as WDDM 1.1; the details of this new version were unveiled at WinHEC 2008. New features include:[10]
- DXGI 1.1, which features return of hardware 2D acceleration for use by GDI[18] (but not GDI+) and Direct2D/DirectWrite
- BitBlt, StretchBlt, TransparentBlt
- AlphaBlend, ColorFill
- ClearType font support
- GPU switching without logoff or reboot
- Direct3D 11 device driver interface (DDI)
- OpenGL installable client driver (ICD)
- DXVA-HD DDI[19]
- Hardware video overlay DDI[20]
- Optional AES 128 encryption
- Optional decoding of encrypted video content
- Support multiple drivers in a multi-adapter and multi-monitor setup[10][21]
Hardware acceleration of GDI and Direct2D/DirectWrite operations helps reduce memory footprint in Windows 7, because DWM compositing engine no longer needs to keep a system memory copy of all surfaces used by GDI/GDI+, as in Windows Vista.[22][23][24]
DXGI 1.1, Direct3D 11, Direct2D, and DirectWrite were made available with Windows Vista Platform Update; however GDI/GDI+ in Vista continues to rely on software rendering[25] and the Desktop Window Manager continues to use Direct3D 9Ex.[26]
WDDM 1.1 drivers are backward compatible with WDDM 1.0 specification; both 1.0 and 1.1 drivers can be used in Windows Vista with or without the Platform Update.[10]
WDDM 1.2
[edit]Windows 8 includes WDDM 1.2[27][28] and DXGI 1.2.[28][29] New features were first previewed at the Build 2011 conference and include performance improvements as well as support for stereoscopic 3D rendering and video playback.
Other major features include preemptive multitasking of the GPU with finer granularity (DMA buffer, primitive, triangle, pixel, or instruction-level),[30] reduced memory footprint, improved resource sharing, and faster timeout detection and recovery. 16-bit color surface formats (565, 5551, 4444) are mandatory in Windows 8, and Direct3D 11 Video supports YUV 4:4:4/4:2:2/4:2:0/4:1:1 video formats with 8, 10, and 16-bit precision, as well as 4 and 8-bit palettized formats.[31]
WDDM 1.2 supports display-only and render-only WDDM drivers, such as Microsoft Basic Display Driver[32] and WARP-based Microsoft Basic Render Driver which replaced kernel-mode VGA driver.
WDDM 1.0/1.1 only allows rudimentary task scheduling using "batch queue" granularity; improvements to multitasking, as well as fast context switching and support for virtual memory, were initially expected in versions tentatively named WDDM 2.0 and WDDM 2.1, which were announced at WinHEC 2006.[33][34][35]
WDDM 1.3
[edit]Windows 8.1 includes WDDM 1.3[36] and DXGI 1.3.[37] New additions include the ability to trim DXGI adapter memory usage, multi-plane overlays, overlapping swap chains and swap chain scaling, select backbuffer subregion for swap chain and lower-latency swap chain presentation. Driver feature additions include wireless displays (Miracast), YUV format ranges, cross-adapter resources and GPU engine enumeration capabilities. Graphics kernel performance improvements.[1]
WDDM 2.0
[edit]Windows 10 includes WDDM 2.0, which is designed to dramatically reduce workload on the kernel-mode driver for GPUs that support virtual memory addressing,[38] to allow multithreading parallelism in the user-mode driver and result in lower CPU utilization.[39][40][41][42] Windows 10 also includes DXGI 1.4.[43]
Direct3D 12 API, announced at Build 2014, requires WDDM 2.0. The new API will do away with automatic resource-management and pipeline-management tasks and allow developers to take full low-level control of adapter memory and rendering states.
The display driver model from Windows 8.1 and Windows Phone have converged into a unified model for Windows 10.[44]
A new memory model is implemented that gives each GPU a per-process virtual address space, this enabled GPU virtual memory and GPU memory paging in WDDM 2.0.[45] Direct addressing of video memory is still supported by WDDMv2 for graphics hardware that requires it, but that is considered a legacy case. IHVs are expected to develop new hardware that supports virtual addressing. Significant changes have been made to the DDI to enable this new memory model.
WDDM 2.1
[edit]Windows 10 Anniversary Update (version 1607) includes WDDM 2.1, which supports Shader Model 6.0 (mandatory for feature levels 12_0 and 12_1),[46] and DXGI 1.5 which supports HDR10 - a 10-bit high dynamic range, wide gamut format[47] defined by ITU-T Rec. 2100/Rec.2020 - and variable refresh rates.[48]
WDDM 2.2
[edit]Windows 10 Creators Update (version 1703) includes WDDM 2.2, which is tailored for virtual, augmented and mixed reality with stereoscopic rendering for the Windows Mixed Reality platform, and DXGI 1.6.[49]
WDDM 2.3
[edit]Windows 10 Fall Creators Update (version 1709) includes WDDM 2.3. The following is a list of new features for Windows Display driver development in Windows 10, version 1709:[50]
- Shader Model 6.1, adding support view instancing and barycentric semantics.[51]
- Display ColorSpace Transform DDIs provide additional control over color space transforms applied in the post-composition display pipeline.
- The D3D12 Copy Queue Timestamp Queries feature will allow applications to issue timestamp queries on COPY command lists/queues. These timestamps are specified to function identically to timestamps on other engines.
- Enhanced Video integration into Direct3D12 Runtime through: hardware accelerated video decoding, content protection and video processing
WDDM 2.4
[edit]Windows 10 April 2018 Update (version 1803) includes WDDM 2.4. Updates to display driver development in Windows 10 version 1803 include the following features[52].:
- Shader Model 6.2, adding support for 16-bit scalars and the ability to select the behaviours with denormal values.[53]
- Indirect Display UMDF class extension, the driver can pass the SRM to the rendering GPU and have a mechanism to query the SRM version being used.
- IOMMU hardware-based GPU isolation support, increasing security by restricting GPU access to system memory.
- GPU paravirtualization support, enabling display drivers to provide rendering capabilities to Hyper-V virtualized environments.
- Brightness, a new interface to support multiple displays that can be set to calibrated nit-based brightness levels.
- D3D11 bitstream encryption, exposing CENC, CENS, CBC1, and CBCS with 8 or 16 byte initialization vectors.
- D3D11 and D3D12 video decode histogram, allowing to leverage fixed function hardware for histogram to improve tone mapping quality for HDR/EDR scenarios.
- D3D12 video decode now supports Decode Tier II, enabling applications to amortize allocation cost and reduce peak memory usage during resolution change.
- Tiled resource tier and LDA atomics, a new cross node sharing tier to add support for atomic shader instructions working across linked adapter (LDA) nodes, allowing to implement multiple GPU rendering techniques like split frame rendering (SFR).
- GPU dithering support, allowing the operating system to explicitly request dithering in scenarios where a higher effective bit depth is needed than is physically available on the monitor link, for example for HDR10 over HDMI 2.0.
- Post-processing color enhancement override, allowing the operating system to request that the driver temporarily disable any post-processing that enhances or alters display colors, for specific application scenarios to enforce colorimetrically accurate color behavior on the display, and safely coexist with OEM or IHV-proprietary display color enhancements.
- Direct3D12 and Video, new API and DDI to provide access to hardware accelerated video decoding, content protection and video processing.
- DisplayID, a new DDI, designed to allow the VESA's DisplayID descriptor to be queried from a display controlled by a graphics adapter.
- GPU performance data, an extension to expose information about the GPU hardware such as temperature, fan speed, clock speeds for engines and memory, memory bandwidth, power draw, and voltages.
- SupportContextlessPresent, a driver cap to help IHVs onboard new driver.
- Improvements to External/Removable GPU support in the OS, providing better support to detachable GPUs.
- Display Diagnostics, with Kernel mode device driver interface changes to allow the driver for a display controller to report diagnostic events to the operating system.
- Shared graphics power components, allowing non-graphics drivers to participate in the power management of a graphics device.
- Shared texture improvements, increasing the types of textures that can be shared across processes and Direct3D devices, adding support to monochrome with minimal memory copying.
WDDM 2.5
[edit]Windows 10 October 2018 Update (Version 1809) Includes WDDM 2.5.[54] Updates to Display driver development in Windows 10, version 1809 include the following features:[55]
- Shader Model 6.3, adding support for DirectX12 Raytracing (DXR).[56]
- Raytracing, in order to support hardware-accelerated raytracing in Direct3D 12.
- Universal Driver Requirements, drivers will need to ensure their DirectX 11 and DirectX12 user-mode drivers and kernel mode drivers, as well other DLL loaded by these components, adhere to the Universal API.
- SRV-Only Tiled Resource Tier 3, a new capability bit for tiled resources, exposing sparse volume textures without requiring unordered-access and render-target operations support.
- Render Pass, introducing render pass concept in Direct3D 12, adding new APIs to be run on existing drivers and allow user mode drivers to choose optimal rendering path without heavy CPU penalty.
- Meta-commands, adding preview support for DirectML, a high-performance, hardware-accelerated DirectX 12 library for machine learning. With Windows 10 version 1903 and newer meta-commands and DirectML are a stable part of Windows.[57]
- HDR Brightness Compensation, a new SDR brightness boost, raising the reference white of SDR content to the user-desired value, allowing SDR content to be reproduced to a typical 200-240 nits. It also allows reporting if the hardware/driver supports HDR output through FP16 pixel format or only ARGB10 pixel format.
- SDR White Level, to let the graphics drivers know the SDR white level value that is being applied by the OS compositor for all the SDR content, for a display which is running in HDR mode.
- Display Synchronization, allowing the operating system to check for display synchronization capabilities if the display is exposed by the driver and prior to enabling the display.
- Tracked Workloads was also added as an experimental feature to better control the trade-off between quicker processor execution and lower power consumption, but was removed from Windows 10 version 2004 and deprecated from earlier OS versions as part of a security fix.
WDDM 2.6
[edit]Windows 10 May 2019 Update (Version 1903) includes WDDM 2.6. Updates to display driver development in Windows 10 version 1903 include the following features:[58]
- Shader Model 6.4, adding support low-precision packed dot product intrinsics and for library sub-objects to simplify ray-tracing.[59]
- Super Wet Ink, allowing the creation of textures in formats and modes the IHVs doesn't natively support, resolving them as a resource projection to a format the hardware/drivers natively support, allowing internal drivers optimizations.
- Variable Rate Shading, also known as coarse pixel shading, a mechanism to enable allocation of rendering performance/power at varying rates across rendered images. It comes with two tiers (tier 1 and tier 2).
- Collect Diagnostic Info, allowing the operating system to collect a private data from drivers for both rendering and display functions. This new feature is a requirement in WDDM 2.6.
- Background Processing, allowing user mode drivers to express desired threading behavior, and the runtime to control/monitor it. APIs allow apps to adjust what amount of background processing is appropriate for their workloads and when to perform that work.
- Driver Hot Update, reducing server downtime and allowing driver security hot patch to the kernel mode driver.
- Microsoft Compute Driver Model (MCDM), for AI processors such as NPU.
WDDM 2.7
[edit]Windows 10 May 2020 Update[60] (Version 2004) includes WDDM 2.7. Updates to display driver development in Windows 10 version 2004 include the following features:[61]
- Shader Model 6.5, adding support to the new pipeline capabilities as well additional Wave intrinsics.[62]
- Hardware-accelerated GPU scheduling: masked as an additional option in the system settings, when enabled offloads high-frequency tasks to a dedicated GPU-based scheduling processor, reducing CPU scheduling overhead. Requires ad-hoc hardware and driver support.[63]
- Sampler Feedback, allowing a finer tune of the resources usage in a scene.[64] It comes with two tiers (tier 0.9 and tier 1.0).[65]
- DirectX Raytracing (DXR) Tier 1.1, introducing inline ray-tracing, indirect rays dispatching, increasing the state object without the need to create a new one, and additional vertex formats for acceleration structures.[66]
- Mesh and Amplification Shaders Stages, a new optional geometry pipeline replacing the traditional pipeline (Input Assembler-Vertex-Hull-Tesselator-Domain-Geometry and Stream Output stages).[67]
- Improved memory allocation control, with better residency control and the possibility to not explicitly zeroing newly created heaps.[68]
- Direct3D 9 resource interop, allowing projecting a Direct3D 9 resource on a Direct3D 12 application.[69]
- Direct3D 12 Video Protected Resource support, allowing play protected content in a Direct3D 12 application.[70]
WDDM 2.8
[edit]Windows 10 Insider Preview Manganese included WDDM 2.8, but no driver was ever publicly demonstrated to support it and it has been skipped for "Iron" and "Cobalt" development releases.
WDDM 2.9
[edit]WDDM 2.9 in Windows 10 Insider Preview "Iron" will bring support for GPU hardware acceleration to the Windows Subsystem for Linux 2 (WSL 2)[71] and support for feature level 12_2[72] and HLSL Shader Model 6.6.[73]
WDDM 3.0
[edit]Windows 11 RTM Final Retail release includes WDDM 3.0,[74][75] which improves graphics architecture in Windows Subsystem for Linux[76] adding:[77]
- User mode driver compiled for Linux in the WSL package.
- Host driver mounted in Linux
- Dynamic refresh rate[78]
- Direct3D 12 video encoding[79]
- Hardware flip queue[80]
WDDM 3.1
[edit]Windows 11 2022 Update (version 22H2) includes WDDM 3.1.[81][82]
WDDM 3.2
[edit]Windows 11 2024 Update (version 24H2) includes WDDM 3.2.[86]
- Shader Model 6.8[87]
- Dirty bit tracking
- Live migration on GPU-P devices
- Native GPU fence objects
- User-mode work submission
- D3D12 AV1 video encoding
- Work graphs[88]
References
[edit]- ^ "Windows Display Driver Model (WDDM) Design Guide". MSDN. Microsoft. Retrieved 19 February 2015.
- ^ a b c d e "Windows Vista Display Driver Model". MSDN. Microsoft. July 2006. Archived from the original on 2010-05-06. Retrieved 9 December 2013.
- ^ "XPDM vs. WDDM". MSDN. Microsoft. 16 November 2013. Retrieved 16 December 2013.
- ^ "Windows 2000 Display Driver Model (XDDM) Design Guide". Windows Dev Center - Hardware. Microsoft. 16 November 2013. Retrieved 9 December 2013.
- ^ "Roadmap for Developing Drivers for the Windows 2000 Display Driver Model (XDDM)". Windows Dev Center - Hardware. Microsoft. 16 November 2013. Retrieved 16 December 2013.
XDDM and VGA drivers will not compile on Windows 8 and later versions
- ^ "Graphics Memory Reporting through WDDM". MSDN. Microsoft. 9 January 2007. Retrieved 9 December 2013.
- ^ Schechter, Greg (2 April 2006). "The role of the Windows Display Driver Model in the DWM". Greg Schechter's Blog. Microsoft. Archived from the original on 20 April 2010. Retrieved 9 December 2013.
- ^ "Cross Process Resource Sharing". MSDN. Microsoft. 10 December 2009. Retrieved 9 December 2013.
- ^ "Timeout Detection and Recovery of GPUs through WDDM". Timeout Detection and Recovery: Microsoft. Archived from the original on 6 September 2011. Retrieved 4 September 2011.
- ^ a b c d "Graphics Guide for Windows 7". Microsoft. 12 June 2009.
- ^ Intel excuse for no GMA900 WDDM driver: no "HW Scheduler" no driver, Beyond3D, October 26, 2006.
- ^ a b "MultiMonitor Support and Windows Vista". Retrieved 20 October 2007.
- ^ Pournelle, Jerry (2004). "WinHEC: The Future of Windows". BYTE. UBM Technology Group. Archived from the original on October 15, 2024. Retrieved December 31, 2025.
Another big change: LDDM will only allow a single display driver at a time. You can still have multiple display adapters, but they'll have to share a single driver—effectively meaning they'll have to be from the same manufacturer. That seems a reasonable restriction.
- ^ Blythe, David. "Working With the Windows 7 Graphics Architecture". WinHEC 2008. Microsoft. Archived from the original on October 20, 2013. Retrieved 9 December 2013.
- ^ Are there Control Panel features that were available under Windows XP that are no longer available on Windows Vista?
- ^ Stretched Desktop or Spanning Mode Not Available in Catalyst Control Center Under Windows Vista Archived November 17, 2009, at the Wayback Machine
- ^ "Description of DualView in Windows XP (Revision 1.5)". Support. Microsoft. 15 January 2006. Retrieved 9 December 2013.
- ^ "GDI Hardware Acceleration". MSDN. Microsoft. Retrieved 14 June 2009.
- ^ "DXVA-HD DDI". MSDN. Microsoft. Retrieved 13 June 2009.
- ^ "Overlay DDI". MSDN. Microsoft. Retrieved 13 June 2009.
- ^ "Multiple Monitors and Video Present Networks". MSDN. Microsoft. Retrieved 14 July 2010.
- ^ Schechter, Greg (3 May 2006). "Redirecting GDI, DirectX, and WPF applications". Greg Schechter's Blog. Microsoft. Archived from the original on 5 March 2010. Retrieved 9 December 2013.
- ^ Chitre, Ameet (25 August 2009). Sinofsky, Steven (ed.). "Engineering Windows 7 Graphics Performance". Engineering Windows 7. Microsoft. Retrieved 9 December 2013.
- ^ Mulcahy, Tom (11 February 2009). "Windows And Video Memory". Zemblanity. Microsoft. Retrieved 9 December 2013.
- ^ Olsen, Thomas (29 October 2008). "Introducing the Microsoft Direct2D API". Tom's Blog. Microsoft. Retrieved 9 December 2013.
- ^ Mark Lawrence (25 November 2009). "Internet Explorer announces to use DirectWrite & Direct2D (comment from Microsoft official)". Archived from the original on 2014-04-08.
- ^ "Windows Developer Preview - New for Display devices". MSDN. Microsoft. 16 November 2013. Retrieved 9 December 2013.
- ^ a b "Windows Display Driver Model Enhancements in Windows Developer Preview". MSDN. Microsoft. 28 September 2012. Retrieved 9 December 2013.
- ^ "DXGI 1.2 Improvements". MSDN. Microsoft. 16 November 2013. Retrieved 9 December 2013.
- ^ "DXGI_Graphics_Preemption_Granularity Enumeration". MSDN. Microsoft. 16 November 2013. Retrieved 9 December 2013.
- ^ "DXGI_FORMAT enumeration". MSDN. Microsoft. 16 November 2013. Retrieved 9 December 2013.
- ^ "Microsoft Basic Display Driver - Windows drivers". 27 June 2024.
- ^ Al-Kady, Nabeel. "Display Driver Logistics And Testing". WinHEC 2006. Microsoft. Retrieved 9 December 2013.
- ^ Pronovost, Steve. "Windows Display Driver Model (WDDM) v2 And Beyond". WinHEC 2006. Microsoft. Retrieved 9 December 2013.
- ^ Dan Warne (June 1, 2006). "Windows graphics system to be overhauled". APC Magazine. Retrieved 20 February 2015.
- ^ "What's new for Windows 8.1 Preview display drivers (WDDM 1.3)". MSDN. Microsoft. 16 November 2013. Retrieved 9 December 2013.
- ^ "DXGI 1.3 Improvements". MSDN. Microsoft. 16 November 2013. Retrieved 9 December 2013.
- ^ "What's new for Windows 10 Insider Preview display drivers (WDDM 2.0)". Microsoft. Retrieved 3 June 2015.
- ^ McMullen, Max (2 April 2014). Direct3D 12 API Preview. MSDN. Retrieved 3 June 2015.
- ^ Moreton, Henry (2014-03-20). "DirectX 12: A Major Stride for Gaming | NVIDIA Blog". Blogs.nvidia.com. Retrieved 2014-03-26.
- ^ "DirectX 12 - DirectX Developer Blog - Site Home - MSDN Blogs". Blogs.msdn.com. 2014-03-20. Retrieved 2014-03-26.
- ^ Smith, Ryan (6 February 2015). "The DirectX 12 Performance Preview: AMD, NVIDIA, & Star Swarm". AnandTech. Purch. Archived from the original on February 7, 2015.
- ^ MSDN - DXGI 1.4 Improvements
- ^ tedhudek. "What's new in driver development". docs.microsoft.com. Retrieved 2018-10-08.
- ^ lorihollasch. "GPU Virtual Memory in WDDM 2.0 - Windows drivers". learn.microsoft.com. Retrieved 2025-06-15.
- ^ "HLSL Shader Model 6.0 - Win32 apps". 25 August 2021.
- ^ "High Dynamic Range and Wide Color Gamut (Windows)". msdn.microsoft.com. Archived from the original on 2016-09-13.
- ^ "Variable refresh rate displays - Win32 apps". 6 January 2021.
- ^ "Channel9 has joined Microsoft Learn".
- ^ "Driver development additions for Windows 10, version 1709 - Display". docs.microsoft.com. Retrieved 2020-04-14.
- ^ "Shader Model 6.1". github.com/microsoft/DirectXShaderCompiler. Retrieved 2017-12-01.
- ^ "What's new in Windows 10, version 1803 - Display". docs.microsoft.com. Archived from the original on 2020-07-20. Retrieved 2020-04-28.
- ^ "Shader Model 6.2". github.com/microsoft/DirectXShaderCompiler. Retrieved 2017-12-01.
- ^ "Features added in prior WDDM 2.X versions - WDDM 2.5". Microsoft Docs. Retrieved 2020-03-28.
- ^ "Windows Drivers - What's new in Windows 10, version 1809 - Display". Microsoft Docs. Archived from the original on 2020-07-20. Retrieved 2020-04-28.
- ^ "Shader Model 6.3". github.com/microsoft/DirectXShaderCompiler. Retrieved 2019-03-11.
- ^ "Getting Started with DirectML". github.com/microsoft/DirectML. 26 November 2021.
- ^ "Features added in prior WDDM 2.X versions - WDDM 2.6". docs.microsoft.com. Retrieved 2020-03-24.
- ^ "Shader Model 6.4". github.com/microsoft/DirectXShaderCompiler. Retrieved 2019-04-11.
- ^ "Dev Preview of New DirectX 12 Features". devblogs.microsoft.com. 28 October 2019. Retrieved 2019-10-28.
- ^ "What's new for Windows 10 display and graphics drivers". docs.microsoft.com. Retrieved 2020-05-12.
- ^ "HLSL Shader Model 6.5". microsoft.github.io. Retrieved 2019-10-15.
- ^ "Hardware Accelerated GPU Scheduling". devblogs.microsoft.com. 30 June 2020. Retrieved 2020-06-30.
- ^ "Coming to DirectX 12— Sampler Feedback: some useful once-hidden data, unlocked". devblogs.microsoft.com. 4 November 2019. Retrieved 2019-11-04.
- ^ "DirectX-Specs - Sampler Feedback - Feature Support". microsoft.github.io. Retrieved 2019-11-04.
- ^ "DirectX Raytracing (DXR) Tier 1.1". devblogs.microsoft.com. 6 November 2019. Retrieved 2019-11-06.
- ^ "Coming to DirectX 12— Mesh Shaders and Amplification Shaders: Reinventing the Geometry Pipeline". devblogs.microsoft.com. 8 November 2019. Retrieved 2019-11-08.
- ^ "Coming to DirectX 12: More control over memory allocation". devblogs.microsoft.com. 11 November 2019. Retrieved 2019-11-11.
- ^ "Coming to DirectX 12: D3D9On12 and D3D11On12 Resource Interop APIs". devblogs.microsoft.com. 13 November 2019. Retrieved 2019-11-13.
- ^ "D3D12 Video Protected Resource Support". microsoft.github.io. Retrieved 2019-05-29.
- ^ "DirectX ❤ Linux". devblogs.microsoft.com. 19 May 2020. Retrieved 2020-05-19.
- ^ "New in DirectX— Feature Level 12_2". 27 August 2020.
- ^ "Announcing HLSL Shader Model 6.6". 20 April 2021.
- ^ "How to get Windows 11". 4 October 2021.
- ^ "Download Windows 11". Microsoft.
- ^ "WSL Graphics Architecture". xdc2020.x.org. Archived from the original on 2021-10-08. Retrieved 2020-09-16.
- ^ "What's new for Windows 11 display and graphics drivers - Windows drivers". 22 August 2024.
- ^ "Dynamic refresh rate – Get the best of both worlds". 28 June 2021.
- ^ "D3D12 video encoding - Windows drivers". 5 March 2022.
- ^ "Hardware flip queue - Windows drivers". 26 June 2024.
- ^ "Available today: The Windows 11 2022 Update". 20 September 2022.
- ^ "Download Windows 11". Microsoft.
- ^ "HLSL Shader Model 6.7".
- ^ lorihollasch. "IOMMU DMA remapping - Windows drivers". docs.microsoft.com. Retrieved 2022-07-24.
- ^ "Sharing the backing store with KMD - Windows drivers". 22 August 2024.
- ^ "What's New in Driver Development for Windows 11, Version 24H2 - Windows drivers". 18 September 2024.
- ^ "DirectX-Specs".
- ^ "Work Graphs - Windows drivers". 22 May 2024.
Windows Display Driver Model
View on GrokipediaBackground
Overview
The Windows Display Driver Model (WDDM) is the graphics display driver architecture for Windows operating systems, serving as the successor to earlier models like the XDDM used in Windows XP.[1] Introduced with Windows Vista in 2006 as WDDM 1.0, it was designed to support advanced graphical user interfaces, such as the Aero interface, which relies on hardware-accelerated composition for visual effects like transparency and animations.[1] WDDM assumes basic familiarity with graphics drivers and enables key features including desktop window composition via the Desktop Window Manager (DWM) and seamless multi-monitor configurations.[1] The primary goals of WDDM include enhancing system stability through mechanisms that prevent full crashes from GPU faults, facilitating efficient sharing of GPU resources across multiple applications via preemptive scheduling, and providing tight integration with DirectX for leveraging full hardware capabilities in rendering and compute tasks.[1] By separating user-mode and kernel-mode operations, it reduces the risk of driver failures impacting the entire system, while enabling better resource management for concurrent graphics workloads.[1] WDDM's timeline began with version 1.0 in Windows Vista, became mandatory starting with Windows 8 (requiring at least WDDM 1.2), and has evolved through subsequent releases, with WDDM 2.0 introduced in Windows 10 and WDDM 3.0 in Windows 11 to accommodate modern demands like high-performance gaming and AI-accelerated workloads.[1][9][9] Recent advancements, such as those in WDDM 3.2 for Windows 11 version 24H2, further optimize GPU and NPU usage for cloud-based AI scenarios.[10]Predecessors and Motivations
The Windows 9x and Me operating systems relied on the Virtual Device Driver (VxD) model for display drivers, which operated as immediate-mode drivers directly intercepting hardware I/O operations without structured queuing or mediation. These drivers ran in a hybrid real-mode and protected-mode environment, simulating hardware access for multitasking DOS applications while lacking robust memory protection mechanisms that segregated user-mode and kernel-mode resources. As a result, faulty drivers or applications could corrupt system memory, leading to widespread instability and frequent crashes across the entire OS.[11] Succeeding this, the Windows 2000 and XP eras introduced the extended Windows Driver Model (XDDM) for display drivers, building on the broader WDM framework with kernel-mode miniport drivers handling hardware interactions and user-mode components managing graphics rendering. While this separated some responsibilities to reduce direct kernel exposure, XDDM retained cooperative scheduling where applications shared GPU access without preemption, allowing a single hung application to monopolize resources and trigger system-wide failures or blue screens. Memory protection remained limited, as kernel-mode code could still access broad address spaces, exacerbating crash risks from driver bugs.[12][13] The development of the Windows Display Driver Model (WDDM) was driven by the need to address these shortcomings, particularly enabling preemptive multitasking on the GPU to prevent resource monopolization by individual applications. Key motivations included enhancing fault isolation by minimizing kernel-mode code execution—thus reducing the potential for system crashes from driver faults—and supporting advanced composited desktop environments like Aero in Windows Vista, which required a WDDM-compliant driver for efficient window composition via the Desktop Window Manager. Additionally, WDDM aimed to improve power management for mobile devices, providing standardized infrastructure for GPU idle states and active power control to extend battery life on laptops. Transitioning to WDDM necessitated hardware vendors to rewrite drivers from XDDM architectures, a process that simplified development long-term but initially demanded significant effort to achieve compatibility with Vista and later systems.[13][14][15][16]Architecture
Core Components
The Windows Display Driver Model (WDDM) is built upon a set of core components that separate responsibilities between user-mode and kernel-mode operations to enhance system stability and performance. These components include the kernel-mode display miniport driver, the user-mode driver, the DirectX Graphics Kernel (DXGK) interface, and supporting subsystems such as the Desktop Window Manager (DWM) and Timeout Detection and Recovery (TDR) mechanism. This architecture ensures that graphics processing is managed efficiently while isolating potential failures. The kernel-mode display miniport driver (KMD), implemented by graphics hardware vendors, serves as the primary interface to the graphics hardware in the kernel space. It communicates with the DirectX Graphics Kernel subsystem (dxgkrnl.sys) through the DXGK interface to handle low-level hardware I/O operations, such as submitting commands to the GPU and managing video memory allocation. This driver is responsible for tasks that require direct hardware access, including interrupt handling and power state transitions, thereby protecting the system from unstable user-mode code.[2][17] In contrast, the user-mode driver (UMD) operates in user space and focuses on higher-level graphics management without direct hardware interaction, which improves overall system reliability by preventing crashes from propagating to the kernel. The UMD implements interfaces for the DirectX runtime, handling operations like surface flipping for display updates and resource creation, while relying on the kernel-mode driver for actual hardware execution. This separation allows the UMD to perform compute-intensive tasks, such as shader compilation and state validation, in a protected environment.[1][2] The DirectX Graphics Kernel (DXGK) interface forms the critical bridge between user-mode and kernel-mode components, providing a standardized set of device driver interfaces (DDIs) for graphics operations. It includes APIs for GPU scheduling, memory management, and power control; for instance, the DxgkDdiPresent function enables efficient screen updates by queuing presentation commands to the hardware, and DxgkDdiQueryAdapterInfo, introduced in WDDM 1.0 (Windows Vista), enables the DirectX Graphics Kernel to retrieve graphics adapter configuration information from the kernel-mode display miniport driver. All drivers supporting WDDM 2.6 and later must implement this function. These interfaces ensure that graphics vendors can implement consistent behavior across Windows versions while abstracting hardware-specific details. The DXGK also facilitates context creation and destruction, supporting seamless transitions in graphics workloads.[17][18][19] Supporting subsystems integrate with these drivers to enable advanced desktop functionality and fault tolerance. The Desktop Window Manager (DWM), a compositing engine, relies on WDDM drivers to render and blend windows using GPU acceleration, managing visual effects like transparency and animations through shared graphics resources. Meanwhile, the Timeout Detection and Recovery (TDR) mechanism monitors GPU operations for excessive delays, typically beyond 2 seconds, and initiates a driver reset to recover from hangs without rebooting the system, thereby maintaining user productivity. These subsystems collectively ensure robust graphics handling in multi-application scenarios.[20][21]User-Mode and Kernel-Mode Operations
The Windows Display Driver Model (WDDM) divides graphics processing into user-mode and kernel-mode operations to balance performance, security, and system stability. Applications initiate graphics tasks by invoking DirectX APIs through the Direct3D runtime, which interfaces with the vendor-supplied user-mode driver (UMD). The UMD translates these high-level API calls into lower-level commands, such as rendering primitives or presentation operations, and submits them via runtime callbacks to the kernel-mode subsystem.[22][2] In the kernel mode, the DirectX Graphics Kernel subsystem (Dxgkrnl.sys) receives these submissions and invokes the corresponding DirectX Graphics Kernel (DXGK) interfaces on the vendor-supplied kernel-mode driver (KMD). The KMD performs validation of command buffers, formats direct memory access (DMA) packets, and prepares allocation lists for GPU execution. Dxgkrnl then schedules the validated work on the GPU through its video scheduler (VidSch), ensuring fair resource allocation across processes while queuing commands for hardware submission via functions like DxgkDdiSubmitCommand. This workflow minimizes kernel-mode involvement in complex computations, delegating them to user mode where possible.[22][2] Security in WDDM relies on strict isolation between user-mode and kernel-mode components to prevent privilege escalation and system-wide faults. User-mode operations, including shader translation and resource creation, execute in a per-process address space without direct hardware access, allowing failures to be contained using structured exception handling. The kernel mode, through Dxgkrnl, arbitrates all access to GPU resources, validating allocations and commands before submission to the KMD, thereby reducing the attack surface by limiting kernel-mode code execution. This design significantly enhances stability, as faults in user-mode drivers do not crash the system.[13] Power and state management further delineate responsibilities between modes. The kernel mode, via dxgkrnl.sys, oversees critical transitions such as suspend and resume, implementing optimizations in WDDM 1.2 and later to maintain seamless high-resolution display during sleep states and rapid recovery post-hibernation. User-mode drivers contribute to efficiency in low-power scenarios, such as video playback, by leveraging features like the hardware flip queue in WDDM 3.0, where the UMD queues multiple frames in advance to the display controller, enabling the CPU and GPU to enter lower power states during idle VSync intervals.[2][23][24] For multi-GPU configurations, the kernel mode centralizes task routing and coordination. Dxgkrnl's GPU virtualization layer manages adapters as a unified pool, directing workloads across multiple GPUs based on availability and affinity while handling failover to maintain continuity in case of adapter failure, integrating with broader fault tolerance mechanisms.[2]Key Features
Video Memory Virtualization
Video memory virtualization in the Windows Display Driver Model (WDDM) provides a unified virtual address space for GPU memory, allowing the GPU to treat graphics resources as a paged memory system analogous to system RAM.[25] Each process receives a unique GPU virtual address (GPUVA) space, where allocations are assigned stable addresses that persist throughout their lifetime, enabling direct referencing by GPU engines without intermediate patching.[25] This model supports paging mechanisms, utilizing either GPU-managed memory management units (GpuMmu) with dedicated page tables or input-output memory management units (IoMmu) that share CPU page tables, to handle translations between virtual and physical addresses.[26] Key mechanisms include segmentation for memory allocation, where the user-mode driver (UMD) requests segments within the GPUVA space to map resources, and dynamic migration of data between system memory and GPU memory to optimize residency.[25] The Video Memory Manager (VidMm) in the kernel oversees these operations, tracking allocations and enforcing commit limits while permitting overcommitment, which allows the total virtual allocations to exceed the physical video RAM (VRAM) capacity by leveraging system memory as backing store.[27] For instance, resources can be paged out to system RAM when not in use, preventing exhaustion of GPU-local memory and supporting workloads that surpass physical VRAM limits.[25] Implementation involves the kernel-mode driver interface (DXGK) through which VidMm maintains page tables and processes UMD requests for segment creation and residency changes, with the GPUVA space allocation being dynamic and resizing as needed based on usage.[26] The UMD submits GPU commands using these virtual addresses directly, bypassing legacy patching requirements, while VidMm handles fault resolution and migration transparently.[25] These features enable handling of large-scale workloads, such as running multiple high-resolution applications simultaneously (e.g., several 4K video streams or complex rendering tasks), by efficiently distributing memory demands across available system resources.[25] Overcommitment and paging reduce the need for disk swapping, minimizing performance degradation during memory pressure and improving overall system responsiveness for graphics-intensive scenarios.[25]GPU Scheduling
In the Windows Display Driver Model (WDDM), GPU scheduling is handled by a preemptive kernel-mode scheduler known as VidSch, which is a component of the DirectX Graphics Kernel (Dxgkrnl.sys). This scheduler enables the operating system to interrupt ongoing GPU tasks and switch contexts between multiple applications, ensuring fair resource allocation and system responsiveness even under heavy loads. Unlike the cooperative scheduling in the legacy Windows Driver Model (WDM), where applications were expected to voluntarily yield GPU control, WDDM's preemptive approach actively manages execution to prevent any single process from monopolizing the GPU. Preemption occurs at the level of Direct Memory Access (DMA) packets, with granularity determined by the driver's capabilities, such as graphics, compute, or DMA buffer preemption levels reported via the D3DKMDT_PREEMPTION_CAPS structure.[1][28][29] Context scheduling in WDDM is facilitated through the DirectX Graphics Kernel (DXGK) interface, where the kernel-mode driver (KMD) creates and manages GPU contexts using functions like DxgkDdiCreateContext. Each context represents a logical execution environment for an application, and VidSch queues these contexts based on submission order and priority. The scheduler supports multiple priority levels to differentiate workloads: high-priority queues are reserved for real-time tasks, such as Desktop Window Manager (DWM) composition or video playback, to guarantee timely preemption and avoid visual glitches, while lower-priority queues handle batch-oriented workloads like game rendering. This prioritization ensures that critical display updates are not delayed by long-running computations.[29][30][29] WDDM's GPU scheduler also accommodates multi-engine architectures in modern GPUs by maintaining separate submission queues for distinct engine types, including 3D rendering, compute processing, video decode, and video encode. This allows VidSch to arbitrate access independently across engines, enabling parallel execution of compatible workloads without interference—for instance, decoding video streams concurrently with 3D graphics operations. Optimizations within the scheduling framework include flip scheduling, which leverages preemption and VSync synchronization (via DXGK_FLIPCAPS flags like FlipOnVSyncMmIo) to minimize latency in presenting updated frames to the display, reducing tearing and improving user experience in dynamic scenarios. Additionally, the scheduler integrates with power management by idling and gating unused engines to conserve energy, though this is coordinated through broader WDDM runtime mechanisms.[30][29]Direct3D Surface Sharing
In the Windows Display Driver Model (WDDM), Direct3D surfaces—such as textures and buffers—are shared across processes using NT handles generated through the DirectX Graphics Infrastructure (DXGI) interface, enabling efficient access without data duplication.[31] These handles serve as global identifiers for the surfaces, allowing a creating process to obtain a share handle viaIDXGIResource1::CreateSharedHandle with specified access permissions (e.g., read or write), which can then be passed to other processes for opening via ID3D11Device1::OpenSharedResource1.[31] This mechanism supports zero-copy operations by directly referencing the underlying video memory allocation, reducing overhead in scenarios requiring inter-process collaboration.[32]
The sharing protocol is mediated by the WDDM kernel-mode components, particularly the video memory manager, which virtualizes surfaces and validates access permissions during handle operations to ensure secure inter-process communication.[22] When a process opens a shared handle, the kernel checks the requested access against the handle's security attributes and the resource's state, preventing unauthorized modifications or reads.[31] This builds on WDDM's video memory virtualization, where surfaces are treated as abstract allocations paged in and out of GPU memory as needed.[13]
Key use cases include remote desktop protocols, where shared surfaces enable efficient screen capture and transmission without redundant copying, and multi-application environments such as video conferencing or game alt-tabbing, allowing seamless composition of content from different processes.[4] For instance, the Desktop Duplication API in Windows 8 leverages this sharing for remote sessions, capturing and duplicating Direct3D surfaces across processes.[4]
Security is maintained through kernel-enforced reference counting on surface residency, where each open handle increments a count; once it reaches zero upon handle closure, the surface can be safely reclaimed or evicted under memory pressure to prevent leaks or dangling pointers.[33] The WDDM scheduler further ensures fault isolation by suspending non-compliant processes without affecting shared resources, upholding system stability during sharing.[13]
Fault Tolerance Mechanisms
The Windows Display Driver Model (WDDM) incorporates Timeout Detection and Recovery (TDR) as a primary mechanism to detect and mitigate GPU hangs, preventing system-wide crashes by isolating and resetting affected components. When a GPU task exceeds the default 2-second timeout period without completing or preempting, the GPU scheduler identifies the hang and initiates recovery by calling the display miniport driver'sDxgkDdiResetFromTimeout function, which resets the driver context and restarts the stalled task.[21] This process typically results in a brief screen flicker, followed by recovery of the desktop environment, with users notified via a message indicating the display driver has stopped responding and recovered.[21]
Complementing TDR, the WDDM GPU scheduler employs a watchdog mechanism to track command submissions and enforce responsiveness, preempting tasks to avoid prolonged occupation of GPU resources by any single operation. This monitoring ensures that the GPU remains available for other processes, integrating with the overall scheduling framework to maintain system stability during graphics operations.[21] If preemption fails within the timeout window, the scheduler escalates to full TDR recovery.
For hardware-level faults, WDDM provides error reporting through DXGK callbacks, allowing drivers to notify the operating system of issues such as error-correcting code (ECC) failures via interrupts like DXGK_INTERRUPT_DMA_PAGE_FAULTED.[34] The system responds with actions such as GPU resets or transitioning the device to an error state, enabling graceful degradation where functionality is limited but the OS continues operating without a full crash.[34]
WDDM enhances fault tolerance through process isolation, where failures like engine timeouts (bug check 0x141) confine recovery to the offending application, blocking its GPU access while preserving functionality for other processes and avoiding kernel-level instability.[21] These events are logged in the Event Viewer for diagnostics, including details on resets and collected debug reports submitted to Microsoft for analysis.[21]
Version History
WDDM 1.0
WDDM 1.0 marked the foundational implementation of the Windows Display Driver Model, building on earlier models like the Windows 2000 Display Driver Model (XDDM) to enable more robust graphics handling in modern operating systems. Released in November 2006 with the RTM of Windows Vista, it was designed to support advanced visual effects such as the Aero glass interface and DirectX 10 graphics API.[1] This version required graphics hardware vendors to develop and certify new drivers compliant with WDDM standards to fully leverage Vista's features, ensuring compatibility and stability for end-users.[35] A core innovation in WDDM 1.0 was the separation of driver functionality into user-mode and kernel-mode components, where the user-mode driver (UMD) handles complex rendering tasks while the kernel-mode driver (KMD) manages essential I/O operations, resource allocation, and implements callbacks such as DxgkDdiQueryAdapterInfo to retrieve graphics adapter configuration information.[1][19] This split improved system reliability by isolating potential failures in graphics processing from core OS functions. Additionally, it introduced basic GPU video memory virtualization, enabling the sharing of up to 2 GB of VRAM across applications through paging mechanisms that prevented exhaustion of physical memory during intensive workloads.[1] Another key feature was Timeout Detection and Recovery (TDR), which monitors GPU operations and resets the driver if a task exceeds the default 2-second timeout, avoiding full system crashes from hung graphics hardware.[21][36] Adoption of WDDM 1.0 was tied closely to Windows Vista certification, with certified drivers mandatory for enabling Aero and optimal performance; uncertiified hardware fell back to basic display modes.[35] The model primarily targeted single-GPU setups, providing foundational support for graphics acceleration without advanced multi-GPU orchestration. However, limitations at launch included rudimentary multi-monitor handling beyond simple spanning, lacking seamless integration across adapters, and elevated CPU overhead during desktop composition by the Desktop Window Manager (DWM), as much of the blending and effects processing relied on less optimized GPU offloading compared to subsequent versions.[37][1]WDDM 1.1
WDDM 1.1 was released in October 2009 alongside Windows 7, marking an evolution from the initial WDDM 1.0 architecture introduced in Windows Vista.[3] This version provides foundational support for DirectX 11, enabling advanced graphics capabilities such as shader model 5.0 and hardware tessellation directly through user-mode drivers (UMD).[38] By extending the virtualization mechanisms from WDDM 1.0, it allows for more efficient resource allocation across applications while maintaining compatibility with existing drivers.[4] Key enhancements in WDDM 1.1 focus on performance and efficiency, including improved power management through better GPU idle detection, which enables the graphics hardware to enter low-power states more rapidly when not in use.[39] It also introduces stereoscopic 3D support via DXGI 1.1, allowing drivers to handle left- and right-eye image pairs for immersive rendering and video playback without requiring kernel-mode intervention. Additionally, optimizations in the flip-model presentation reduce latency by streamlining the swap chain operations, minimizing the time between frame rendering and display output for smoother animations. Optimizations in WDDM 1.1 extend to multi-monitor configurations, with new Win32 APIs facilitating the connection and management of up to four displays per graphics adapter, improving desktop spanning and independent monitor control. The user-mode driver component receives enhancements for DirectX 11-specific features like tessellation, where the hull and domain shaders are processed more efficiently in user space, reducing overhead for geometry generation in complex scenes. These advancements contributed to Windows 7's smoother user interface, leveraging DirectX 11 for fluid transitions and animations, while power efficiency gains from idle detection and presentation optimizations resulted in 20-30% improved battery life on laptops compared to Windows Vista.[40]WDDM 1.2
WDDM 1.2 was released in October 2012 with Windows 8 and became a mandatory requirement for graphics hardware certification on that platform.[4][41] This version builds on prior GPU scheduling capabilities to deliver enhanced reliability and performance for modern user interfaces.[4] A major advancement in WDDM 1.2 is its native multi-monitor support, enabling up to four active displays for improved productivity in extended desktop configurations.[4] It also integrates key DirectX 11.1 capabilities.[4] Additional improvements focus on user interaction and virtualization: enhanced GPU scheduling prioritizes touch input for lower latency on touch-enabled devices, while new driver types—such as display-only and render-only—facilitate better graphics passthrough in Hyper-V virtual machines.[4] These features collectively enabled the fluid operation of Windows 8's Metro UI, ensuring seamless transitions and high-fidelity rendering that were essential for the operating system's touch-first design.[4] WDDM 1.2 compliance was enforced for all Windows 8 systems, with full graphics drivers required as the primary boot device to achieve certification.[42]WDDM 1.3
WDDM 1.3 was introduced in October 2013 alongside Windows 8.1, bringing incremental performance optimizations to the display driver architecture while maintaining compatibility with prior versions.[5][43] This version emphasized refinements in graphics rendering and resource management, particularly through support for DirectX 11.2, which included features like tiled resources for handling large textures with partial memory residency.[44] Tiled resources function as bindless-like mechanisms, allowing applications to reference oversized logical resources without allocating full physical memory, thus reducing overhead in scenarios involving expansive datasets such as terrain rendering or high-resolution UI elements.[44] These improvements optimized memory migration by enabling efficient paging of resource tiles between system and video memory, minimizing stalls during data transfers.[5] Further enhancements focused on better CPU-GPU overlap and rendering efficiency, achieved via graphics kernel updates including history buffer management for precise API call timing and reduced present overhead with support for additional texture formats.[5][45] Variable refresh rate overhead was lowered through adaptive sync capabilities, such as dropping to 48 Hz for 24 fps content on 60 Hz displays to conserve power without compromising playback quality.[5] Video processing saw advancements in YUV format handling for studio or extended range inputs, supporting higher-fidelity color pipelines suitable for professional workflows.[5] It also enhanced Direct3D surface sharing via cross-adapter resource management in hybrid GPU configurations, allowing seamless data exchange between integrated and discrete graphics.[5] The collective impact of these tweaks was evident in improved handling of high-resolution content, enabling smoother 4K video playback by alleviating memory bottlenecks and rendering latencies in demanding applications.[44] Multiplane overlay support further laid groundwork for layered composition in modern displays, facilitating efficient blending of video and graphics planes for power-efficient, high-quality output.[46] Overall, WDDM 1.3 refined the model's scalability for emerging display technologies without introducing architectural overhauls.[5]WDDM 2.0
WDDM 2.0, released on July 29, 2015, alongside Windows 10, represented a major redesign of the Windows Display Driver Model to support advanced graphics workloads, particularly those leveraging DirectX 12.[9] This version shifted toward lower-overhead GPU access by enabling user-mode drivers to submit work directly to hardware, reducing kernel-mode intervention and improving overall efficiency for modern applications.[6] A core innovation in WDDM 2.0 is full support for DirectX 12, which requires drivers compliant with this model to unlock features like explicit resource management and reduced CPU overhead in graphics pipelines.[47] This integration allows developers to handle multi-GPU configurations explicitly, where applications can distribute rendering tasks across multiple adapters without relying on vendor-specific technologies like SLI or CrossFire, providing greater flexibility for heterogeneous GPU setups. Additionally, WDDM 2.0 introduces GPU virtual addressing (GPUVA), assigning each process a unique virtual address space shared across all GPU contexts, with support for up to 1 TB (40-bit addressing) per process on compatible hardware.[25] This expansion facilitates virtualized GPU (vGPU) support in virtual machines, allowing multiple VMs to securely access GPU resources through models like GpuMmu or IoMmu, which manage page tables for isolation and paging.[25] WDDM 2.0 also adds the independent flip model for display presentation, enabling swap chains to flip frames directly to the hardware without Desktop Window Manager (DWM) composition in exclusive fullscreen modes, thereby minimizing latency for gaming and video playback.[48] Complementing this, it incorporates hardware-accelerated video decode scheduling via enhancements to the video memory manager and DirectX Video Acceleration (DXVA), permitting efficient queuing and execution of decode operations on GPU engines with reduced synchronization overhead.[6] These changes collectively enable low-overhead gaming by streamlining DirectX 12 pipelines and enhance server virtualization through robust GPU resource sharing in Hyper-V environments.[47]WDDM 2.1
WDDM 2.1 was introduced in August 2016 alongside the Windows 10 Anniversary Update (version 1607), enhancing the graphics driver architecture with a focus on video processing and overall system efficiency.[49][50] Key new features include hardware-accelerated video decoding queues enabled through DirectX Memory Surface Sharing, which facilitates efficient frame sharing across processes in camera and capture scenarios using NV12 textures, thereby reducing latency and bandwidth requirements for video workloads.[49] This builds on prior capabilities by optimizing video pipeline integration. Additionally, WDDM 2.1 provides improved power efficiency for media applications via enhancements to memory offer and reclaim mechanisms, which minimize graphics memory footprint and prevent unnecessary background app terminations, leading to lower overall power consumption.[49] Support for HDR10 was also added, enabling high dynamic range gaming and 4K Ultra HD video playback on compatible displays.[50] Optimizations in WDDM 2.1 emphasize better context switching for mixed workloads, such as gaming combined with streaming, through present batching that introduces multi-threading for flip model swapchains.[49] This extends the GPU scheduling introduced in WDDM 2.0, allowing smoother integration of tools like the Windows Game Bar and Game DVR in full-screen scenarios without significant performance degradation. The impact includes reduced CPU usage for video-related tasks, as pipeline state object (PSO) caching stores precompiled shaders for faster loading and execution in media and graphics applications.[49]WDDM 2.2
WDDM 2.2 was released in April 2017 alongside the Windows 10 Creators Update (version 1703), marking a significant evolution in the display driver model to support advanced graphics scenarios, particularly those involving mixed reality and high-fidelity visuals. A key advancement in WDDM 2.2 is the mandatory implementation of kernel-mode DirectX Graphics Kernel (DXGK) device driver interfaces (DDIs) for multi-plane overlay (MPO), which enables hardware-accelerated composition of up to eight overlapping video and graphics planes per display.[51] This feature builds on earlier MPO capabilities introduced in WDDM 1.3 by shifting capability queries to kernel mode, allowing for dynamic adjustments based on display configuration changes and reducing CPU overhead during complex scene rendering. By offloading composition tasks—such as blending layers with alpha, rotation, scaling, and color space conversion—to the GPU, MPO in WDDM 2.2 optimizes bandwidth usage and improves efficiency for desktop windowing and video playback.[46] WDDM 2.2 also introduces enhanced color management capabilities, extending support for high dynamic range (HDR) and wide color gamut (WCG) to desktop applications beyond gaming. This allows for more accurate rendering of extended color spaces like Rec. 2020 on compatible wide-gamut displays, enabling richer contrast, brighter highlights, and a broader spectrum of colors in everyday use cases such as photo editing and media consumption. Hardware vendors, including NVIDIA and AMD, updated their drivers to leverage these features, ensuring seamless integration with the Creators Update's emphasis on creative workflows.[52] These improvements collectively deliver smoother visuals in games and videos by minimizing latency in layer composition and enhancing perceptual quality through superior color fidelity, making WDDM 2.2 particularly beneficial for content creators and immersive experiences.WDDM 2.3
WDDM 2.3 was introduced in October 2017 with the Windows 10 Fall Creators Update (version 1709).[53] This version added hardware-accelerated Graphics Device Interface (GDI) support for 2D graphics rendering, enabling GPU acceleration for traditional GDI operations that were previously CPU-bound.[54] This enhancement allows legacy applications relying on GDI to benefit from improved performance without requiring code updates, reducing CPU overhead in desktop compositing. It builds on Direct3D surface sharing for efficient resource handling across processes.[54] WDDM 2.3 also improved multiplane overlay (MPO) functionality with enhanced alpha blending capabilities, supporting pre-multiplied alpha for more accurate layer compositing in the Desktop Window Manager (DWM).[46] This results in smoother visual effects and reduced latency for overlapping windows, particularly in scenarios involving transparency and layered content. Further enhancements included better compatibility for external displays connected through USB-C and Thunderbolt ports, optimizing bandwidth allocation and display configuration for multi-monitor enterprise setups. These changes collectively accelerate rendering in legacy applications, making WDDM 2.3 particularly valuable for enterprise environments where older software must coexist with modern hardware.[55]WDDM 2.4
WDDM 2.4 was released in April 2018 as part of the Windows 10 April 2018 Update (version 1803), enhancing the display driver model's efficiency and compatibility for modern hardware configurations.[53] This version builds on previous iterations by introducing features that optimize resource management in hybrid and virtualized environments, reducing overhead and improving overall system responsiveness. A major efficiency improvement in WDDM 2.4 is the support for GPU paravirtualization, which enables more direct GPU access in Hyper-V virtual machines, minimizing emulation layers for better performance in virtualized rendering workloads.[56] Complementing this, IOMMU-based GPU isolation leverages hardware input-output memory management units to enforce strict memory access controls, enhancing security and facilitating faster recovery from timeout detection and recovery (TDR) events in multi-GPU setups by isolating faulty components without system-wide disruption.[57] WDDM 2.4 also refines presentation mechanisms, including optimized multi-plane overlay (MPO) handling for power savings in hybrid GPU systems where rendering occurs on one GPU and display on another, such as integrated graphics for efficiency.[58] These optimizations reduce latency in flip scheduling by streamlining frame presentation across GPUs, contributing to smoother operation in mixed compute and graphics loads. Additionally, the model provides broader compatibility for APIs like Vulkan 1.1 through updated driver interfaces, enabling developers to leverage advanced cross-platform graphics without compatibility barriers.[59] The combined impact of these enhancements is particularly beneficial for mobile gaming on laptops with switchable graphics, offering improved battery life and reduced input lag in dynamic workloads, while maintaining robust fault tolerance for multi-GPU configurations.[60]WDDM 2.5
WDDM 2.5 was introduced in the Windows 10 October 2018 Update (version 1809), marking a significant advancement in graphics driver capabilities by integrating hardware-accelerated ray tracing support.[61] This version added new Direct3D device driver interfaces (DDIs) to enable DirectX Raytracing (DXR), allowing developers to implement real-time ray tracing directly within Direct3D 12 pipelines for more realistic rendering of light interactions, reflections, shadows, and global illumination.[61] The feature leverages dedicated ray tracing hardware on compatible GPUs, reducing computational overhead compared to software-based approaches and facilitating hybrid rendering techniques that combine ray tracing with traditional rasterization.[62] In addition to DXR, WDDM 2.5 provided foundational support for Vulkan 1.1 through updated driver interfaces, enabling cross-API compatibility and allowing graphics hardware to expose advanced features like ray tracing acceleration structures to Vulkan-based applications via later extensions such as VK_KHR_ray_tracing_pipeline.[63] This integration broadened the applicability of ray tracing beyond DirectX, supporting diverse development ecosystems while maintaining consistency in hardware resource management and scheduling. WDDM 2.5 also incorporated enhancements to display synchronization, where the operating system queries adapter capabilities during initialization to optimize multi-monitor and variable refresh rate setups, improving overall system responsiveness.[61] The impact of these features was evident in early real-time ray tracing implementations, such as in the game Control (released in 2019 by Remedy Entertainment), which utilized DXR for dynamic ray-traced reflections and ambient occlusion, achieving photorealistic visuals on RTX-enabled hardware without prohibitive performance costs.[64] By building on prior WDDM scheduling mechanisms, version 2.5 ensured efficient GPU resource allocation for ray tracing workloads, as detailed in the GPU scheduling overview. Overall, WDDM 2.5 laid the groundwork for widespread adoption of ray tracing in consumer applications, emphasizing hardware-software synergy for next-generation graphics rendering.[61]WDDM 2.6
WDDM 2.6 was introduced in Windows 10 version 1903, released in May 2019.[61] This version builds on previous iterations by enhancing rendering efficiency and compute capabilities, particularly for modern graphics workloads. Key advancements focus on optimizing shader execution and resource management to support higher-resolution displays and complex scenes without proportionally increasing computational demands.[61] A major addition is Variable Rate Shading (VRS) Tier 2, which extends the coarse pixel shading introduced in earlier tiers by allowing shading rates to be specified on a per-draw basis, per-provoking-vertex, or via a screenspace image with 16x16 tile granularity.[61] This enables developers to apply lower shading rates to peripheral or less detailed areas of the frame, reducing pixel shader invocations and thereby improving performance in high-resolution rendering scenarios. VRS Tier 2 integrates seamlessly with DirectX 12, facilitating more efficient GPU utilization in games and applications where visual fidelity can be maintained with variable detail levels.[65] Compute shader optimizations in WDDM 2.6 include support for background processing, where user-mode drivers can schedule low-priority threads to run asynchronously, minimizing interference with foreground rendering tasks.[61] This enhances overall system responsiveness, especially in multitasking environments. Additionally, the introduction of the Microsoft Compute Driver Model (MCDM) in WDDM 2.6 provides a framework for developing drivers for compute-only devices, laying groundwork for integration with specialized hardware like Neural Processing Units (NPUs) in future AI-accelerated workflows.[66] These features collectively improve efficiency in high-resolution rendering by reducing GPU shading overhead, with potential performance gains depending on workload; for instance, VRS can lower computational load in areas of low visual importance without compromising perceived quality.[65] Overall, WDDM 2.6 contributes to better power efficiency and frame rates in graphics-intensive applications.[61] Additionally, starting with WDDM 2.6, all drivers supporting this version and later must implement the DxgkDdiQueryAdapterInfo kernel-mode callback function to retrieve graphics adapter configuration information.[19]WDDM 2.7
WDDM 2.7 was introduced in May 2020 alongside the Windows 10 May 2020 Update (version 2004), enabling enhanced support for DirectX 12 Ultimate features on compatible hardware.[67] This version builds on prior iterations by incorporating advanced graphics pipeline capabilities, primarily through integration with DirectX 12 Ultimate, to improve rendering efficiency and developer flexibility.[68] Key new features in WDDM 2.7 include mesh shaders and sampler feedback. Mesh shaders replace the traditional input assembler stage in the Direct3D 12 graphics pipeline, offering programmable flexibility for rasterization tasks such as vertex processing and primitive assembly.[67] They support early culling to reduce unnecessary GPU workload on index data and introduce amplification shaders for dynamic control over geometric detail levels, which hardware capabilities are reported via theMeshShaderTier in driver interfaces.[67] Sampler feedback captures detailed information about texture sampling locations and frequencies, stored in feedback maps to optimize texture streaming and shading computations in real-time applications.[67] Additionally, WDDM 2.7 improves multi-queue support for compute workloads through hardware-accelerated GPU scheduling, allowing the GPU to directly manage task prioritization across multiple command queues, reducing latency in parallel compute scenarios.[67]
These enhancements provide better accommodation for hardware variances across vendors, such as AMD and NVIDIA GPUs, by standardizing DirectX 12 Ultimate feature exposure while optimizing performance on diverse architectures like NVIDIA's Pascal and later series or AMD's RDNA implementations.[69] The overall impact is particularly notable in gaming, where mesh shaders streamline geometry processing by minimizing overhead in complex scenes, enabling more efficient handling of dynamic environments without traditional fixed-function limitations.[67]
