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
First Thoughts
Bringing our preview of DirectX 12 to a close, what we’re seeing today is both a promising sign of what has been accomplished so far and a reminder of what is left to do. As it stands much of DirectX 12’s story remains to be told – features, feature levels, developer support, and more will only finally be unveiled by Microsoft next month at GDC 2015. So today’s preview is much more of a beginning than an end when it comes to sizing up the future of DirectX.
But for the time being we’re finally at a point where we can say the pieces are coming together, and we can finally see parts of the bigger picture. Drivers, APIs, and applications are starting to arrive, giving us our first look at DirectX 12’s performance. And we have to say we like what we’ve seen so far.
With DirectX 12 Microsoft and its partners set out to create a cross-vendor but still low-level API, and while there was admittedly little doubt they could pull it off, there has always been the question of how well they could do it. What kind of improvements and performance could you truly wring out of a new API when it has to work across different products and can never entirely avoid abstraction? The answer as it turns out is that you can still enjoy all of the major benefits of a low-level API, not the least of which are the incredible improvements in CPU efficiency and multi-threading.
That said, any time we’re looking at an early preview it’s important to keep our expectations in check, and that is especially the case with DirectX 12. Star Swarm is a best case scenario and designed to be a best case scenario; it isn’t so much a measure of real world performance as it is technological potential.
But to that end, it’s clear that DirectX 12 has a lot of potential in the right hands and the right circumstances. It isn’t going to be easy to master, and I suspect it won’t be a quick transition, but I am very interested in seeing what developers can do with this API. With the reduced overhead, the better threading, and ultimately a vastly more efficient means of submitting draw calls, there’s a lot of potential waiting to be exploited.
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.