computerbaseAshes of the Singularity Beta1 DirectX 12 Benchmarks

[ThatBuzzkiller]

There are other hardware features like CR, ROV etc. which will improve performance. Why is Oxide not using them to realize better graphics?

ROVs could be easily implemented but it's not useful in the case of AotS since the game doesn't require serialized UAV access with respect to the generated pixel shader's invocation order to render it's alpha affects plus only Intel's implementation is performant compared to Nvidia trying to avert developers from using it as much as possible ...

Conservative rasterization can't be dropped in on most game engines since it's intrusive to the rendering pipeline so the rendering pipeline needs to be developed around it's usage ...

It's a similar case for AMD as to why the PC developers aren't making use of shader specificed stencil reference value which can be useful for shadow caster culling or showing off the use cases for fully bindless resources which will be of use in the long run ...

 

[littleg]

That GPU usage graph for DX11 and DX12 posted a couple of pages tells the whole story. Fury X and the other GCN cards finally living up to their potential. Will be interesting to see if this carries on with the other DX12 games that are coming out.

 

[Bacon1]

I would like an analysis of the differences between the dx12 and 11 builds. If more is happening in dx12 vs dx11 it would explain why nvidia doesn't gain performance in dx12. They could do the same thing faster in dx12 then, answering :

From an old video Oxide was talking about how with DX12, each "shot" (weapon particles) will cast its own light, which is not possible under DX11. I don't have the game so can't test that myself, but I'm guessing thats where most of the performance goes, or maybe thats only enabled while using async compute. Maybe some reviewer site will do IQ tests between DX11 and DX12, Oxide dev said that they were overhauling how that system worked in this latest build

Hmm... well, I suppose we could investigate it but that effect has already been completely changed, just not out yet in public. So it's probably a waste of time for us at this point to investigate. I haven't seen any noticeable differences between AMD and NVidia myself.

http://www.overclock.net/t/1590939/...-async-compute-yet-says-amd/350#post_24893376

^^ was regarding the IQ differences we were talking a dozen pages back between Nvidia and AMD, so since those effects are now changed we'll have to see what the differences are.

 

[beginner99]

It is the other way around. Disabling Asynchronous Compute is effort that you have to put into coding.

And if NV pays for it, it will be done. See Tomb Raider.

Back to Async Compute, I have said all along since 2014, Maxwell is NOT capable of Async Compute/Shading, they still have ONE engine and that is totally against the principle of DX12 multi-engine workloads.

They knew all along their hardware was incapable, but they have no issues telling lies to the press, even telling AnandTech they could. Now they have to issue a correction saying its not enabled, despite promising a long time ago to enable it.

I find it difficult to understand why people defend their actions. Tell lies to sell more hardware, 3.5GB 970, people defend that... tell lies that their GPUs support DX12 Async Compute to sell more hardware, you defending that too?

Here's the final say, because its officially from AMD, unless NV would like to make a statement against this:

NV GPUs do not have functional Async Shading/Compute. Not in Vulkan.

https://community.amd.com/community...on-gpus-are-ready-for-the-vulkan-graphics-api



Not in DX12.

https://community.amd.com/community...blade-stealth-plus-razer-core-gaming-solution

You have to give NV credit for making money. Yes it's bad for the consumer but if I were owner or shareholder I would applaud to NV's clever practices like always crippling their GPU in some way that you have to my the new one to be able to play modern games.

GTX 680: vram, crippling fo kepler
GTX 780 Ti: crippling of kepler with drivers and GimpWorks so people need to buy maxell. GTX 970 faster than 780 Ti in some games.
GTX970: vram "bug". Sell it for seaminglx cheap price but with built in vram defect so people need to upgrade again soon
Maxwell in general: crippled Dx12 performance. Fixed in Pascal. User needs to upgrade.

See the pattern? It's brilliant from point of view of being CEO or shareholder of NV. However frustrating from the standpoint of a consumer. I don't get NV fanboys. The pattern has been here since 7970/680. Every single AMD card aged better. I can see if you got burned by the 680, even if you then bought the 780 Ti but after that you are just stupid to buy NV. Pascal might come with some obscure limitation again, at least NV has less option to cripple it on drivers again like they did with Maxwell.

 

[GodisanAtheist]

