DirectX 12 Performance Tested In Ashes of the Singularity

Vigile writes: The future of graphics APIs lies in DirectX 12 and Vulkan, both built to target GPU hardware at a lower level than previously available. The advantages are better performance, better efficiency on all hardware and more control for the developer that is willing to put in the time and effort to understand the hardware in question. Until today we have only heard or seen theoretical "peak" performance claims of DX12 compared to DX11. PC Perspective just posted an article that uses a pre-beta version of Ashes of the Singularity, an upcoming RTS utilizing the Oxide Games Nitrous engine, to evaluate and compare DX12's performance claims and gains against DX11. In the story we find five different processor platforms tested with two different GPUs and two different resolutions. Results are interesting and show that DX12 levels the playing field for AMD, with its R9 390X gaining enough ground in DX12 to overcome a significant performance deficit that exists using DX11 to the GTX 980.

Comments

Wait a min, Direct X 12 needs what?

[Anonymous Coward]

The Developer now must know MORE about the underlying hardware to make the best use of Direct X 12?

This is a total step in the WRONG direction. So now having Direct X 12 hardware doesn't mean your game now just works, oh no. If you want the full experience you now must have the HARDWARE that your game was written for, or forget all this compatible Direct X stuff. How's this different from the game developer just coding directly to the video hardware of choice? That's what they do now, especially when they are funded by the video hardware guys in an effort to sell more hardware..

For this Direct X thing to really be useful, it needs to isolate the developer from the hardware implementation. You need to abstract away the vendor specifics and make the programming agnostic to what hardware it's running on... Otherwise this is all going to just going to be what it has always been, vendor lock in for specific games and drive us towards only ONE video hardware chip maker....

Re:Wait a min, Direct X 12 needs what?

[GigaplexNZ]

The Developer now must know MORE about the underlying hardware to make the best use of Direct X 12?

Uh, yeah, that's what a lower level API means.

Re:Wait a min, Direct X 12 needs what?

[exomondo]

I'm not quite sure why you are modded down, this is a perfectly valid and legitimate concern.

Part of the problem of PC gaming has always been that the choice of hardware has meant we have had to have abstraction layers and these introduced inefficiencies which have reached significant levels nowadays. You remember seeing every time a new console generation is released that PC gamers proclaim it is terrible because their PC hardware is theoretically more powerful? Well that is true however being more powerful is pointless if that power can not be efficiently utilized, it just goes to waste. Heavy abstractions and generic implementations mean a lot of that increased power is wasted. So it is about bringing APIs up to scratch with modern hardware and removing some of the legacy cruft. It means more responsibility on the part of the application developer in the same way that it did when we went from the fixed function pipeline to the programmable pipeline many years ago.

For this Direct X thing to really be useful, it needs to isolate the developer from the hardware implementation. You need to abstract away the vendor specifics and make the programming agnostic to what hardware it's running on.

Well it still is relatively hardware agnostic, the difference is that we have had many advances in hardware that are not reflected in modern APIs. Take resource binding for example, currently resources are bound to "slots" when you define a shader pipeline and are fixed at draw time so if you want to change the resources that this shader pipeline uses you need to bind those new resources to those slots and draw again. This was a great general view of hardware at the time and is forward-compatible. But modern hardware has long had the capability to index a table of resources rather than just whatever is currently bound to the resource slots though the APIs are not architected to allow this. So this is generally implemented on an application-specific basis in the driver when the driver author (usually the hardware manufacturer) works with the application developer to understand what they are trying to accomplish that the API doesn't provide and then create a kind of munging layer in the driver that converts the application's "bind->draw bound, rebind->draw bound" workflow into a "create table->draw all" workflow. This is partly why you see significant performance differences in applications between driver versions but also why an application on similarly capable hardware can perform so vastly different between vendors.

That's just one example, I hope it's somewhat clear. Yes there is less of an abstraction in some areas but at the API level it doesn't do things like expose an AMD R9 -specific feature or an nVidia GTX980 -specific feature.

Re:Wait a min, Direct X 12 needs what?

[Dutch Gun]

