Windows Display Driver Model

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. 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.

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.

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.

Windows Vista alerting the user of a successful WDDM recovery

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. With a WDDM driver, 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]

One of the chief scenarios 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 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 was in place.

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]

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[17] (but not GDI+) and Direct2D/DirectWrite
  • BitBlt, StretchBlt, TransparentBlt
  • AlphaBlend, ColorFill
  • ClearType font support
• Direct3D 11 device driver interface (DDI)
• DXVA-HD DDI[18]
• Hardware video overlay DDI[19]
• Optional AES 128 encryption
• Optional decoding of encrypted video content
• Support multiple drivers in a multi-adapter and multi-monitor setup[10][20]

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.[21][22][23]

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[24] and the Desktop Window Manager continues to use Direct3D 9Ex.[25]

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]

Windows 8 includes WDDM 1.2[26][27] and DXGI 1.2.[27][28] 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),[29] 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.[30]

WDDM 1.2 supports display-only and render-only WDDM drivers, such as Microsoft Basic Display Driver[31] 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.[32][33][34]

Windows 8.1 includes WDDM 1.3[35] and DXGI 1.3.[36] 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.

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,[37] to allow multithreading parallelism in the user-mode driver and result in lower CPU utilization.[38][39][40][41] Windows 10 also includes DXGI 1.4.[42]

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.[43]

A new memory model is implemented that gives each GPU a per-process virtual address space. 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.

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),[44] and DXGI 1.5 which supports HDR10 - a 10-bit high dynamic range, wide gamut format[45] defined by ITU-T Rec. 2100/Rec.2020 - and variable refresh rates.[46]

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.[47]

Windows 10 Fall Creators Update (version 1709) includes WDDM 2.3.

• Hardware queues
• IOMMU support
• Blocklist support
• Surface swapchains
• Device GUID lookup support
• Version query (BIOS/architecture information)
• Perfdata query (clock frequencies (current/max/OC), voltage (current/max/OC), memory frequency, memory bandwidth, PCIE bandwidth, fan RPM, power usage, temperature (max/warning), power override status)

The following is a list of new features for Windows Display driver development in Windows 10, version 1709:[48]

• 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:

1. Hardware accelerated video decoding
2. Content protection
3. Video processing

Windows 10 April 2018 Update (version 1803) includes WDDM 2.4.

• Additional d3d memory allocation types
• Adapter paravirtualization
• Arbitrary Code Guard
• Configurable DisplayRender timings
• Detachable adapter support
• Display configuration support
• Source owner support
• Display redirection
• ColorSpaceTransform support
• Protected device session
• Process device removal (checks if the process using the adapter can recover from graphics device removal)

The following are updates to Display driver development in Windows 10, version 1803 :

• Indirect Display UMDF class extension - The Indirect Display 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 - Increases security by restricting GPU access to system memory.
• GPU paravirtualization support - Enables display drivers to provide rendering capabilities to Hyper-V virtualized environments.
• Brightness - A new brightness interface to support multiple displays that can be set to calibrated nit-based brightness levels.
• D3D11 bitstream encryption - Additional GUIDS and parameters to D3D11 to support exposing CENC, CENS, CBC1, and CBCS with 8 or 16 byte initialization vectors.
• D3D11 and D3D12 video decode histogram - A luminance histogram allows the media team to leverage fixed function hardware for histogram to improve tone mapping quality for HDR/EDR scenarios. Fixed function hardware is useful when GPU is already saturated in these scenarios and to enable parallel processing. This feature is optional and should only be implemented if fixed function hardware is available. This feature should not be implemented with 3D or Compute.
• D3D12 video decode now supports Decode Tier II, indicating driver supports Array of Textures that enable 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. This improves ISVs ability to implement multiple GPU rendering techniques like split frame rendering (SFR) and clearly advances the capabilities over what is possible in D3D11.
• GPU dithering support - Drivers can report the ability to performing dithering on the wire signal for a given timing mode. This allows the OS 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 - Adds the ability for the OS to request that the driver temporarily disable any post-processing that enhances or alters display colors. This is to support scenarios where specific applications want 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 the following capabilities:
  • Hardware accelerated video decoding
  • Content Protection
  • 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 and shall support DisplayID v1.3 and DisplayID v2.0. The DDI is an extension of existing DxgkDdiQueryAdapterInfo DDI and shall be supported by all drivers with DXGKDDI_INTERFACE_VERSION >= DXGKDDI_INTERFACE_VERSION_WDDM2_3, including kernel mode display only drivers and indirect display drivers.
