Ashes of the Singularity Revisited: A Beta Look at DirectX 12 & Asynchronous Shading
by Daniel Williams & Ryan Smith on February 24, 2016 1:00 PM ESTDirectX 12 vs. DirectX 11
Now that we’ve had the chance to look at DirecX 12 performance, let’s take a look at things with DirectX 11 thrown into the mix. As a reminder, while the two rendering paths are graphically identical, the DirectX 12 path introduces the latter’s multi-core scalability along with asynchronous shading functionality. The game and the underlying Nitrous engine is designed to take advantage of both, but particularly the multi-core functionality as the game pushes some very high batch counts.
Given that we had never benchmarked Ashes under DirectX 11 before, what we had been expecting was a significant performance regression when switching to it. Instead what we found was far more surprising.
On the RTG side of matters, there is a large performance gap between DX11 and DX12 at all resolutions, increasing with the overall performance of the video card being tested. Even on the R9 290X and the 7970, using DX12 is a no brainer, as it improves performance by 20% or more.
The big surprise however is with the NVIDIA cards. For the more powerful GTX 980 Ti and GTX 780 Ti, NVIDIA doesn’t gain anything from the DX12 rendering path; in fact they lose a percent or two in performance. This means that they have very good performance under DX11 (particular the GTX 980 Ti), but it’s not doing them any favors under DX12, where as we’ve seen RTG has a rather consistent performance lead. In the past NVIDIA has gone through some pretty extreme lengths to optimize the CPU usage of their DX11 driver, so this may be the payoff from general optimizations, or even a round of Ashes-specific optimizations.
Breaking down the gains on a percentage basis at 1080p, the most CPU-demanding resolution, we find that the Fury X picks up a full 50% from DX12, followed by 29% and 23% for the R9 290X and 7970 respectively. Meanwhile at the opposite end of the spectrum are the GTX 980 Ti and GTX 780 Ti, who lose 1% and 3% respectively.
Finally, right in the middle of all of this is the GTX 680. Given what happens to the architecturally similar GTX 780 Ti, this may be a case of GPU memory limitations (this is the only 2GB NVIDIA card in this set), as there’s otherwise no reason to expect the weakest NVIDIA GPU to benefit the most from DX12.
Overall then this neatly illustrates why RTG in particular has been so gung-ho about DX12, as Ashes’ DX12 path has netted them a very significant increase in performance. To some degree however what this means is a glass half full/half empty full situation; RTG gains so much from DX12 in large part because of their poorer DX11 performance (especially on the faster cards), but on the other hand a “simple” API change has unlocked a great deal of GPU power that wasn’t otherwise being used and vaulted them well into the lead. As for NVIDIA, is it that their cards don’t benefit from DX12, or is it that their DX11 driver stack is that good to begin with? At the end of the day Ashes is just a single game – and a beta game at that – but it will be interesting to see if this is a one-off situation or if it becomes recurring.
Facebook
Twitter
RSS
153 Comments
View All Comments
Beany2013 - Wednesday, February 24, 2016 - link
You are aware that Mantle and DX12 are actually different APIs, yeah?zheega - Wednesday, February 24, 2016 - link
AMD just released new drivers that say are made for this benchmark. Can we get a quick follow-up if their performance improves even more??http://support.amd.com/en-us/kb-articles/Pages/AMD...
AMD has partnered with Stardock in association with Oxide to bring gamers Ashes of the Singularity – Benchmark 2.0 the first benchmark to release with DirectX® 12 benchmarking capabilities such as Asynchronous Compute, multi-GPU and multi-threaded command buffer Re-ordering. Radeon Software Crimson Edition 16.2 is optimized to support this exciting new release.
revanchrist - Wednesday, February 24, 2016 - link
See? Every time when there's a pro AMD game tested, there'll be much butt hurt fanboy comments. And i guess everyone knows why. Because when you bought something, you'll always want to justified your purchase and you know who's got the lion share of the dGPU market now. Guess nowadays people are just too sensitive or has a heart of glasses, which makes them judging things ever so subjectively and personally.Socius - Wednesday, February 24, 2016 - link
For anyone who missed it:"Update 02/24: NVIDIA sent a note over this afternoon letting us know that asynchornous shading is not enabled in their current drivers, hence the performance we are seeing here. Unfortunately they are not providing an ETA for when this feature will be enabled."
ToTTenTranz - Wednesday, February 24, 2016 - link
"Unfortunately they are not providing an ETA for when this feature will be enabled."If ever...
andrewaggb - Wednesday, February 24, 2016 - link
Makes sense why it would be slightly slower. Also makes through benchmarks less meaningfulExt3h - Wednesday, February 24, 2016 - link
"not enabled" is a strange and misleading wording, since it obviously is both available and working correctly according to the specification.Should be read as "not being made full use of", as it is only lacking any clever way of profiting from asynchronous compute in hardware.
barn25 - Thursday, February 25, 2016 - link
If you google around you will find out nvidia does not have asynchornous shading on its DX"12" cards. this was actually first found out in WDDM 1.3 back in windows 8.1 when they would not support the optional features which AMD does.Ext3h - Thursday, February 25, 2016 - link
I know that the wrong terminology kept being used for years now, especially driven by major tech review websites like this one. But that's still not making it any less wrong.The API is fully functional. So the driver does support it. Whether it does so efficiently is an entirely different matter, you don't NEED hardware "support" to provide that feature. Hardware support is only required to provide parallel execution, as opposed to the default sequential fallback. The latter one is perfectly within the bounds in the specification, and counts as fully functional. It's just not providing any additional benefits, but it's neither broken nor deactivated.
barn25 - Thursday, February 25, 2016 - link
Don't try to change it. I am referring to HW Asyc compute, which AMD supports and NVidia does not. Using a shim will impact performance even greater.