This is fantastic news, if Sontin is right (or if he's wrong, or whatever).

NV didn't get to 80% marketshare running their business like AMD; AMD isn't going to win back any of that marketshare running their business like AMD either. If Sontin is right, this is a fantastic case of AMD running their business like NV and there might be hope for them and a competitive GPU marketplace after all. This is how you do good word of mouth marketing.

You need to heavily slant things in your favor (think NV and tesselation) and get it in front of everyone to mold public perception of your products.

Maybe NV ends up doing fine in DX 12 and this is all a crazy conspiracy, but buyers will (rightly or wrongly) think "do I want to take that chance on performance with NV?" And go AMD instead.

 

[Bacon1]

Anyone know if any of the reviews used the 16.2 drivers? They have perf increase for Ashes.

Radeon Software Crimson Edition 16.2 Highlights
AMD has partnered with Stardock in association with Oxide to bring gamers Ashes of the Singularity – Benchmark 2.0 the first benchmark to release with DirectX® 12 benchmarking capabilities such as Asynchronous Compute, multi-GPU and multi-threaded command buffer Re-ordering. Radeon Software Crimson Edition 16.2 is optimized to support this exciting new release.

The SteamVR Performance Test: we are pleased to report that our Radeon R9 390, Nano, and Fury series GPUs are all able to achieve 'VR Recommended' status, the highest achievable level of experience possible. In addition to that, our affinity multi-GPU feature is already showing significant performance uplift over a single GPU on Radeon cards in the aforementioned benchmark

Performance and quality improvements for

* Rise of the Tomb Raider™
* Ashes of the Singularity – Benchmark 2

Crossfire Profiles available for

* The Division
* XCOM 2

http://support.amd.com/en-us/kb-articles/Pages/AMD_Radeon_Software_Crimson_Edition_16.2.aspx

 

[3DVagabond]

Agreed.

AMD involved? Bad news for Nvidia and Intel.

http://www.computerbase.de/2016-02/.../#diagramm-cpu-skalierung-1920-1080-r9-fury-x



But if it would be 970>Fury X it would be gimping. Right?

Difference is Gameworks doesn't improve performance for anyone. Also, AMD isn't blocking nVidia's involvement. So, this isn't the same thing at all.

 

[Silverforce11]

NV didn't get to 80% marketshare running their business like AMD; AMD isn't going to win back any of that marketshare running their business like AMD either. If Sontin is right, this is a fantastic case of AMD running their business like NV and there might be hope for them and a competitive GPU marketplace after all. This is how you do good word of mouth marketing.

You need to heavily slant things in your favor (think NV and tesselation) and get it in front of everyone to mold public perception of your products.

Maybe NV ends up doing fine in DX 12 and this is all a crazy conspiracy, but buyers will (rightly or wrongly) think "do I want to take that chance on performance with NV?" And go AMD instead.

AMD should have done what you suggested years ago when they still had a decent marketshare.

The thing is, it's too late. 970 out-sold all of AMD GPUs combined.

980Ti/Titan X sold massively better than Fury/X. Low end, the 750Ti dominates, low-midrange, the 960 won.

Nothing AMD can do now change that.

This year, when DX12 games start to come out, we will soon have Pascal vs Polaris, and unless Pascal is gimped at DX12, it will be as if nothing has happened, NV got away with selling lies and Maxwell users will upgrade to Pascal, as usual.

Basically those 970 owners, of which dwarfs all other mid-range/high-end GPUS will have to upgrade once the DX12 era is in fullswing. It's gimped on bandwidth, ROPs, 3.5GB vram and lacks DX12/Vulkan Async Compute. Due to its 3.5 + 0.5 vram segmentation, it requires driver heuristics (per NV's own words, from AnandTech's article back then) aka driver optimizations to function well. Think that's going to happen in the Pascal era? "Game Ready" doesn't apply to old-tech.

Yup, so millions of those gamers will look to upgrade later this year. NV's got it in the bag!

 

[3DVagabond]

Sure. The only horse in the race when you get paid to shoot everyone else.

So, AMD who according to some can't even fund GPU or driver development, now has the money to buy off devs? Can't have it both ways.

 

[Silverforce11]

So, AMD who according to some can't even fund GPU or driver development, now has the money to buy off devs? Can't have it both ways.

Anyone remember this?

"NVIDIA's Dirty Dealing with DX10.1 and How GT200 Doesn't Support it"

http://www.anandtech.com/show/2549/7

It's useful to point out that, in spite of the fact that NVIDIA doesn't support DX10.1 and DX10 offers no caps bits, NVIDIA does enable developers to query their driver on support for a feature.

Hardware doesn't support it, drivers fake it anyway.

After asking our question, this is the response we got from NVIDIA Technical Marketing:

"We support Multisample readback, which is about the only dx10.1 feature (some) developers are interested in. If we say what we can't do, ATI will try to have developers do it, which can only harm pc gaming and frustrate gamers."

The policy decision that has lead us to run into this type of response at every turn is reprehensible. Aside from being blatantly untrue at any level, it leaves us to wonder why we find ourselves even having to respond to this sort of a statement.

Amazing isn't it. NV fakes things their hardware support, because they worry ATI will "try to have" devs use features that harm "pc gaming and frustrate gamers".

This sums it up:

Next, the idea that developers in collusion with ATI would actively try to harm pc gaming and frustrate gamers is false (and wreaks of paranoia).

JHH is a paranoid man, so he fears ATI will bribe devs to sabotage NV GPUs with features their hardware can't do or can't do well, he starts the TWIMTBP program with that exact intention.

NVIDIA insists that if it reveals it's true feature set, AMD will buy off a bunch of developers with its vast hoards of cash to enable support for DX10.1 code NVIDIA can't run. Oh wait, I'm sorry, NVIDIA is worth twice as much as AMD who is billions in debt and struggling to keep up with its competitors on the CPU and GPU side. So we ask: who do you think is more likely to start buying off developers to the detriment of the industry?

And to sum it up, NV is being silent again on hardware features of DX12/Vulkan Async Compute.

So who really suffers from NVIDIA's flawed policy of silence and deception? The first to feel it are the hardware enthusiasts who love learning about hardware. Next in line are the developers because they don't even know what features NVIDIA is capable of offering. Of course, there is AMD who won't be able to sell developers on support for features that could make their hardware perform better because NVIDIA hardware doesn't support it (even if it does). Finally there are the gamers who can and will never know what could have been if a developer had easy access to just one more tool.

My god. That is tech journalism at it's best.

Not a servant of these tech corporations, but a real investigative attempt at the truth.

How we all hardware enthusiasts suffer due to the decline of objective tech journalism these days!

 

[AtenRa]

Yup, so millions of those gamers will look to upgrade later this year. NV's got it in the bag!

Fortunately there are still two players in the game, some of those gamers will have the opportunity to choose between Polaris and Pascal. This time DX-12 games will be available, it is not 2014 anymore.

 

[Shivansps]

You know what im seeing there? something that does not worth expending an extra cent on developing anything.

and that 2160P mayor gain does not make sence to me, one whould think its on 1080P where the mayor perf gain will show up, because its where we are more CPU, DX11 limited and GPU resources are not fully used on every frame.

Just too much over hype on a feature used in a crappy alpha game, its like taking Star Citizen as a example of anything.

 

[Mahigan]

You know what im seeing there? something that does not worth expending an extra cent on developing anything.

and that 2160P mayor gain does not make sence to me, one whould think its on 1080P where the mayor perf gain will show up, because its where we are more CPU, DX11 limited and GPU resources are not fully used on every frame.

Just too much over hype on a feature used in a crappy alpha game, its like taking Star Citizen as a example of anything.

I dunno, looks totally worth it to me The game is in Beta and the feature will be used in Hitman, Fable Legends, Deus Ex: Mankind Divided, Battlefield 5, Gears of War Ultimate Edition and others.

Spoiler

 

[Hitman928]

Anyone know if any of the reviews used the 16.2 drivers? They have perf increase for Ashes.



http://support.amd.com/en-us/kb-articles/Pages/AMD_Radeon_Software_Crimson_Edition_16.2.aspx

anandtech and tomshardware.de did not. Computebase.de did. I didn't check others.

 

[zlatan]

There are other hardware features like CR, ROV etc. which will improve performance. Why is Oxide not using them to realize better graphics?

While CR and ROVs are powerful features, it is not easy to implement these in an efficient way.

Maxwell only support the Tier_1 option of CR which is good for generating light maps and sub-pixel shadow maps, but nothing else really. Tier_2 is also not really useful for accelerating voxelization, because it needs a really big engine rewrite. The consoles don't support it also, so there is no point to support an accelerated form of the CPU-based voxelization.
Tier_3 is interesting because it supports occlusion culling, but it is only available on Skylake, so if Intel don't finance the research, than most devs will wait a little, when more hardwares can use this feature.

ROVs is a different beast. It is very useful, but still needs a well designed implementation, and it can be really performance hog with today's hardware. Skylake has a relatively good implementation, but this is not enough. Of course, if Intel finance than there is no problem.

But in the end, for the first steps it is very logical to support the core features of D3D12 like the multi-threaded command buffer recording and the multiengine model.

 

[SPBHM]

did Nvidia release the DX12 drivers for Fermi that they promised for last year? would be interesting to see how they perform.

 

[Silverforce11]

anandtech and tomshardware.de did not. Computebase.de did. I didn't check others.

Very interesting, they actually optimized DX11 performance with 16.2!

 

[Erenhardt]

So async compute gives around 10% boost across all GCN. Not bad but I hoped for more. Curious to see how it pans out in other games.

 

[Spjut]

did Nvidia release the DX12 drivers for Fermi that they promised for last year? would be interesting to see how they perform.

DX12 support is still MIA for Fermi, but Fermi did recently get support for WDDM 2.0, so it's probably getting close


Computerbase.de also did a test for various CPUs. Even when comparing it to Nvidia's DX11 performance, DX12 brings a nice increase for the slower CPUs
http://www.computerbase.de/2016-02/ashes-of-the-singularity-directx-12-amd-nvidia/5/

 

[Mahigan]

did Nvidia release the DX12 drivers for Fermi that they promised for last year? would be interesting to see how they perform.

When hell freezes over, around the same time that they'll implement full Asynchronous Compute support. I heard that they're simply waiting for a portal to Narnia to open up so that they can contract a few magical elves to sprinkle pixie dust over their Maxwell, Kepler and Fermi GPUs.

Any day now....

Oh and did you hear about Pascal?? Better buy that one quick. It's got electrolytes

 

[Dygaza]

Very interesting, they actually optimized DX11 performance with 16.2!

Dunno where you getting this, but I'm not getting any better results under DX11 with these drivers. Gotta remember that this benchmark is new. I'm not sure if the map is different, but atleast it has snow in it. Also it now has 2 different races fighting against eachoters. So there are new effects aswell. So can't really make straight comparision to older version of the benchmark.

 

[HurleyBird]

So async compute gives around 10% boost across all GCN. Not bad but I hoped for more. Curious to see how it pans out in other games.

As long as you aren't on GCN 1.0, yeah.

 

[Mahigan]

So async compute gives around 10% boost across all GCN. Not bad but I hoped for more. Curious to see how it pans out in other games.

20% on Fiji
10% on Hawaii
2% on Tahiti

But that's for Ashes of the Singularity, other games will be different and vary in terms of a performance boost.

 

[Dygaza]

Do we have any idea how much more async compute this new version of benchmark uses?

We had very basic support of this feature. During the process of development for Multi-GPU, we realized that some of the lessons learned and code written could be applied to async compute. Thus, this benchmark 2 has a much more advanced implementation of this feature.

This doesn't really tell if there is more of it, or just same amount in more advanced form.

 

[ThatBuzzkiller]

While CR and ROVs are powerful features, it is not easy to implement these in an efficient way.

Maxwell only support the Tier_1 option of CR which is good for generating light maps and sub-pixel shadow maps, but nothing else really. Tier_2 is also not really useful for accelerating voxelization, because it needs a really big engine rewrite. The consoles don't support it also, so there is no point to support an accelerated form of the CPU-based voxelization.
Tier_3 is interesting because it supports occlusion culling, but it is only available on Skylake, so if Intel don't finance the research, than most devs will wait a little, when more hardwares can use this feature.

ROVs is a different beast. It is very useful, but still needs a well designed implementation, and it can be really performance hog with today's hardware. Skylake has a relatively good implementation, but this is not enough. Of course, if Intel finance than there is no problem.

But in the end, for the first steps it is very logical to support the core features of D3D12 like the multi-threaded command buffer recording and the multiengine model.

This ...

Conservative rasterization requires an engine overhaul and using ROVs to deterministically order fragment shaders is especially troublesome for big GPUs, performance wise ...

Depending on the implementation, too many overlaps for OIT and you could end up with performance slower than a resource/texture barrier! ROVs limit GPU parallelism since your introducing sync points across work groups ...

Tiled GPUs have a nice property of sorting their geometry per tile which allows them to get near free draw call ordering on framebuffer access but it's a double edged sword since it's very hard to scale with high fragment count ...

I'd be very interested to know about the performance characteristics of AMD's ordered atomic counters since you could implement clever per-pixel data structures much like ROVs ...

http://www.uni-weimar.de/fileadmin/...ts/publications/2015.Pacific.Graphics.OIT.pdf

https://diglib.eg.org/handle/10.2312/egsh.20141012.049-052

http://graphics.cs.williams.edu/papers/TransparencyI3D16/McGuire2016Transparency.pdf

All of these papers are extremely promising alternatives for OIT without having to do shader interlocks ...