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
About a year and a half ago AMD kicked off the public half of a race to improve the state of graphics APIs. Dubbed "Mantle", AMD’s in-house API for their Radeon cards stripped away the abstraction and inefficiencies of traditional high-level APIs like DirectX 11 and OpenGL 4, and instead gave developers a means to access the GPU in a low-level, game console-like manner. The impetus: with a low-level API, engine developers could achieve better performance than with a high-level API, sometimes vastly exceeding what DirectX and OpenGL could offer.
While AMD was the first such company to publicly announce their low-level API, they were not the last. 2014 saw the announcement of APIs such as DirectX 12, OpenGL Next, and Apple’s Metal, all of which would implement similar ideas for similar performance reasons. It was a renaissance in the graphics API space after many years of slow progress, and one desperately needed to keep pace with the progress of both GPUs and CPUs.
In the PC graphics space we’ve already seen how early versions of Mantle perform, with Mantle offering some substantial boosts in performance, especially in CPU-bound scenarios. As awesome as Mantle is though, it is currently a de-facto proprietary AMD API, which means it can only be used with AMD GPUs; what about NVIDIA and Intel GPUs? For that we turn towards DirectX, Microsoft’s traditional cross-vendor API that will be making the same jump as Mantle, but using a common API for the benefit of every vendor in the Windows ecosystem.
DirectX 12 was first announced at GDC 2014, where Microsoft unveiled the existence of the new API along with their planned goals, a brief demonstration of very early code, and limited technical details about how the API would work. Since then Microsoft has been hard at work on DirectX 12 as part of the larger Windows 10 development effort, culminating in the release of the latest Windows 10 Technical Preview, Build 9926, which is shipping with an early preview version of DirectX 12.
GDC 2014 - DirectX 12 Unveiled: 3DMark 2011 CPU Time: Direct3D 11 vs. Direct3D 12
With the various pieces of Microsoft’s latest API finally coming together, today we will be taking our first look at the performance future of DirectX. The API is stabilizing, video card drivers are improving, and the first DirectX 12 application has been written; Microsoft and their partners are finally ready to show off DirectX 12. To that end, today we’ll looking at DirectX 12 through Oxide Games’ Star Swarm benchmark, our first DirectX 12 application and a true API efficiency torture test.
Does DirectX 12 bring the same kind of performance benefits we saw with Mantle? Can it resolve the CPU bottlenecking that DirectX 11 struggles with? How well does the concept of a low-level API work for a common API with disparate hardware? Let’s find out!
Facebook
Twitter
RSS
245 Comments
View All Comments
tipoo - Friday, February 6, 2015 - link
They'd still be relatively slower than the i3, but just higher in absolute terms relative to themselves.Sivar - Friday, February 6, 2015 - link
Has no one informed Microsoft?They will never actually release DirectX 12:
http://tech.slashdot.org/story/13/04/12/1847250/am...
HighTech4US - Thursday, February 26, 2015 - link
WOW, who would have thought that NEVER would only last 2 years.jwcalla - Friday, February 6, 2015 - link
So it took MS three years to catch up to OGL? I guess better late than never. ;-Ptipoo - Friday, February 6, 2015 - link
Oh, so that's why the consortium is dropping OpenGL in favor of a from-the-ground-up API called GLNext? OpenGL hasn't been better than DX in many years. OpenGL holdouts like Carmack even said so themselves, that they only still use it because of inertia, but DX was better recently.jwcalla - Friday, February 6, 2015 - link
Yeah, whatever. BMDI has been available in OGL for years now and now DX is finally getting it.glNext will likely just be the AZDO stuff w/ a more developer-friendly API + some marketing hype.
tipoo - Friday, February 6, 2015 - link
That's one feature. Total API performance was still not in OGLs favour.jwcalla - Friday, February 6, 2015 - link
Sure it was. Look at Valve's comparison in their L4D2 ports, and that's with OpenGL 2.x/3.x vs. D3D9.nulian - Saturday, February 7, 2015 - link
Which was vs DX9 and even valve said they could have improved DX 9 performance if they wanted to. DX 10+ is very different.killeak - Sunday, February 8, 2015 - link
As a developer that shipped all my games in both D3D and OpenGL (some also in OpenGL ES), I think OpenGL issues are fare more complex than a feature or two.What Khronos does with OpenGL it self is just defining the interface and its ideal behavior behind it. The issue is, the actual implementation is not done by Khronos but the IHVs in their drivers. Which means that every combination of OS + GPU + driver can behave different, and in practice this happens a lot!
With D3D, you have one single implementation: The one done by MS in their OS. Sure, each Windows version has it's own implementation, and each GPU has different drivers, but the RunTime of D3D handles almost everything. Which in practice mean, that if the games run on a GPU in a particular version of Windows, it will run on every other GPU with that version of Windows (as long the GPU has the required features). It could happen that with advanced features and back doors/extensions this is not the rule, but that is an exception in the world of DX, in OpenGL is always like that.
So, sure, I want OpenGL to be in parity feature wise with D3D (if is more advance better), but I am more worried about things like shader compilation, where you have hundred of different compilers in the market, since each GPU + OS + Drivers has its own. In PC is not that bad (is still bad), but on mobile is a disaster.
Also it doesn't help that IHVs want to sell HW, not software, in fact they only make software (drivers) because they have to, is not their business, so they optimize their drivers for benchmarks and the like, but the actual implementation is never solid. In that regard, I am happy to see that the presentation of glNext at GDC, is done by developers and not IHVs.
To be honest, I will be more pleased if Valve made their runtime for SteamOS, and Google for Android, and let the drivers do just the interface with the HW, nothing else. In the end, Apple does that for Macs (but is also true that they also control the HW). Maybe they could have, at least, something like the Windows WHQL in order to keep all implementation for their OS in line.
And just as a note, I never shipped a game on Windows that runs better on OpenGL that on Direct3D, ever, even when I invested more time on the OpenGL implementation.