Features added in prior WDDM 2.X versions

This page describes display and graphics drivers’ features that were added in previous versions of WDDM 2.X for Windows 10. To see features added for the most recent WDDM 2.X version, see What’s new for Windows 10 display and graphics drivers.

WDDM 2.6

Super Wet Ink

Super-Wet Ink is a feature that revolves around front-buffer rendering. IHV drivers can support the creation of “displayable” textures of formats or modes that are not supported by the hardware. They can do this by allocating the texture that the app requested, along with a “shadow” texture with a format/layout that can be displayed, and then copying between the two at present-time. This “shadow” may not necessarily be a texture in the normal way we think of it, but may just be compression data. Additionally, it may not be required to exist, but may be an optimization instead.

The runtime will evolve to understand these aspects of displayable surfaces:

Whether or not a shadow must exist for display on a particular VidPnSource/plane.

Whether it is more optimal for a shadow to exist.

When to transfer contents from the application surface to the shadow surface. The runtime will be explicit about this operation, as opposed to it being implicit within Present.

How to request setting a mode or dynamically flipping between the original and shadow surfaces.

Scanout may begin shortly after a VBlank, scans vertically from top to bottom of the image, and completes shortly before the next VBlank. This is not always the case, depending on the timing of the pixel clock, and the layout of the data in the texture; especially if there is actually compression available.

New DDIs were added to separate and understand transformations which occur prior to scanout, in order to (when possible) enable front-buffer rendering. See D3DWDDM2_6DDI_SCANOUT_FLAGS and PFND3DWDDM2_6DDI_PREPARE_SCANOUT_TRANSFORMATION.

Variable Rate Shading

Variable rate shading, or coarse pixel shading, is a mechanism to enable allocation of rendering performance/power at varying rates across rendered images.

In the previous model, in order to use MSAA (multi-sample anti-aliasing) to reduce geometric aliasing:

• The amount by which to reduce geometric aliasing needs to be known up-front when the target is allocated.
• The amount by which to reduce geometric aliasing can’t be changed once the target is allocated.

In WDDM 2.6, the new model extends MSAA into the opposite, coarse pixel direction, by adding a new concept of coarse shading. This is where shading can be performed at a frequency coarser than a pixel. A group of pixels can be shaded as a single unit and the result is then broadcast to all samples in the group.

A coarse shading API allows apps to specify the number of pixels that belong to a shaded group. The coarse pixel size can be varied after the render target is allocated. So, different portions of the screen or different draw passes can have different course shading rates.

A multiple-tier implementation is available with two user-queryable caps. For Tiers 1 and 2, coarse shading is available for both single-sampled and MSAA resources. For MSAA resources, shading can be performed per-coarse-pixel or per-sample as usual. However, on Tiers 1 and 2, for MSAA resources, coarse sampling cannot be used to shade at a frequency between per-pixel and per-sample.

Shading rate can only be specified on a per-draw-basis; nothing more granular than that

Shading rate applies uniformly to what is drawn independently of where it lies within the render target

Shading rate can be specified on a per-draw-basis, as in Tier 1. It can also be specified by a combination of per-draw-basis, and of:

• Semantic from the per-provoking-vertex, and
• A screenspace image

Shading rates from the three sources are combined using a set of combiners

Screen space image tile size is 16×16 or smaller. Shading rate requested by the app is guaranteed to be delivered exactly (for precision of temporal and other reconstruction filters)

SV_ShadingRate PS input is supported. The per-provoking vertex rate, also referred to here as a per-primitive rate, is only valid when one viewport is used and SV_ViewportIndex is not written to.

The per-provoking vertex rate, also referred to as a per-primitive rate, can be used with more than one viewport if the SupportsPerVertexShadingRateWithMultipleViewports cap is marked true. Additionally, in that case, it can be used when SV_ViewportIndex is written to.

Collect Diagnostic Info

Collect diagnostic info allows the OS to collect a private data from drivers for graphics adapters which consist of both rendering and display functions. This new feature is a requirement in WDDM 2.6.

