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
Alexey291 - Friday, February 6, 2015 - link
It can be as free as it likes. In fact for all I care they can pay me to install it... Still not going to bother. And you know why? There's no benefit for me who only uses a Windows desktop as a gaming machine.Not a single one. Dx12 is not interesting either because my current build is actually limited by vsync. Nothing else but 60fps vsync (fake fps are for kids). And it's only a mid range build.
So why should I bother if all I do in Windows at home is launch steam (or a game from an icon on the desktop) aaaand that's it?
Nuno Simões - Friday, February 6, 2015 - link
Clearly, you need to read the article again.Alexey291 - Saturday, February 7, 2015 - link
There's a difference in a benchmark. Well surprise surprise. On the other hand games are likely to be optimised before release. Even games by Ubisoft MIGHT be optimised somewhat.So the difference between dx11 and 12 will be imperceptible as usual. Just like the difference between ten and eleven was even though benchmarks have always shown that 11 is more efficient and generally faster.
Nuno Simões - Saturday, February 7, 2015 - link
So, it's faster and more efficient, but that's worthless?What happened between 10 and 11 is that developers used those improevments to add to substance, not speed, and that is probably going to happen again. But anyway you see it, there is a gain in something. And, besides, just the gains from frametimes and lower buffers is worth it. Less stutter is always a good thing.
And the bad optimisation from some developers is hardly DX's fault, or any other API for that matter. Having a better API doesn't suddenly turn all other API's into s*it.
inighthawki - Saturday, February 7, 2015 - link
What are you blabbering on about? No benefit? Fake fps? Do you even know anything about PCs or gaming?Alexey291 - Saturday, February 7, 2015 - link
You don't actually understand that screen tearing is a bad thing do you? :)Murloc - Saturday, February 7, 2015 - link
I've never seen screen tearing in my life and I don't use vsync despite having a 60 Hz monitor.Fact is, you and I have not much to gain from DX12, apart for the new features (e.g. I have a dx10 card and I can't play games with the dx11 settings which do add substance to games, so it does have a benefit, you can't say there is no difference).
So whether you upgrade or not will not influence the choices of game engine developers.
The CPU bottlenecked people are using 144Hz monitors and willing to spend money to get the best so they do gain something. Not everybody is you.
Besides, I will be upgrading to windows 10 because the new features without the horrible w8 stuff are really an improvement, e.g. the decent copy/paste dialog that is already in w8.
Add the fact that it's free for w8/8.1 owners and it will see immediate adoption.
Some people stayed on XP for years instead of going to Vista before 7, but they eventually upgraded anyway because the difference in usability is quite significant. Not being adopted as fast as you some guy on the internet think would be fast enough is no excuse to stop development, otherwise someone else will catch up.
inighthawki - Saturday, February 7, 2015 - link
I well understand what screen tearing is, but not locking to vsync doesn't suddenly make it 'fake FPS.' You literally just made up a term that means nothing/. You're also ignoring the common downside of vsync: input lag. For many people it is extremely noticeable and makes games unplayable unless they invest in low latency displays with fast refresh rates.Margalus - Saturday, February 7, 2015 - link
it does make it "fake fps" in a way. It doesn't matter if fraps is telling you that you are getting 150fps, your monitor is only capable of showing 60fps. So that 150fps is a fallacy, you are only seeing 60fps. And without vsync enabled, those 60fps that your monitor is showing are comprised of pieces more than one frame in each, hence the tearing.but other than that, I can disagree with most everything that poster said..
inighthawki - Saturday, February 7, 2015 - link
Correct, I realize that. But it's still not really fake. Just because you cannot see every frame it renders does not mean that it doesn't render them, or that there isn't an advantage to doing so. By enabling vsync, you are imposing a presentation limit on the application. It must wait until the vsync to present the frame, which means the application must block until it does. The faster the GPU is at rendering frames, the larger impact this has on input latency. By default, DirectX allows you to queue three frames ahead. this means if your GPU can render all three frames within one refresh period of your monitor, you will have a 3 frame latency (plus display latency) between when it's rendered and when you see it on screen, since each frame needs to be displayed in the order it is rendered. With vsync off, you get tearing because there is no wait on presents. The moment you finish is the moment you can swap the backbuffer and begin the next frame. You always have (nearly) the minimal amount of latency possible. This is avoidable with proper implementations of triple buffering that allow the developer to discard old frames. In all cases, the fps still means something. Rendering at 120fps and only seeing 60 of them doesn't make it useless to do so.