• GPU performance data - Extensions to DdiQueryAdapterInfo will expose information such as temperature, fan speed, clock speeds for engines and memory, memory bandwidth, power draw, and voltages
• Miscellaneous - A new SupportContextlessPresent driver cap to help IHV onboard new driver.
• Improvements to External/Removable GPU support in the OS. As a first step to add better support, Dxgkrnl needs to determine if a GPU is “detachable”, i.e. hot-pluggable. For RS4 we would like to leverage the driver's knowledge about this instead of building our own infrastructure. For this purpose, we are adding a “Detachable” bit to DXGK_ DRIVERCAPS struct. Driver will set this bit during adapter initialization if the adapter is hot-pluggable.
• Display Diagnostics - Kernel mode device driver interface (DDI) changes to allow the driver for a display controller to report diagnostic events to the OS. This provides a channel through which the driver can log events which would otherwise be invisible to the OS as the events are not a response to an OS request or something the OS needs to react to.
• Shared graphics power components - Allows non-graphics drivers to participate in the power management of a graphics device. A non-graphics driver will use a driver interface to manage one or more of these shared power components in coordination with the graphics driver.
• Shared texture improvements - Includes increasing the types of textures that can be shared across processes and D3D devices. This design enables the frame server OS component to support monochrome with minimal memory copying.

Since the introduction of Windows 10 April 2018 Update, and due to changes in the WDDM, it became possible to use the same dual graphics in laptops. For example, it allows you to run programs / games on a more powerful video card, and display the image via the built-in graphics directly on the internal (PCI-E) or external bus, without having to connect the monitor to a powerful video card. It can also act as a solution to the problem if there is no VGA video output on the video card, and it is present on the motherboard.

Windows 10 October 2018 Update (Version 1809) Includes WDDM 2.5.

Updates to Display driver development in Windows 10, version 1809 include the following :

• Raytracing - New Direct3D DDIs were created in parallel of Direct3D APIs, in order to support hardware-accelerated raytracing. Example DDIs include: PFND3D12DDI_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_0054, PFND3D12DDI_COPY_RAYTRACING_ACCELERATION_STRUCTURE_0054. For more info about raytracing, see DirectX Raytracing.
• Universal Driver Requirements - WDDM 2.5 drivers will need to ensure their DirectX11 UMD, DirectX12 UMD, KMDs, and any other DLL loaded by these components, adhere to the Universal API.
• SRV-Only Tiled Resource Tier 3 - In Windows 10, version 1809, Tiled Resource Tier 3 capabilities can be supported less-orthogonally by GPUs. Direct3D12 now supports sparse volume textures without requiring unordered-access and render-target operations. SRV-Only Tiled Resource Tier 3 is a conceptual tier that fits between Tier 2 and Tier 3. Hardware support is optional, just like orthogonal Tiled Resource Tier 3 support currently is. But, supporting SRV-Only Tiled Resource Tier 3 is a super-set tier that requires support for Tiled Resource Tier 2. Drivers that already advertise support for orthogonal Tiled Resource Tier 3 merely have to update their drivers to support the latest “options caps” DDI structure version. The runtime will advertise SRV-Only Tiled Resource Tier 3 support to applications for any hardware that already supports orthogonal Tiled Resource Tier 3.
• Render Pass - The Render Pass feature was added to:
  • Allow new APIs to be run on existing drivers.
  • Allow user mode drivers to choose optimal rendering path without heavy CPU penalty.
• Meta-commands - A Meta-command is Direct3D12 object that represents an IHV-accelerated algorithm. It's an opaque reference to a command generator implemented by the driver. Meta-command updates include Descriptor Table Binding and Texture binding. See D3D12DDI_META_COMMAND_PARAMETER_TYPE and D3D12DDIARG_META_COMMAND_PARAMETER_DESC.
  • Enable Compute Algorithms to use Texture Resources (swizzled memory)
  • Enable Graphics Pipeline Algorithms
