The Current State of DirectX 12 & WDDM 2.0

Although DirectX 12 is up and running in the latest public release of Windows 10, it and many of its related components are still under development. Windows 10 itself is still feature-incomplete, so what we’re looking at here today doesn’t even qualify as beta software. As a result today’s preview should be taken as just that: an early preview. There are still bugs, and performance and compatibility is subject to change. But as of now everything is far enough along that we can finally get a reasonable look at what DirectX 12 is capable of.

From a technical perspective the DirectX 12 API is just one part of a bigger picture. Like Microsoft’s last couple of DirectX 11 minor version upgrades, DirectX 12 goes hand-in-hand with a new version of the Windows Display Driver Model, WDDM 2.0. In fact WDDM 2.0 is the biggest change to WDDM since the driver model was introduced in Windows Vista, and as a result DirectX 12 itself represents a very large overhaul of the Windows GPU ecosystem.

Top: Radeon R9 290X. Bottom: GeForce GTX 980

Microsoft has not released too many details on WDDM 2.0 so far – more information will be released around GDC 2015 – but WDDM 2.0 is based around enabling DirectX 12, adding the necessary features to the kernel and display drivers in order to support the API above it. Among the features tied to WDDM 2.0 are DX12’s explicit memory management and dynamic resource indexing, both of which wouldn’t have been nearly as performant under WDDM 1.3. WDDM 2.0 is also responsible for some of the baser CPU efficiency optimizations in DX12, such as changes to how memory residency is handled and how DX12 applications can more explicitly control residence.

The overhauling of WDDM for 2.0 means that graphics drivers are impacted as well as the OS, and like Microsoft, NVIDIA and AMD have been preparing for WDDM 2.0 with updated graphics drivers. These drivers are still a work in progress, and as a result not all hardware support is enabled and not all bugs have been worked out.

DirectX 12 Support Status
  Current Status Supported At Launch
AMD GCN 1.2 (285) Working Yes
AMD GCN 1.1 (290/260 Series) Working Yes
AMD GCN 1.0 (7000/200 Series) Buggy Yes
NVIDIA Maxwell 2 (900 Series) Working Yes
NVIDIA Maxwell 1 (750 Series) Working Yes
NVIDIA Kepler (600/700 Series) Working Yes
NVIDIA Fermi (400/500 Series) Not Active Yes

In short, among AMD and NVIDIA their latest products are up and running in WDDM 2.0, but not on all of their earlier products. In AMD’s case GCN 1.0 cards are supported under their WDDM 2.0 driver, but we are encountering texturing issues in Star Swarm that do not occur with GCN 1.1 and later. Meanwhile in NVIDIA’s case, as is common for NVIDIA beta drivers they only ship with support enabled for their newer GPUs – Kepler, Maxwell 1, and Maxwell 2 – with Fermi support disabled. Both AMD and NVIIDA have already committed to supporting DirectX 12 (and by extension WDDM 2.0) on GCN 1.0 and later and Fermi and later respectively, so while we can’t test these products today, they should be working by the time DirectX 12 ships.

Also absent for the moment is a definition for DirectX 12’s Feature Level 12_0 and DirectX 11’s 11_3. Separate from the low-level API itself, DirectX 12 and its high-level counterpart DirectX 11.3 will introduce new rendering features such as volume tiled resources and conservative rasterization. While all of the above listed video cards will support the DirectX 12 low-level API, only the very newest video cards will support FL 12_0, and consequently be fully DX12 compliant on both a feature and API basis. Like so many other aspects of DirectX 12, Microsoft is saving any discussion of feature levels for GDC, at which time we should find out what the final feature requirements will be and which (if any) current cards will fully support FL 12_0.

Finally, with Microsoft’s announcement of their Windows 10 plans last month, Microsoft is also finally clarifying their plans for the deployment of DirectX 12. Because DirectX 12 and WDDM 2.0 are tied at the hip, and by extension tied to Windows 10, DirectX 12 will only be available on Windows 10. Windows 8/8.1 and Windows 7 will not be receiving DirectX 12 support.

DirectX 12 Supported OSes
  Will Support DX12? Required WDDM Version
Windows 10 Yes 2.0
Windows 8.1 No N/A
Windows 8 No N/A
Windows 7 No N/A

Backporting DirectX 12 to earlier OSes would require backporting WDDM 2.0 as well, which brings with it several issues due to the fact that WDDM 2.0 is a kernel component. Microsoft would either have to compromise on WDDM 2.0 features in order to make it work on these older kernels, or alternatively would have to more radically overhaul these kernels to accommodate the full WDDM 2.0 feature set, the latter of which is a significant engineering task and carries a significant risk of breaking earlier Windows installations. Microsoft has already tried this once before in backporting parts of Direct3D 11.1 and WDDM 1.2 to Windows 7, only to discover that even that smaller-scale project had compatibility problems. A backport of DirectX 12 would in turn be even more problematic.