No, don't worry. I haven't seen the DirectX 12 API yet myself (I'm still working in DX9-11 land), but I'm pretty sure all this is doing is making the abstraction layer more closely match the realities of the existing hardware designs. That is, it's not eliminating the abstraction altogether, but making it a much thinner layer, so as to avoid imposing unnecessary overhead.

All the GPUs work in roughly the same manner, because they have to execute the same common shader micro-code. In order to be labeled as "DX11" or "DX12" compliant hardware, a GPU must be able to perform a minimum set of functionality. Moreover, the vast majority of this functionality is accessed via shader languages, and this doesn't change from GPU to GPU.

I'd be surprised if there was any significant divergence at all between different types of GPUs in the code at all. DirectX 12 looks like it's going to be a very good thing, both for developers and for gamers.

Re:Wait a min, Direct X 12 needs what?

[Anonymous Coward]

I know slashdot usually does not read AC, but I reply none the less.

Your post and grandparent is spot on, but I still do not think it is a problem. The ecosystem has changed a lot, "back then" basically every studio wrote their own engine, today we have three big engine makers (Epic with UE, Crytek with CryEngine, and Unity) on the market plus a few big in-house engines of the publishers that they do not license out.
A few other larger projects make their own engines, but if we are down to half a dozen major ones and another half dozen big ones we are basically there.

Small projects - and many AAA titles - just take one of the existing engines and do not bother.

There also was a large change on the manufacturer side: there are not half a dozen big card makers anymore with a whole lineup of products, we are seeing two major makers for games + intel for everything else; their chips are also based on the very few actual designs and custom-building code for these two or five bases is possible - especially as we have big engine makers who do the heavy lifting.

The heavy abstraction of old DirectX versions was the right thing to do - and the introduction of DirectX is actually one thing Microsoft did really right and we have to thank them for that. Does anyone remember the chaos in the DOS-days? - but now it is also the right thing to keep a common API but reduce the abstraction at the cost of big engine makers (putting 10s and 100s of millions in their products) and large publishers who in-house create an engine (Frostbite, for example) which fuels several AAA titles in the years to come.

Driver Differences

[nateman1352]

I think what this benchmark really tells us is two things:

1. nVidia has not optimized their driver stack for DX12 as much as AMD has optimized for DX12
2. The performance difference between AMD and nVidia is likely a software issue, not a hardware issue (nVidia's driver has a more optimized DX11 implementation than AMD's). However, it is possible that nVidia's silicon architecture is designed to run DX11 workloads better than AMD's.

Bullet #1 make sense, AMD has been developing Mantle for years now so they likely have a more mature stack for these low level APIs. Bullet #2 also makes sense, AMD/ATI's driver has been a known weak point for a long time now.

If it means I have to take Windows 10?

[hairyfeet]

I'll pass, even though I have all AMD hardware. Its just not worth giving up my privacy and having Big Brother MSFT snoop through everything I do just to have DX12. I love gaming but not enough to let MSFT stick a webcam over my shoulder, thx anyway.

DX12 levels the playing field for AMD

[JohnStock]

No.. This engine's implementation *may* level the playing field for AMD but that does not mean that API does.

These results don't make much sense

[Kjella]

It is widely known that DX12 will reduce draw call overhead, making weaker CPUs perform better relative to stronger CPUs. This is of course good for AMD, since they don't have high-end CPUs anymore though it's bit of a "scorched earth" result where gamers don't need expensive CPUs at all. But if you look at "Ashes (Heavy) DX11 to DX12 Scaling - Radeon R9 390X" and look at an extremely powerful CPU like the Core i7-6700 you're seeing 50-100% gains. If you're that severely bottle-necked by a 4+ GHz quad core then this is not a typical DX11 game.

We can compare the "typical" difference between a R9 390X and GTX980 in Anandtech's bench, though I have to substitute for a R290X "Uber" so the differences should actually be even smaller. Normally these cards are almost head to head, the question is not why DX12 is closing the gap but why there's such a huge DX11 gap to begin with. And the only reason I can come up with is because they're pushing way, way more draw calls than normal. Which may be DX12 enabling developers to do things they wanted to, but couldn't before or it could be to make someone look good/bad.

Its the threading model

[Anonymous Coward]

Direct3D 11 introduced the capability to render with multiple threads via deferred contexts. NVidia chose to support that feature, AMD did not. Direct3D 12 mandates multithreaded rendering.

Star Swarm style marketing continues

[Luckyo]

Those who haven't clued in yet: this is the same engine that was used for "unreleased game turned DX 12 synthetic benchmark" star swarm. All same caveats apply:
1. Unknown engine not available to public with unknown performance. We have no idea how DX11 implementation is made, or why DX12 is so much faster than anywhere else seen so far.
2. Is in pre-alpha, meaning performance is all over the place and a complete black box, it could render faster in DX11 in next build for all we know.

We've been there with mantle already. Specialized tech demos showing massive performance boost from using mantle over DX11. Then release, frostbite et al start supporting it and we see minimal to no performance boost outside really low end CPUs bundled with really high end GPUs.

Show me this kinds of numbers on a known engine that has a polished DX11 implementation like unreal 4 engine, and I'll actually believe you. Until then, all I see is more marketing BS.

Re:Star Swarm style marketing continues

[Fragnet]

We do know why DX12 is a lot faster. For example here's one of a thousand articles about it. Also please see NVIDIA's SIGGRAPH 2015 presentation on Vulkan (same kind of technology as D3D 12).