• HDR Brightness Compensation - A new SDR brightness boost was introduced to raise the reference white of SDR content to the user-desired value, allowing SDR content to be reproduced to a typical 200-240 nits, which is equivalent to what users have expected for SDR displays. SDR brightness boost affects overall Brightness3 behavior in two ways:
  1. This boost is applied pre-blend only on SDR content. HDR content is not affected. Meanwhile, for most laptop/brightness3 scenarios, users expect all content (SDR and HDR) to be adjusted.
  2. When the Brightness3 stack in the OS is determines the desired nits value, it is not aware of the already applied SDR boost. The driver must then apply a compensation to the desired nits value coming from Brightness3 DDIs for HDR. Since Graphics drivers (and downstream TCON etc.) will be modifying the pixel values of the content to get desired nits value, there should also be a compensation applied to the HDR content metadata as provided by the applications via D3DDDI_HDR_METADATA_HDR10 or OS defaults via DxgkDdiSetTargetAdjustedColorimetry. Since Graphics driver (TCONs) are responsible for modifying the pixel data, it is the driver's responsibility to compensate the HDR content metadata.
• HDR Pixel Format Support - This kernel mode device driver interface (DDI) change is part of WDDM 2.5 to expose new capabilities to be reported by driver/device, providing information regarding the HDR functionality supported by the driver/device. Currently, OS determines if the driver/device supports HDR based on the HighColorSpace bit of the DXGK_MONITORLINKINFO_CAPABILITIES structure as read from DdiUpdateMonitorLinkInfo. The HighColorSpace bit gives a combination of driver/link/monitor capability to run in HDR mode. The HDR capabilities reporting by the driver now includes a Driver/Device level capabilities, which will let OS know if the Driver/Device supports true HDR (i.e. FP16HDR), or only supports a limited form of HDR (i.e. ARGB10HDR), as defined below:
  • FP16HDR: Driver/device can take FP16 pixel format surfaces with scRGB/CCCS colorspace and apply PQ/2084 encoding and BT.2020 primaries during scanout pipeline to convert output signal to HDR10.
  • ARGB10HDR: Driver/device can take ARGB10 pixel format surfaces which are already PQ/2084 encoded and scan out HDR10 signal. Driver/device can't handle FP16HDR as defined above or cannot handle the extended numeric range of scRGB FP16. Graphics drivers can only report support for either FP16HDR or ARGB10HDR as they are not really superset/subset configurations and OS will fail the Start Adapter if both are reported as supported at the same time. See DXGK_MONITORLINKINFO_CAPABILITIES and _DXGK_DISPLAY_DRIVERCAPS_EXTENSION.
• SDR White Level - A kernel mode device driver interface change includes adding new parameters to existing DDIs 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. See _DXGK_COLORIMETRY.

Windows 10 May 2019 Update (Version 1903) includes WDDM 2.6.

• Adding support for Shader Model 6.4

• 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.

• 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.

Tier 1:

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

Tier 2:

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 16x16 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.

Windows 10 May 2020 Update[49] (Version 2004) includes WDDM 2.7.

• Shader Model 6.5[50]

• Hardware-accelerated GPU scheduling: an additional option in the system settings,It allows the video card to directly manage its video memory, which in turn improves the performance of the minimum and average FPS, and thereby reducing latency. It works regardless of the API used for games and applications such as DirectX / Vulkan / OpenGL. Requires a minimum version of shader model 6.3 in hardware from the video card.

• DirectX 12 Sampler Feedback[51]

Sampler Feedback is a Direct3D 12 feature for capturing and recording texture sampling information and locations. Without sampler feedback, these details would be opaque to the developer. This feature gives applications the ability to not just know what mip was sampled, but to know where on those mips. Applications might be interested in sampling information, for example, to:

accurately know what to load next in a texture streaming system, or accurately know what needs to be shaded in a texture-space-shading rendering system. Feedback of sample operations is written to a "feedback map" which acts as a kind of opaque resource which must be transcoded to get application-inspectable information out. As for the writing of feedback itself, there are HLSL constructs in shader model 6_5 for that. The semantics are very similar to the semantics for Texture2D's Sample and its variants.