The bright side of all of this is that with Microsoft’s plans to offer Windows 10 as a free upgrade for Windows 7/8/8.1 users, the issue is largely rendered moot. Though DirectX 12 isn’t being backported, Windows users will instead be able to jump forward for free, so unlike Windows 8 this will not require spending money on a new OS just to gain access to the latest version of DirectX. This in turn is consistent with Microsoft’s overall plans to bring all Windows users up to Windows 10 rather than letting the market get fragmented among different Windows versions (and risk repeating another XP), so the revelation that DirectX 12 will not get backported has largely been expected since Microsoft’s Windows 10 announcement.

Meanwhile we won’t dwell on the subject too much, but DirectX 12 being limited to Windows 10 does open up a window of opportunity for Mantle and OpenGL Next. With Mantle already working on Windows 7/8 and OpenGL Next widely expected to be similarly portable, these APIs will be the only low-level APIs available to earlier Windows users.

The DirectX 12 Preview Star Swarm & The Test
Comments Locked

245 Comments

View All Comments

  • tipoo - Friday, February 6, 2015 - link

    They'd still be relatively slower than the i3, but just higher in absolute terms relative to themselves.
  • Sivar - Friday, February 6, 2015 - link

    Has no one informed Microsoft?
    They will never actually release DirectX 12:
    http://tech.slashdot.org/story/13/04/12/1847250/am...
  • HighTech4US - Thursday, February 26, 2015 - link

    WOW, who would have thought that NEVER would only last 2 years.
  • jwcalla - Friday, February 6, 2015 - link

    So it took MS three years to catch up to OGL? I guess better late than never. ;-P
  • tipoo - Friday, February 6, 2015 - link

    Oh, so that's why the consortium is dropping OpenGL in favor of a from-the-ground-up API called GLNext? OpenGL hasn't been better than DX in many years. OpenGL holdouts like Carmack even said so themselves, that they only still use it because of inertia, but DX was better recently.
  • jwcalla - Friday, February 6, 2015 - link

    Yeah, whatever. BMDI has been available in OGL for years now and now DX is finally getting it.

    glNext will likely just be the AZDO stuff w/ a more developer-friendly API + some marketing hype.
  • tipoo - Friday, February 6, 2015 - link

    That's one feature. Total API performance was still not in OGLs favour.
  • jwcalla - Friday, February 6, 2015 - link

    Sure it was. Look at Valve's comparison in their L4D2 ports, and that's with OpenGL 2.x/3.x vs. D3D9.
  • nulian - Saturday, February 7, 2015 - link

    Which was vs DX9 and even valve said they could have improved DX 9 performance if they wanted to. DX 10+ is very different.
  • killeak - Sunday, February 8, 2015 - link

    As a developer that shipped all my games in both D3D and OpenGL (some also in OpenGL ES), I think OpenGL issues are fare more complex than a feature or two.

    What Khronos does with OpenGL it self is just defining the interface and its ideal behavior behind it. The issue is, the actual implementation is not done by Khronos but the IHVs in their drivers. Which means that every combination of OS + GPU + driver can behave different, and in practice this happens a lot!

    With D3D, you have one single implementation: The one done by MS in their OS. Sure, each Windows version has it's own implementation, and each GPU has different drivers, but the RunTime of D3D handles almost everything. Which in practice mean, that if the games run on a GPU in a particular version of Windows, it will run on every other GPU with that version of Windows (as long the GPU has the required features). It could happen that with advanced features and back doors/extensions this is not the rule, but that is an exception in the world of DX, in OpenGL is always like that.

    So, sure, I want OpenGL to be in parity feature wise with D3D (if is more advance better), but I am more worried about things like shader compilation, where you have hundred of different compilers in the market, since each GPU + OS + Drivers has its own. In PC is not that bad (is still bad), but on mobile is a disaster.

    Also it doesn't help that IHVs want to sell HW, not software, in fact they only make software (drivers) because they have to, is not their business, so they optimize their drivers for benchmarks and the like, but the actual implementation is never solid. In that regard, I am happy to see that the presentation of glNext at GDC, is done by developers and not IHVs.

    To be honest, I will be more pleased if Valve made their runtime for SteamOS, and Google for Android, and let the drivers do just the interface with the HW, nothing else. In the end, Apple does that for Macs (but is also true that they also control the HW). Maybe they could have, at least, something like the Windows WHQL in order to keep all implementation for their OS in line.

    And just as a note, I never shipped a game on Windows that runs better on OpenGL that on Direct3D, ever, even when I invested more time on the OpenGL implementation.

Log in

Don't have an account? Sign up now