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
CPU Scaling
Diving into our look at DirectX 12, let’s start with what is going to be the most critical component for a benchmark like Star Swarm, the CPU scaling.
Because Star Swarm is designed to exploit the threading inefficiencies of DirectX 11, the biggest gains from switching to DirectX 12 on Star Swarm come from removing the CPU bottleneck. Under DirectX 11 the bulk of Star Swarm’s batch submission work happens under a single thread, and as a result the benchmark is effectively bottlenecked by single-threaded performance, unable to scale out with multiple CPU cores. This is one of the issues DirectX 12 sets out to resolve, with the low-level API allowing Oxide to more directly control how work is submitted, and as such better balance it over multiple CPU cores.
Starting with a look at CPU scaling on our fastest cards, what we find is that besides the absurd performance difference between DirectX 11 and DirectX 12, performance scales roughly as we’d expect among our CPU configurations. Star Swarm's DirectX 11 path, being single-threaded bound, scales very slightly with clockspeed and core count increases. The DirectX 12 path on the other hand scales up moderately well from 2 to 4 cores, but doesn’t scale up beyond that. This is due to the fact that at these settings, even pushing over 100K draw calls, both GPUs are solidly GPU limited. Anything more than 4 cores goes to waste as we’re no longer CPU-bound. Which means that we don’t even need a highly threaded processor to take advantage of DirectX 12’s strengths in this scenario, as even a 4 core processor provides plenty of kick.
Meanwhile this setup also highlights the fact that under DirectX 11, there is a massive difference in performance between AMD and NVIDIA. In both cases we are completely CPU bound, with AMD’s drivers only able to deliver 1/3rd the performance of NVIDIA’s. Given that this is the original Mantle benchmark I’m not sure we should read into the DirectX 11 situation too much since AMD has little incentive to optimize for this game, but there is clearly a massive difference in CPU efficiency under DirectX 11 in this case.
Having effectively ruled out the need for 6 core CPUs for Star Swarm, let’s take a look at a breakdown across all of our cards for performance with 2 and 4 cores. What we find is that Star Swarm and DirectX 12 are so efficient that only our most powerful card, the GTX 980, finds itself CPU-bound with just 2 cores. For the AMD cards and other NVIDIA cards we can get GPU bound with the equivalent of an Intel Core i3 processor, showcasing just how effective DirectX 12’s improved batch submission process can be. In fact it’s so efficient that Oxide is running both batch submission and a complete AI simulation over just 2 cores.
Speaking of batch submission, if we look at Star Swarm’s statistics we can find out just what’s going on with batch submission. The results are nothing short of incredible, particularly in the case of AMD. Batch submission time is down from dozens of milliseconds or more to just 3-5ms for our fastest cards, an improvement just overof a whole order of magnitude. For all practical purposes the need to spend CPU time to submit batches has been eliminated entirely, with upwards of 120K draw calls being submitted in a handful of milliseconds. It is this optimization that is at the core of Star Swarm’s DirectX 12 performance improvements, and going forward it could potentially benefit many other games as well.
Another metric we can look at is actual CPU usage as reported by the OS, as shown above. In this case CPU usage more or less perfectly matches our earlier expectations: with DirectX 11 both the GTX 980 and R9 290X show very uneven usage with 1-2 cores doing the bulk of the work, whereas with DirectX 12 CPU usage is spread out evenly over all 4 CPU cores.
At the risk of speaking to the point that it’s redundant, what we’re seeing here is exactly why Mantle, DirectX 12, OpenGL Next, and other low-level APIs have been created. With single-threaded performance struggling to increase while GPUs continue to improve by leaps and bounds with each generation, something must be done to allow games to better spread out their rendering & submission workloads over multiple cores. The solution to that problem is to eliminate the abstraction and let the developers do it themselves through APIs like DirectX 12.
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.