The new DDI should allow the OS to collect information at any time a driver is loaded. Currently the OS uses DxgkDdiCollectDebugInfo function implemented by the miniport to query driver private data for TDR (timeout detection and recovery) related cases. The new DDI will be used to collect data for variety of reasons. The OS will call this DDI when diagnostic is needed providing a type of information being requested. The driver should collect all private information important to investigate the issue and submit it to the OS. DxgkDdiCollectDebugInfo will be eventually deprecated and replaced with DxgkDdiCollectDiagnosticInfo.

Background Processing

Background processing allows user mode drivers to express desired threading behavior, and the runtime to control/monitor it. User mode drivers would spin up background threads and assign the threads as low a priority as possible, and rely on the NT scheduler to ensure these threads don’t disrupt the critical-path threads, generally with success.

APIs allow apps to adjust what amount of background processing is appropriate for their workloads and when to perform that work.

Driver Hot Update

Driver hot update reduces server downtime as much as possible when an OS component needs to be updated.

Driver hot patch is used to apply a security patch to the kernel mode driver. In this case the driver is asked to save adapter memory, the adapter is stopped, the driver is unloaded, new driver is loaded and the adapter is started again.

WDDM 2.5

Tracked Workloads

Tracked Workloads is an experimental feature that provides more control over the trade-off between quicker processor execution vs. lower power consumption, and is not available until further notice. The implementation was removed from Windows 10, version 2003; and deprecated from earlier OS versions as part of a security fix.

Content changes

Topic	Date	Description
EDID Extension (VSDB) for HMDs and Specialized Displays	12/03/2018	Specification for Display Manufacturers
DirectX Graphics Kernel Subsystem (Dxgkrnl.sys)	12/04/2018	Kernel-mode interfaces that the Windows operating system implements through the Microsoft DirectX graphics kernel subsystem (Dxgkrnl.sys).
WDDM 2.1 Features	01/10/2019	Describes new and updated features for WDDM 2.1

Raytracing

New Direct3D DDI’s were created in parallel of Direct3D API’s, in order to support hardware-accelerated raytracing. Example DDIs include:

For more info about raytracing, see:

Display Synchronization

The OS will check for capabilities for display synchronization when the display is exposed by the driver to the OS, so prior to enabling the display. For TypeIntegratedDisplay child devices, this is reported via a call to DxgkDdiQueryAdapterInfo with Type DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2 during adapter initialization. For TypeVideoOutput child devices, which are supported starting with WDDM 2.5, the capabilities are reported as part of the hot plug processing via DxgkDdiUpdateMonitorLinkInfo so that the capabilities may change based on the target or connected monitor.

The OS specifies the display synchronization in the DxgkDdiSetTimingsFromVidPn call in the Input field in the per path DXGK_SET_TIMING_PATH_INFO structure.

WDDM 2.1

WDDM 2.1 enables new scenarios and provides significant improvements in the areas of performance, reliability, upgrade resiliency, diagnostic improvements and future system advancements for the Windows graphics sub-system. The WDDM 2.0 driver model is a pre-requisite for D3D12. WDDM 2.0 and DirectX12 are available only on Windows 10 and higher.

The following is a list of feature additions and updates for WDDM 2.1.

Improved graphics performance by reducing overhead time spent in memory management and more efficient usage of scarce graphics memory. The graphics performance improvements are:

• Offer and reclaim resources — offer and reclaim improvements to reduce memory footprint of applications running in background mode.
• Support for 2MB Page Table Entry encoding — In WDDM 2.1, large Page Table Entry (PTE) encoding in VRAM is enabled. This change boosts performance on systems that support it.
• Support for 64KB memory pages — Virtual memory allocations using a 64KB granularity is also supported in WDDM 2.1. This change especially benefits APUs and SoCs by reducing overhead for accessing virtual memory pages.

Hardware-based protected content improvements with present batching (PlayReady 3.0)

Driver Store installation for graphics drivers to improve driver upgrade resiliency.

DXIL, a new shader complier language

D3D12 performance and optimization improvements

Improved diagnostic options for developers

For more information, see WDDM 2.1 Features.

WDDM 2.0

WDDM 2.0 includes memory management updates.

