The DirectX 12 Performance Preview: AMD, NVIDIA, & Star Swarm
by Ryan Smith on February 6, 2015 2:00 PM EST- Posted in
- GPUs
- AMD
- Microsoft
- NVIDIA
- DirectX 12
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.
Facebook
Twitter
RSS
245 Comments
View All Comments
inighthawki - Monday, February 9, 2015 - link
>> btw funny how "M$ would need to do huge kernel rework to bring DX12 to Win7/8" while mantle, which does similar thing, is easily capable to be "OS version independent" (sure it is amd specific but still)How do you know that DX12 will not support a number of features that Mantle will not? For example, DX12 is expected to provide the application with manual memory management, a feature not available in Mantle while running on WDDM 1.3 or below.
lordken - Tuesday, February 10, 2015 - link
what I meant is in performance terms. While mantle is able to deliver +/-same performance boost as DX12 but still on old windows kernel.Not saying DX12 wont support something that mantle wont be able to do on old windows kernel. I merely tried to highlight that same performance boost can be achieved on current OS without the need of M$ taunting gamers with Win10 (forced) upgrade for DX12
killeak - Tuesday, February 10, 2015 - link
"btw funny how "M$ would need to do huge kernel rework to bring DX12 to Win7/8" while mantle, which does similar thing, is easily capable to be "OS version independent" (sure it is amd specific but still)"Direct3D has a very different design. While APIs like OpenGL or Mantle are implemented in the drivers, Direct3D is implemented (the runtime) in the OS. That means, that no matter what hardware you have, the code that is executed under the API, is for most part, always the same. Sure, the Driver needs to expose and abstract the hardware (following another API, in this case WDDM 2.0), but the actual implementation is much more slim. Which means is much more solid and reliable.
Now, OpenGL is implemented in the driver, the OS only expose the basic C functions to create the context and the like. A good driver can make OpenGL works as fast, or even more, than D3D, but the reality says that 90% of the time, OpenGL works worse. Not just because of performance, but because each driver for each OS and each GPU has a different implementation, things usually doesn't work as you expected.
After years of working with OpenGL and D3D, the thing that I miss more of D3D when I am coding for OpenGL platforms, is the single runtime. Program once, run everywhere (well on every windows) works on D3D but not on OpenGL, hell is even harder on mobile with OpenGL ES, and the broken drivers of Mali, Qualcomm, etc. Sure, if your app is simple OpenGL works, but for AAA it just doesn't cut...
The true is, IHVs are here to sell hardware, not software, so they invest the minimum time and money on it (most of the time they optimize drivers for big AAA titles and benchmarks). For mobile, where SoCs are replaced every year, is even workse, since drivers never get mature enough. Heck, Mali for example doesn't have devices with the 700 series on the market and they already announced the 800 series, while their OpenGL ES drivers for the 600 are really bad.
Going back to Mantle and Win7/8. In the drivers, you can do what ever you want, so yes, you can make your own API and make it work wherever you want, that is why Mantle can do things low level without WDDM 2.0, it doesn't need to be common or compatible to other drivers/vendors.
Bill McGann - Tuesday, February 10, 2015 - link
Yeah, this is a huge reason why GL is largely ignored by Windows devs. D3D is extremely stable thanks to it largely being implemented by MS, and them having the power to test/certify the vendor's back-ends.GL on the other hand is the wild west, with every vendor doing whatever they like... You even have them stealing MS's terrible 90's browser-war strategies of deliberately supporting broken behavior, hoping devs will use it, so that games will break on other vendor's (strictly compliant) drivers. Any situation where vendors are abusing devs like this is pretty f'ed up.
tobi1449 - Thursday, February 12, 2015 - link
The console & pc aspect isn't going anywhere and was never meant to. AMD formulated their early press releases in a way that some people jumped the hype train before it was even built, but AMD was shut down by Microsoft and Sony pretty quickly about that.Bill McGann - Tuesday, February 10, 2015 - link
FYI mantle is very carefully specified as a vendor-agnostic API, like GL, with extensions for vendor-specific behavior.If AMD even bother launching Mantle after D3D12/GLNext appear, and if it remains AMD-only, it's because nVidia/Intel have chosen not to adopt the spec, not because AMD have deliberately made it AMD-only.
tobi1449 - Thursday, February 12, 2015 - link
a) I can see why there's resistance against adopting a competitors API.b) AFAIK AMD hasn't released anything needed to implement Mantle for other hardware yet. Sure, they've often talked about it and most of the time Mantle is mentioned this pops up, but in reality (if this is still correct) it is as locked down as say G-Sync or PhysX.
Arbie - Tuesday, February 10, 2015 - link
I closely followed graphics board technology and performance for many years. But after a certain point I realized that there are actually very few - count 'em on one hand - games that I even enjoy playing. Three of those start with "Crysis" (and the other two with "Peggle"). The Battlefield series might have the same replay interest; don't know.So unless and until there are really startling ~3x gains for the same $$, my interest in desktop graphics card performance is much more constrained by game quality than by technology. I don't want to run "Borderlands" 50% faster because... I don't want to run it at all. Or any other of the lousy console ports out there.
computertech82 - Wednesday, February 11, 2015 - link
SLIGHT PROBLEM. I think it's safe to say the dx11 vs dx12 was ran on the SAME OS 10. That probably just means dx11 runs crappy on win10, not that dx12 is so much better. I bet it would be different with win7/8 dx11 vs win10 dx12 (meaning very little difference).Notmyusualid - Thursday, February 12, 2015 - link
Good point - hadn't considered it until you mentioned it.Then the comparison should really have been dx11 - Win 7/8, dx12 - Win 10, Mantle - both (if poss).