While sampler feedback makes good use of new shading language constructs, it also involves UMD changes. For device-capability-checking, there's a cap called SamplerFeedbackTier reported through D3D12DDI_D3D12_OPTIONS_DATA_0073. Resource creation has been revised to take a new field, the sampler feedback mip region, of type D3D12DDI_MIP_REGION_0075. Going along with this, there's also a new descriptor-creating method, PFND3D12DDI_CREATE_SAMPLER_FEEDBACK_UNORDERED_ACCESS_VIEW_0075.

• DirectX Raytracing (DXR) Tier 1.1[52]

WDDM 2.7 brings along some new features and improvements which build on the initial release of DXR in Direct3D 12.

Inline raytracing is an alternative form of raytracing that doesn’t use any separate dynamic shaders or shader tables. It gives the developer flexibility and some convenience in all those cases where shaders using DXR 1.0-style raytracing, call them "dynamic-shader-based" raytracing, don't fit. Inline raytracing is available in any shader stage, including compute shaders, pixel shaders, and so forth. This is being mentioned here as something available with WDDM 2.7, although it doesn't correspond to a DDI change.

Applications can call DispatchRays through ExecuteIndirect, allowing raytracing work to be configured on the GPU. This could be useful for applications that seek to cull, sort, or adjust raytracing work and they use shaders for doing that. Going along with this, there is now a D3D12DDI_INDIRECT_ARGUMENT_TYPE enumeration value. When using indirect raytracing dispatch, each element of the execute-indirect buffer is of type D3D12DDIARG_DISPATCH_RAYS_0054.

The overhead of creating pipeline state to account for different shader combinations is one of those difficult problems in 3D computer graphics. DXR 1.1 includes something that can help: add-to-state-object. AddToStateObject(), as it is exposed in the API, allows applications to add shaders to an existing state object with CPU overhead proportional only to what is being added. Going along with this, there are two device DDI functions: PFND3D12DDI_ADD_TO_STATE_OBJECT_0072 and PFND3D12DDI_CALC_PRIVATE_ADD_TO_STATE_OBJECT_SIZE_0072[53].

For general capability-reporting, there's a new enumeration value D3D12DDI_RAYTRACING_TIER_1_1 used for reporting tier 1.1.

• DirectX 12 Mesh Shaders and Amplification Shaders[54]

Mesh shaders are a means of increasing the flexibility and performance of Direct3D 12's graphics pipeline when using rasterization. They act as a new replacement for the input assembler — in particular, vertex and geometry shader stages — replacing some of the input assembler's fixed-function behavior with flexible-function behavior. With mesh shaders, applications can apply culling earlier, and therefore more efficiently, than the input assembler. Primitives can be culled without having their index data processed by the GPU, which is highly beneficial as we see the primitive counts of 3D applications getting higher and higher over time.

In the case that there is a pixel shader attached, the primitives output from a mesh shader will feed directly into the pixel shader stage.

The mesh shader feature introduces the mesh shader stage along with a new stage: the amplification shader. Amplifications shaders replace the GPU tessellation stage. Applications set up their amplification shader to invoke a mesh shader some number of times as needed. Amplification shaders are an optional step which allow an application to dynamically control levels of geometric detail.

The mesh shader feature involves new shading language constructs as well as UMD changes. For reporting device capability of mesh shaders, there's a field called MeshShaderTier reported through D3D12DDI_D3D12_OPTIONS_DATA_0073. And, since this introduces two new shader stages, there are two new fields in D3D12DDIARG_CREATE_PIPELINE_STATE_0075, hMeshShader and hAmplificationShader. To kick things off, there's the command list DDI PFND3D12DDI_DISPATCH_MESH_0074 and also D3D12DDI_INDIRECT_ARGUMENT_TYPE_DISPATCH_MESH for indirect dispatch.

• DirectX 12 improved memory allocation control[55]

• DirectX 12 and Direct3D 9 resource interop[56]

• DirectX 12 Video Protected Resource support[57]

This feature adds optional protected resource support to D3D12 Video operations to WDDM 2.7. Protected resources for Cross-API sharing and Graphics/Compute/Operations was introduced in WDDM 2.4, but these resources were not yet permitted for video operations until now.

