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
DirectX 12 vs. Mantle, Power Consumption
Although the bulk of our coverage today is going to be focused on DirectX 12 versus DirectX 11, we also wanted to take a moment to also stop and look at DirectX 12 and how it compares to AMD’s Mantle. Mantle offers an interesting point of contrast being that it has been in beta longer than DirectX 12, but also due to the fact that it’s an even lower level API than DirectX 12. Since Mantle only needs to work on AMD’s GPUs and can be tweaked for AMD’s architectures, it offers AMD the chance to exploit their GPUs in a few additional ways that a common, cross-vendor API like DirectX 12 cannot.
With 4 cores we find that AMD achieves better results with Mantle than DirectX 12 across the board. The gains are never very great – a few percent here and there – but they are consistent and just outside our window of variability for the Star Swarm benchmark. With such a small gain there are a number of factors that can possibly explain this outcome – better developed drivers, better developed application, further benefits of working with a known hardware platform – so we can’t credit any one factor. But it’s safe to say that at least in this one instance, at this time, Star Swarm’s Mantle rendering path produces even better results than its DirectX 12 path on AMD cards.
On the other hand, Mantle doesn’t seem to be able to accommodate a two-core situation as well, with the 290X seeing a small but distinct performance regression from switching to Mantle from DirectX 12. Though we didn’t have time to look at an AMD APU for this article, it would be interesting to see if this regression occurs on their 2M/4C parts as well as it does here; AMD is banking heavily on low-level APIs like Mantle to help level the CPU playing field with Intel, so if Mantle needs 4 CPU cores to fully spread its wings with faster cards, that might be a problem.
Diving deeper, we can see that part of the explanation for our Mantle performance regression may come from the batch submission process. DirectX 12 is unexpectedly well ahead of Mantle here, with batch submission taking on average a bit more than half as long as it does under Mantle. As batch submission times are highly correlated to CPU bottlenecking on Star Swarm, this would imply that DirectX 12 would bottleneck later than Mantle in this instance. That said, since we’re so strongly GPU-bound right now it’s not at all clear if either API would be CPU bottlenecked any time soon.
Update: Oxide Games has emailed us this evening with a bit more detail about what's going on under the hood, and why Mantle batch submission times are higher. When working with large numbers of very small batches, Star Swarm is capable of throwing enough work at the GPU such that the GPU's command processor becomes the bottleneck. For this reason the Mantle path includes an optimization routine for small batches (OptimizeSmallBatch=1), which trades GPU power for CPU power, doing a second pass on the batches in the CPU to combine some of them before submitting them to the GPU. This bypasses the command processor bottleneck, but it increases the amount of work the CPU needs to do (though note that in AMD's case, it's still several times faster than DX11).
This feature is enabled by default in our build, and by combining those small batches this is the likely reason that the Mantle path holds a slight performance edge over the DX12 path on our AMD cards. The tradeoff is that in a 2 core configuration, the extra CPU workload from the optimization pass is just enough to cause Star Swarm to start bottlenecking at the CPU again. For the time being this is a user-adjustable feature in Star Swarm, and Oxide notes that in any shipping game the small batch feature would likely be turned off by default on slower CPUs.
If we turn off the small batch optimization feature, what we find is that Mantle' s batch submission time drops nearly in half, to an average of 4.4ms. With the second pass removed, Mantle and DirectX 12 take roughly the same amount of time to submit batches in a single pass. However as Oxide noted, there is a performance hit; the Mantle rendering path's performance goes from being ahead of DirectX 12 to trailing it. So given sufficient CPU power to pay the price for batch optimization, it can have a signifcant impact (16%) on improving performance under Mantle.
Finally, we wanted to take a quick look at power consumption among cards and APIs. To once again repeat what we said earlier, Star Swarm is an imperfect, non-deterministic benchmark, and coupled with the in-development status of DirectX 12 everything here is subject to change. However we thought this was interesting enough to include in our evaluation.
As expected, the increased throughput from DirectX 12 and Mantle drive up system power consumption. With the CPU no longer the bottleneck, the GPU never gets a chance to idle and video card power consumption ramps up to full load.
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).