WDDM 1.2 features

This topic describes the Windows Display Driver Model (WDDM) Version 1.2 feature set, which includes several new enhancements that improve performance, reliability, and the overall end-user experience.

Each of these features requires special support from third-party WDDM 1.2 and later drivers. This section elaborates on what constitutes the WDDM 1.2 feature set.

WDDM 1.2 has both mandatory and optional features. The driver must implement all the mandatory features to claim itself as a «WDDM 1.2 driver,» while the driver can implement any combination (or none) of the optional features. A non-WDDM 1.2 driver must report none of the WDDM 1.2 features.

This table summarizes the WDDM 1.2 feature set. «M» indicates mandatory, «O» indicates optional, and «NA» indicates not applicable. To read details about each feature, follow the link in the left column.

WindowsВ 8 features enabled by WDDM 1.2	Feature benefit	WDDM driver type: Full graphics	WDDM driver type: Render only	WDDM driver type: Display only
Video memory offer and reclaim	Enables more efficient usage of video memory	M	M	NA
GPU preemption	Improves desktop responsiveness	M	M	NA
TDR changes in Windows 8	Improved resiliency to GPU hangs	M	M	NA
Optimized screen rotation support	Screen rotation experience without flicker	M	NA	M
Stereoscopic 3D	Provides a consistent API and DDI platform to enable Stereoscopic 3D scenarios	O	NA	NA
Direct3D 11 video playback improvements	Simplified programming experience for video playback applications	M*	M*	NA
Direct flip of video memory	Improvements in the video playback and composition stack to reduce power consumption	M	NA	NA
Providing seamless state transitions	High resolution is maintained in state transitions and during bug checks	M	NA	M
Plug and Play (PnP) start and stop	Maintain high resolution as display ownership is transitioned between firmware, Windows, and driver	M	NA	M
Standby hibernate optimizations	Enables optimizations to the graphics stack to improve performance on sleep and resume	O	O	NA
GPU power management of idle states and active power	Provides a standardized infrastructure for fine-grained device power management	O	O	O
XPS rasterization on the GPU	Enables a quality printing experience on Windows with third-party drivers	M**	M**	NA
Container ID support for displays	Helps represent monitor device connectivity and associated state to the user in a user interface similar to the device hub	M	NA	M
Disabling Frame Pointer Omission (FPO) optimization	Improves debugging of performance problems related to FPO in the field	M	M	M
User-mode driver logging	Improves ability to diagnose and investigate memory-related issues by providing better view into memory usage	M	M	NA

*This feature is mandatory for all WDDM 1.2 drivers with Microsoft Direct3D 10-, 10.1-, 11-, or 11.1-capable hardware (or later).

**No new device driver interface (DDI) or behavior changes. However, WDDM 1.2 and later drivers must be able to pass XML Paper Specification (XPS) rasterization conformance tests to ensure a quality printing experience for hardware-accelerated XPS printing scenarios.

A new set of APIs is available starting with WindowsВ 8 for duplicating the desktop for collaboration scenarios. For more details, see Desktop duplication.

Additional new features in WindowsВ 8

The following added or updated display driver DDIs are also provided in WindowsВ 8:

Kernel Mode Display-Only Driver (KMDOD) Interface: Provides a limited set of display functions without rendering capability. See the Kernel mode display-only miniport driver sample.

Support for system on a chip (SoC) architecture through the SPB interface: Lets a display miniport driver access bus resources on an SoC system.

Surprise removal of secondary adapter

System Firmware Table Interface: Lets the display miniport driver enumerate and read the system firmware table.

Brightness Control Interface V. 2 (Adaptive and Smooth Brightness Control): Lets a display miniport driver reduce power to the display backlight and still smoothly adapt to changes in ambient light and user requests to change brightness. Also see Windows 8 brightness control for integrated displays.

Microsoft DirectX Graphics Infrastructure DDI (DXGI)

Allocation sharing & enqueing GPU events

Cancel command interface

Output duplication

Windows 8 OpenGL Enhancements: OpenGL installable client drivers (ICDs) can call new functions to control access to resources and to map between objects and identifiers.