Each video operation adds a new capability check with a support flag so drivers can indicate if that operation supports protected resources . Indicating support means that operation can read/write protected resources and supports Cross-API sharing if the resource type supports it. Operation support for protected resources is orthogonal to other operation capabilities with the exception of decode profile and interlace type for decode. Once protected resource support is reported, it must be supported by all the existing non-protected resource capabilities of that operation. For example, if Decode reports protected resource support and reports decode histogram support for a given format, the decoder must support decode histogram for both non-protected and protected resources.

Creation methods are modified to take an optional D3D12DDI_HPROTECTEDRESOURCESESSION instance. Drivers are given this parameter at object creation time to inform setup and allocations. Further, the memory budget checks are revised to indicate whether or not the operation will use protected resources. When the parameter is non-NULL, this indicates that the operation will write to protected resources. To write to an unprotected resource, the operation object must be recreated.

Decoder and motion estimation references must be protected resources when the output is a protected resource. Video processing may read from a combination of protected and unprotected resources when writing to a protected resource.

Before recording one ore more operations that writes to a protected resource, PFND3D12DDI_SETPROTECTEDRESOURCESESSION_0030 must be called with a non-NULL protected resource session. Calling PFND3D12DDI_SETPROTECTEDRESOURCESESSION_0030 with NULL is required before recording one or more operations that write to non-protected resources.

NOTE: Motion Estimation initially shipped with WDDM 2.6 requiring support for Protected Resources, but this was withdrawn late in the release. This feature is reintroducing optional protected resource support for motion estimation.

• Content Protection

Optional protected resource support was added to Direct3D 12 video operations in WDDM 2.7. For background, protected resources existed before WDDM 2.7, but were available only for cross-API sharing and graphics or compute, not video.

Support for protected resources is not reported by the driver as a global thing; it's on a per-operation basis. If a driver reports supporting protected resources for a particular operation, that means that means that operation can read and write protected resources and supports cross-API sharing if the resource type allows for it. Another thing worth mentioning is that if a driver claims protected resource support for a particular format, it must support that format as a non-protected resource too.

With WDDM 2.7, resource creation methods are modified to take an optional D3D12DDI_HPROTECTEDRESOURCESESSION instance. Drivers are given this parameter at object-creation time to inform setup and allocations. Further, the memory budget checks are revised to indicate whether or not the operation will use protected resources. When the protected-resource-session parameter is non-NULL, this indicates that the operation will write to protected resources. To write to an unprotected resource, the operation object must be recreated.

Decoder and motion estimation references must be protected resources when the output is a protected resource. Video processing may read from a combination of protected and unprotected resources when writing to a protected resource.

Before recording one or more operations that writes to a protected resource, PFND3D12DDI_SETPROTECTEDRESOURCESESSION_0030 must be called with a non-NULL protected resource session. Calling PFND3D12DDI_SETPROTECTEDRESOURCESESSION_0030 with NULL is required before recording one or more operations that write to non-protected resources.

To know more beyond the above guided tour of DDI changes for content protection in WDDM 2.7, see D3D12DDI_VIDEO_DECODE_PROTECTED_RESOURCES_DATA_0072 as a starting point.

• Improved History Buffer Reporting for Tools

WDDM 2.7 introduces a DDI change which benefits GPU debugging tools' use of history buffers. With this change, a single command buffer submission can contain work corresponding to multiple command lists rather than just single command lists at a time. This change allows GPU debugging tools to more accurately report applications' performance characteristics.

This capability is reported through D3D12DDICAPS_TYPE_0073_SUPPORT_BATCHED_MARKERS. There is a new D3DDDI_MARKERLOGTYPE of enumeration value D3DDDIMLT_BATCHED, which corresponds to D3DDDI_BATCHEDMARKERDATA. ETW event data structures have been revved to contain some number of D3DDDI_BATCHEDMARKERDATA elements when they are of type D3DDDIMLT_BATCHED.

• DisplayPort (DP) AUX/I2C

The DP Auxiliary (AUX) channel provides access to DP Configuration Data (DPCD), which is a per-device register file used for reading the DP device's capabilities, link training, topology discovery, I2C bus access, and so forth. See DXGK_DP_INTERFACE as a starting point.

Windows 10 21H1 Update includes WDDM 2.9.[58]