Device.Graphics Requirements
Device.Graphics.AdapterBase
The Base feature set required by all graphic devices.
| Related Requirements |
Device.Graphics.AdapterBase.ApplicationVerifier Device.Graphics.AdapterBase.DriverVersion Device.Graphics.AdapterBase.PowerManagementCompliance Device.Graphics.AdapterBase.RegistryEntries Device.Graphics.AdapterBase.SubsystemResettable |
Device.Graphics.AdapterBase.ApplicationVerifier
Graphics driver components comply with Application Verifier test criteria
| Target Feature |
Device.Graphics.AdapterBase |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
All user-mode modules (.dll or .exe files) that are part of a graphics driver must satisfy the test criteria for Application Verifier tests. During testing of the driver Application Verifier must be turned on for processes where the driver modules are executing. Application Verifier will cause a break when an error is detected.For graphics drivers, AppVerifier is required for critical executables (i.e. DWM.exe as an example) used to test stability or robustness of the graphics driver.In addition, Application Verifier must be enabled on IHV's control panel executable as part of this requirementThese Application Verifier tests must be turned on for the processes during testing:
com
exceptions
handles
heaps
inputoutput
leak
locks
memory
rpc
threadpool
tls
hangs
Additional Information
| Business Justification |
WDDM display drivers have user mode components. App Verifier increases robustness of the user mode components by looking for memory corruption, leaks, and general API misuse. This improves overall driver stability and therefore stability of the platform. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterBase.DriverVersion
Driver DLL for graphic adapter or chipset has properly formatted file version
| Target Feature |
Device.Graphics.AdapterBase |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
The file version of the graphic driver DLLs (UMD, KMD) and .SYS files must match each other and must be of the form:
A.BB.CC.DDDD
The A field must be set to 10 for WDDM 1.3 drivers on Windows 8.1.
The A field must be set to 9 for WDDM 1.2 drivers on Windows 8.
The A field must be set to 8 for WDDM 1.1 drivers on Windows 7.
The A field must be set to 7 for WDDM 1.0 drivers on Windows Vista.
The A field must be set to 6 for XDDM drivers on Windows Vista.
For Windows 7 and earlier (WDDM 1.1 and earlier) drivers the BB field must be set to the DDI version that the driver supports:
DirectX 9 drivers (which expose any of the D3DDEVCAPS2_* caps) must set BB equal to 14.
DirectX 10 drivers must set BB equal to 15.
D3D11-DDI driver on D3D10 hardware must set BB equal to 16.
D3D11-DDI driver on D3D11 hardware must set BB equal to 17.
For Windows 8 (WDDM 1.2) drivers the BB field must be set to the highest DirectX Feature Level supported by the driver on the graphics hardware covered by the driver:
A Feature Level 9 driver must set BB equal to 14
A Feature Level 10 driver must set BB equal to 15
A Feature Level 11 driver must set BB equal to 17
A Feature Level 11_1 driver must set BB equal to 18
The CC field can be equal to any value between 01 and 99.
The DDDD field can be set to any numerical value between 0 and 9999.
For example:
Windows Vista DirectX 9.0-compatible WDDM drivers can use the range 7.14.01.0000 to 7.14.99.9999
Windows 7 DirectX 10.0-compatible WDDM 1.1 drivers can use the range 8.15.01.0000 to 8.15.99.9999
Windows 8 WDDM 1.2 driver on DX10 hardware would be 9.15.99.9999
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterBase.PowerManagementCompliance
Graphics adapter complies with VESA and ACPI power management specifications to enable system sleep
| Target Feature |
Device.Graphics.AdapterBase |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
To ensure correct implementation of operating system-controlled power management, graphic adapters and their drivers must respond to:
Required device (D0 and D3) power states as highlighted in the WDK
Operating system power management for ACPI power states
*VESA BIOS Power Management Functions, which defines extensions to VGA ROM BIOS services for power management. (*This line does not apply to UEFI GOP based platforms)
Additional Information
| Business Justification |
The graphics adapter must comply with the above specification to enable system sleep transitions such as Standby and Hibernate. This results in power savings when the system is not in use. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterBase.RegistryEntries
Device driver install applications for a graphics device create required registry entries
| Target Feature |
Device.Graphics.AdapterBase |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
The following registry entries must be created during video driver installation:
REG_BINARY: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\PART_GUID\ID\InstalledDisplayDrivers: This key should contain the User-mode driver name.
REG_BINARY: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\PART_GUID\ID\HardwareInformation.MemorySize
The below Hardware Information values are written by WDDM driver:
REG_BINARY: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\PART_GUID\ID\HardwareInformation.ChipType
REG_BINARY: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\PART_GUID\ID\HardwareInformation.DACType
REG_BINARY: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\PART_GUID\ID\HardwareInformation.AdapterString
REG_BINARY: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\PART_GUID\ID\HardwareInformation.BiosString
REG_BINARY: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\PART_GUID\ID\HardwareInformation.MemorySize
The following INF directives must be included in the INF:
Feature Score - This is a General Installation setting that must be supported by all WDDM drivers.
Copy Flags to Support PNP Stop directive
Driver\Services Start Type directive
Capability Override settings to disable OpenGL
[Version] section directives
[SourceDiskNames] section directives
General x64 directives
General [Install] section directives
The Driver DLL must have a properly formatted file version as defined in the requirement Device.Graphics.AdapterBase.DriverVersion
Additional Information
| Business Justification |
Several Windows components and 3rd party applications rely on the information being surfaced through the above registry keys which are written by the installation application or by the WDDM driver. Missing or incorrect information could result in application compatibility problems or wrong OS behavior. Examples:The HardwareInformation values are used by the "Advanced Settings" tab in the Display Control Panel The FeatureScore INF key is used for driver ranking and installation The InstalledDisplayDrivers registry key is used by WHQL tests For additional details on the above registry keys and their description, please refer to the "Installing Display Miniport and User-Mode Display Drivers" in the Windows Driver Kit (WDK) on MSDN . |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterBase.SubsystemResettable
A graphics subsystem must be resettable to a normal operational state
| Target Feature |
Device.Graphics.AdapterBase |
| Applies to |
Windows 7 Client x86, x64 Windows Server 2008 Release 2 x64 |
Description
(2008-12-5 Update: Reworded and clarified requirement based on feedback.)If the GPU is hung for any reason, independent of what the hardware is processing at the time, it must be resettable to a normal operational state. This basically implies that TDR must be supported by any GPU. Hybrid system should be able to handle TDR just like non-hybrid system and have mechanism to reset either (or both) the GPU to bring the system back to a functioning state when the operating system detects a hang.Design Notes:The ability to reset the GPU is independent of the current working state of the system. See the Windows Driver Kit, Jun. 26, 2013 topic.
Additional Information
| Business Justification |
This feature will allow us to recover from faults in the display hardware, resulting is a better user experience. If we do not implement this feature, more blue screens will result. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender
The Render feature of a Graphic Device.
| Related Requirements |
Device.Graphics.AdapterRender.MinimumDirectXLevel Device.Graphics.AdapterRender.RGBFrameBuffer Device.Graphics.AdapterRender.YUVSupport |
Device.Graphics.AdapterRender.MinimumDirectXLevel
Graphics Adapter implements minimum hardware acceleration capabilities
| Target Feature |
Device.Graphics.AdapterRender |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
The Display subsystem is required to implement the DirectX 9 hardware specification and the driver is required to expose through the D3D9 UMD DDI the capabilities of Direct3D 10 Feature Level 9_3 as described in MSDN here:
https://msdn.microsoft.com/library/ff476876(v=VS.85).aspx
https://msdn.microsoft.com/library/ff476150.aspx
https://msdn.microsoft.com/library/ff476149.aspx
https://msdn.microsoft.com/library/ff471324(v=VS.85).aspx
Additional Information
| Business Justification |
Windows 8 will leverage a modern graphics stack that supports HLSL programmability. Shader Model 3.0 was introduced at the tail end of the Windows XP lifecycle. It has garnered broad adoption and is used ubiquitously across the PC, XBOX console and Windows Phone. To support the modern graphics stack and the benefits it provides to key applications like Internet Explorer, Windows Live and Microsoft Office, all Windows hardware on any form factor is required to support D3D9 with capabilities corresponding to Direct3D 10 Feature Level 9_3. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.RGBFrameBuffer
Display chipset implements specified component order and endian representation for 8-bpp or greater integer RGB frame buffer formats
| Target Feature |
Device.Graphics.AdapterRender |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
For an N-bit-per-component RGB frame buffer format, the lowest N bits must contain the blue component, the next N bits must contain the green component, the next N bits must contain the red component, and the remaining 32-(3 x N) bits may contain alpha. The resulting 32-bit value must be stored in memory in little-endian format.
Additional Information
| Business Justification |
For basic failure modes, the OS will address the graphics device as a linear framebuffer. To correctly display colors in this mode, and agreed upon ordering of bytes is required. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.YUVSupport
Display driver that supports YUV textures can process textures and functions correctly
| Target Feature |
Device.Graphics.AdapterRender |
| Applies to |
Windows 7 Client x86, x64 Windows Server 2008 Release 2 x64 |
Description
If the hardware supports YUV texture surfaces and the capability is reported, then the driver must be able to process these surfaces without any intermediate transforms and function correctly. Design Notes:It should be assumed that the YUV data is in the BT.601 color space unless the YUV texture is greater than 576 height in which case it is in the BT.709 color space, and the appropriate color space conversion matrices should be used when reading the texture.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D101Core
D3D 10.1 core feature
| Related Requirements |
Device.Graphics.AdapterRender.D3D101Core.D3D101CorePrimary |
Device.Graphics.AdapterRender.D3D101Core.D3D101CorePrimary
If Graphics Device supports Direct3D 10.1, it must comply with the Direct3D 10.1 and DXGI Specifications
| Target Feature |
Device.Graphics.AdapterRender.D3D101Core |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
If the graphics devices implements Direct3D 10.1 it must meet all requirements defined in the Direct3D 10.1 specification and must provide sufficient performance for Direct3D 10.1 features.
Since Direct3D 10.1 is a superset of Direct3D 10, implementation of Direct3D 10.1 also requires support of Direct3D 10 feature set.
All features required by this specification must be exposed by the device driver including those features defined for the DXGI DDI header.
Design Notes:
Sufficient performance is described in requirement System.Fundamentals.Graphics.DisplayRender.Performance
Additional Information
| Business Justification |
D3D10.1 was an update to the D3D10 specification initially supported in Windows Vista SP1. It provides BGRA format support to allow applications better performance and interoperability with mixed mode GDI and D3D applications. It further enhances the Anti-aliasing capabilities of the D3D10 specifications. D3D10 and by extension D3D10.1 is a tightly defined platform which Windows continues to leverage for consistent, performant, hardware accelerated graphical experiences. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D101WDDM11
D3D 10.1 core feature with WDDM 1.1 additions
| Related Requirements |
Device.Graphics.AdapterRender.D3D101WDDM11.D3D101v11Primary |
Device.Graphics.AdapterRender.D3D101WDDM11.D3D101v11Primary
If WDDM 1.1 Graphics Device supports Direct3D 10.1, it must comply with the Direct3D 10.1 and DXGI Specifications and support BGRA
| Target Feature |
Device.Graphics.AdapterRender.D3D101WDDM11 |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
If the graphics hardware implements Direct3D 10.1 it must meet all requirements defined in the Direct3D 10.1 specification and must provide sufficient performance for Direct3D 10.1 features.
Since Direct3D 10.1 is a superset of Direct3D 10, implementation of Direct3D 10.1 also requires support of Direct3D 10 feature set. Additionally the following features originally defined in the D3D9 Hardware specification are now required:
BGRA
All features required by this specification must be exposed by the device driver including those features defined for the DXGI DDI header. Design Notes: Sufficient performance is described in requirement System.Fundamentals.Graphics.DisplayRender.Performance.
Additional Information
| Business Justification |
D3D10.1 was an update to the D3D10 specification initially supported in Windows Vista SP1. It provides BGRA format support to allow applications better performance and interoperability with mixed mode GDI and D3D applications. It further enhances the Anti-aliasing capabilities of the D3D10 specifications. D3D10 and by extension D3D10.1 is a tightly defined platform which Windows continues to leverage for consistent, performant, hardware accelerated graphical experiences. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D101WDDM12
D3D 10.1 core feature with WDDM 1.2 additions
| Related Requirements |
Device.Graphics.AdapterRender.D3D101WDDM12.D3D101v12Primary |
Device.Graphics.AdapterRender.D3D101WDDM12.D3D101v12Primary
If WDDM 1.2 Graphics Device supports Direct3D 10.1, it must comply with the Direct3D 10.1, DXGI and D3D10 portion of the Direct3D 11.1 Feature Specifications
| Target Feature |
Device.Graphics.AdapterRender.D3D101WDDM12 |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
If the graphics hardware implements Direct3D 10.1 it must meet all requirements defined in the Direct3D 10.1 specification and must provide sufficient performance for Direct3D 10.1 features.
Since Direct3D 10.1 is a superset of Direct3D 10, implementation of Direct3D 10.1 also requires support of Direct3D 10 feature set. Additionally the following features originally defined in the D3D9 Hardware specification are now required:
BGRA
Half Precision pixel formats (5551, 565, 4444)
Same Surface Blts
Please see the Direct3D 11.1 Features Spec for complete details of all new features required to be exposed with a WDDM 1.2 driver for D3D10+ hardware.
All features required by this specification must be exposed by the device driver including those features defined for the DXGI DDI header. Design Notes:Sufficient performance is described in requirement System.Fundamentals.Graphics.DisplayRender.Performance
Additional Information
| Business Justification |
D3D10.1 was an update to the D3D10 specification initially supported in Windows Vista SP1. It provides BGRA format support to allow applications better performance and interoperability with mixed mode GDI and D3D applications. It further enhances the Anti-aliasing capabilities of the D3D10 specifications. D3D10 and by extension D3D10.1 is a tightly defined platform which Windows continues to leverage for consistent, performant, hardware accelerated graphical experiences. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D10ComputeShader
D3D10* Shader Model 4_* Compute Shader Functionality
| Related Requirements |
Device.Graphics.AdapterRender.D3D10ComputeShader.D3D10CoreC |
Device.Graphics.AdapterRender.D3D10ComputeShader.D3D10CoreC
If graphic hardware implements D3D10* Shader Model 4_* Compute Shader Functionality it must conform to the D3D11 hardware specifications
| Target Feature |
Device.Graphics.AdapterRender.D3D10ComputeShader |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
The D3D11 Specification allows for optionally implementing Shader Model 4_* Compute Shader functionality on D3D10* hardware. If the hardware includes support for and the driver exposes this functionality it must conform to the specifications for this feature as defined in the D3D11 Hardware Specification.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D10Core
D3D 10 core feature
| Related Requirements |
Device.Graphics.AdapterRender.D3D10Core.D3D10CorePrimary |
Device.Graphics.AdapterRender.D3D10Core.D3D10CorePrimary
If Graphics Devices supports Direct3D 10, it must comply with the Direct3D 10 and DXGI specifications
| Target Feature |
Device.Graphics.AdapterRender.D3D10Core |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
If the graphic hardware implements Direct3D 10 it must meet all requirements defined in the Direct3D 10 specification and must provide sufficient performance for Direct3D 10 features. All features required by this specification must be exposed by the device driver including those features defined for the DXGI DDI header. The following list includes some of the required features called out in the Direct3D 10 specification:
Geometry shader
Stream output
Integer instruction set
New compressed formats
Render to vertex buffer
Render to cube map
Render to volume
Design Notes:Sufficient performance is described in requirement System.Fundamentals.Graphics.DisplayRender.Performance
Additional Information
| Business Justification |
D3D10 was designed to be the baseline graphics hardware requirement for Windows Vista. The primary motivation for this baseline was the desire to present developers with a cleaner API that delivers several key values. Innovation: New features like Geometry shader and Stream Output satisfy the large appetite for graphics technology innovation in the PC ecosystem. Since graphics is a significant area of differentiation for platforms, form factors and applications, Windows must continue to be a leader in this area. Cleaner API: Improved syntax and generalized structure so developing graphics applications is easier Improved performance: Direct3D 10 includes several innovations that deliver better performance Improved Quality: Due to a more strict specification (e.g. rasterization, floating point), testing and certification is more reliable and required less investment in special cases. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D10D3D11LogicOps
D3D10-D3D11 Logic Ops
| Related Requirements |
Device.Graphics.AdapterRender.D3D10D3D11LogicOps.D3D10CoreD |
Device.Graphics.AdapterRender.D3D10D3D11LogicOps.D3D10CoreD
If graphic hardware implements Logic Ops functionality it must conform to the D3D11 hardware specifications
| Target Feature |
Device.Graphics.AdapterRender.D3D10D3D11LogicOps |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
The D3D11.1 Specification allows for optionally implementing Logic Ops functionality on D3D10, D3D10.1 and D3D11 hardware. If the hardware supports and exposes support for this functionality it must conform to the specifications for this feature as defined in the D3D11.1 Hardware Specification.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D10Multisampling4X
D3D10 Multisampling (4X)
| Related Requirements |
Device.Graphics.AdapterRender.D3D10Multisampling4X.D3D10CoreA |
Device.Graphics.AdapterRender.D3D10Multisampling4X.D3D10CoreA
If graphic hardware implements D3D10 4x Multisampling it must conform to the D3D10 hardware specifications
| Target Feature |
Device.Graphics.AdapterRender.D3D10Multisampling4X |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
The D3D10 Specification allows for optionally implementing 4X Multisampling. If the hardware includes support for and the driver exposes this functionality it must conform to the specifications for this feature as defined in the D3D10 Hardware Specification.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D10Multisampling8X
D3D10* Multisampling (8X)
| Related Requirements |
Device.Graphics.AdapterRender.D3D10Multisampling8X.D3D10CoreB |
Device.Graphics.AdapterRender.D3D10Multisampling8X.D3D10CoreB
If graphic hardware implements D3D10* 8X Multisampling then it must conform to the D3D10 hardware specifications.
| Target Feature |
Device.Graphics.AdapterRender.D3D10Multisampling8X |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
The D3D10 Specification allows for optionally implementing 8X Multisampling. If the hardware includes support for and the driver exposes this functionality it must conform to the specifications for this feature as defined in the D3D10 Hardware Specification.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D10WDDM11
D3D 10 core feature with WDDM 1.1 additions
| Related Requirements |
Device.Graphics.AdapterRender.D3D10WDDM11.D3D10v11Primary |
Device.Graphics.AdapterRender.D3D10WDDM11.D3D10v11Primary
If the graphic hardware implements Direct3D 10 and the driver is WDDM1.1, it must comply with the Direct3D 10 and DXGI Specifications and support BGRA
| Target Feature |
Device.Graphics.AdapterRender.D3D10WDDM11 |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
If the graphic hardware implements Direct3D 10 and the driver is WDDM1.1, it must meet all requirements defined in the Direct3D 10 specification and must provide sufficient performance for Direct3D 10 features. Additionally the following features originally defined in the D3D9 Hardware specification are now required:
BGRA
All features required by this specification must be exposed by the device driver including those features defined for the DXGI DDI header. The following list includes some of the required features called out in the Direct3D 10 specification:
Geometry shader
Stream output
Integer instruction set
New compressed formats
Render to vertex buffer
Render to cube map
Render to volume
Design Notes:Sufficient performance is described in requirement System.Fundamentals.Graphics.DisplayRender.Performance
Additional Information
| Business Justification |
D3D10 was designed to be the baseline graphics hardware requirement for Windows Vista. The primary motivation for this baseline was the desire to present developers with a cleaner API that delivers several key values. Innovation: New features like Geometry shader and Stream Output satisfy the large appetite for graphics technology innovation in the PC ecosystem. Since graphics is a significant area of differentiation for platforms, form factors and applications, Windows must continue to be a leader in this area. Cleaner API: Improved syntax and generalized structure so developing graphics applications is easier Improved performance: Direct3D 10 includes several innovations that deliver better performance Improved Quality: Due to a more strict specification (e.g. rasterization, floating point), testing and certification is more reliable and required less investment in special cases. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D10WDDM12
D3D 10 core feature with WDDM 1.2 additions
| Related Requirements |
Device.Graphics.AdapterRender.D3D10WDDM12.D3D10v12Primary Device.Graphics.AdapterRender.D3D10WDDM12.Stereoscopic3DArraySupport |
Device.Graphics.AdapterRender.D3D10WDDM12.D3D10v12Primary
If the graphics hardware implements Direct3D 10 and the Driver is WDDM1.2, it must comply with the Direct3D 10, DXGI and the D3D10 additions in the Direct3D 11.1 Feature Specifications
| Target Feature |
Device.Graphics.AdapterRender.D3D10WDDM12 |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
If the graphic hardware implements Direct3D 10 and the driver is WDDM1.2 it must meet all requirements defined in the Direct3D 10 specification and must provide sufficient performance for Direct3D 10 features. Additionally the following features originally defined in the D3D9 Hardware specification are now required:
BGRA
Half Precision pixel formats (5551, 565, 4444)
Same Surface Blts
Please see the Direct3D 11.1 Features Spec for complete details of all new features required to be exposed with a WDDM 1.2 driver for D3D10+ hardware.All features required by this specification must be exposed by the device driver including those features defined for the DXGI DDI header. The following list includes some of the required features called out in the Direct3D 10 specification:
Geometry shader
Stream output
Integer instruction set
New compressed formats
Render to vertex buffer
Render to cube map
Render to volume
Design Notes:Sufficient performance is described in requirement System.Fundamentals.Graphics.DisplayRender.Performance
Additional Information
| Business Justification |
D3D10 was designed to be the baseline graphics hardware requirement for Windows Vista. The primary motivation for this baseline was the desire to present developers with a cleaner API that delivers several key values. Innovation: New features like Geometry shader and Stream Output satisfy the large appetite for graphics technology innovation in the PC ecosystem. Since graphics is a significant area of differentiation for platforms, form factors and applications, Windows must continue to be a leader in this area. Cleaner API: Improved syntax and generalized structure so developing graphics applications is easier Improved performance: Direct3D 10 includes several innovations that deliver better performance Improved Quality: Due to a more strict specification (e.g. rasterization, floating point), testing and certification is more reliable and required less investment in special cases. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D10WDDM12.Stereoscopic3DArraySupport
WDDM1.2 drivers must support Stereoscopic 3D in D3D by adding expanded array support.
| Target Feature |
Device.Graphics.AdapterRender.D3D10WDDM12 |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
New support required by WDDM 1.2
| DDI or feature |
WDDM 1.1 |
WDDM 1.2 |
| Creation of backbuffers (and primaries) using D3D10DDIARG_CREATERESOURCE & D3D11DDIARG_CREATERESOURCE |
Restricted to ArraySize = 1 |
Generalized to ArraySize = 2 |
| DXGI UM backbuffer DDIs (DXGI_DDI_ARG_BLT, DXGI_DDI_ARG_ROTATE_RESOURCE_IDENTITIES, DXGI_DDI_ARG_PRESENT, DXGI_DDI_ARG_SETDISPLAYMODE) |
Restricted to backbuffers |
Same, but including stereo back buffers |
| Presentation in general (kernel and user) |
Restricted to backbuffers |
Same, but including stereo back buffers |
| Sharing |
Restricted to ArraySize = 1 |
Generalized to any ArraySize (including > 2) |
| GDI interop |
Restricted to ArraySize = 1 |
Generalized to any ArraySize (including > 2) |
| HLSL non-arrayed sampler declarations |
Restricted to ArraySize = 1 |
Generalized to any ArraySize (including > 2) |
HLSL non-arrayed sampler declarations indicates allowing certain shaders that sample from single-subresource-resources currently to also sample from single-subresource-views of resources with multiple subresources. Note that drivers must support extended array for Stereo 3D APIs but for fullscreen exclusive Stereo 3D apps to display, the driver should also support Stereo scanout on the output. For example in a multi-adapter system with two WDDM 1.2 graphics adapters either adapter may be used to create a stereo windowed swapchain, even if only one of the adapters actually supports stereo output. Background infoThe following table shows how in Windows 7 / WDDM 1.1 there was a simple sequence of nested classes of resources and some of the DDIs that only applied to specific subsets.
| Type of resource (general to specific) |
DDIs that only apply to specific resources |
| D3D Texture2D resources |
|
| D3D Texture2D resources with ArraySize <= 2 |
|
| D3D Texture2D resources with ArraySize == 1 |
Sharing, GDI interop |
| Backbuffers |
DXGI_DDI_ARG_BLT, etc. |
| Primaries |
Specific presentation operations |
WDDM 1.2 generalizes backbuffers (and primaries) to include stereo pairs (ArraySize = 2; while WDDM1.2 backbuffers and primaries are resources with ArraySize =1) All DDIs that are specific to backbuffers are implicitly and explicitly generalized to support these new stereo backbuffers (e.g. DXGI_DDI_ARG_BLT). Some features that are implicitly used by swapchains (e.g. sharing) and that had been limited to only ArraySize=1 textures are generalized to support resources with any ArraySize. GDI interop is also extended to support resources with any ArraySize. GDI interop isn't strictly necessary for stereo support but is included to meet the goal of making it easy to port mono applications to support stereo. (The decision to support general ArraySize and not just 1 or 2 for shared resources and GDI interop was based on the judgment that further special casing here would not be best for the API.)
Additional Information
| Business Justification |
This requirement is necessary for a good quality of experience for running Stereo applications in Windows 8. Windows will switch to "Stereo" mode when the user launches a Stereo application. Having a stereo resolution equivalent to the native resolution in mono mode will ensure that there is no mode change failure when the user launches a windowed mode or full-screen Stereo application. If the Stereo 3D Display does not support a Stereo equivalent of the native resolution, then the user will be unable to run the stereo application unless a different resolution is selected manually from the "Screen Resolution" display applet. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D111Core
D3D 11.1 core feature
| Related Requirements |
Device.Graphics.AdapterRender.D3D111Core.D3D111CorePrimary |
Device.Graphics.AdapterRender.D3D111Core.D3D111CorePrimary
If Graphics Device supports Direct3D 11.1, it must comply with the Direct3D 11.1 and DXGI Specifications
| Target Feature |
Device.Graphics.AdapterRender.D3D111Core |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
A graphics device must meet all requirements defined in the Direct3D 11.1 specification and must provide sufficient performance for Direct3D 11.1 features.
Direct3D 11.1 is a superset of Direct3D 11, (which is a strict superset of Direct3D 10.1 and Direct3D 10) therefore implementation of Direct3D 11.1 also requires full support for the features defined by the Direct3D 10, Direct3D 10.1 and Direct3D 11 specifications respectively.
All features required by this specification must be exposed by the device driver including those features defined for the DXGI DDI header. Design Notes:Sufficient performance is described in requirement System.Fundamentals.Graphics.DisplayRender.Performance
Additional Information
| Business Justification |
D3D11.1 is a update to D3D11 delivering a few key features like:Logic OpsHalf Precision pixel formats (5551, 565, 4444)Same Surface BltsUAVs at every stageUAV-Multi-sample AntialiasingTarget Independent Rasterization (TIR)New shader instructions The features are focused primarily around enabling a modern hardware accelerated graphics stack for Windows 8 and enabling performance across a wider range variety of hardware architectures and price points. D3D11.1 is a tightly defined platform from which Windows continues to leverage for consistent, performant, hardware accelerated graphical experiences. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D11Core
D3D 11 core feature
| Related Requirements |
Device.Graphics.AdapterRender.D3D11Core.D3D11CorePrimary |
Device.Graphics.AdapterRender.D3D11Core.D3D11CorePrimary
If Graphics Device implements Direct3D 11, it must comply with the Direct3D 11 and DXGI Specifications
| Target Feature |
Device.Graphics.AdapterRender.D3D11Core |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
If a graphics device implements Direct3D 11, it must meet all requirements defined in the Direct3D 11 specification and must provide sufficient performance for Direct3D 11 features.Since Direct3D 11 is a superset of Direct3D 10, implementation of Direct3D 11 also requires support of Direct3D 10.1 feature set and by extension Direct3D 10. All features required by this specification must be exposed by the device driver including those features defined for the DXGI DDI header.Design Notes:Sufficient performance is described in requirement System.Fundamentals.Graphics.DisplayRender.Performance
Additional Information
| Business Justification |
D3D11 was introduced with the release of Windows7. It was developed to push the envelope of graphics hardware capabilities that strive to achieve near photo realism in a real time rendering system. At the time of its release the graphics industry entered a new era where graphics hardware was utilized for general purpose computation in massively parallel scenarios. PCs that wish to be considered "top of the line" devices could derive significant value by integrating D3D11 graphics hardware. D3D11 hardware would be expected in high-end gaming and media devices. The key features of D3D11 include: Innovation: Direct3D pushes the quality and performance bar of the graphics ecosystem with key technologies like tessellation, multithreading, dynamic shader linking, and improved texture compression formats. General Purpose Computing on GPUs: After years of innovation, programmability and parallel performance advancements in the graphics pipeline lend themselves well to DirectCompute - a means of utilizing the massive computational power of GPUs for general purposes (e.g. technical computing) Platform Continuity: Direct3D11 is a strict superset of D3D10 and D3D10.1 so investments made on those platforms translate well to D3D11 as well |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D11DoublePrecisionShader
D3D11* Double Precision Shader Functionality
| Related Requirements |
Device.Graphics.AdapterRender.D3D11DoublePrecisionShader.D3D11CoreC |
Device.Graphics.AdapterRender.D3D11DoublePrecisionShader.D3D11CoreC
If graphic hardware implements D3D11* Double Precision it must conform to the feature specification as outlined in the D3D11 hardware specification
| Target Feature |
Device.Graphics.AdapterRender.D3D11DoublePrecisionShader |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
The D3D11 Specification allows for optionally implementing Double Precision Shader functionality on D3D11* hardware. If the hardware includes support for and the driver exposes this functionality it must conform to the specifications for this feature as defined in the D3D11 Hardware Specification.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D11DriverCommandLists
D3D11* Driver Command Lists
| Related Requirements |
Device.Graphics.AdapterRender.D3D11DriverCommandLists.D3D11CoreB |
Device.Graphics.AdapterRender.D3D11DriverCommandLists.D3D11CoreB
If graphics hardware implements the D3D11* driver command list it must conform to the feature specification as defined in the D3D11 hardware specification
| Target Feature |
Device.Graphics.AdapterRender.D3D11DriverCommandLists |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
[Error] - Look for file C:\WinCertMSDB\Docs\Device.Graphics.AdapterRender.D3D11DriverCommandLists.D3D11CoreB.docx
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D11DriverConcurrentObjectCreation
D3D11* Driver Concurrent Object Creation
| Related Requirements |
Device.Graphics.AdapterRender.D3D11DriverConcurrentObjectCreation.D3D11CoreA |
Device.Graphics.AdapterRender.D3D11DriverConcurrentObjectCreation.D3D11CoreA
If graphics hardware implements the D3D11* Driver Concurrent Object Creation it must conform to the feature specification as defined in the D3D11 hardware specification
| Target Feature |
Device.Graphics.AdapterRender.D3D11DriverConcurrentObjectCreation |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
The D3D11 Specification allows for optionally implementing Driver Concurrent Object creation functionality on D3D11* hardware. If the hardware includes support for and the driver exposes this functionality it must conform to the specifications for this feature as defined in the D3D11 Hardware Specification.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D11Level9WDDM12
The Windows 8 WDDM 1.2 Updates to the D3D9 UM DDI
| Related Requirements |
Device.Graphics.AdapterRender.D3D11Level9WDDM12.D3D9UMDDIUpdate |
Device.Graphics.AdapterRender.D3D11Level9WDDM12.D3D9UMDDIUpdate
If the graphics hardware driver implements the WDDM1.2 specification it must include the D3D9 User Mode DDI additions as defined by the D3D11.1 API/DDI Specification
| Target Feature |
Device.Graphics.AdapterRender.D3D11Level9WDDM12 |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
A WDDM 1.2 graphics driver is required to implement the D3D9 Adapter DDI and D3D9 DDI additions as defined in the D3D11.1 API/DDI specification in addition to the D3D9 DDI as defined by the DirectX 9 hardware and driver specifications.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D11Level9WDDM13
Windows 8.1 WDDM1.3 updates to the D3D9 UM DDI
| Related Requirements |
Device.Graphics.AdapterRender.D3D11Level9WDDM13.LargeCaptureTextures Device.Graphics.AdapterRender.D3D11Level9WDDM13.Level9Instancing Device.Graphics.AdapterRender.D3D11Level9WDDM13.NativeStagingBuffers Device.Graphics.AdapterRender.D3D11Level9WDDM13.NativeUpdateSubresource Device.Graphics.AdapterRender.D3D11Level9WDDM13.TimestampCounterSupport |
Device.Graphics.AdapterRender.D3D11Level9WDDM13.LargeCaptureTextures
Direct3D Large Capture Textures
| Target Feature |
Device.Graphics.AdapterRender.D3D11Level9WDDM13 |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
All 9 UMDs, regardless of maximum feature level of hardware, must now properly validate the texture size parameters being passed to CreateResource2.
Graphics drivers must now gracefully fail (by returning a E_INVALIDARG) CAPTURE texture create requests that exceed the capabilities of the hardware.
Any CAPTURE textures that are approved for creation must behave identical to CAPTURE textures as they are defined.
Additional Information
| Business Justification |
Capture Textures are used to store the output of integrated cameras on tablet/laptop systems. Upcoming systems may have cameras which exceed the nominal texture size restrictions in Direct3D. This feature is necessary to allow these cameras to capture images at full resolution. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D11Level9WDDM13.Level9Instancing
Level 9 Instancing
| Target Feature |
Device.Graphics.AdapterRender.D3D11Level9WDDM13 |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
In Windows 8.1, the OS will be making increased use of D3D Instancing to reduce CPU/GPU usage. All WDDM1.3 drivers must support Instancing as described in the Feature Level 9_3.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D11Level9WDDM13.NativeStagingBuffers
Level9 Native Staging Buffer Performance Validation
| Target Feature |
Device.Graphics.AdapterRender.D3D11Level9WDDM13 |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
Directx9 level graphic hardware implementing WDDM1.3 must support the D3D9 Native Staging buffers DDI
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D11Level9WDDM13.NativeUpdateSubresource
Direct3D Level9 Native UpdateSubresource
| Target Feature |
Device.Graphics.AdapterRender.D3D11Level9WDDM13 |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
For Windows 8.1 the Direct3D9 DDI spec will include native support for the UpdateSubresource DDI. When D3D9-level parts implement this DDI, the UpdateSubresource API calls for a given amount of memory must be executed no slower than a CPU copy operation.
Additional Information
| Business Justification |
The UpdateSubresource API is used in several performance-intensive scenarios, such as video processing and UI rendering. Introducing this function as a native DDI improves the performance of this API significantly on 9-level parts. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D11Level9WDDM13.TimestampCounterSupport
Direct3D Level9 Timestamps and Counters
| Target Feature |
Device.Graphics.AdapterRender.D3D11Level9WDDM13 |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
Timestamp Query support will be made mandatory for all 9-level WDDM 1.3 drivers, specifically these Query types:
a.D3DDDIQUERYTYPE_TIMESTAMP
b.D3DDDIQUERYTYPE_TIMESTAMPDISJOINT
c.D3DDDIQUERYTYPE_TIMESTAMPFREQ
Additionally the CheckDounter and CheckCounterInfo Direct3D11 Counter DDIs must be supported.
Additional Information
| Business Justification |
Timestamp queries and Counters are important ways for apps and performance profilers to better understand the performance characteristics of an app. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D11PartialPrecision
D3D11 Partial Precision shader support
| Related Requirements |
Device.Graphics.AdapterRender.D3D11PartialPrecision.D3D11CoreE |
Device.Graphics.AdapterRender.D3D11PartialPrecision.D3D11CoreE
If graphic hardware implements the D3D11.1 Partial Precision Shader Functionality it must conform to the feature specification as defined in the D3D11.1 hardware specification
| Target Feature |
Device.Graphics.AdapterRender.D3D11PartialPrecision |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
The D3D11.1 Specification allows for optionally implementing Partial Precision Shader functionality on D3D9, D3D10* and D3D11* hardware with a WDDM 1.2 driver. If the hardware includes support for and the driver exposes this functionality it must conform to the specifications for this feature as defined in the D3D11.1 Hardware Specification.
Additional Information
| Business Justification |
This requirement is necessary to ensure consistency of this feature across multiple implementations, and provide Application developers a robust platform for application development and deployment on the Windows platform. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D11WDDM12
D3D 11 core feature with WDDM 1.2 additions
| Related Requirements |
Device.Graphics.AdapterRender.D3D11WDDM12.D3D11v12Primary |
Device.Graphics.AdapterRender.D3D11WDDM12.D3D11v12Primary
If WDDM 1.2 Graphics Device implements Direct3D 11, it must comply with the Direct3D 11, DXGI and the D3D10 portion of the Direct3D 11.1 Features Specification
| Target Feature |
Device.Graphics.AdapterRender.D3D11WDDM12 |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
If a graphics device implements Direct3D 11, it must meet all requirements defined in the Direct3D 11 specification and must provide sufficient performance for Direct3D 11 features.Since Direct3D 11 is a superset of Direct3D 10, implementation of Direct3D 11 also requires support of Direct3D 10.1 feature set and by extension Direct3D 10. In Windows 8 the following features originally defined in the D3D9 Hardware specification are now also required:
Half Precision pixel formats (5551, 565, 4444)
Same Surface Blts
Please see the Direct3D 11.1 Features Spec for complete details of all new features required to be exposed with a WDDM 1.2 driver for D3D10+ hardware.All features required by this specification must be exposed by the device driver including those features defined for the DXGI DDI header. Design Notes:Sufficient performance is described in requirement System.Fundamentals.Graphics.DisplayRender.Performance
Additional Information
| Business Justification |
D3D11 was introduced with the release of Windows7. It was developed to push the envelope of graphics hardware capabilities that strive to achieve near photo realism in a real time rendering system. At the time of its release the graphics industry entered a new era where graphics hardware was utilized for general purpose computation in massively parallel scenarios. PCs that wish to be considered "top of the line" devices could derive significant value by integrating D3D11 graphics hardware. D3D11 hardware would be expected in high-end gaming and media devices. The key features of D3D11 include: Innovation: Direct3D pushes the quality and performance bar of the graphics ecosystem with key technologies like tessellation, multithreading, dynamic shader linking, and improved texture compression formats. General Purpose Computing on GPUs: After years of innovation, programmability and parallel performance advancements in the graphics pipeline lend themselves well to DirectCompute - a means of utilizing the massive computational power of GPUs for general purposes (e.g. technical computing) Platform Continuity: Direct3D11 is a strict superset of D3D10 and D3D10.1 so investments made on those platforms translate well to D3D11 as well |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D11WDDM12DoublePrecisionShader
D3D11* Double Precision Shader Functionality with additional ops codes introduced with WDDM 1.2
| Related Requirements |
Device.Graphics.AdapterRender.D3D11WDDM12DoublePrecisionShader.D3D11v12C |
Device.Graphics.AdapterRender.D3D11WDDM12DoublePrecisionShader.D3D11v12C
If graphic hardware implements the D3D11* Double Precision Shader Functionality with WDDM 1.2 driver additions it must conform to the feature specifications as defined in the D3D11 hardware specification
| Target Feature |
Device.Graphics.AdapterRender.D3D11WDDM12DoublePrecisionShader |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
The D3D11 Specification allows for optionally implementing Double Precision Shader functionality on D3D11* hardware. If the hardware includes support for and the driver exposes this functionality it must conform to the specifications for this feature as defined in the D3D11 Hardware Specification. For Windows 8 a WDDM 1.2 Graphics device driver if it supports Double Precision Shader functionality is required to support the extended double precision math as described in the Shader Model Improvements Specification.
Additional Information
| Business Justification |
This requirement is necessary to ensure consistency of this feature across multiple implementations, and provide Application developers a robust platform for application development and deployment on the Windows platform. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.AdapterRender.D3D11WDDM13
D3D11.1 Tiled Resource support
| Related Requirements |
Device.Graphics.AdapterRender.D3D11WDDM13.MapDefault |
Device.Graphics.AdapterRender.D3D11WDDM13.MapDefault
Map Default
| Target Feature |
Device.Graphics.AdapterRender.D3D11WDDM13 |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
For Direct3D Feature Level 11_0 and higher parts, the WDDM1.3 drivers must allow mappable DEFAULT buffers to be created. Apps will be able to request these mappable resources through setting the CPU_Read/CPU_Write access flags as described in the WDDM1.3 spec. The mappable DEFAULT buffers should behave identically to existing DEFAULT buffers today from an API perspective (other than being able to be mapped). The mapping/CPU-access performance of mappable DEFAULT buffers should be comparable to STAGING buffers
Additional Information
| Business Justification |
Mappable Default resources will dramatically improve the performance of scenarios involving heavy CPU access of resources. For this feature to work as intended it is necessary that no extra copies take place on the CPU during these map calls. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM
The base feature set implemented by drivers supporting all versions of the WDDM
| Related Requirements |
Device.Graphics.WDDM.Base Device.Graphics.WDDM.Checklist Device.Graphics.WDDM.GPUFenceCommands |
Device.Graphics.WDDM.Base
Graphics drivers must be implemented per WDDM 1.0 spec
| Target Feature |
Device.Graphics.WDDM |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
As implied by the WDDM 1.0 Specification, Display Drivers must minimally support D3D9 and Pixel Shader 2.0.WDDM 1.0 introduces the following key requirements:
User-mode Display Driver
Video Memory Manager
(p1) Linear Memory Manager
(p1) Rectangular Memory Manager
GPU Scheduler
Mode-Switch Architecture Cleanup
Merged Miniport and DLL
Recovery from Hardware Hangs
Simplified Kernel-mode Objects
Legacy DDI Consolidation
Hot-plug of Display Cards, Hot Docking, and Support for "Clone View"
MSDN documentation is updated based on the WDDM 1.0 Specification. Please verify MSDN documentation for WDDM 1.0 requirements.
Additional Information
| Business Justification |
Key benefits to the end-user include:Improved Stability by moving parts of the display driver into user mode memory, and adding support for hang recovery (Timeout Driver Recovery - TDR). Video Memory Virtualization - Prevents a single application from allocating all video memory for its exclusive use. Scheduling - More effective sharing (multitasking) of GPU. Security - GPU sharing and video memory virtualization prevent a single app from taking over these resources. Simplifies Driver Development by obsoleting legacy Direct3D features. OS promotes legacy fixed function features to D3D9 and Shader 2.0. WDDM removes the notion of Device Lost and supports newer Direct3D interfaces such as D3D9Ex, D3D10, 10.1. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Checklist
All Graphics devices comply with base requirements checklist for graphics cards, chipsets and drivers.
| Target Feature |
Device.Graphics.WDDM |
| Applies to |
Windows 7 Client x86, x64 Windows Server 2008 Release 2 x64 |
Description
[Version 2: Noted that digital connectors highly recommended but not required until Jun 2010.][Version 3: Removing digital connectors requirement point]All Graphics Cards need to adhere to the following checklist:Memory Allocations and Access (applicable for all form factors)
The GPU must not access an allocation after the last DMA buffer, that was submitted to the GPU referencing that allocation, is reported as complete.
The GPU must not access any allocations which were not specified in the allocation list associated with the DMA buffer being executed.
Card/Chipset Requirements (not applicable for server devices)
For a multi-headed display adapter, it is recommended that the display adapter expose all display resources through a single function and not as a multifunction device. If a sound controller or tuner is part of the device, the device can then be exposed as a multifunction device.
If a second display class function is exposed for legacy compatibility the adapter must be fully functional without using the second head. The second(or additional) functional heads must:
Have sub-class 80 (other) to avoid a generic driver being used.
Not have an expansion ROM.
Not describe more than 1 MB of total memory space resources.
Not duplicate the frame buffer resources.
Not describe any interrupt resources.
Not describe any I/O space resources.
Non display base class functions on the same device, such as a multimedia device class, sub class video device, or sub class audio device, are not subject to these restrictions
WDDM Driver Checklist (not applicable for non-WDDM drivers)
WDDM drivers must not report a submission fence as completed until the operation for the associated submission is truly completed. This is required by the scheduling model in WDDM. The WDDM must not use the DDI in such a way that the stability of Windows is compromised.
WDDM drivers must insert a fence/interrupt pair for each fence requested and must not hold off reporting the completion of that fence. The fence must be reported as soon as the associated required interrupt is generated by the GPU. For example, it must not wait until the timer interrupt or until the next VSync. This is required by the Scheduling model in DDM.
WDDM drivers must not wait or block during DdiSubmitCommand which is necessary from the perspective of the Video Scheduler in WDDM. The driver must not wait or block during a DdiBuildPagingBuffer call as well.
The WDDM driver must not expose more than one node per physical engine. The driver and GPU cannot schedule a single physical engine between multiple nodes.
The WDDM driver must not map a virtual address to video memory which is directly exposed to an application. This is fundamental to the implementation of video memory management support in the WDDM driver. The WDDM driver must not hide or expose video memory in a way that the video memory manager is unaware of. Exceptionsto this are allowed specifically for the implementation of GPU Developer Tools (Debuggers, Profilers, ). Such exception must apply only in a scenario where the GPU developer tools, in order to perform, need to map video memory to virtual address space, for the duration of the session and only for the process of the application being operated on.
The WDDM driver must not expose any memory segments which are used for the sole purpose of reporting additional video memory than is actually present for its appropriate use. The correct amount of video memory must be reported for use by various applications through Windows. The WDDM driver can use up to 5% of the system memory for internal use such as cursor bitmaps, ring buffer, etc; any amount above this must not be used to hide or expose video memory in a fashion such that the video memory manager is unaware of.
A WDDM driver must use ACPI for all interactions with the system BIOS. SMI is currently allowed but highly discouraged by Microsoft. See WinHEC 2005 presentation, TWAR05007
Design Notes:For more information on any of the items in the Details section, refer to the Windows Driver Kit and search for the relevant keywords.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.GPUFenceCommands
GPU that is capable of processing fence commands in the command queue triggers an interrupt
| Target Feature |
Device.Graphics.WDDM |
| Applies to |
Windows 7 Client x86, x64 Windows Server 2008 Release 2 x64 |
Description
When the hardware consumes a fence command, it must notify the operating system by triggering an interrupt to the CPU, with the fence ID communicated to the ISR.Design Notes:See the Windows Driver Kit
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Display
The base feature set implemented by drivers supporting all versions of the WDDM Display DDIs
| Related Requirements |
Device.Graphics.WDDM.Display.Base Device.Graphics.WDDM.Display.GammaCorrection Device.Graphics.WDDM.Display.HotPlugDetection Device.Graphics.WDDM.Display.I2CSupport Device.Graphics.WDDM.Display.MediaCenterResolutionTiming Device.Graphics.WDDM.Display.Multimon Device.Graphics.WDDM.Display.ResetToVGA |
Device.Graphics.WDDM.Display.Base
Graphics drivers must be implemented per WDDM 1.0 spec
| Target Feature |
Device.Graphics.WDDM.Display |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
See requirement Device.Graphics.WDDM.Base
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Display.GammaCorrection
Graphics Adapter must support gamma correction in hardware without using any additional graphics memory bandwidth
| Target Feature |
Device.Graphics.WDDM.Display |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
ICM uses the ability to perform gamma correction for the attached monitor and to allow game applications to switch palettes. This capability also supports transition effects in applications. To support ICM, the display adapter or chipset gamma must be programmatically adjustable.To perform gamma correction in hardware, downloadable RAM DAC entries (LUT) must be included.The LUT must implement at least 256 entries per component input for 8-bit color channel components. Hardware may implement the LUT for larger component resolutions by using interpolation if at least 128 sample points are used.This ability must be supported without requiring the use of graphics memory bandwidth.
Additional Information
| Business Justification |
Not having this will break the logon/logoff, sleep/wake, hibernate/resume fade effect, and Win7 Display Color Calibration (DCC) tool and its display calibration loader. This would also break every third-party display calibration tool, including those by X-Rite and DataColor. This would make Windows useless for serious digital color photography work. This is required for servers also since DCC is included in the Experience Pack for the Server SKUs. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Display.HotPlugDetection
Graphics adapter must reliably detect the connect and disconnect event of display devices.
| Target Feature |
Device.Graphics.WDDM.Display |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Windows supports two levels of display detection - interruptible and poll-able.
Interruptible is defined as the case where the graphics adapter is able to automatically detect a change in display connectivity and report it to Windows. The ability of the hardware to automatically generate an interrupt for display connectivity change is called Hot Plug Detect (HPD). The HPD must not cause any visual corruption on any display already connected to the system.
Poll-able is defined as the case where Windows has to explicitly query the graphics adapter to query for a change in the display connectivity. In some cases visual corruption might be displayed for a very brief time.
All standard digital connectors (DisplayPort, HDMI, DVI) support HPD and the graphics adapter must report these connectors as interruptible. Once the hardware generates the interrupt, the graphics adapter must notify Windows via the DxgkCbIndicateChildStatus DDI found here: https://msdn.microsoft.com/library/ff559522(VS.85).aspx. Analog connectors (HD-15, S-Video, Component, Composite) are not required to support interruptible display detection. However, it is possible that HPD can be implemented in the hardware (e.g. load sensing, I2C) for such connectors. In such a case the graphics adapter must report this connector as interruptible as above. Software polling cannot be used to achieve HPD functionality for analog connectors. For those analog connectors, where HPD is not implemented in the hardware, the graphics adapter must report the connector as polled. In such a case the graphics adapter must only perform detection on the connector when explicitly requested by Windows via the D3DKMTPollDisplayChildren DDI, found here: https://msdn.microsoft.com/library/ff547077(v=VS.85).aspx. Design Notes:
See the Windows Driver Kit: https://msdn.microsoft.com/library/ff559522(VS.85).aspx for " DxgkCbIndicateChildStatus."
The following HPD methods are VESA standards: DVI HPD is covered in the VESA Plug and Play (PnP) Standard for the Display/Graphics Subsystem, Release A. DisplayPort HPD is covered in all versions of the DisplayPort standard.
Additional Information
| Business Justification |
HPD is required on HDMI, DVI, and DisplayPort and there are existing industry specifications on HPD for both HW and SW, however this requirement is primarily to ensure a robust system level solution for detecting and configuring monitors. This will help provide the best experience to end consumers when they plug and play a monitor to the PC over digital interfaces. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Display.I2CSupport
Graphics device driver must have I2C support in WDDM
| Target Feature |
Device.Graphics.WDDM.Display |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
The following is the set of interfaces that every WDDM driver is required to implement for I2C support:DxgkDdiI2CReceiveDataFromDisplayDxgkDdiI2CTransmitDataToDisplayThese interfaces are documented in the WDK and can be found here.
Additional Information
| Business Justification |
Windows uses the I2C interfaces to obtain the EDID from each of the displays connected to the system. Obtaining the EDID is critical for setting the native resolution of the panel. In cases where the display connector does not inherently support hot plug detect, the graphics driver might use the I2C line to detect the presence/absence of the display device. Additionally, Windows provides a rich set of APIs for Monitor configuration. These APIs are useful for advanced configuration of Display devices. Such advanced configuration is for being able to programmatically control display settings like Brightness, Contrast, Color calibration, image position, image size etc. The APIs are documented here on MSDN. The above mentioned interfaces are needed to support this set of APIs. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Display.MediaCenterResolutionTiming
Display subsystem that supports Media Center functionality must support digital television (EIA/CEA-861B) resolutions and timings over digital interfaces
| Target Feature |
Device.Graphics.WDDM.Display |
| Applies to |
Windows 7 Client x86, x64 |
Description
VESA specifies display modes and timing information that standard VGA graphics and display monitors use. VESA does not specify display modes and timing information for consumer displays (TV). To support Media Center functionality requirements for display modes and timing, the graphics subsystem must also support all display modes and timing information over VGA, DVI, HDMI, or other digital interconnect, as required by EIA/CEA-861B. These display modes must be exposed by the video miniport so that they appear in the default timings list.The required modes are those listed as mandatory in the EIA/CEA-861B specification as well as both the two high definition modes:
1280x720p (60Hz, 59Hz and 50Hz)
1920x1080i or 1920x1080p(60Hz, 59Hz and 50Hz)
720x480p (59Hz)
720x576p (50Hz)
All other variants of resolutions and refresh rates defined in EIA/CEA-861B are optional, but recommended to support the widest range of consumer displays.Design Notes:For EIA/CEA requirement details, see EIA/CEA-861-B, Sections 3.1 and 4, "A DTV Profile for Uncompressed High-Speed Digital Interfaces."59Hz is defined in the Windows Display Driver Model (WDDM)to be equivalent to 59.94Hz.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Display.Multimon
If a Graphics adapter supports more than 1 source and 1 target, it must support all multiple-monitor configurations in Windows
| Target Feature |
Device.Graphics.WDDM.Display |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
A graphics driver can enumerate sources and targets based on its capabilities. Windows queries the driver for the number of sources and targets by calling the DxgkDdiEnumVidPnCofuncModality DDI, found here https://msdn.microsoft.com/library/ff559649.aspx. Windows supports the following monitor configurations:
Single monitor configuration - only one physical monitor is active and the entire desktop is displayed on it
Extended monitor configuration - multiple monitors are active in and different parts of the desktop are displayed on it. GDI must be made aware of the monitor boundaries such that Windows features like maximize, aero snap etc work according to spec
Duplicate monitor configuration - the exact same desktop contents are displayed on multiple monitors
The number of targets must always be greater than or equal to the number of sources. If the driver enumerates exactly 1 source and 1 target, then no multiple monitor configurations are supported. If the driver enumerates exactly 1 source and multiple targets, then the driver must support single monitor and duplicate monitor configurations.If the driver enumerates multiple sources and multiple targets, then the driver must support all the supported configurations. Additionally:
the capability of each source when enabled by its self, with respect to resolution, Direct3D, protected content playback, should be the same. The capabilities of the target will vary based on the target type.
the operating system must be able to drive any target from any source, although the driver can constrain which targets can be driven in combination.
Multiple-monitor support is built into Windows; therefore, graphics drivers must not include any special code to provide support already available in the OS.It must be possible for a user to set all the configurations supported using the Windows Display Control Panel and by pressing the Win+P key combination.
Additional Information
| Business Justification |
Windows enables different user interfaces based on the number of sources and targets enumerated by the driver. Once the driver has enumerated the sources and targets it is important for the driver to support all the multiple monitor configurations that are expected by Windows so that the user interface can accurately represent the current state and allow the user to make changes to the monitor configurations. It is important that all drivers support these configurations so that the user has confidence in the Windows platform and its eco system. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Display.ResetToVGA
Display adapter or chipset supports standard VGA modes and can be reset to standard VGA modes
| Target Feature |
Device.Graphics.WDDM.Display |
| Applies to |
Windows 7 Client x86, x64 Windows Server 2008 Release 2 x64 |
Description
The display adapter or chipset must support standard VGA. If necessary, the device must be able to reset to standard VGA from high-resolutions. To reset the device sufficiently implies that the device is fully functional as a VGA device. It must be fully functional when programmed via the video BIOS and when programmed directly through standard VGA registers.The hardware and BIOS must be able to support original VGA mode 12h and VESA modes to allow at least the minimum desktop resolution for Windows, the native resolution of any integrated display and, on external monitors, resolutions of 640 x 480, 800 x 600 and 1024 x 768. All required modes should be supported with at least 16 bits per pixel, though 32 bits per pixel is highly recommended. Since the 16-bit BIOS is executed within an emulated environment, the BIOS implementation cannot assume that the code is being run natively and therefore must not trigger SMIs in order to perform the requested action. Likewise, since the BIOS is executed while the OS is running, it must not touch hardware outside of the display device.It is recommended that the BIOS validate the compatibility of all display resolutions it enumerates against the capabilities of the active monitor(s). If a monitor does not support a display timing compatible with a timing available to the BIOS, the resolution must be reported as not supported by hardware configuration by setting D0 of the ModeAttributes when the BIOS is invoked via int 10h function 4f01h for this mode.If no monitor capabilities are available (missing EDID) for an active on an analog connecter, the BIOS should report at least the above required resolutions as supported by hardware configuration. When the OS attempts to set one of these modes, the BIOS should set the mode using a 60Hzprogressive timing for a monitor connector (example HD15) or using the BIOSes default timing for an analog TV connector. Hybrid Graphics: Not all devices in a Hybrid Graphics system are required to support standard VGA. At least the boot device must support standard VGA and must be able to reset to standard VGA. These requirements exist to ensure basic functionality of the display adapter/chipset in all circumstances.Design Notes:The list of VESA modes can be obtained from VESA (www.vesa.org). VGA is defined by IBM spec.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Display.HDMIorDPDCNs
The optional feature implemented by WDDM drivers supporting the audio DCNs over HDMI or DisplayPort.
| Related Requirements |
Device.Graphics.WDDM.Display.HDMIorDPDCNs.DCNCompliance |
Device.Graphics.WDDM.Display.HDMIorDPDCNs.DCNCompliance
Display driver that contains either an HD Audio interface supporting multi-channel HDMI or a DisplayPort audio consistent with HD Audio must comply with HD Audio HDMI & DisplayPort DCNs
| Target Feature |
Device.Graphics.WDDM.Display.HDMIorDPDCNs |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
If a display driver is designed for an HDMI or DisplayPort adapter or chipset that contains an HD Audio interface that implements any of the verbs listed below, the graphics driver must:
Comply with the following HD Audio DCNs:
HDA034-A2: HDMI Content Protection and Multi-Channel Support
HDA039-A: HDMI/ELD Memory Structure
HDA036-A: DisplayPort Support and HDMI Miscellaneous Corrections
Read and parse the EDID from any attached HDMI or DisplayPort sink device and populate the ELD buffer to accurately reflect the hardware and sink device capabilities as required in the HD Audio DCN HDA039-A: HDMI/ELD Memory Structure.
Program all possible Short Audio Descriptors (SADs) from the EDID into the ELD
Correctly program the Presence Detect (PD) and ELD Valid (ELDV) bits on the HDMI or DP transmitter hardware for consumption by the audio driver in response to the following events as outlined in the HD Audio DCN HDA034-A2: HDMI Content Protection and Multi-Channel Support.
Hot plug events (HDMI/DisplayPort Sink Connected/Disconnected)
According to DCN referenced above
Video mode changes
According to DCN referenced above
Graphics power state transitions
When the graphics subsystem exits power state D0:
If sink is attached, PD = 1, ELDV = 0
Otherwise, PD = 0, ELDV = 0
When graphics subsystem enters power state D0:
If sink is attached, PD = 1, ELDV = 1
Otherwise, PD = 0, ELDV = 0
Driver load
According to DCN referenced above
Driver unload
PD = 1, ELDV = 1
ELD_Version = 1Fh; indicative of basic audio
Respond to HD Audio-initiated requests for HDCP as outlined in the HD Audio DCN HDA034-A2: HDMI Content Protection and Multi-Channel Support within 10 seconds.
Ensure that the READY and CES (current encryption state) values in the CP_CONTROL verb accurately reflect the state of the display subsystem, as outlined in the HD Audio DCN HDA034-A2: HDMI Content Protection and Multi-Channel Support.
The Verbs are:
F2Fh (Get HDMI ELD Data)
F2Dh (Get Converter Channel Count)
72Dh (Set Converter Channel Count)
F2Eh (Get HDMI Data Island Packet - Size Info)
72Eh (Set HDMI Data Island Packet - Size Info)
F30h (Get HDMI Data Island Packet - Index)
730h (Set HDMI Data Island Packet - Index)
F31h (Get HDMI Data Island Packet - Data)
731h (Set HDMI Data Island Packet - Data)
F32h (Get HDMI Data Island Packet - Transmit-Control)
732h (Set HDMI Data Island Packet - Transmit-3Control)
F33h (Get Content Protection Control)
733h (Set Content Protection Control)
F34h (Get Converter Channel to HDMI Slot Mapping)
734h (Set Converter Channel to HDMI Slot Mapping)
Additional Information
| Business Justification |
HDMI audio is heavily dependent on the video driver properly handling the communication of data, parameters and supported formats to the audio driver. This requirement ensures that video drivers perform these functions and enable audio over HDMI. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Display.TVOut
If the feature set implemented by drivers which devices contain an SVideo or Composite output
| Related Requirements |
Device.Graphics.WDDM.Display.TVOut.Base Device.Graphics.WDDM.Display.TVOut.DAC Device.Graphics.WDDM.Display.TVOut.Encoder |
Device.Graphics.WDDM.Display.TVOut.Base
TV-out capable display subsystem supports specific timing standards for NTSC and PAL/SECAM regions
| Target Feature |
Device.Graphics.WDDM.Display.TVOut |
| Applies to |
Windows 7 Client x86, x64 Windows Server 2008 Release 2 x64 |
Description
If the display subsystem supports composite or S-video TV-out, it must support NTSC and PAL/SECAM timings appropriate for the region of sale on its other display output interfaces(s) such as DVI or HDMI, as follows:
NTSC Regions: 720x480, 59-Hz
PAL/SECAM Regions: 720x576, 50-Hz
The refresh rate of 59.94 Hz is an abbreviated reference used for video. The full refresh rate is 60000/1001 Hz and must be supported as such. Systems equipped with analog three-wire component video output connectors must also implement support for standard definition video timings defined in EIA/CEA-770.2-C and the May 2005 errata to this standard. Support for high-definition analog timings is optional.Design Notes:The refresh rate of 59-Hz is an abbreviated reference used for video.
Additional Information
| Business Justification |
The TV output from the PC must at least be equal to CE set top boxes available today. Video playback in Media Center will degrade. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Display.TVOut.DAC
TV out-capable display subsystem connects to a dedicated default DAC and timing generator
| Target Feature |
Device.Graphics.WDDM.Display.TVOut |
| Applies to |
Windows 7 Client x86, x64 Windows Server 2008 Release 2 x64 |
Description
For Video quality purposes, TV output must run at a resolution that is different from the VGA output. A dedicated TV Video subsystem with an independent timing generator must display content at independent resolutions from other video output connectors. If TV output is supported simultaneously with another output (DVI, CRT, or LVDS), the TV timing must not be affected by the timing requirements of the other outputs and vice-versa, so that a user may run TV-out in a multi-monitor configuration.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Display.TVOut.Encoder
TV out-capable display subsystem that supports a TV out encoder as a second head meets general multiple-monitor requirements
| Target Feature |
Device.Graphics.WDDM.Display.TVOut |
| Applies to |
Windows 7 Client x86, x64 Windows Server 2008 Release 2 x64 |
Description
The TV-out encoder on the display adapter must be treated as a second or even third independent head.
Additional Information
| Business Justification |
TV out must act as a secondary or third head if implemented, and must meet a general multi-mon requirements. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.DisplayRender
The base feature set implemented by drivers supporting all versions of the WDDM for both Display and Render DDIs
| Related Requirements |
Device.Graphics.WDDM.DisplayRender.Base Device.Graphics.WDDM.DisplayRender.DriverSetupCompatible Device.Graphics.WDDM.DisplayRender.OutputProtection Device.Graphics.WDDM.DisplayRender.Stability |
Device.Graphics.WDDM.DisplayRender.Base
Graphics drivers must be implemented per WDDM 1.0 spec
| Target Feature |
Device.Graphics.WDDM.DisplayRender |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
See requirement Device.Graphics.WDDM.Base
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.DisplayRender.DriverSetupCompatible
Graphics drivers must be implemented per WDDM 1.0 spec
| Target Feature |
Device.Graphics.WDDM.DisplayRender |
| Applies to |
Windows 8.1 Client x86, x64 |
Description
All WDDM graphics drivers being submitted for posting to Windows Update targeting Windows 8.1 Client SKUs must install correctly on injection in to the Windows 8.1 OS image driver store during OS setup.
Additional Information
| Business Justification |
Windows 8.1 x86/x64 will not include 3rd party in-box graphics drivers. Instead the latest applicable Windows Update graphics driver packages will be downloaded and injected into the Windows 8.1 OS image by Dynamic Update during Windows 8.1 upgrade installation. Note that this download and injection will not occur for Server SKUs. The PnP Manager then installs the best graphics drivers from the Windows 8.1 driver store. This test ensures that certified graphics drivers on Windows Update will install correctly in this scenario. |
| Exceptions |
This requirement only applies to full WDDM graphics drivers being submitted for posting to Windows Update targeting Windows 8.1. It does not apply to Display-Only or Render-Only drivers. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.DisplayRender.OutputProtection
Display adapter supports output connectors with content protection features and provides control via Protected Media Path-Output Protection Manager (PVP-OPM) and Certified Output Protection Protocol (COPP).
| Target Feature |
Device.Graphics.WDDM.DisplayRender |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
To enable playback of protected DVD content, digital video outputs must support a digital monitor link protection mechanism such as HDCP to obtain Windows 8 Client Logo. This requirement is applicable for all Full Graphics devices.The OPM API and Media Foundation PMP require display drivers to properly implement the OPM DDIs to handle premium content. High grade premium content will not be passed to the display driver unless the display driver has a PVP-OPM certificate. Drivers that support the OPM DDIs must have a driver certificate to testify that the compliance rules, robustness rules, and terms of the PVP-OPM legal agreement, have been met. The display driver must support both the COPP* and PVP-OPM driver interfaces for controlling and signaling video output protection state.Output protection behaviors are specified by the PVP-OPM compliance rules. The document is available to graphics vendors by request to wmla@microsoft.com.The WDDM driver must implement the necessary Display Mode Management DDIs and structures as documented in the Windows Driver Kit and the WDDM documentation to enable TV playback. and Analog Content Protection (ACP) support for Media Center*.D3DKMDT_VIDPN_PRESENT_PATH_CONTENT: Media center will use this information to change the TV mode (TV_PLAYBACK vs. WIN_GRAPHICS) D3DKMDT_VIDPN_PRESENT_PATH_COPYPROTECTION_TYPE and D3DKMDT_VIDPN_PRESENT_PATH_COPYPROTECTION_SUPPORT: These structures are necessary to provide ACP support through the LDDM driver. S-Video and composite video output interfaces must support the following: CGMS-A on Line 20 as specified by IEC 61880 CGMS-A on Line 21 as specified by EIA-608-B Component (YPbPr) outputs must support the following:CGMS-A with redistribution control as specified by EIA-805When the TV-out interface is enabled, the display driver must expose a 720x480 60-Hz display mode and/or a 720x576 50-Hz display mode. These display modes must be exposed by the video miniport and added to the default timings list for Windows applications to set when connected to a standard definition TV.Supports SDTV Modes: The WDDM miniport driver must set this parameter to TRUE for the video output to expose SDTV modes like NTSC, PAL or SECAM.Cable Ready systems with CableCARD support with digital video outputs (for example HDMI, or DP) must support a CableLabs approved digital monitor link protection mechanism such as HDCP. Design Notes:
S-Video and composite video output interfaces may be implemented through the same connector. If a proprietary interface is used, an adapter must be made available either included with the system or available for purchase at point of sale. System or device that uses 7-pin S-Video connectors is not required to provide an adapter so long as the first four pins on the 7-pin connector are electrically compatible with a standard 4-pin S-Video connector. Microsoft recommends including SCART output when appropriate for the region of sale.
* COPP, ACP, CGMS-A, analog TV-out, and SDTV support are required on x86 and x64 architectures and operating systems only.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.DisplayRender.Stability
All WDDM graphics drivers must not generate any hangs or faults under prolonged stress conditions.
| Target Feature |
Device.Graphics.WDDM.DisplayRender |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
Graphics drivers must function properly, and not generate any hangs or faults throughout the duration of stress testing as specified in the
"4-hour WDDM Profile"
To "stress" a graphics driver, Comparative Reliability Analyzer for Software and Hardware (CRASH) launches and terminates other test applications to simulate real-world scenarios.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.DisplayRender.OutputProtection
The base optional WDDM feature set for Windows 7 containing requirements for OPM
| Related Requirements |
Device.Graphics.WDDM.DisplayRender.OutputProtection.Windows7 |
Device.Graphics.WDDM.DisplayRender.OutputProtection.Windows7
Display adapter supports output connectors with content protection features and provides control via Protected Media Path-Output Protection Manager (PVP-OPM) and Certified Output Protection Protocol (COPP).
| Target Feature |
Device.Graphics.WDDM.DisplayRender.OutputProtection |
| Applies to |
Windows 7 Client x86, x64 Windows Server 2008 Release 2 x64 |
Description
To enable playback of protected DVD content, digital video outputs must support a digital monitor link protection mechanism such as HDCP to obtain Windows 7 Logo. This is an if implemented feature.The OPM API and Media Foundation PMP require display drivers to properly implement the OPM DDIs to handle premium content. High grade premium content will not be passed to the display driver unless the display driver has a PVP-OPM certificate. Drivers that support the OPM DDIs must have a driver certificate to testify that the compliance rules, robustness rules, and terms of the PVP-OPM legal agreement, have been met. The display driver must support both the COPP and PVP-OPM driver interfaces for controlling and signaling video output protection state.Output protection behaviors are specified by the PVP-OPM compliance rules. The document is available to graphics vendors by request to wmla@microsoft.com.The WDDM driver must implement the necessary Display Mode Management DDIs and structures as documented in the Windows Driver Kit and the WDDM documentation to enable TV playback. and Analog Content Protection (ACP) support for Media Center.The WDDM driver must implement the necessary Display Mode Management DDIs and structures as documented in the Windows Driver Kit and the WDDM documentation to enable TV playback and Analog Content Protection (ACP) support for Media Center.D3DKMDT_VIDPN_PRESENT_PATH_CONTENT: Media center will use this information to change the TV mode (TV_PLAYBACK vs. WIN_GRAPHICS) D3DKMDT_VIDPN_PRESENT_PATH_COPYPROTECTION_TYPE and D3DKMDT_VIDPN_PRESENT_PATH_COPYPROTECTION_SUPPORT: These structures are necessary to provide ACP support through the LDDM driver. S-Video and composite video output interfaces must support the following: CGMS-A on Line 20 as specified by IEC 61880 CGMS-A on Line 21 as specified by EIA-608-B Component (YPbPr) outputs must support the following:CGMS-A with redistribution control as specified by EIA-805When the TV-out interface is enabled, the display driver must expose a 720x480 60-Hz display mode and/or a 720x576 50-Hz display mode. These display modes must be exposed by the video miniport and added to the default timings list for Windows applications to set when connected to a standard definition TV.Supports SDTV Modes: The WDDM miniport driver must set this parameter to TRUE for the video output to expose SDTV modes like NTSC, PAL or SECAM.Cable Ready systems with CableCARD support with digital video outputs (for example HDMI, or DP) must support a CableLabs approved digital monitor link protection mechanism such as HDCP. Design Notes:S-Video and composite video output interfaces may be implemented through the same connector. If a proprietary interface is used, an adapter must be made available either included with the system or available for purchase at point of sale. System or device that uses 7-pin S-Video connectors is not required to provide an adapter so long as the first four pins on the 7-pin connector are electrically compatible with a standard 4-pin S-Video connector. Microsoft recommends including SCART output when appropriate for the region of sale.
Additional Information
| Business Justification |
Content providers will not allow use of protected content without engaging video output link protections per the compliance rules in force. For example, protected DVD or Blu-Ray playback will usually require activating HDCP on HDMI, or DP connectors. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Render
The base feature set implemented by drivers supporting all versions of the WDDM Render DDIs
| Related Requirements |
Device.Graphics.WDDM.Render.Base Device.Graphics.WDDM.Render.VideoDecoding Device.Graphics.WDDM.Render.VideoProcessing Device.Graphics.WDDM.Render.Windows7.VideoDecoding |
Device.Graphics.WDDM.Render.Base
Graphics drivers must be implemented per WDDM 1.0 spec
| Target Feature |
Device.Graphics.WDDM.Render |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
See requirement Device.Graphics.WDDM.Base
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Render.VideoDecoding
Display driver supports the DirectX VA 2.0 Video Decoder DDI
| Target Feature |
Device.Graphics.WDDM.Render |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Display WDDM drivers must support the DXVA 2.0 Video Decoder DDI.
WDDM drivers must support the following DXVA modes:
DXVA2_ModeMPEG2_VLD
DXVA_ModeH264_VLD
DXVA2_ModeVC1_D
WDDM drivers must support at least one of the following sets of MPEG2 GUIDs:
DXVA2_ModeMPEG2_VLD and DXVA2_ModeMPEG2_iDCT
DXVA2_ModeMPEG2_VLD and DXVA2_ModeMPEG2_MoComp
DXVA2_ModeMPEG2_iDCT
DXVA2_ModeMPEG2and1_VLD
And at least one of the H.264 GUIDs:
DXVA_ModeH264_MoComp
DXVA_ModeH264_VLD
In addition, WDDM drivers must support at least one of the following VC1 modes:
DXVA2_ModeVC1_B (Mo-Comp + Post-Proc**)
DXVA2_ModeVC1_C (iDCT + Mo-Comp+ Post-Proc**)
DXVA2_ModeVC1_D (VLD + IDCT + Mo-Comp + Post-Proc**)
If the display adapter supports hardware-accelerated decode of H.264, it must support either the DXVA_ModeH264_MoComp GUID or the DXVA_ModeH264_VLD GUID.
If the display adapter support hardware accelerated decode of HEVC, it must support the DXVA_ModeHEVC_VLD_Main GUID.
Finally, WDDM drivers must support Standardized AES 128 for both MPEG2 and H.264***.
** Note that it is not a requirement to implement the "Post-Proc" stage on DXVA2_ModeVC1 GUIDs.
Design Notes
1.MPEG-2 support is required on x86 and x64 architectures and operating systems only.
2.*** Standardized AES 128 support is required on x86 and x64 architectures and operating systems only.
Other considerations:
VideoDecoderCreationLatency:
System latency in DXVA creation should be shorter than 100ms each in 5 runs
Single Stream Decode Quality:
DXVA decoder can decode 1080p at 60fps (both Modern and Classic UI)
Concurrent decoding:
DXVA decoder is able to concurrently decode multiple streams (1080p, 720p, 540p and 360p)
Dynamic decoding:
DXVA decoder is able to decode 1-6 streams with different formats simultaneously.
VideoDecoderHighGPUUsage:
DXVA decoder output quality meets bar under high GPU Usage (both in Modern and Classic UI)
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Render.VideoProcessing
Display WDDM driver supports the DirectX VA 2.0 Video Processor DDI
| Target Feature |
Device.Graphics.WDDM.Render |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Display WDDM drivers must support the DXVA 2.0 Video Processor DDI and implement support for the following Video Processor Device GUIDs:
DXVADDI_VideoProcProgressiveDevice
DXVADDI_VideoProcBobDevice
The following DXVA2 video processor caps must be supported for each of the video processor device GUIDs:
DXVADDI_VIDEOPROCESS_YUV2RGB
DXVADDI_VIDEOPROCESS_YUV2RGBEXTENDED
DXVADDI_VIDEOPROCESS_STRETCHX
DXVADDI_VIDEOPROCESS_STRETCHY
DXVADDI_VIDEOPROCESS_SUBRECTS
DXVADDI_VIDEOPROCESS_SUBSTREAMS
DXVA2_VideoProcess_SubStreamsExtended
DXVA2_VideoProcess_Constriction
In addition, to support DXVADDI_VIDEOPROCESS_YUV2RGBEXTENDED caps, the following color parameters must be supported when color-space converting from a YUV surface to a RGB surface:
D3DDDIARG_VIDEOPROCESSBLT.DestFormat.NominalRange
oDXVADDI_NominalRange_Unknown (should be interpreted as 0_255 if a sophisticated algorithm is not implemented)
oDXVADDI_NominalRange_0_255
oDXVADDI_NominalRange_16_235
D3DDDIARG_VIDEOPROCESSBLT.pSrcSurfaces[].SampleFormat.VideoTransferMatrix
oDXVADDI_VideoTransferMatrix_Unknown (should be interpreted as BT601 unless the source surface is greater than 576 height in which case should be interpreted as BT709)
oDXVADDI_VideoTransferMatrix_BT709
oDXVADDI_VideoTransferMatrix_BT601
The following YUV formats must be supported as the video stream:
YUY2 - 8-bit packed 4:2:2
NV12 - 8-bit planar 4:2:0
If the video processor supports 10-bit YUV formats, the following formats must be supported:
Y210 - 10-bit packed 4:2:2
Y410 - 10-bit packed 4:4:4
P210 - 10-bit planar 4:2:2
P010 - 10-bit planar 4:2:0
If the video processor supports 16-bit YUV formats, the following formats must be supported:
Y216 - 16-bit packed 4:2:2
Y416 - 16-bit packed 4:4:4
P216 - 16-bit planar 4:2:2
P016 - 16-bit planar 4:2:0
The following YUV format must be supported as the video sub-streams:
AYUV - 8-bit packed 4:4:4
For these formats, color converting YUV-to-RGB blits run through the VideoProcessBlt function must at least be able to use BT. 601 and BT. 709 conversion matrices. This process allows the graphics to switch between the YUV-to-RGB matrix transforms for different color formats, to ensure proper handling of video that originates from different standard color spaces such as those defined in ITU-R Recommendations BT. 601 and BT.709, is required.
Updated Requirements:
Tolerance threshold: 50dB of quality difference between reference and DXVAHD modes
Color conversion support of the following for playback, transcode and capture scenarios:
oNV12->ARGB32
oYUY2->ARGB32
oARGB32->NV12 (both full-swing and studio-swing)
o420O->NV12
o420O->ARGB32
oAYUV->NV12
Rescaling support for the above conversions
Rotation support
Extended Range (Full-Swing) support for transcode and capture scenarios
Support for updated DX9 and DX10+ user mode DDIs as documented on Connect at https://connect.microsoft.com/site1304/Downloads/DownloadDetails.aspx?DownloadID=47236
Additional Information
| Business Justification |
Basic functionality of defined in the most common video specifications (for example: H.264, Blu-ray) require conversion of all of the specified YUV formats to RGB data for display of video. In order to enable full support for these encoding formats, all WDDM hardware must support these conversion capabilities. High quality color conversion ensures comparable video quality can be obtained for video to competitive platforms |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM.Render.Windows7.VideoDecoding
Display driver supports the DirectX VA 2.0 Video Decoder DDI
| Target Feature |
Device.Graphics.WDDM.Render |
| Applies to |
Windows 7 Client x86, x64 Windows Server 2008 Release 2 x64 |
Description
For both Windows Vista Premium Logo and Windows 7 Logo, display WDDM drivers must support the DXVA 2.0 Video Decoder DDI. WDDM drivers must support at least the following GUIDs:((DXVA2_ModeMPEG2_VLD and DXVA2_ModeMPEG2_iDCT) or (DXVA2_ModeMPEG2_VLD and DXVA2_ModeMPEG2_MoComp) or (DXVA2_ModeMPEG2_iDCT)) and (DXVA2_ModeVC1_B (Mo-Comp + Post-Proc**) or DXVA2_ModeVC1_C (iDCT + Mo-Comp+ Post-Proc**)or DXVA2_ModeVC1_D (VLD + IDCT + Mo-Comp + Post-Proc**) ) andIf the display adapter supports hardware-accellerated decode of H.264, it must support the following GUID(DXVA_ModeH264_MoComp or DXVA_ModeH264_VLD)** Note that it is not a requirement to implement the "Post-Proc" stage on DXVA2_ModeVC1 GUIDs.
Additional Information
| Exceptions |
This requirement is if-implemented for Windows Server 2008 Release 2 x64 |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM11
The base feature set implemented by drivers supporting WDDM 1.1
| Related Requirements |
Device.Graphics.WDDM11.Base |
Device.Graphics.WDDM11.Base
Graphic drivers written for a discrete graphic adapters or an integrated graphics adapters devices must meet all requirements defined in the WDDM 1.1 specifications.
| Target Feature |
Device.Graphics.WDDM11 |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
WDDM 1.1 introduces the following key requirements over WDDM 1.0:
Hardware acceleration of select GDI features.
Implementation of DMM DDIs for Connecting and Configuring Displays
Support for 32-bit BGRA pixel format compatible with GDI. (Through DirectX10 and later DDIs.)
Provide additional information to aid in debugging VSync TDRs.
Kernel mode drivers must be compiled with Frame Pointer Optimizations (FPO) disabled.
Optional features, if implemented, must be incorporated according to the specifications and WDK documentation, including Standardized AES128, DXVA-HD, overlays, and Direct3D11.
MSDN documentation is updated based on the WDDM 1.1 Specification. Please consult MSDN documentation for WDDM 1.1 requirements.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM11.Display
The base feature set implemented by drivers supporting all versions of the WDDM Display DDIs
| Related Requirements |
Device.Graphics.WDDM11.Display.Base |
Device.Graphics.WDDM11.Display.Base
Graphic drivers written for a discrete graphic adapters or an integrated graphics adapters devices must meet all requirements defined in the WDDM 1.1 specifications.
| Target Feature |
Device.Graphics.WDDM11.Display |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
See requirement Device.Graphics.WDDM11.Base
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM11.DisplayRender
The base feature set implemented by drivers supporting all versions of the WDDM for both Display and Render DDIs
| Related Requirements |
Device.Graphics.WDDM11.DisplayRender.Base |
Device.Graphics.WDDM11.DisplayRender.Base
Graphic drivers written for a discrete graphic adapters or an integrated graphics adapters devices must meet all requirements defined in the WDDM 1.1 specifications.
| Target Feature |
Device.Graphics.WDDM11.DisplayRender |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
See requirement Device.Graphics.WDDM11.Base
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM11.DisplayRender.D3D9Overlay
The optional feature implemented by WDDM 1.1 drivers and greater allowing for surfaces to present in a hardware overlay.
| Related Requirements |
Device.Graphics.WDDM11.DisplayRender.D3D9Overlay.D3D9Overlay |
Device.Graphics.WDDM11.DisplayRender.D3D9Overlay.D3D9Overlay
WDDM1.1 driver supports Direct3D 9 Overlays
| Target Feature |
Device.Graphics.WDDM11.DisplayRender.D3D9Overlay |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
If the WDDM1.1 driver supports Direct3D 9 Overlays the video overlay presentation requirements are as follows:
A WDDM v1.1 driver must set the D3DCAPS_OVERLAY bit in the D3DCaps9.Caps field.
A WDDM v1.1 driver must support query type D3DDDICAPS_CHECKOVERLAYSUPPORT to the user mode pfnGetCaps DDI call.
A WDDM v1.1 driver must support overlays in at least one valid configuration (Displaymode, OverlayFormat, Width, and Height) when called to DDICHECKOVERLAYSUPPORTDATA for supported overlay and the Max width and height of supported overlay must be greater than zero.
Additional Information
| Business Justification |
The WDDM v1.1 overlay DDI enables Direct3D9 based applications to use video overlays while running Aero Glass (DWM On). The feature improves upon the security model for video overlay presentation as well as performance by eliminating per frame composition. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM11.Render
The base feature set implemented by drivers supporting all versions of the WDDM Render DDIs
| Related Requirements |
Device.Graphics.WDDM11.Render.Base |
Device.Graphics.WDDM11.Render.Base
Graphic drivers written for a discrete graphic adapters or an integrated graphics adapters devices must meet all requirements defined in the WDDM 1.1 specifications.
| Target Feature |
Device.Graphics.WDDM11.Render |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
See requirement Device.Graphics.WDDM11.Base
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM11.Render.ContentProtection
The optional feature implemented by WDDM 1.1 drivers allowing for D3D9 surfaces to be protected.
| Related Requirements |
Device.Graphics.WDDM11.Render.ContentProtection.ContentProtection |
Device.Graphics.WDDM11.Render.ContentProtection.ContentProtection
WDDM1.1 Driver supports GPU-based Content Protection
| Target Feature |
Device.Graphics.WDDM11.Render.ContentProtection |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
If the WDDM1.1 driver supports GPU based content protection it must support the following features:
Encryption BLT -- Video to System BLT with encryption
Driver Protections of Shared Surfaces
Encryption on Eviction- Encryption of video memory resources when evicted from video memory.
Decryption BLT System to Video BLT with decryption
For more details on each of these features, please refer to the Windows WDK documentation.
Additional Information
| Business Justification |
This WDDM v1.1 content protection DDI enables Windows Media Center as well as 3rd party video players in windowed mode with DWM on. The feature support scales from driver/software to driver/hardware protections. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM11.Render.DXVAHD
The optional feature implemented by WDDM 1.1 drivers supporting the new state based video processing DDIs.
| Related Requirements |
Device.Graphics.WDDM11.Render.DXVAHD.DXVAHD |
Device.Graphics.WDDM11.Render.DXVAHD.DXVAHD
WDDM1.1 driver supports DXVA-HD
| Target Feature |
Device.Graphics.WDDM11.Render.DXVAHD |
| Applies to |
Windows 7 Client x86, x64 Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
If the WDDM1.1 driver supports DXVA-HD then the following input formats (D3DDDICAPS_DXVAHD_GETVPINPUTFORMATS) must be supported:
YUY2
AYUV
NV12
X8R8G8B8
A8R8G8B8
Also the driver must support the following output formats ( D3DDDICAPS_DXVAHD_GETVPOUTPUTFORMATS)
X8R8G8B8
A8R8G8B8
Additional Information
| Business Justification |
The WDDM v1.1 DXVA-HD requirements ensure that processing of the common video formats is enabled for all existing applications that rely on DXVA and DXVA-HD. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12
The base feature set implemented by drivers supporting WDDM 1.2.
| Related Requirements |
Device.Graphics.WDDM12.Base |
Device.Graphics.WDDM12.Base
Graphics drivers must be implemented per WDDM 1.2 spec
| Target Feature |
Device.Graphics.WDDM12 |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Windows 8 also introduces features and capabilities that require graphics driver changes. These incremental changes range from small changes such as smooth rotation, to large changes such as 3D stereo, and D3D11 video support. The WDDM driver model that provides these Windows 8 features is referred to as "WDDM v1.2" WDDM v1.2 is a superset of WDDM 1.1, and WDDM 1.0. WDDM v1.2 is required by all systems shipped with Windows 8. WDDM 1.0 and WDDM 1.1 will only be supported with legacy devices on legacy systems. The best experience, and Windows 8 specific features are only enabled by a WDDM 1.2 driver. A WDDM driver that implements some WDDM 1.2 required features, but not all required features will fail to load on Windows 8.For Windows 8 XDDM is officially retired and XDDM drivers will no longer load on Windows 8 Client or Server. Below is a summary these WDDM versions:
| Operating System |
Driver Models Supported |
D3D versions supported |
Features enabled |
| Windows Vista |
WDDM 1.0XDDM on Server and limited UMPC |
D3D9, D3D10 |
Scheduling, Memory Management, Fault tolerance, D3D9 & 10 |
| Windows Vista SP1 / Windows 7 client pack |
WDDM 1.05XDDM on Server 2008 |
D3D9, D3D10, D3D10.1 |
+ BGRA support in D3D10, D3D 10.1 |
| Windows 7 |
WDDM 1.1XDDM on Server 2008 R2 |
D3D9, D3D10, D3D10.1, D3D11 |
GDI Hardware acceleration, Connecting and configuring Displays, DXVA HD, D3D11 |
| Windows 8 |
WDDM 1.2 |
D3D9, D3D10, D3D10.1, D3D11, D3D11.1 |
Smooth Rotation, 3D Stereo, D3D11 Video, GPU Preemption,TDR ImprovementsDiagnostic Improvements,Performance and Memory usage Optimizations,Power Management,etc. |
WDDM v1.2 also introduces new types of graphics drivers, targeting specific scenarios and is described below:
WDDM Full Graphics Driver: This is the full version of the WDDM graphics driver that supports hardware accelerated 2D & 3D operations. This driver is fully capable of handling all the render, display and video functions. WDDM 1.0 and WDDM 1.1 are full graphics drivers. All Windows 8 client systems must have a full graphics WDDM 1.2 device as the primary boot device.
WDDM Display Only Driver: This driver is only supported as a WDDM 1.2 driver and enables IHVs to write a WDDM based kernel mode driver that is capable of driving display only devices. The OS handles the 2D or 3D rendering using a software simulated GPU.
WDDM Render Only Driver: This driver is only supported as a WDDM 1.2 driver and enables IHVs to write a WDDM driver that supports only rendering functionality. Render only devices are not allowed as the primary graphics device on client systems.
Table below explains the scenario usage for the new driver types:
| Client |
Server |
Client running in a Virtual Environment |
Server Virtual |
|
| Full Graphics |
Required as boot device |
Optional |
Optional |
Optional |
| Display Only |
Not allowed |
Optional |
Optional |
Optional |
| Render Only |
Optional as non primary adapter |
Optional |
Optional |
Optional |
| Headless |
Not allowed |
Optional |
N/A |
N/A |
WDDM v1.2 Feature caps
Table below lists the requirements for a WDDM v1.2 driver to specify to Windows the WDDM Driver Type, version and the feature caps (visible to dxgkrnl) that WDDM v1.2 drivers are required to set. If a driver has wrongfully claimed itself as "WDDM v1.2" or has implemented partial features (only some of the mandatory features), then it will fail to create an adapter and the system will fall back to the Microsoft Basic Display Driver.WDDM Driver Requirements
| WDDM driver type |
DDI requirements |
| Full Graphics |
Implement all the Render-specific and the Display-specific required DDIs |
| Display-Only |
Implement all the Display-specific DDIs and return a null pointer for all the Render-specific DDIs |
| Render-Only |
Implement all the Render-specific DDIs and return a null pointer for all the Display-specific DDIsOR Implement all the DDIs for a full WDDM driver but report DISPLAY_ADAPTER_INFO::NumVidPnSources = 0 and DISPLAY_ADAPTER_INFO::NumVidPnTargets = 0 |
WDDM v1.2 Feature Caps
Feature
WDDM Driver Type
Feature Caps
Full Graphics
Render Only
Display Only
WDDM version
M
M
M
DXGK_DRIVERCAPS::WDDMVersion
Bugcheck and PnP Stop support for Non VGA
M
NA
M
DXGK_DRIVERCAPS::SupportNonVGA
Optimized screen rotation Support
M
NA
M
DXGK_DRIVERCAPS::SupportSmoothRotation
GPU Preemption
M
M
NA
DXGK_DRIVERCAPS::PreemptionCaps
FlipOnVSyncMmIo
M
M
NA
DXGK_FLIPCAPS::FlipOnVSyncMmIoFlipOnVSyncMmIo is NOT a new feature; this is already documented and has been available since Windows Vista; the requirement here is to set FlipOnVSyncMmIo cap
TDR Improvements
M
M
NA
DXGK_DRIVERCAPS::SupportPerEngineTDR
Optimizing the graphics stack to improve performance on sleep & resume
O
O
NA
DXGK_SEGMENTDESCRIPTOR3::Flags
Stereoscopic 3D: New infrastructure to process and present stereoscopic content
O
NA
NA
D3DKMDT_VIDPN_SOURCE_MODE_TYPE
DirectFlip
M
NA
NA
DXGK_DRIVERCAPS::SupportDirectFlip
GDI Hardware acceleration (This is a required WDDM v1.1 feature)
M
M
NA
DXGK_PRESENTATIONCAPS::SupportKernelModeCommandBuffer
GPU power management of idle and active power
O
O
O
If this feature is supported the DDI functions must be supported (SetPowerComponentFState and PowerRuntimeControlRequest)
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Display
Display feature requirements for all WDDM12 drivers which support the display specific DDIs.
| Related Requirements |
Device.Graphics.WDDM12.Display.Base Device.Graphics.WDDM12.Display.ContainerIDSupport Device.Graphics.WDDM12.Display.DisplayOutputControl Device.Graphics.WDDM12.Display.ModeEnumeration Device.Graphics.WDDM12.Display.PnpStopStartSupport Device.Graphics.WDDM12.Display.ProvideLinearFrameBuffer |
Device.Graphics.WDDM12.Display.Base
Requirements for a WDDM graphics adapter to support display functionality
| Target Feature |
Device.Graphics.WDDM12.Display |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
In Windows 8 and beyond WDDM has been extended to support a WDDM driver that is only responsible for Display Scan out capabilities. Such a driver is not allowed to support any Rendering capabilities. A driver is considered a WDDM Display Only driver if it implements the following DDIs
Common WDDM DDIs
These DDIs are for the common device functionalities such as PnP support and Power support. These functions are required by all WDDM drivers and if not implemented the driver will not be started by Windows. These DDIs are already documented in the WDK. Required:DxgkDdiAddDevice DxgkDdiStartDevice DxgkDdiStopDeviceDxgkDdiRemoveDevice DxgkDdiDispatchIoRequestDxgkDdiSetPowerState DxgkDdiUnloadOptional:DxgkDdiInterruptRoutine*DxgkDdiDpcRoutineDxgkDdiNotifyAcpiEventDxgkDdiQueryInterfaceDxgkDdiControlEtwLoggingDxgkDdiEscapeDxgkDdiCollectDbgInfo*DxgkDdiInterruptRoutine function is required if current hardware device reports hardware interrupt. In this case , if driver did not supply this DDI function, OS would fail the initialization. If current hardware does not have interrupt and driver supplies this DDI function, OS will still allow this driver to be loaded and DxgkDdiInterruptRoutine will never be called.* DdiNotifyAcpiEvent DDI function is used to notify graphics drivers on some ACPI events. It is optional for rendering device. On normal WDDM graphics devices, this DDI function will return a flag to indicate dxgkrnl.sys to take some further actions such as reset display mode or poll the connected monitors. For the rendering only device, these flags are not used and must be set to zero
Display Only DDIs
Following DDI functions are required to be implemented by a Display Only driver. If the driver does not supply all of these DDIs, Windows will fail to initialize this driver.DxgkDdiQueryChildRelationsDxgkDdiQueryChildStatusDxgkDdiQueryDeviceDescriptorDxgkDdiResetDeviceDxgkDdiQueryAdapterInfoDxgkDdiSetPalette * DxgkDdiSetPointerPosition **DxgkDdiSetPointerShape **DxgkDdiIsSupportedVidPnDxgkDdiRecommendFunctionalVidPn ***DxgkDdiEnumVidPnCofuncModalityDxgkDdiSetVidPnSourceVisibilityDxgkDdiCommitVidPnDxgkDdiUpdateActiveVidPnPresentPathDxgkDdiRecommendMonitorModesDxgkDdiGetScanLineDxgkDdiQueryVidPnHWCapabilityDxgkDdiPresentDisplayOnlyDxgkDdiReleasePostDisplayOwnershipDxgkDdiSystemDisplayEnable DxgkDdiSystemDisplayWriteDxgkDdiI2CReceiveDataFromDisplayDxgkDdiI2CTransmitDataFromDisplay*DxgkDdiSetPalette is a required DDI. If driver does not support any palette mode, it should still supply this DDI.**DxgkDdiSetPointerPosition and DxgkDdiSetPointerShape are required DDIs. If driver does not support any hardware cursor, it should still supply these two DDIs.***DxgkDdiRecommendFunctionalVidPn is a required DDI. If driver does not support any ACPI event, it should still supply this DDI.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Display.ContainerIDSupport
Graphics Adapter must support the DDI for Container ID
| Target Feature |
Device.Graphics.WDDM12.Display |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
A graphics adapter must implement the DxgkDdiGetDeviceContainer DDI. Windows will use this DDI to ask the driver for the container ID. The driver must try and obtain the Container ID from the display hardware. In case the Display device does not provide a Container ID, then Windows will automatically manufacture a Container ID for the display. The uniqueness of the Container ID is achieved by using the Manufacture ID, Product ID and Serial number of the display obtained from the EDID. Using this information, a driver for another device can generate the same container ID as the display device by using the RtlGenerateClass5Guid function included in wdm.h.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Display.DisplayOutputControl
Support for WDDM taking control of Display output while WDDM driver is running
| Target Feature |
Device.Graphics.WDDM12.Display |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
In Windows 8 and beyond, there is a need for a more seamless hand off of the display control between Windows and the WDDM graphics driver. This means that in some cases Windows needs to take over the control of the Display scan out without having to PnP Stop the WDDM Driver. One such scenario is when Windows needs to bug check the system and display the blue screen. This set of DDIs enables that cleaner hand off.The following DDIs are required to be implemented by a Full and Display Only WDDM 1.2 driverDxgkDdiSystemDisplayEnableDxgkDdiSystemDisplayWriteThese DDIs are documented here on WDK. The following are the requirements for WDDM driver while implementing these DDIs:
When Windows calls DxgkDdiSystemDisplayEnable, driver must cancel all the GPU operations or reset GPU to an idle state
Windows will provide a Target ID as part of the DDI call. The driver must continue to drive the display associated with the target ID
The driver must check the connectivity of the display on the provided Target ID. If specified target does not have a display connected, driver should fail this call with STATUS_NOT_SUPPORTED.
The driver must disable the signal to all other displays connected to the adapter except the target ID provided.
If this is not possible, driver should try and put a blank image on all other displays
If this is not possible, driver must leave the last image on the screen unchanged
For the selected Target ID, the driver must keep the current display mode and provide this mode back to Windows as part of the DDI call
In case the driver is not able to maintain the current mode OR the target ID is not part of the active topology, the driver should try and set the native resolution of the display OR a high res mode. At the very least the driver must reset to a mode which is larger than or equals to 640x480 24bpp color format on the specified target.
It is NOT required that driver should use linear frame buffer mode. But driver should support the write operation from a D3DDDIFMT_A8R8G8B8 source to this frame buffer.
This function might be called at high IRQL level or after system has been bugcheck. Driver should put this function in non-paged code section and only use non-paged memory.
Windows kernel mode functions might be also NOT available when this function is called.
Once the driver has handed over Display Control to Windows, Windows will use the DxgkDdiSystemDisplayWrite DDI to update the screen image. Windows will use the DDI to write a block of image from specified source image to the screen which is reset via DxgkDdiSystemDisplayEnable function. This function will pass the driver the start address of source image as well as the stride, width, and height. The color format of source image is always D3DDDIFMT_X8R8G8B8. Windows guarantees that the source image is in non-paged memory. Driver must write this source image to current screen at (PostionX, PositionY).
This function might be called at high IRQL level or after system has been bugcheck. Driver should put this function in non-paged code section and only use non-paged memory.
Windows kernel mode functions might be also NOT available when this function is called.
It is recommended to use the CPU to write the image from source to the frame buffer since the bugcheck might be caused by repeated TDR and the GPU might be in an unknown condition.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Display.ModeEnumeration
Mode enumeration requirements
| Target Feature |
Device.Graphics.WDDM12.Display |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Target modes
Graphics Adapter must be able to scan out any resolution that is greater than or equal to 1024 x 768 progressive at 32 bpp and a maximum timing which is up to 148.5 Mhz pixel clock per the VESA and Industry Standards and Guidelines for Computer Display Monitor Timing (DMT) Nov 2007 Update or CEA-861-E specs. The graphics driver may support modes that are greater than or less then these constraint's but the driver is not required to do so.
The graphics drier is not required to support any interlaced timings, but may choose to do so
During DxgkDdiEnumVidPnCofuncModality DDI call, the supported target modes must be greater than or equal to the pinned source modes except for analog TV connector type or if the target cannot support any timing with a resolution of 1024 x 768 or greater. This means that for all other conditions the driver is only allowed to scale up. Driver can support downscaling if the user requests it specifically for overscan compensation on TVs.
Source modes
Graphics Adapter must support the native resolution of the integrated panel.
If the Graphics Adapter has enough bandwidth, it must support the native resolution of any connected display
Graphics driver must enumerate at least one source mode for every achievable Detailed timing in the EDID of the display
If the only mode supported by the display device is less than or equal to 640 x 480, then the driver can downscale in this case. However, the source mode must be at least 800 x 600.
Graphics driver must only enumerate sources modes of 32 bpp or higher.
For Duplicate (Clone) mode
If there are 2 displays configured in duplicate mode, the Graphics Adapter must support setting the following configuration
If there are any common detailed timings between the 2 displays that are less than or equal to 1920 x 1080 progressive at 32 bpp, the Graphics Adapter must support driving the displays at this timing in duplicate mode
At a minimum 1024 x 768 must be supported in duplicate mode
For more than 2 displays configured in duplicate mode, the Graphics Adapter may chose an appropriate mode to support
At a minimum, irrespective of the number of displays in duplicate mode, the Graphics Adapter must be able to support a Source Mode of 1024 x 768 progressive at 32 bpp in duplicate mode
For Extend mode
If there are 2 displays configured in extended mode, the Graphics Adapter must support setting the following configuration
On systems with integrated displays: Native resolution on integrated display and simultaneously up to 1920 x 1080 progressive at 32 bpp on the non-integrated display
Up to 1920 x 1080 progressive at 32 bpp on each non-integrated display
For more than 2 displays configured in extended mode, the Graphics Adapter may chose appropriate set of modes to support based on available bandwidth
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Display.PnpStopStartSupport
Support for PnP Stop in WDDM
| Target Feature |
Device.Graphics.WDDM12.Display |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
Since the introduction of WDDM, every driver is required to support PnP Start and Stop. This requirement enhances the support for PnP start and stop in WDDM. Once a WDDM driver is stopped, Windows needs to take over the display control and when the driver is started, Windows needs to hand back display control to the driver. In Windows 8, WDDM 1.2 introduces a new DDI to add support for UEFI based systems and also to improve the user experience in such a scenario. The following DDIs are required to be implemented by a Full and Display Only WDDM 1.2 driverDxgkDdiReleasePostDisplayOwnershipThe following are the requirements for the driver when implementing this DDI
Windows will provide a Target ID as part of the DDI call. The driver must continue to drive the display associated with the target ID
The driver must check the connectivity of the display on the provided Target ID. If specified target does not have a display connected, driver should fail this call with STATUS_NOT_SUPPORTED.
The driver must disable the signal to all other displays connected to the adapter except the target ID provided.
If this is not possible, driver should try and put a blank image on all other displays
If this is not possible, driver must leave the last image on the screen unchanged
If there is an ACPI ID associated with the target ID, then that must be provided back to Windows as part of the return data structure PDXGK_DISPLAY_INFORMATION
For the selected Target ID, the driver must keep the current display mode and provide this mode back to Windows as part of the DDI call
In case the driver is not able to maintain the current mode OR the target ID is not part of the active topology, the driver should select an alternate active target and try and maintain the current resolution of that target. If that is not possible the driver should try and set the native resolution of the display OR a high res mode. At the very least the driver must reset to a mode which is larger than or equals to 800x600 24bpp (D3DDDIFMT_R8G8B8) or 32bpp (D3DDDIFMT_X8R8G8B8).
If no target is active, then the driver should attempt to enable a target. Preferably the internal panel (if available)
Driver must clean the current frame buffer, disable hardware cursor, disable all overlays and set to default GAMMA ramp.
Driver must make the current frame buffer linear (either by using swizzle range or disabling swizzle mode).
Driver must make the current frame buffer accessible by CPU
Driver must ensure that visibility is set to "enabled" on the specified target
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Display.ProvideLinearFrameBuffer
Graphics Device can provide a linear frame buffer usable by Windows
| Target Feature |
Device.Graphics.WDDM12.Display |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
There are numerous scenarios where components in the Windows OS need to be able to update the display when an IHV driver is not loaded. Some of these scenarios are: Boot, Bugcheck, safemode, driver upgrades, etc. To ensure a graphics device is compatible with these Windows scenarios it must:1) Ensure updates to the frame buffer must be scanned out without requiring addition IHV/OEM software/drivers. 2) Provide a linear frame buffer that is CPU accessible on demand from the IHV driver.3) On UEFI systems at boot using UEFI 2.3 GOP4) On BIOS systems using VBE 3.0 standards.This requirement is intended to provide the necessary support of SYSFUND-8081(SystemUEFIDisplay) and SYSFUND-8082(DisplayReqVideoBIOS)
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.DisplayOnly
The optional feature set implemented by WDDM 1.2 drivers which support only the display specific DDIs.
| Related Requirements |
Device.Graphics.WDDM12.DisplayOnly.Base |
Device.Graphics.WDDM12.DisplayOnly.Base
Requirements for a WDDM graphics adapter to support display functionality
| Target Feature |
Device.Graphics.WDDM12.DisplayOnly |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2008 Release 2 x64 Windows Server 2012 x64 |
Description
In Windows 8 and beyond WDDM has been extended to support a WDDM driver that is only responsible for Display Scan out capabilities. Such a driver is not allowed to support any Rendering capabilities. A driver is considered a WDDM Display Only driver if it only implements the following DDIs and does not implement any of the render DDIs
Common WDDM DDIs
These DDIs are for the common device functionalities such as PnP support and Power support. These functions are required by all WDDM drivers and if not implemented the driver will not be started by Windows. These DDIs are already documented in the WDK. Required:DxgkDdiAddDevice DxgkDdiStartDevice DxgkDdiStopDeviceDxgkDdiRemoveDevice DxgkDdiDispatchIoRequestDxgkDdiSetPowerState DxgkDdiUnloadOptional:DxgkDdiInterruptRoutine*DxgkDdiDpcRoutineDxgkDdiNotifyAcpiEventDxgkDdiQueryInterfaceDxgkDdiControlEtwLoggingDxgkDdiEscapeDxgkDdiCollectDbgInfo*DxgkDdiInterruptRoutine function is required if current hardware device reports hardware interrupt. In this case , if driver did not supply this DDI function, OS would fail the initialization. If current hardware does not have interrupt and driver supplies this DDI function, OS will still allow this driver to be loaded and DxgkDdiInterruptRoutine will never be called.* DdiNotifyAcpiEvent DDI function is used to notify graphics drivers on some ACPI events. It is optional for rendering device. On normal WDDM graphics devices, this DDI function will return a flag to indicate dxgkrnl.sys to take some further actions such as reset display mode or poll the connected monitors. For the rendering only device, these flags are not used and must be set to zero
Display Only DDIs
Following DDI functions are required to be implemented by a Display Only driver. If the driver does not supply all of these DDIs, Windows will fail to initialize this driver.DxgkDdiQueryChildRelationsDxgkDdiQueryChildStatusDxgkDdiQueryDeviceDescriptorDxgkDdiResetDeviceDxgkDdiQueryAdapterInfoDxgkDdiSetPalette * DxgkDdiSetPointerPosition **DxgkDdiSetPointerShape **DxgkDdiIsSupportedVidPnDxgkDdiRecommendFunctionalVidPn ***DxgkDdiEnumVidPnCofuncModalityDxgkDdiSetVidPnSourceVisibilityDxgkDdiCommitVidPnDxgkDdiUpdateActiveVidPnPresentPathDxgkDdiRecommendMonitorModesDxgkDdiGetScanLineDxgkDdiQueryVidPnHWCapabilityDxgkDdiPresentDisplayOnlyDxgkDdiReleasePostDisplayOwnershipDxgkDdiSystemDisplayEnable DxgkDdiSystemDisplayWrite*DxgkDdiSetPalette is a required DDI. If driver does not support any palette mode, it should still supply this DDI.**DxgkDdiSetPointerPosition and DxgkDdiSetPointerShape are required DDIs. If driver does not support any hardware cursor, it should still supply these two DDIs.***DxgkDdiRecommendFunctionalVidPn is a required DDI. If driver does not support any ACPI event, it should still supply this DDI.Design Note:The only color format supported for display only drivers is D3DDDIFMT_A8R8G8B8 therefore these drivers should only enumerate source modes of this format.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.DisplayRender
The optional feature set implemented by WDDM 1.2 drivers supporting both display and render DDIs.
| Related Requirements |
Device.Graphics.WDDM12.DisplayRender.Base |
Device.Graphics.WDDM12.DisplayRender.Base
Requirements for a WDDM graphics adapter implementing both Render and Display DDIs
| Target Feature |
Device.Graphics.WDDM12.DisplayRender |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
In Windows 8 and beyond WDDM has been extended to support a WDDM driver that is only responsible for Display Scan out capabilities. Such a driver is not allowed to support any Rendering capabilities. In Windows 8 and beyond WDDM has also been extended to support a WDDM driver that is only responsible for Rendering and Compute DDIs. Such a driver is not allowed to support any Display Scan out capabilities. Driver's implementing both sets of DDI's (Display and Render) are considered full graphics adapters.
Common WDDM DDIs
These DDIs are for the common device functionalities such as PnP support and Power support. These functions are required by all WDDM drivers and if not implemented the driver will not be started by Windows. These DDIs are already documented in the WDK. Required:DxgkDdiAddDevice DxgkDdiStartDevice DxgkDdiStopDeviceDxgkDdiRemoveDevice DxgkDdiDispatchIoRequestDxgkDdiSetPowerState DxgkDdiUnloadOptional:DxgkDdiInterruptRoutine*DxgkDdiDpcRoutineDxgkDdiNotifyAcpiEventDxgkDdiQueryInterfaceDxgkDdiControlEtwLoggingDxgkDdiEscapeDxgkDdiCollectDbgInfo*DxgkDdiInterruptRoutine function is required if current hardware device reports hardware interrupt. In this case , if driver did not supply this DDI function, OS would fail the initialization. If current hardware does not have interrupt and driver supplies this DDI function, OS will still allow this driver to be loaded and DxgkDdiInterruptRoutine will never be called.
Display Only DDIs
Following DDI functions are required to be implemented by a Display Only driver. If the driver does not supply all of these DDIs, Windows will fail to initialize this driver.DxgkDdiQueryChildRelationsDxgkDdiQueryChildStatusDxgkDdiQueryDeviceDescriptorDxgkDdiResetDeviceDxgkDdiQueryAdapterInfoDxgkDdiSetPalette * DxgkDdiSetPointerPosition **DxgkDdiSetPointerShape **DxgkDdiIsSupportedVidPnDxgkDdiRecommendFunctionalVidPn ***DxgkDdiEnumVidPnCofuncModalityDxgkDdiSetVidPnSourceVisibilityDxgkDdiCommitVidPnDxgkDdiUpdateActiveVidPnPresentPathDxgkDdiRecommendMonitorModesDxgkDdiGetScanLineDxgkDdiQueryVidPnHWCapabilityDxgkDdiPresentDisplayOnlyDxgkDdiReleasePostDisplayOwnershipDxgkDdiSystemDisplayEnable DxgkDdiSystemDisplayWrite*DxgkDdiSetPalette is a required DDI. If driver does not support any palette mode, it should still supply this DDI.**DxgkDdiSetPointerPosition and DxgkDdiSetPointerShape are required DDIs. If driver does not support any hardware cursor, it should still supply these two DDIs.***DxgkDdiRecommendFunctionalVidPn is a required DDI. If driver does not support any ACPI event, it should still supply this DDI.* DdiNotifyAcpiEvent DDI function is used to notify graphics drivers on some ACPI events. It is optional for rendering device. On normal WDDM graphics devices, this DDI function will return a flag to indicate dxgkrnl.sys to take some further actions such as reset display mode or poll the connected monitors. For the rendering only device, these flags are not used and must be set to zero
Rendering only DDIs
These DDI functions are for the rendering functionalities. Required: DxgkDdiInterruptRoutine DxgkDdiDpcRoutine DxgkDdiResetDevice DxgkDdiCreateDeviceDxgkDdiDestroyAllocationDxgkDdiDescribeAllocationDxgkDdiOpenAllocationDxgkDdiCloseAllocationDxgkDdiGetStandardAllocationDriverDataDxgkDdiSubmitCommandDxgkDdiPreemptCommandDxgkDdiBuildPagingBufferDxgkDdiResetFromTimeoutDxgkDdiRestartFromTimeoutDxgkDdiQueryCurrentFenceDxgkDdiControlInterruptDxgkDdiDestroyDeviceDxgkDdiPresentDxgkDdiCreateAllocationDxgkDdiPatchDxgkDdiRenderDxgkDdiRenderKmOptional:If rendering hardware support swizzling ranger, driver should also supply following two functionsDxgkDdiAcquireSwizzlingRangeDxgkDdiReleaseSwizzlingRange
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.DisplayRender.ProcessingStereoscopicVideoContent
The optional feature set implemented by WDDM 1.2 drivers which support stereoscopic video processing.
| Related Requirements |
Device.Graphics.WDDM12.DisplayRender.ProcessingStereoscopicVideoContent.ProcessingStereoscopicVideoContent |
Device.Graphics.WDDM12.DisplayRender.ProcessingStereoscopicVideoContent.ProcessingStereoscopicVideoContent
If Display adapter supports presentation and processing of stereoscopic video content it must conform to the DXGI specification for Stereo 3D
| Target Feature |
Device.Graphics.WDDM12.DisplayRender.ProcessingStereoscopicVideoContent |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
WDDM 1.2 drivers may optionally process video data encoded for stereo. If the driver publishes that it can support stereo, it must support processing of content in horizontally and vertically arranged left and right eye views, as well as separate streams for the left and right eye views.In addition, if the driver publishes that it can support stereo, it may optionally also process the following stereo content layouts:
Row interleaved
Column interleaved
Checkerboard
Flipped Configurations
Finally, the driver may optionally support new stereo processing features:
Mono offset
Stereo Eye Adjustment
For all optional content layouts and processing features, the driver must publish the appropriate cap to indicate if it supports the feature.
Additional Information
| Business Justification |
Enabling physical and streaming 3DS media content on Win8 will allow consumers to watch their favorite media content on their PCs and utilize their stereo video hardware (TVs, monitors, shutter glasses, etc) with Windows. This should also spur the sales of high-end PCs, Monitors and Laptops. Mono offset provides the ability to generate menus and overlays for stereo displays from non-stereo content. This is used for stereo blu-ray menus. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.DisplayRender.RuntimePowerMgmt
The optional feature set implemented by WDDM 1.2 drivers which support the runtime power management DDIs.
| Related Requirements |
Device.Graphics.WDDM12.DisplayRender.RuntimePowerMgmt.RuntimePowerMgmt |
Device.Graphics.WDDM12.DisplayRender.RuntimePowerMgmt.RuntimePowerMgmt
If implemented - WDDM 1.2 drivers must use the new WDDM 1.2 GPU Power Management DDI for F-state and p-state power management.
| Target Feature |
Device.Graphics.WDDM12.DisplayRender.RuntimePowerMgmt |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
WDDM 1.2 drivers can optionally support F-state and p-state Power Management.For more details on the use of the SoC GPU Power Management WDDM v1.2 DDI, please refer to the Windows 8 WDK documentation.
Additional Information
| Business Justification |
Energy Efficiency has become a key distinguishing feature for OEMs today. Given the proliferation of small form factors, the concept of "All day Battery Life" is being strived for. The scenario here is that you carry your mobile device without the power brick and only at the end of the day; you plug it into the power source for recharging the battery. GPUs and Displays are two of the largest power consumers in desktops and mobile devices; hence the importance of managing the Idle and Active power cannot be understated. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Render
The base feature set implemented by WDDM 1.2 drivers which support the render specific DDIs.
| Related Requirements |
Device.Graphics.WDDM12.Render.Base Device.Graphics.WDDM12.Render.D3D11VideoDecoding Device.Graphics.WDDM12.Render.D3D11VideoProcessing Device.Graphics.WDDM12.Render.DirectFlip Device.Graphics.WDDM12.Render.FlipOnVSyncMmIo Device.Graphics.WDDM12.Render.OfferReclaim Device.Graphics.WDDM12.Render.PreemptionGranularity Device.Graphics.WDDM12.Render.PremiumContentPlayback Device.Graphics.WDDM12.Render.TDRResiliency Device.Graphics.WDDM12.Render.UMDLogging Device.Graphics.WDDM12.Render.XPSRasterizationConformance |
Device.Graphics.WDDM12.Render.Base
Requirements for a WDDM graphics adapter to support render functionality
| Target Feature |
Device.Graphics.WDDM12.Render |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
In Windows 8 and beyond WDDM has been extended to support a WDDM driver that is only responsible for Rendering and Compute DDIs. Such a driver is not allowed to support any Display Scan out capabilities. A driver is considered a WDDM Render Only driver if one of the following two conditions is met:
The driver implements all the DDIs required for a full WDDM driver but reports 0 sources and 0 targets
The driver implements all the Render specific DDIs and returns a null pointer for all the Display specific DDIs. The DDIs required for this are called out below
Common WDDM DDIs
These DDI functions are for the common device functionalities such as PnP support and Power support. These functions are required by all WDDM drivers and if not implemented the driver will not be started by Windows. These DDIs are already documented in the WDK: https://msdn.microsoft.com/library/ff554066(v=VS.85).aspx. Required:DxgkDdiAddDevice DxgkDdiStartDevice DxgkDdiStopDeviceDxgkDdiRemoveDevice DxgkDdiDispatchIoRequestDxgkDdiSetPowerState DxgkDdiUnloadOptional:DdiNotifyAcpiEvent ** DdiNotifyAcpiEvent DDI function is used to notify graphics drivers on some ACPI events. It is optional for rendering device. On normal WDDM graphics devices, this DDI function will return a flag to indicate dxgkrnl.sys to take some further actions such as reset display mode or poll the connected monitors. For the rendering only device, these flags are not used and must be set to zero
Rendering only DDIs
These DDI functions are for the rendering functionalities. Required: DxgkDdiInterruptRoutine DxgkDdiDpcRoutine DxgkDdiResetDevice DxgkDdiCreateDeviceDxgkDdiDestroyAllocationDxgkDdiDescribeAllocationDxgkDdiOpenAllocationDxgkDdiCloseAllocationDxgkDdiGetStandardAllocationDriverDataDxgkDdiSubmitCommandDxgkDdiPreemptCommandDxgkDdiBuildPagingBufferDxgkDdiResetFromTimeoutDxgkDdiRestartFromTimeoutDxgkDdiQueryCurrentFenceDxgkDdiControlInterruptDxgkDdiDestroyDeviceDxgkDdiPresentDxgkDdiCreateAllocationDxgkDdiPatchDxgkDdiRenderDxgkDdiRenderKmOptional:If rendering hardware support swizzling ranger, driver should also supply following two functionsDxgkDdiAcquireSwizzlingRangeDxgkDdiReleaseSwizzlingRange
Additional Information
| Business Justification |
Over the years there has been an increasing focus on GPGPU scenarios for doing vast amount of complex mathematical or graphical operations. Some of the common examples of this are graphics rendering for animation, database processing, financial & astronomical calculations and oil and gas exploration. The use of GPGPU has proved benefits in performance, power consumption and cost. This feature makes it easier for an OEM to ship a system specifically targeted for such a use without having the added complexity of supporting a display device |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Render.D3D11VideoDecoding
Display driver supports the DirectX 11 Video Decoder DDI
| Target Feature |
Device.Graphics.WDDM12.Render |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Display WDDM 1.2 drivers must support the DirectX 11 Video Decoder DDI. WDDM drivers must support at least one of the following sets of MPEG2 GUIDs:
D3D11_DECODER_PROFILE_MPEG2_VLD and D3D11_DECODER_PROFILE_MPEG2_IDCT
D3D11_DECODER_PROFILE_MPEG2_VLD and D3D11_DECODER_PROFILE_MPEG2_MOCOMP
D3D11_DECODER_PROFILE_MPEG2_IDCT
D3D11_DECODER_PROFILE_MPEG2AND1_VLD
And at least one of the H.264 GUIDs:
D3D11_DECODER_PROFILE_H264_MOCOMP_NOFGT
D3D11_DECODER_PROFILE_H264_MOCOMP_FGT
D3D11_DECODER_PROFILE_H264_VLD_NOFGT
D3D11_DECODER_PROFILE_H264_VLD_FGT
In addition, WDDM drivers must support at least one of the following VC1 modes:
D3D11_DECODER_PROFILE_VC1_MOCOMP
D3D11_DECODER_PROFILE_VC1_IDCT
D3D11_DECODER_PROFILE_VC1_VLD
D3D11_DECODER_PROFILE_VC1_D2010
WDDM drivers must support Standardized AES 128 (defined in the WDDM v1.1 specifications) for both MPEG2 and H.264***.Finally, WDDM drivers must support DXGI_FORMAT_420_OPAQUE and DXGI_FORMAT_NV_12 as decoder output formats.Design Notes
MPEG-2 support is required on x86 and x64 architectures and operating systems only.
** Note that it is not a requirement to implement the "Post-Proc" stage on DXVA2_ModeVC1 GUIDs.
*** Standardized AES 128 support is required on x86 and x64 architectures and operating systems only.
Additional Information
| Business Justification |
Requiring video decode support on all Windows system ensure us that consumers can rely upon Windows as a platform for viewing high-quality video content. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Render.D3D11VideoProcessing
Display driver supports appropriate DDIs for DirectX 11 Video Processing
| Target Feature |
Device.Graphics.WDDM12.Render |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
The following video processor device capability DDIs must be supported:
BOB Deinterlacing
DXVAHDDDI_PROCESSOR_CAPS_DEINTERLACE_BOB
D3D11_1DDI_VIDEO_PROCESSOR_PROCESSOR_CAPS_DEINTERLACE_BOB
Constriction
DXVAHDDDI_FEATURE_CAPS_CONSTRICTION
D3D11_1DDI_VIDEO_PROCESSOR_FEATURE_CAPS_CONSTRICTION
Rotation
DXVAHDDDI_FEATURE_CAPS_ROTATION
D3D11_1DDI_VIDEO_PROCESSOR_FEATURE_CAPS_ROTATION
Arbitrary stretching/shrinking
Both full and nominal RGB ranges must be supported on the input and the output YCbCr data, specifically:
0 to 255
DXVAHDDDI_STREAM_STATE_INPUT_COLOR_SPACE_DATA
RGB_Range field is set to 0
DXVAHDDDI_BLT_STATE_OUTPUT_COLOR_SPACE_DATA RGB_Range field is set to 0
D3D11_1DDI_VIDEO_PROCESSOR_COLOR_SPACE RGB_Range field set to 0
16 to 235
DXVAHDDDI_STREAM_STATE_INPUT_COLOR_SPACE_DATA
RGB_Range field is set to 1
DXVAHDDDI_BLT_STATE_OUTPUT_COLOR_SPACE_DATA RGB_Range field is set to 1
D3D11_1DDI_VIDEO_PROCESSOR_COLOR_SPACE RGB_Range field set to 1
BT. 601 and BT. 709 conversion matrices must be supported on the input and the output YCbCr data, specifically:
DXVAHDDDI_STREAM_STATE_INPUT_COLOR_SPACE_DATA.YCbCr_Matrix
Both setting the field to 0 (representing BT.601) and 1 (representing BT.709) must be supported.
DXVAHDDDI_BLT_STATE_OUTPUT_COLOR_SPACE_DATA.YCbCr_Matrix
Both setting the field to 0 (representing BT.601) and 1 (representing BT.709) must be supported.
D3D11_1DDI_VIDEO_PROCESSOR_COLOR_SPACE.YCbCr_Matrix
Both setting the field to 0 (representing BT.601) and 1 (representing BT.709) must be supported.
Arbitrary background color
Per-stream source rectangle
Per-stream destination rectangle
Overall destination rectangle
At least one stream
The following formats must be supported for input:
D3DFMT_420_OPAQUE
D3DFMT_NV12
D3DFMT_YUY2
Any formats supported as output from DXVA 2.0 decode or DirectX 11 Video decode
Depending on the feature level made available by the driver for Direct3D (e.g. 9.1 - 9.3 for Direct3D 9 DDIs, 10.0 for Direct3D 10 DDIs, etc.), the following formats must be supported for output:
9.1 - 9.3 Feature Levels
D3DFMT_A8R8G8B8
D3DFMT_NV12
10.0 - 10.1 Feature Levels
DXGI_FORMAT_R16G16B16A16_FLOAT
DXGI_FORMAT_R8G8B8A8_UNORM
DXGI_FORMAT_R10G10B10A2_UNORM
DXGI_FORMAT_R8G8B8A8_UNORM_SRGB
DXGI_FORMAT_NV12
The following formats are also required if the driver supports these as a swapchain format:
DXGI_FORMAT_B8G8R8A8_UNORM
DXGI_FORMAT_B8G8R8A8_UNORM_SRGB
DXGI_FORMAT_R10G10B10_XR_BIAS_A2_UNORM
11.0 Feature Level and beyond
DXGI_FORMAT_R16G16B16A16_FLOAT
DXGI_FORMAT_R8G8B8A8_UNORM
DXGI_FORMAT_R10G10B10A2_UNORM
DXGI_FORMAT_R8G8B8A8_UNORM_SRGB
DXGI_FORMAT_NV12, DXGI_FORMAT_B8G8R8A8_UNORM
DXGI_FORMAT_B8G8R8A8_UNORM_SRGB
DXGI_FORMAT_R10G10B10_XR_BIAS_A2_UNORM
Design Notes
MPEG-2 support is required on x86 and x64 architectures and operating systems only.
Additional Information
| Business Justification |
Basic functionality of defined in the most common video specifications (e.g. H.264, Blu-ray) require conversion of all of the specified YUV formats to RGB data for display of video. In order to enable full support for these encoding formats, all WDDM hardware must support these conversion capabilities.High quality color conversion ensures comparable video quality can be obtained for video to competitive platforms. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Render.DirectFlip
Driver must Support the DirectFlip DDI
| Target Feature |
Device.Graphics.WDDM12.Render |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
The driver must publish the SupportDirectFlip field as TRUE in the DXGK_DRIVERCAPS structure.WDDM 1.2 drivers for the Direct3D 11 DDI must implement the D3D11_1DDI_CHECKDIRECTFLIPSUPPORT DDI and return TRUE from the DDI when it is called with at least the following parameters:
The app resource matches the DWM resource in format and pixel dimensions
The D3DDDI_CHECKDIRECTFLIP_IMMEDIATE flag not set
WDDM 1.2 drivers for the Direct3D 9 DDI must implement the D3DDDIARG_CHECKDIRECTFLIPSUPPORT DDI and return TRUE from the DDI when it is called with at least the following parameters:
The app resource matches the DWM resource in format and pixel dimensions
The D3DDDI_CHECKDIRECTFLIP_IMMEDIATE flag not set
The driver must support the creation of shared primary swapchains, specifically identified as resources created with:
pPrimaryDesc as non-NULL.
D3D10_DDI_RESOURCE_MISC_SHARED set in MiscFlags.
D3D10_DDI_BIND_SHADER_RESOURCE, D3D10_DDI_BIND_PRESENT, and D3D10_DDI_BIND_RENDER_TARGET all set in BindFlags.
When the SharedPrimaryTransition bit is set in the DXGK_SETVIDVIDPNSOURCEADDRESS DDI, the driver must:
Validate that the hardware can seamlessly switch between the two allocations.
Perform a seamless switch to the new primary indicated by the DDI.
Additional Information
| Business Justification |
To ensure optimal power consumption for video playback and other full-screen scenarios, providing DirectFlip enables a minimum amount of memory bandwidth for displaying full-screen content while ensuring smooth transitions between full-screen applications, other applications, and the desktop environment. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Render.FlipOnVSyncMmIo
WDDM1.2 drivers supports a memory mapped I/O (MMIO)-based flip that takes effect on the next vertical sync
| Target Feature |
Device.Graphics.WDDM12.Render |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
All WDDM1.2 drivers must publish the FlipOnVSyncMmIo field as TRUE in the DXGK_FLIPCAPS structure, and implement behavior outlined under FlipOnVSyncMmIo here:https://msdn.microsoft.com/library/ff561069(v=VS.85).aspx
Additional Information
| Business Justification |
In Windows 8, the GPU scheduler will attempt to preempt hardware even in the presence of pending flips. To prevent tearing and rendering artifacts the driver is required to support the MmIoFlip based model. Explicitly requiring this support upfront will reduce the chance of rendering issues appearing on customer machines. In addition, support for the hardware flip queue code path is eliminated. In past operating systems, this led to some reliability problems which were difficult to diagnose. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Render.OfferReclaim
WDDM 1.2 drivers must use the Offer and Reclaim DDI to reduce memory footprint
| Target Feature |
Device.Graphics.WDDM12.Render |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
WDDM 1.2 drivers must use the new UMD Offer and Reclaim DDI to reduce the overhead of memory resources created for temporary surfaces in local video and system memory. An example is the use of staging buffers to accelerate the process of uploading data to GPU local memory. By offering these resources, the operating system can reuse the memory without risking the expense of destroying and recreating them at high frequency.WDDM Drivers also often keep allocations that an application is no longer using so that if the application creates another allocation with the same properties, it can give back the old one. This reduces the performance impact of rapidly destroying and re-creating allocations, a common bad behavior for applications, but it also can have a very high memory cost. By offering those allocations, the WDDM 1.2 driver can keep most of its performance without wasting memory.Below are detailed sub-requirements:
WDDM 1.2 drivers must always "Offer" internal staging buffers once they have been used. These temporary buffers generally hold data being moved or copied from a source to a destination. In Windows 7 and previous operating systems, these temporary surfaces are left in memory even though they were no longer in use.
WDDM 1.2 drivers must always "Offer" the deferred deletions of surfaces which are recycled: If a driver decides to defer the destruction of a surface, it must at least offer it to the video memory manager.
WDDM 1.2 driver should only Offer packed allocations when all of the individual resources contained in the allocation have been Offer-ed. The allocation as a whole should be reclaimed when any individual resources have been reclaimed.
WDDM 1.2 drivers must always Offer Discarded allocations if it implements its own Renaming mechanism.
WDDM 1.2 drivers should never pack allocations larger than 64KB with other allocations, guaranteeing for application that offer will give them the expected benefit.
For more details on the use of the Offer and Reclaim WDDM v1.2 DDI, please refer to the Windows 8 WDK documentation.
Additional Information
| Business Justification |
Use of Offer and Reclaim API by WDDM 1.2 drivers will provide the following benefits:WDDM 1.2 drivers using this API will use less memory resources under memory pressure. More memory will be available for other applications running on the system and are in need of system memory. Releasing memory allocations used by temporary staging surfaces once the work is done will result in a lower memory footprint for WDDM drivers and also applications which use the Offer API.Reduced time to enter and come out of Hibernate - memory resources Offer-ed by WDDM 1.2 drivers will be deleted when the system enters Hibernate. This will reduce the time to enter Hibernation. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Render.PreemptionGranularity
WDDM 1.2 drivers must report the granularity level of GPU Preemption.
| Target Feature |
Device.Graphics.WDDM12.Render |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
A WDDM 1.2 driver must report the GPU Preemption granularity for running Graphics and Compute scenarios.The WDDM 1.2 must do the following:
The WDDM 1.2 driver must first set the "PreemptionAware" flag and the "MultiEngineAware" flag in the _DXGK_VIDSCHCAPS structure through the DxgkDdiQueryAdapterInfo DDI.
The WDDM 1.2 driver must set the appropriate GPU Preemption granularity through "D3DKMDT_PREEMPTION_CAPS PreemptionCaps".
There is no mandatory requirement on the actual level of preemption for Graphics or Compute. For example, if a GPU does not support any level of Mid-DMA Buffer Graphics Preemption such as that on the triangle boundary or others, then it can report this cap as D3DKMDT_GRAPHICS_PREEMPTION_DMA_BUFFER_BOUNDARY. Similarly, if it does not support any level of finer grained preemption for Compute, then it must report the cap as D3DKMDT_COMPUTE_PREEMPTION_DMA_BUFFER_BOUNDARY.However, if the GPU does support Mid-DMA Buffer or Packet Preemption, then the WDDM 1.2 driver must choose the appropriate cap in order to take advantage of the benefits offered by finer grained GPU Preemption for Graphics and/or Compute.For more details on the use of the GPU Preemption WDDM v1.2 DDI, please refer to the Windows 8 WDK documentation.
Additional Information
| Business Justification |
The goal of GPU Preemption is to improve desktop and touch responsiveness by allowing desktop compositions and foreground applications low latency access to the GPU even on a busy desktop with the GPU being used for background compute task. GPU Compute has become more pervasive over the past decade. GPUs are increasingly used for distributed computing and data-parallel tasks such as image processing, video encoding and decoding, scientific simulation and several others. Depending on the exact nature of the workload, some of these tasks take significant amounts of time to complete execution. When needed, these long-running tasks need to be interrupted as quickly as possible so that the GPU can be used to render the desktop or response from user touch input.A WDDM 1.2 driver which supports GPU Preemption as highlighted in the Details section above will also benefit from better system fault-tolerance through the "TDR Improvements" feature. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Render.PremiumContentPlayback
Protected Environment Signature requirement for WDDM1.2 drivers and above
| Target Feature |
Device.Graphics.WDDM12.Render |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
Any WDDM 1.2 and above user mode graphics driver binary required for premium content playback must be properly signed as required by the Windows Protected Environment (PE) license program. Compliance with the PE license program is already required by section 3.1 of the PVP-OPM license agreement. Specifically, each binary in the required set must be signed to an approved root recognized by Windows OS Code Integrity for PE, and have either or both of the following signing characteristics:
1.Catalog signature with an overall attribute of PE TRUSTED, with a hash entry for each specific file setting a field and value of PETrusted=1.
2.Embedded signature with per-page hashes.
Additionally the process of determining what signature each module needs is being standardized, each INF file now must include a SignatureAttributes section uniquely identifying what type of signature is applicable for the associated driver binaries. Adding this section to existing inf files is a very simple process.
An example follows:
[SignatureAttributes]
NameOfFile.dll = SignatureAttributes.PETrust
[SignatureAttributes.PETrust]
PETrust=true
Additional Information
| Business Justification |
Premium content playback using Windows Store apps require display driver binaries to be properly signed as required by Windows Protected Environment license program. Playback fails if a driver binary does not meet this requirement leading to poor user experience. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Render.TDRResiliency
WDDM 1.2 drivers for GPUs which support Per-Engine Reset must implement the Windows 8 DDI for TDR Resiliency.
| Target Feature |
Device.Graphics.WDDM12.Render |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
A WDDM 1.2 driver for a GPU supporting Per-Engine Reset must implement the TDR DDI for improved reliability and resiliency. The WDDM 1.2 must do the following:
The WDDM 1.2 driver must satisfy the WDDM 1.2 GPU Preemption requirement.
The WDDM 1.2 driver must implement the following GPU Engine DDIs:
QueryDependentEngineGroup
QueryEngineStatus
ResetEngine
WDDM 1.2 drivers must continue supporting the pre-Windows 8 TDR behavior of Adapter-wide Reset and Restart. Semantics of these existing DDIs remain the same as before Windows 8.
For more details on the use of the GPU Preemption and TDR Improvements WDDM v1.2 DDI, please refer to the Windows 8 WDK documentation.
Additional Information
| Business Justification |
The goal of an improved mechanism for GPU "Timeout Detection & Recovery" (or TDR) is improved resiliency to GPU hangs which are triggered by long-running graphics workloads taking more than the allowed time for work completion. On previous Windows operating systems, repeated operations like these result in repeated TDRs which eventually crash the system. Applications which do "Compute on the GPU" that can submit work to the GPU can also take much longer to complete than the allowed timeout. With the Windows 8 feature support for GPU Preemption, these tasks can execute without interfering with other applications, including the desktop window manager (DWM). The TDR improvements consist of the following changes:Detection change: Allow applications to opt out of TDR if they want to (long-running compute scenarios). This class of applications won't hit a TDR for running for extended periods of time as long as the application remains preemptible and allows other tasks to run. Recovery change: Only the hung GPU engine is reset and only the device having submitted the work is put in error; no one else is impacted by the TDR. Repeated TDRs: There will be no more bugchecks on repeated TDRs in most cases. Applications having caused multiple successive faults won't be allowed to touch the GPU for some amount of time. Non-interactive applications such as Compute applications will be allowed to use as much of the GPU as they need as long as they don't interfere with other applications which need to share the GPU. In order to keep the desktop responsive, applications that negatively interfere with DWM will be penalized by preventing them from accessing the GPU. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Render.UMDLogging
WDDM 1.2 drivers must implement WDDM User-Mode Driver or UMD Logging to aid diagnosability.
| Target Feature |
Device.Graphics.WDDM12.Render |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
A WDDM 1.2 driver must expose the relationship between the Direct3D resources and Video Memory allocations by implementing the UMD logging ETW interfaces. Below are the specific requirements for the drivers:
UMD must report allocation size specified in CreateResource call, even if size of memory allocated is greater
UMD must log MapAllocation event for each of its internal allocation and specify purpose of that allocation
UMD must log MapAllocation event for each renamed surface
UMD must log MapAllocation for every surface that it packs into an existing surface
UMD must log MapAllocation for every surface that currently exists in the event of a rundown
UMD must log MapAllocation in response to CreateResource call, even if no new memory is allocated
UMD must log UnmapAllocation each time its internal allocation is destroyed
UMD must log UnmapAllocation each time application destroys and allocation, even if actual memory allocation is not destroyed
UMD must log UnmapAllocation each time it closes one of the renamed allocations
UMD must log UnmapAllocation for each surface that is packed into a larger allocation
In addition to logging MapAllocation and UnmapAllocation events as they happen, the Graphics Driver must be able to report all existing mappings between resources and allocations at any point in time.For more details on the use of the UMD Logging WDDM v1.2 DDI, please refer to the Windows 8 WDK documentation.
Additional Information
| Business Justification |
With an increasing number of graphics applications utilizing GPU resources, the diagnosability of graphics performance and video memory related issues has become critical. To get a more actionable breakdown of video memory, the driver needs to expose the relationship between D3D resources and VidMm allocations. With this information added to ETW traces it will be possible to see the video memory allocations from the API's perspective. For developers, it will clarify memory costs that are currently very hard to see, like internal fragmentation or the impact of rapidly discarding surfaces. It will also enable Microsoft to work better with customers and partners who provide traces for analysis of performance problems. In particular it will help overcome a common blocking point in investigating memory-related performance issues: the application is using too large a working set, but cannot tell which API resources or calls are causing the problem. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.Render.XPSRasterizationConformance
WDDM 1.2 drivers must support XPS Rasterization
| Target Feature |
Device.Graphics.WDDM12.Render |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
To ensure a quality printing experience on Windows 8 the WDDM1.2 Graphic drivers must support XPS Rasterization
Additional Information
| Business Justification |
In Windows 8, the XPS Rasterization component uses Direct2D in hardware rendering mode to rasterize XPS pages into WIC bitmaps whenever the component is invoked on a machine with a WDDM 1.2 driver. The XPS Rasterization component is used by many print device drivers to produce device specific PDLs. The XPSRAS Display Conformance Requirement tests whether a WDDM 1.2 GPU driver produces correct rasterization results when used by Direct2D in the context of the XPS Rasterizer. The XPS Rasterizer is a system component used heavily by Windows print drivers to rasterize an XML Paper Specification (XPS) Print Descriptor Language (PDL). To determine the correctness of rasterization results, a comparison is performed between the results obtained from the XPS Rasterizer when executed on a system with the subject WDDM 1.2 GPU driver, and results obtain from baseline use of the XPS Rasterizer. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.RenderOnly
The optional feature set implemented by WDDM 1.2 drivers which support only the render specific DDIs.
| Related Requirements |
Device.Graphics.WDDM12.RenderOnly.Base |
Device.Graphics.WDDM12.RenderOnly.Base
Requirements for a WDDM graphics adapter to support render functionality
| Target Feature |
Device.Graphics.WDDM12.RenderOnly |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
In Windows 8 and beyond WDDM has been extended to support a WDDM driver that is only responsible for Rendering and Compute DDIs. Such a driver is not allowed to support any Display Scan out capabilities. A driver is considered a WDDM Render Only driver if one of the following two conditions is met:
The driver implements all the DDIs required for a full WDDM driver but reports 0 sources and 0 targets
The driver implements all the Render specific DDIs and returns a null pointer for all the Display specific DDIs. The DDIs required for this are called out below
Common WDDM DDIs
These DDI functions are for the common device functionalities such as PnP support and Power support. These functions are required by all WDDM drivers and if not implemented the driver will not be started by Windows. These DDIs are already documented in the WDK. Required:DxgkDdiAddDevice DxgkDdiStartDevice DxgkDdiStopDeviceDxgkDdiRemoveDevice DxgkDdiDispatchIoRequestDxgkDdiSetPowerState DxgkDdiUnloadOptional:DdiNotifyAcpiEvent ** DdiNotifyAcpiEvent DDI function is used to notify graphics drivers on some ACPI events. It is optional for rendering device. On normal WDDM graphics devices, this DDI function will return a flag to indicate dxgkrnl.sys to take some further actions such as reset display mode or poll the connected monitors. For the rendering only device, these flags are not used and must be set to zero
Rendering only DDIs
These DDI functions are for the rendering functionalities. Required: DxgkDdiInterruptRoutine DxgkDdiDpcRoutine DxgkDdiResetDevice DxgkDdiCreateDeviceDxgkDdiDestroyAllocationDxgkDdiDescribeAllocationDxgkDdiOpenAllocationDxgkDdiCloseAllocationDxgkDdiGetStandardAllocationDriverDataDxgkDdiSubmitCommandDxgkDdiPreemptCommandDxgkDdiBuildPagingBufferDxgkDdiResetFromTimeoutDxgkDdiRestartFromTimeoutDxgkDdiQueryCurrentFenceDxgkDdiControlInterruptDxgkDdiDestroyDeviceDxgkDdiPresentDxgkDdiCreateAllocationDxgkDdiPatchDxgkDdiRenderDxgkDdiRenderKmOptional:If rendering hardware support swizzling ranger, driver should also supply following two functionsDxgkDdiAcquireSwizzlingRangeDxgkDdiReleaseSwizzlingRange
Additional Information
| Business Justification |
Over the years there has been an increasing focus on GPGPU scenarios for doing vast amount of complex mathematical or graphical operations. Some of the common examples of this are graphics rendering for animation, database processing, financial & astronomical calculations and oil and gas exploration. The use of GPGPU has proved benefits in performance, power consumption and cost. This feature makes it easier for an OEM to ship a system specifically targeted for such a use without having the added complexity of supporting a display device |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM12.StandbyHibernateFlags
The optional feature implemented by WDDM 1.2 drivers supporting the new stand by hibernation flags.
| Related Requirements |
Device.Graphics.WDDM12.StandbyHibernateFlags.StandbyHibernateFlags |
Device.Graphics.WDDM12.StandbyHibernateFlags.StandbyHibernateFlags
WDDM v1.2 graphics drivers can optionally specify if they support the Windows 8 optimized standby or hibernate flags
| Target Feature |
Device.Graphics.WDDM12.StandbyHibernateFlags |
| Applies to |
Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 |
Description
To improve performance on sleep & resume for standby and hibernate, a WDDM 1.2 drivers can utilize the new StandbyHibernateFlags (PreservedDuringStandby, PreservedDuringHibernate, and PartiallyPreservedDuringHibernate). To utilize this feature drivers must set one or more of the StandbyHibernateFlags when enumerating segment capabilities. Doing so indicates that eviction should be skipped during power state transition for the corresponding segments. Verification of memory retention during power transition will be verified for all WDDM 1.2 driver setting a StandbyHibernateFlag.
Additional Information
| Business Justification |
Smarter Resource Utilization: Reduction in sleep and resume times by avoiding unnecessary memory eviction and duplication in Integrated Graphics. End user experience:By reducing the response time for resume from standby state, PC users will be less frustrated and can become productive faster with quicker access to their productivity tools. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13
The base feature set implemented by drivers supporting WDDM1.3
| Related Requirements |
Device.Graphics.WDDM13.Base |
Device.Graphics.WDDM13.Base
Graphic drivers must implement WDDM1.3
| Target Feature |
Device.Graphics.WDDM13 |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
Windows 8.1 introduces a new set of features and DDI changes that will be referred to as WDDM1.3. The implementation of WDDM1.3 is required and the WDDM1.3 spec must be followed.
WDDM 1.3 is required for all new systems which are shipped with Windows 8.1
| Feature Name |
Applicable DX H/W Class |
Full Graphics Driver x86/x64 |
Render Only Driver x86/x64 |
Full Graphics Driver ARM/RT |
| Hybrid Graphics (GPU Kernel) |
DX11+ |
If implemented |
NA |
NA |
| Multiplane Overlays (GPU Kernel) |
All |
If implemented |
NA |
Mandatory |
| Wireless display support |
All |
If implemented |
NA |
If implemented |
| 48 Hz Video Playback |
All |
Mandatory |
NA |
Mandatory |
| Shared Surface support for more formats |
All |
Mandatory |
Mandatory |
Mandatory |
| Present Overhead Optimization |
All |
Mandatory |
Mandatory |
Mandatory |
| Kernel Performance: GPU engine enumeration |
All |
Mandatory |
Mandatory |
Mandatory |
| Power Management Enhancements: GPU p-state support |
All |
If implemented |
If implemented |
Mandatory |
| Power Management Enhancements: Stable P-State |
All |
Mandatory |
Mandatory |
Mandatory |
| Power Management Enhancements: GPU f-state hysteresis |
All |
If implemented* |
If implemented |
Mandatory |
| Power Management Enhancements: Aggressive V-sync |
All |
If implemented |
NA |
Mandatory |
| Access to thermal interface |
All |
If implemented |
If implemented |
If implemented |
| Rendering Performance Improvements: D3D9 Staging Buffers |
All |
Mandatory for DX9.x HW Optional for DX10+ |
NA |
Mandatory |
| Rendering Performance Improvements: D3D9 Native UpdateSubResource |
All |
Mandatory for DX9.x HW Optional for DX10+ |
NA |
Mandatory |
| Rendering Performance Improvements: D3D9 Timestamps and Counters |
All |
Mandatory for DX9.x HW Optional for DX10+ |
NA |
Mandatory |
| Rendering Performance Improvements: D3D Resource Trim |
All |
Mandatory |
Mandatory |
Mandatory |
| Rendering Performance Improvements: Feature Level 9 Instancing |
All |
Mandatory for DX9.x HW |
NA |
Mandatory |
| Rendering Performance Improvements: D3D9 Large Capture Textures |
All |
Mandatory |
NA |
Mandatory |
| Rendering Performance Improvements: Map Default |
DX11+ |
Mandatory |
NA |
NA |
| Tiled Resources |
DX11.1 |
If implemented |
If Implemented |
If implemented |
| Independent Flip |
All |
Mandatory |
NA |
Mandatory |
| D3D Modification for Tools: High Performance Timing Data |
All |
Mandatory |
Mandatory |
Mandatory |
| Full Range YUV Support |
DX10+ |
Mandatory |
Mandatory |
Mandatory |
*Mandatory if implementing Connected Standby
There are no additional requirements for Display only Driver, hence it is not called out in the table
D3D Requirements:
| DirectX Hardware |
KMD Requirements |
UMD Requirements |
| D3D9 |
Required: WDDM v1.3 |
Required: D3D9 - UMD DDI |
| D3D10 |
Required: WDDM v1.3 |
Required: D3D9 - UMD DDI Required: D3D10- UMD DDI Required: D3D11.1 - UMD DDI |
| D3D10.1 |
Required: WDDM v1.3 |
Required: D3D9 - UMD DDI Required: D3D10- UMD DDI Required: D3D10.1- UMD DDI Required: D3D11.1 - UMD DDI |
| D3D11 |
Required: WDDM v1.3 |
Required: D3D9 - UMD DDI Required: D3D10- UMD DDI Required: D3D10.1- UMD DDI Required: D3D11 - UMD DDI Required: D3D11.1 - UMD DDI |
| D3D11.1 |
Required: WDDM v1.3 |
Required: D3D9 - UMD DDI Required: D3D10- UMD DDI Required: D3D10.1- UMD DDI Required: D3D11 - UMD DDI Required: D3D11.1 - UMD DDI |
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13.DisplayRender
Parent feature node of requirements which have impact for display and render GPU.
| Related Requirements |
Device.Graphics.WDDM13.DisplayRender.48HzVideoPlayback Device.Graphics.WDDM13.DisplayRender.IndependentFlip Device.Graphics.WDDM13.DisplayRender.MultiplaneOverlaySupport Device.Graphics.WDDM13.DisplayRender.MultiPlaneOverlayVideoProcessing |
Device.Graphics.WDDM13.DisplayRender.48HzVideoPlayback
WDDM1.3 drivers must support 48hz Video Playback
| Target Feature |
Device.Graphics.WDDM13.DisplayRender |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
Graphic Drivers implementing WDDM1.3 must implement DDIs that:
1.Report whether the collective system can seamlessly switch to 48 Hz (intersection of SOC and display panel capabilities)
2.If so, allow the refresh rate (such as 48 Hz) to be specified on each particular Present DDI.
The HCK test will validate that the refresh rate with within a 0.5% tolerance of the requested value, again assuming the graphics driver reports support for the particular refresh rate. This will be validated for devices which report support for 48 Hz or 50 Hz through the capabilities DDI through an HCK test, which is described in detail the 48 Hz IHV spec.
Additional Information
| Business Justification |
Running a display panel at 48 Hz for 24fps video playback results in improved video quality playback, since 3:2 pull-down is no longer necessary. Furthermore, running display panels at lower refresh-rates introduces measureable power savings, improving video playback battery life. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13.DisplayRender.IndependentFlip
IndependentFlip Support
| Target Feature |
Device.Graphics.WDDM13.DisplayRender |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
All WDDM 1.3 drivers MUST support independentFlip. As such, all WDDM 1.3 drives MUST set the UINT FlipIndependent member to 1 in the updated DXGK_FLIPCAPS structure. See the IndependentFlip DDI Document for more details about the updated DXGK_FLIPCAPS structure.
Additional Information
| Business Justification |
IndependentFlip aims to establish performance parity between full screen exclusive swap chains and swap chains that are presented using DirectFlip. This feature will improve the user and developer experience by affording better performance in all DirectFlip scenarios, mainly full screen modern games. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13.DisplayRender.MultiplaneOverlaySupport
Multi-plane Overlay Support
| Target Feature |
Device.Graphics.WDDM13.DisplayRender |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
All WDDM 1.3 display drivers must report multi-plane overlay capabilities of the hardware using the DDI defined by the Multi-plane Overlay Support DDI specification. WDDM 1.3 drivers which claim to support multi-plane overlays must meet all of the following hardware criteria:
Hardware must support non-overlapping planes.
One plane can cover one portion of the screen while another plane can cover a different, mutually exclusive, portion of the screen.
If there is any portion of the screen not covered by a plane, the hardware must scan out black for that area. The hardware can assume that there is a virtual plane at the bottom-most Z order that is filled with black.
Hardware must support overlapping planes. Blending between the planes using pre-multiplied alpha must be supported.
The hardware must also be able to enable/disable alpha blending on a per-plane basis.
When only one output is active, the active output must support multi-plane overlays. In the case of clone mode where multiple outputs are simultaneously active, hardware should not report that it supports multi-plane overlays unless all active outputs support multi-plane overlays.
The DWM s swapchain (plane 0) must be able to interact with the other overlay planes.
All planes must be able to be enabled and disabled, including plane 0 (the DWM s swapchain).
All planes must support source and destination clipping, including plane 0 (the DWM s swapchain).
At least one plane must support shrinking and stretching, independent from other planes that may be enabled.
Planes that support scaling must support both bilinear filtering and better than bilinear filtering quality.
At least one plane must support:
Both 601 and 709 YUV to RGB matrix conversion for YUV formats.
Both normal range YUV luminance (16 - 235) and full range YUV luminance (0 255).
The following register latching scenarios must be handled:
All per-plane attributes (buffer address, clipping, scaling, etc.) must atomically post on the vertical retrace period. When updating a block of registers, they must all post atomically (i.e. if the VSYNC occurs after writing 10 of 20 registers pertaining to the overlay plane, none of them will post until the next VSYNC since they cannot all post on the current VSYNC).
Each plane can be updated independently from the other planes. For example, if the plane 0 registers have been updated prior to the VSYNC and later we are updating the plane 1 registers when the VSYNC occurs, the plane 1 updates might wait until the next VSYNC but the plane 0 updates should occur on time.
When multiple planes are updated during a single present call, the updates should occur atomically. For example, if a single present call is updating plane 0 and enabling plane 1, the plane 0 registers should not post on the VSYNC unless the plane 1 registers also post on the same VSYNC.
Transformation, scaling, and blending should occur as follows (in the specified order):
The source allocation is clipped according to the specified source rectangle. The source rectangle is guaranteed to be bounded within the size of the source allocation.
Apply Horizontal image flip, then Vertical image flip if requested.
Apply scaling according to the destination rectangle, apply clipping according to the clip rectangle, and apply the appropriate filtering when scaling.
Blend with allocations at other layers. Blending should be performed from top to bottom (or until hit opaque layer) in Z-order. If alpha blending is requested, hardware must honor the per-pixel-alpha and color value is pre-multiplied by alpha. Pseudo code is indicated below, this does source over destination operation repeatedly from top to bottom, (((Layer[0] over Layer[1]) over Layer[2]) over Layer[n]). Outside of the destination rectangle, each layer must be treated as transparent (0,0,0,0).
Color = Color[0]; // layer 0 is topmost.
Alpha = Color[0].Alpha;
for (i = 1; Alpha < 1 && i < LayersToBlend; i++)
{
Color += ((1 - Alpha) * Color[i]);
Alpha += ((1 - Alpha) * Color[i].Alpha);
}
Output Color;
It is OK if hardware blends bottom to top as long as the output result is the same. In this case, the following blend algorithm should be used:
Color = Color[LayersToBlend-1]; // Bottom most layer
Alpha = Color[LayersToBlend-1].Alpha;
if (LayersToBlend > 1)
{
for (i = LayersToBlend - 2; Alpha < 1 && i >= 0; i--)
{
Color = Color[i] + ((1 Color[i].Alpha) * Color;
Alpha = Color[i].Alpha + (1 Color[i].Alpha) * Alpha;
}
}
Output Color;
Black color must be displayed at the area where not covered by any of destination rectangles from any layers. Hardware can assume there is a conceptual virtual black bottom most layer that is the size of the screen.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13.DisplayRender.MultiPlaneOverlayVideoProcessing
Multi-plane overlay scaler quality
| Target Feature |
Device.Graphics.WDDM13.DisplayRender |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
If a WDDM1.3 driver exposes multi-plane overlay support, and
X is the PSNR value between the output image of the scaler used by the multi-plane overlay hardware when compared to output of reference software video processor.
Y is the PSNR value between the output image of DXVAHD VideoPrecessBlt when compared to output of reference software video processor.
Z is the PSNR value between the output image of the scaler used by the multi-plane overlay hardware when compared to output image of VideoProcessBlt.
Then:
Non scaling operations:
For the following video processing operations:
Color space conversions
The following color space conversions of Y CbCr and sRGB must be supported:
BT.601 primaries and BT.709 primaries
Nominal range (i.e. between reference black/white levels of 0..255 and 16..235)
180 degrees rotation, horizontal or vertical flip transformations
Goal:
X, Y, and Z must be greater than or equal to 50 dB.
Scaling operations:
For the following video scaling operations:
Image contraction (1080p to 720p)
Image enlargement (720p to 1080p)
Image enlargement (480p to 1080p)
Goal:
Z must be greater than or equal to 50 dB.
The thresholds for X and Y will depend on the test content. Reference the HCK documentation for the test to determine the threshold for each test.
Note: The image from the software reference video processor is generated using an 8x8 Lanczos filter.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13.DisplayRender.CoolingInterface
Feature for Thermal Hints
| Related Requirements |
Device.Graphics.WDDM13.DisplayRender.CoolingInterface.ThermalHints |
Device.Graphics.WDDM13.DisplayRender.CoolingInterface.ThermalHints
Optional Thermal Hints support for WDDM1.3 drivers
| Target Feature |
Device.Graphics.WDDM13.DisplayRender.CoolingInterface |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
WDDM graphics 1.3 or later drivers must check for the new added DeviceUid field in the QUERY_INTERFACE structure OS passed in by the DxgkDdiQueryInterface function and return a valid interface function on the OS specified device.
If ACPI firmware adds the current graphics device into ACPI ThermalZone, then the IHV miniport must support the DxgkDdiQueryInterface on the GUID_THERMAL_COOLING_INTERFACE for the current graphics device.
Validation:
ACPI.sys will only query the thermal cooling interface if the current device is in a thermal zone. Dxgkrnl.sys can validate that the IHV miniport driver supports the GUID_THERMAL_COOLING_INTERFACE when ACPI queries this interface. In this case, WHCK can receive the error log that the miniport driver fails the DxgkDdiQueryInterface call on GUID_THERMAL_COOLING_INTERFACE and fail the WHCK test.
Additional Information
| Business Justification |
When running intensive applications tablets running on SoCs can get extremely warm and uncomfortable to hold. The SoC has the ability to sense that the temperature has been exceeded. We can use this information to throttle different device classes thus reducing power consumption on the device and preventing the user from putting down the tablet. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13.DisplayRender.WirelessDisplay
The optional feature set implemented by WDDM 1.3 drivers which support the Miracast functionality
| Related Requirements |
Device.Graphics.WDDM13.DisplayRender.WirelessDisplay.BasicWirelessDisplay |
Device.Graphics.WDDM13.DisplayRender.WirelessDisplay.BasicWirelessDisplay
Optional Wireless Display support for WDDM1.3 drivers
| Target Feature |
Device.Graphics.WDDM13.DisplayRender.WirelessDisplay |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
This is an optional feature for WDDM 1.3 drivers.
The WDDM Miracast user mode driver must be a separate DLL.
If a driver supports Miracast display, then it must enumerate only one Miracast target along with other supported targets.
Driver must accurately report the target type to Windows. Any time Windows connects to a Miracast device, driver must use the new target type irrespective of the connection between the Miracast end point and the display device.
Driver must only indicate the arrival of a monitor once the Miracast session is established, the device capabilities have been obtained, HDCP negotiations has taken place and the user mode driver is ready to stream display to the device.
Driver must use the new DDIs for any private communication between UMD and KMD. Driver must not poll for packet state.
Driver must use the new DDIs for any private communication between UMD and KMD. Driver must not poll for packet state.
All memory access by the GPU must be allocated through DirectX APIs Driver must not carve out or hide memory used for the implementation.
All hardware being used for the implementation must be exposed to Windows to enable accurate power management.
Driver must report v-sync on the wireless displays.
Driver must use published Windows networking APIs from user mode and must not use any private interfaces with the NW driver.
Every time the receiver requests an i-frame, the driver must log it with Windows using a new DDI.
If the Miracast device supports Audio, the driver must enumerate an Audio end point to Windows similar to how it is enumerated for HDMI/Display Port. The container ID for the audio device must match that of the corresponding Miracast display device.
When Windows sets the MC display to monitor idle the driver must set the power saving mode as defined in the MC standard. When the user provides input to resume from monitor idle, the MC display must be brought back to full power and the user must be able to use it without having to reconnect.
The user mode Miracast driver must complete the new DDI to stop Miracast session, within 3 seconds.
Driver must conform with the same resolution enumeration requirement as other target types as specified in the WHCK.
In the event that there is no display physically connected to the Miracast sink, then the driver must still allow the connection to succeed but must not report the display to Windows. Once the display is physically connected then the driver must report it to windows.
In the event that a user physically disconnects the display from the Miracast sink device the driver must report the display removal and Windows will disconnect from the session.
WDDM driver must be capable of support HDCP over Miracast.
If a sink device does not support HDCP, the driver must still allow the connection to succeed.
In case the driver TDR's, the driver should appropriately terminate the session.
Additional Information
| Business Justification |
Enables the graphics drivers to support wireless displays over the Miracast protocol. This allows PCs to wirelessly connect to displays creating a compelling user experience |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13.EnhancedPowerManagement
Graphics Kernel Power Management Enhancements
| Related Requirements |
Device.Graphics.WDDM13.EnhancedPowerManagement.FState Device.Graphics.WDDM13.EnhancedPowerManagement.PState Device.Graphics.WDDM13.EnhancedPowerManagement.VSYNC |
Device.Graphics.WDDM13.EnhancedPowerManagement.FState
F-State Hysteresis
| Target Feature |
Device.Graphics.WDDM13.EnhancedPowerManagement |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
WDDM 1.3 introduces some power management enhancements. If implemented then:
LATENCY TIME VALIDATION
For a transition from a lower power F-State to a higher one, it is expected that the time it takes to complete the transition will not be more than 10% over the transition latency time reported by the driver.
Additional Information
| Business Justification |
Optimize power consumption by managing F-States for better low power residency. Using activity information from the GPU kernel scheduler and display port interface, this project will lower energy consumption by the graphics subsystem hardware. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13.EnhancedPowerManagement.VSYNC
Aggressive VSYNC
| Target Feature |
Device.Graphics.WDDM13.EnhancedPowerManagement |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
WDDM 1.3 introduces some power management enhancements:
IN PHASE VSYNC
While the Vsync is enabled, 98% of the Vsyncs must be within 500us of the expected value with no Vsyncs exceeding a variance of more than 1.5ms.
Additional Information
| Business Justification |
Optimize power consumption by controlling VSYNCs more tightly with idle conditions. Using activity information from the GPU kernel scheduler and display port interface, this project will lower energy consumption by the graphics subsystem hardware |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13.Render
The base feature set implemented by WDDM 1.3 drivers which support the render specific DDIs.
| Related Requirements |
Device.Graphics.WDDM13.Render.CheckDDIBoundaries Device.Graphics.WDDM13.Render.DirtyRect Device.Graphics.WDDM13.Render.GPUNode Device.Graphics.WDDM13.Render.HighPerformanceTimingData Device.Graphics.WDDM13.Render.PresentOverheadOptimization Device.Graphics.WDDM13.Render.SharedSurfaceSupport Device.Graphics.WDDM13.Render.TrimSupport |
Device.Graphics.WDDM13.Render.CheckDDIBoundaries
Hybrid Graphics
| Target Feature |
Device.Graphics.WDDM13.Render |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
Graphics drivers should not circumvent DDI boundaries.
No system level or runtime level API detouring allowed The driver is not allowed to intercept OS system or runtime calls, or modify arguments passed by OS system or runtime APIs, or wrap the objects returned from the API entrypoints.
Access and use of internal data structures not allowed
No driver layering allowed - Only 1 user mode/kernel mode driver is allowed to be loaded and communicate with the runtime and kernel binaries.
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13.Render.DirtyRect
Optional DirtyRect support for WDDM1.3 drivers
| Target Feature |
Device.Graphics.WDDM13.Render |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) |
Description
WDDM1.3 introduces the ability to support DirtyRect. If DirtyRect if implemented then it must follow the spec
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13.Render.GPUNode
Graphics Kernel Performance
| Target Feature |
Device.Graphics.WDDM13.Render |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
If implementing WDDM1.3 then the driver must:
The driver must specify a valid enum value for each engine per physical adapter.
The driver must specify one engine of type DXGK_ENGINE_TYPE_3D per physical adapter.
For each engine, the given enum value must meet the requirements as stated in the engine definitions table in the DDI
Additional Information
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13.Render.HighPerformanceTimingData
High Performance Graphics Timing Data
| Target Feature |
Device.Graphics.WDDM13.Render |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
High Performance Graphics Timing Data provides light weight and highly detailed timing data for graphics workloads. This data is used by analysis tools to identify performance or other graphics related issues in Windows applications or the graphics stack.
A WDDM1.3 driver must ensure that the graphics device/driver provides the following:
A high resolution GPU Timer
12.5 MHz (80ns resolution) or better.
At least 32 bits of timestamp resolution
The GPU timestamp can be sampled for all engines in a GPU
The GPU timestamp can be sampled at the end of the GPU pipeline
The GPU timestamp frequency can be sampled.
The GPU timestamp is invariant and is unaffected by p-state transitions.
Among the other changes for this feature, this will include the addition of two new flags to the existing DdiControlEtwLogging interface; when these flags are set so that the first flag is value of 1 and the second flag is a value of 0, then the driver must ensure that:
All engine components must ensure that they are never clock- or power-gated as long as the flag remains enabled, and must in general refrain from entering any idle states. The components must remain active to ensure there is no latency added due to power transitions.
All engine components must ensure that their processing frequencies and functional bus bandwidths are kept at their maximum stable operating values. Thermal events requiring P-State transition down should still occur to prevent damage to the hardware, but P-States should be defined so that these are exceptional occurrences that are not normally seen in cool lab environments.
The sampled GPU timestamp can be correlated with previously issued graphics commands
Generation of timing data is off by default, but can be turned on and off at any time.
The overhead of collecting this performance data is no slower than using the timestamp query technique that is already available in D3D9 and D3D10+
Timing data can be collected via the D3D9 driver on feature level 9 hardware and the D3D10 driver on feature level 10+ hardware.
Resulting data on Tile based deferred rendering hardware appears as if it was generated on an immediate mode rendering device.
Additional Information
| Business Justification |
Application developers want to build compelling and engaging graphics application or games, but their progress can be suddenly slowed when they hit unexpected performance issues. These issue may have a simple root cause, may be platform specific, or simply a bug in the application. Yet analysis can be time consuming and difficult. Graphics performance analysis is difficult because of the large volume of data, the parallelism, the numerous CPU and GPU processors involved and because the commands executed on a GPU are opaque to existing tools. To isolate a problem, it is necessary to understand exactly what code is running on the CPU, what code is running on each engine of the GPU and the timing relationships between these massively parallel tasks. But the overhead of existing timing data collection is too intrusive and affects the performance of the application too much. High performance timing data, allows a developer to use a tool to gather the specific timing of the work being executed on the GPU and CPU for every graphics API call and the relationship between each unit of work, and then quickly analyze the location of a potential problem in the code, the data, or the graphics stack. |
| Enforcement Date |
Feb. 01, 2014 |
Device.Graphics.WDDM13.Render.PresentOverheadOptimization
Present Overhead Optimization
| Target Feature |
Device.Graphics.WDDM13.Render |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
WDDM1.3 drivers must support the new DDI, Present1, on Feature Level 9 hardware through the D3D9 DDI, as well as on Feature 10+ hardware through the D3D11 DDI. WDDM1.3 drivers on Feature Level 10+ hardware can optionally support this feature through the D3D9 DDI; however, such support should be consistent with its support for all other Optional Performance Features (e.g. Shared Surface Support).
To ensure the desired performance characteristics when Present1 is used the following is required:
Rendering as a result of calling the new DDI must be same as the rendering as a result of using traditional multiple single-present DDI calls
The driver must only call the Present callback once per DDI call (and not once per resource)
Additional Information
| Business Justification |
The desktop compositor maintains a series of surfaces for efficient update by the application by re-using the underlying SwapChain presentation mechanism. When the app completes surface updating, one Present DDI will be called for each surface requires command buffer flushes and an expensive graphics kernel call. Therefore, the overall length of CPU time is heavily dependent on the number of surfaces passed into the call, and is a significant bottleneck of using the compositor. Since mainstream applications are presenting an increasing amount of surfaces per-frame, they are significantly limited by the overhead associated with each of them. It is desired to reduce the cost when presenting multiple surfaces. By optimizing present overhead, applications can reduce their overall time interacting with the compositor. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13.Render.SharedSurfaceSupport
Shared Surface Support
| Target Feature |
Device.Graphics.WDDM13.Render |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
WDDM1.3 drivers must support these new formats and capabilities for shared surfaces:
Drivers support new formats on Level9 hardware,
A8_UNORM
R8_UNORM
R8G8_UNORM
Driver supports shared surfaces in new formats (A8_UNORM, R8G8_UNORM, R8_UNORM, BC1_*, BC2_*, and BC3_*) with the following capabilities on Feature Level 9 hardware through the D3D9 DDI, as well as on Feature 10+ hardware through the D3D11 DDI. WDDM1.3 drivers on Feature Level 10+ hardware can optionally support this feature through the D3D9 DDI; however, such support should be consistent with its support for all other Optional Performance Features (e.g. Present Overhead Support)
Resources sharing;
Resources can be used as render target;
Resources can be blended;
Resources can be filtered;
Resources can be accessed.
Additional Information
| Business Justification |
Shared surfaces in new formats will enable apps to share opacity masks and YCbCr/DDS textures in their native formats with other processes. Doing so will improve app s composition performance. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.WDDM13.Render.TrimSupport
Direct3D Trim
| Target Feature |
Device.Graphics.WDDM13.Render |
| Applies to |
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 |
Description
The Trim API is new in the WDDM1.3 updates to the D3D9 UM DDI, supporting this API is required by graphic devices and the driver must do the following:
After a device calls Trim, the graphics driver memory usage must return to within 5% of its usage after initial device creation.
The responsiveness of the graphics driver for rendering operations after calling Trim must be comparable to that of the driver after initial Direct3D device creation.
Calling Trim must not change the state of the Direct3D device all rendering operations should continue to be evaluated normally.
Additional Information
| Business Justification |
The Trim API will be an important way for apps to reduce their memory usage and subsequently their chances of termination. This will improve the user experience by reducing system memory pressure and reducing the frequency of running apps needing to be reloaded (reducing responsiveness) due to termination. These HCK tests are necessary to ensure that the user experience is positively affected by this feature. To that end, they will ensure that drivers achieve the expected memory savings by returning to near their original memory usage. They will ensure that the responsiveness of applications is not negatively affected beyond what is typical for a start-up scenario. Finally, they will ensure that the API does not put the drivers in a different state or impact any other rendering functionality. |
| Enforcement Date |
Jun. 26, 2013 |
Device.Graphics.XDDM
The base feature set implemented by drivers developed using the XDDM
| Related Requirements |
Device.Graphics.XDDM.Stability |
Device.Graphics.XDDM.Stability
All XDDM graphics drivers must not generate any hangs or faults under prolonged stress conditions.
| Target Feature |
Device.Graphics.XDDM |
| Applies to |
Windows Server 2008 Release 2 x64 |
Description
Graphics drivers must function properly, and not generate any hangs or faults throughout the duration of stress testing as specified in the
"Legacy Stress Profile"
To "stress" a graphics driver, Comparative Reliability Analyzer for Software and Hardware (CRASH) launches and terminates other test applications to simulate real-world scenarios.
Additional Information
| Business Justification |
The CRASH tests which are exercised through this logo requirement ensure reliability and stability of the graphics driver on the Windows platform. These tests which simulate various productivity, graphics and gaming scenarios exercise various code paths in the graphics stack. They also stress the system to ensure that the stability is not affected with an increased workload. |
| Enforcement Date |
Jun. 26, 2013 |