Ashes of the Singularity User Benchmarks Thread

[AtenRa]

Asynchronous compute isn't some magic bullet you know. It may give big benefits for AMD's architecture seeing as though GCN has a problem with underutilization, but hardly anything for NVidia's as Maxwell is much more efficient.

The under-utilization is happening in EVERY GPU under DX-11, its not a problem of GCN specifically. DX-11 cannot utilize the entire GPU (memory, compute, rasters etc) simultaneously on GCN or Maxwell.

It is only in DX-12 with Async Compute that you can use more parts of the GPU simultaneously if the hardware supports it.

 

[Carfax83]

The under-utilization is happening in EVERY GPU under DX-11, its not a problem of GCN specifically. DX-11 cannot utilize the entire GPU (memory, compute, rasters etc) simultaneously on GCN or Maxwell.

It is only in DX-12 with Async Compute that you can use more parts of the GPU simultaneously if the hardware supports it.

Of course underutilization is a problem for every GPU, I never said otherwise.

But some GPU architectures have a bigger problem with it than others. Maxwell is a much more efficient architecture than GCN, which is why it is able to do more with less and with lower overall energy consumption.

AC uses idle resources to perform the compute tasks, so obviously a GPU with a greater amount of idle resources are going to get larger performance gains from AC compared to one that has less idle resources.

 

[3DVagabond]

And what am I supposed to get pray tell? The developer said it was enabled in the driver, but it just wasn't working the way it should be working.

If Maxwell 2 doesn't support AC as the dev suggests, then why on Earth would they enable it in their drivers?

The likely answer is that it's supported, but either not properly implemented (due to hardware design), or not properly optimized in their driver codebase.

I'm betting on the latter..

So you stated without reservation that the games path was buggy. Now you are saying that it's nVidia's hardware or drivers. Which is it?

 

[Carfax83]

So you stated without reservation that the games path was buggy. Now you are saying that it's nVidia's hardware or drivers. Which is it?

It's likely not the game's fault. It's something on NVidia's end, most likely a driver problem that can hopefully be fixed.. It's ultimately the driver that maps closest to the hardware after all..

 

[sontin]

This is the first time a major dev studio has come out and say flat out that NV GPUs cannot do async compute. Other devs have been hush on the issue and NV themselves haven't demoed any async shader features of DX12.

It is the same company who blames nVidia's drivers while warning reviewers to not use MSAA under DX12 because they havent optimized their engine for it.

Why should we believe them? And where is the proof that AS isnt working?

 

[Skurge]

Anyone remember when the 9700 Pro and the FX5800Ultra were out. John Carmack said the 9700Pro was the definitive DX9 graphics card. Nvidia maintained their cards would run DX9 great. Then HL2 came out and the FX series ran DX9 so badly Valve forced them to run in DX8.... sound familiar? Now that may have been a long time ago, but nVidia is not a quiet company and if their cards could run async compute well. You would be hearing it from from them. Like Tessellation. Any company can be caught of guard or wrong footed.

If that is the case. Pascal and AI is still a very long time away. We should see who has the advantage moving into next year. I just hope no IHV's strong arm any of the devs into removing useful features just cause their hardware doesn't run it well. If that happens on a large scale then I'm pretty much done with PC gaming.

I am optimistic though.

 

[Silverforce11]

It is the same company who blames nVidia's drivers while warning reviewers to not use MSAA under DX12 because they havent optimized their engine for it.

Why should we believe them? And where is the proof that AS isnt working?

There is no war of words between us and Nvidia. Nvidia made some incorrect statements, and at this point they will not dispute our position if you ask their PR.

That is, they are not disputing anything in our blog. I believe the initial confusion was because Nvidia PR was putting pressure on us to disable certain settings in the benchmark, when we refused, I think they took it a little too personally.

That's pretty damn ballsy. Basically Oxide is challenging NV to prove them wrong.

They sound damn certain, so the ball is in NV's court.

 

[Silverforce11]

Anyone remember when the 9700 Pro and the FX5800Ultra were out. John Carmack said the 9700Pro was the definitive DX9 graphics card. Nvidia maintained their cards would run DX9 great. Then HL2 came out and the FX series ran DX9 so badly Valve forced them to run in DX8.... sound familiar? Now that may have been a long time ago, but nVidia is not a quiet company and if their cards could run async compute well. You would be hearing it from from them. Like Tessellation. Any company can be caught of guard or wrong footed.

If that is the case. Pascal and AI is still a very long time away. We should see who has the advantage moving into next year. I just hope no IHV's strong arm any of the devs into removing useful features just cause their hardware doesn't run it well. If that happens on a large scale then I'm pretty much done with PC gaming.

I am optimistic though.

Spot on.

However, Async Compute is just one of the DX12 features. A game can simply not use it at all and rely purely on lower API overhead & native multi-threading, in which case there is no negative for NV in DX12. But that case alone, helps GCN tremendously due to their DX11 bottlenecks. Async Compute on top of that, is just icing on the cake for AMD.

Now knowing more about the uarchs, its definitely a case of AMD making a major gamble with GCN (one uarch, designed to be long lasting, forward looking [maximize return for $ investment]) and using their console advantage to push forward an new API that gives them the edge.

Regarding your second point, based on what we've seen so far, there's no way GameWorks titles will have Async Compute, that much is certain. The PC port will have those features disabled. It will also push some FL12.1 to give NV GPUs an edge. Contrary, AMD GE titles will push Async Compute, to use it to offload the main rendering threads onto the ACEs giving them a major speed boost. Basically both companies will have a powerful stick they can beat each other with. How bad for AMD this will be, it will depend on whether FL12.1 is optional fluff in games like HBAO, GodRays etc (since AMD hardware can't run FL12.1 at all due to no support) or its a core feature, if its core, a title is basically NV exclusive.

 

[TheELF]

Not because of the "more units that it really needs"

Yeah on the console apus they barely get the things they need to work,so of course they don't have gains because of more units.
Needs a real genius to figure that one out.

In ashes, if the game did not have so many units, would the devs be able to find enough stuff to run in parallel to get a boost?

 

[3DVagabond]

It's likely not the game's fault. It's something on NVidia's end, most likely a driver problem that can hopefully be fixed.. It's ultimately the driver that maps closest to the hardware after all..

I obviously misunderstood what you were saying. Thanks for clearing it up.

 

[stuff_me_good]

I just hope that what ever new features DX12 has AMD won't make the same mistake like they did with tesselation. They introduced this new really good feature, but settle for moderate performance with it. Then NV goes crazy on it and makes it 3x faster than AMD's tesselation and pushes developers to overly use it so it would hurt AMD.

Remember those heavily tesselated boxes on crysis 2? I just hope AMD doesn't make same mistake again and leave room for some shit like that for next architecture.

 

[3DVagabond]

I just hope that what ever new features DX12 has AMD won't make the same mistake like they did with tesselation. They introduced this new really good feature, but settle for moderate performance with it. Then NV goes crazy on it and makes it 3x faster than AMD's tesselation and pushes developers to overly use it so it would hurt AMD.

Remember those heavily tesselated boxes on crysis 2? I just hope AMD doesn't make same mistake again and leave room for some shit like that for next architecture.

AFAIU nVidia uses CC's (shaders) for tessellation. AMD designed their GPU's differently and use separate transistors (Tessellation engine). That has worked better for nVidia in raw tessellation power. As the CC's increase so does tessellation performance. Now, AMD did it the way they did because they believe that doing it the way nVidia does will cause issues if the shaders become bottlenecked by the tessellation workload. So far that hasn't proven true. With DX12 feeding more information to the GPU that might change. We'll see.

 

[desprado]

Really some members are making me laugh at this topic.

First yes Async Compute is very good and D12 is the best for PC gaming but you need developers to support it. Therefore, developers requires money to invest in their engine to properly support it.

Second, the big problem is corporate companies like Sony and MS will never want PC gaming to dominate that is why most of the developers won’t be interested to implementing it very fast.

Third and the biggest problem is console port due to 3/1 ratio of gaming sales.

That is the reason it will take around 3 to 4 years to fully support Dx12 all features and same like Dx11, which took more than 3 years for every AAA title to use it. However, there will be some games supporting Dx12 but it will not take full advantage of Dx12 yet.

 

[Silverforce11]

@desprado

Didn't you use to say last year that DX12 was an important feature, that's why Maxwell is better? At the time we didn't know the specs of GCN on DX12 but NV came out and said their Maxwell was fully DX12 compliant. I recall seeing a lot of members here tout DX12 as a great advantage for NV.

Back then a lot of the same people were adamant that DX12 is not Mantle-like, I recall massive threads with a ton of flaming hate against Mantle.

Now suddenly it's DX12 not important, it takes years...

Why the flip flop? Hmm.

ps. We don't need EVERY AAA title to be DX12 for it to be important. There's already a confirmed swathe of DX12 games incoming very soon.

 

[sontin]

That's pretty damn ballsy. Basically Oxide is challenging NV to prove them wrong.

They sound damn certain, so the ball is in NV's court.

Oxide official said that their MSAA implementation under DX12 has problem because Oxide hasnt optimized it.
The ball is in their court.

Now they are saying that nVidia doesnt support Async Compute, although Microsoft demonstrated Async Compute on their hardware.

I still wait for an explanation why nVidia's DX11 path should be faster than DX12. They cant even blame Async Compute for the performance degression anymore. :sneaky:

 

[3DVagabond]

Oxide official said that their MSAA implementation under DX12 has problem because Oxide hasnt optimized it.
The ball is in their court.

Now they are saying that nVidia doesnt support Async Compute, although Microsoft demonstrated Async Compute on their hardware.

I still wait for an explanation why nVidia's DX11 path should be faster than DX12. They cant even blame Async Compute for the performance degression anymore. :sneaky:

They said that nVidia wrote code that took it out of their render pipe. If they do support it you think they would have written code that supported it for their hardware, not taken it out.

Interesting that it's the only vendor specific code. Alternately, what happens when AMD tries to get devs to run code for their hardware in games that are sponsored by nVidia?

 

[Mahigan]

Folks need to set their partisanship aside. It doesn't help you, me, us or anyone except the Corporation to whom you have sworn PR allegiances too.

From what we do know is that the console developers are making good use of Async Shading. They're making more use out of it than Oxide has. Look what happened in Ashes of the Singularity with only a handful of post processing effects?

There's no use in trying to mitigate any damage to one Corporation. It isn't your job. Your job is to inform others and help the new PC gamers make the correct investments going forward. Your fellow PC gamers are your allies not your foes. By supporting one another, we place the burden of innovation in the large tech companies (as it should be).

Async Shading is some pretty amazing technology. If widely used, it would allow for gaming realism that is beyond anything any of us have experienced. The promise of Cinematic Gaming, promised to us back when the GeForceFX was released, is near our finger tips... Why not collectively push for it?

NVIDIA is doing fine. They were able to optimize their shader code by working with Oxide. Going forward the onus on innovation ought to be placed on their hands. We shouldn't push for a lower usage of this feature just because we fear the impact it may have on our preferred brand.

I am confident that Pascal will rectify this short coming. NVIDIA is sitting on a large cash pile. They'll be fine.

Now what is in YOUR interests? A better gaming experience? Or more stagnation?

The ball is in your court.

 

[TheELF]

They said that nVidia wrote code that took it out of their render pipe. If they do support it you think they would have written code that supported it for their hardware, not taken it out.

If something already works great, or at least better than something new, why should they leave the worse code in?
If down the road they(either oxide or nvidia) improve the new thing to the point that it is better then the old then they will put it back in.

 

[Azix]

And what am I supposed to get pray tell? The developer said it was enabled in the driver, but it just wasn't working the way it should be working.

If Maxwell 2 doesn't support AC as the dev suggests, then why on Earth would they enable it in their drivers?

The likely answer is that it's supported, but either not properly implemented (due to hardware design), or not properly optimized in their driver codebase.

I'm betting on the latter..

He said the architecture does not support it. This info can come from knowing arch details from documentation etc. This can not be cancelled by speculation on why it's in drivers.

The other thing is that it might not matter much on Maxwell. They wouldn't likely gain the same performance benefit

I think people are having trouble accepting the extra power in gcn. E.g. 8.9tflops fury x, ~5.6-6tflops 980ti. This matters now because Amd hardware has the extra power top be tapped with better efficiency provided by async. 30% probably lines up well with the difference. With 30% more performance gcn is going to end current Maxwell

Spot on.

However, Async Compute is just one of the DX12 features. A game can simply not use it at all and rely purely on lower API overhead & native multi-threading, in which case there is no negative for NV in DX12. But that case alone, helps GCN tremendously due to their DX11 bottlenecks. Async Compute on top of that, is just icing on the cake for AMD.

Now knowing more about the uarchs, its definitely a case of AMD making a major gamble with GCN (one uarch, designed to be long lasting, forward looking [maximize return for $ investment]) and using their console advantage to push forward an new API that gives them the edge.

Regarding your second point, based on what we've seen so far, there's no way GameWorks titles will have Async Compute, that much is certain. The PC port will have those features disabled. It will also push some FL12.1 to give NV GPUs an edge. Contrary, AMD GE titles will push Async Compute, to use it to offload the main rendering threads onto the ACEs giving them a major speed boost. Basically both companies will have a powerful stick they can beat each other with. How bad for AMD this will be, it will depend on whether FL12.1 is optional fluff in games like HBAO, GodRays etc (since AMD hardware can't run FL12.1 at all due to no support) or its a core feature, if its core, a title is basically NV exclusive.

I think I remember someone saying conservative rasterization through software might have been faster on AMD hardware than the hardware implemetation on nvidia. Someone post a link to a dev possibly saying this on twitter. Either way, that at least can be done in software well enough.

The other feature saves VRAM? Won't matter much.

It is the same company who blames nVidia's drivers while warning reviewers to not use MSAA under DX12 because they havent optimized their engine for it.

Why should we believe them? And where is the proof that AS isnt working?

Oxide official said that their MSAA implementation under DX12 has problem because Oxide hasnt optimized it.
The ball is in their court.

Now they are saying that nVidia doesnt support Async Compute, although Microsoft demonstrated Async Compute on their hardware.

I still wait for an explanation why nVidia's DX11 path should be faster than DX12. They cant even blame Async Compute for the performance degression anymore. :sneaky:

You post a lot of misinformation.

They never said reviewers should not use MSAA, nvidia did. They did not say they hadn't optimized their engine for MSAA AFAIK.

Your english is good so i don't get why you seem to be shifting sentences and meanings around. They said their dx12 MSAA was standard and ran the same on all hardware. They said that some modifications nvidia might have made in dx11 driver might not have carried over and are willing to make those driver like changes in their own game FOR NVIDIA.

Microsoft did not demonstrate asynchronous compute on nvidia hardware AFAIK. If you are talking about the fable legends demo you or someone else posted, that was demonstrating Typed UAVs or something of the sort. It was not async compute.

I have yet to see anyone claiming maxwell 2 has it much less does well at it. A game having effects does not mean its being done asynchronously. You can do those things the normal way, but AMD having async means they can do it faster, separately from the graphics pipeline or do more.

They can enable it in drivers through software but clearly the hardware chokes.

That's pretty damn ballsy. Basically Oxide is challenging NV to prove them wrong.

They sound damn certain, so the ball is in NV's court.

I dont think it is. Seems just a this is how it is statement. nvidia won't disagree because they know the truth and got over their initial butthurtedness.

 

[3DVagabond]

If something already works great, or at least better than something new, why should they leave the worse code in?
If down the road they(either oxide or nvidia) improve the new thing to the point that it is better then the old then they will put it back in.

Async compute is better. It allows better utilization of the hardware resources by reducing stalled processes.

 

[tential]

And what am I supposed to get pray tell? The developer said it was enabled in the driver, but it just wasn't working the way it should be working.

If Maxwell 2 doesn't support AC as the dev suggests, then why on Earth would they enable it in their drivers?

The likely answer is that it's supported, but either not properly implemented (due to hardware design), or not properly optimized in their driver codebase.

I'm betting on the latter..

That wasn't what was said. You might want to reread that again since you aren't seeming to understand the full situation.

 

[TheELF]

Async compute is better. It allows better utilization of the hardware resources by reducing stalled processes.

I'm not arguing that,but nvidia has optimized dx11 for 3-4 years now while async has been optimized for 0 years ,if old works better for now then why not use it for now?

 

[Mahigan]

I'm not arguing that,but nvidia has optimized dx11 for 3-4 years now while async has been optimized for 0 years ,if old works better for now then why not use it for now?

Because we're moving towards new. Also because new works best on consoles. Consoles make more money for devs, thus programming for consoles makes more sense. When porting over to the PC, you keep the Async coding and program a new Vendor ID specific path for NVIDIA.

 

[Silverforce11]

Because we're moving towards new. Also because new works best on consoles. Consoles make more money for devs, thus programming for consoles makes more sense. When porting over to the PC, you keep the Async coding and program a new Vendor ID specific path for NVIDIA.

Well the easiest option for PC ports will just have a slider in graphics option, if they use Async Shaders for Global Illumination, Dynamic Lights or High-res Shadow Maps, the slider will be enable/disable. Removing a feature takes more effort as is making a vendor specific path.

Similar to the GameWorks situation in current games where there are options, like HBAO, Enhanced Godrays, Fur/HairWorks etc. Slider is the easiest way to ensure the cross-platform game runs well on more hardware.

As to Ashes/Oxide, this is the important point:

I suspect that one thing that is helping AMD on GPU performance is D3D12 exposes Async Compute, which D3D11 did not. Ashes uses a modest amount of it, which gave us a noticeable perf improvement. It was mostly opportunistic where we just took a few compute tasks we were already doing and made them asynchronous, Ashes really isn't a poster-child for advanced GCN features.

Our use of Async Compute, however, pales with comparisons to some of the things which the console guys are starting to do. Most of those haven't made their way to the PC yet, but I've heard of developers getting 30% GPU performance by using Async Compute.

The underline is something people misunderstand about async compute, they think its extra stuff, for low utilization GPUs to use. It's NOT. Utilization has nothing to do with it because a shader can do both graphics & compute workload simultaneously as they require different calculations. This is one of the key points in AMD's DX12 Async Compute presentation. The problem is there's no way to do it in DX11. When people talk about low efficiency of GCN on DX11, it's also about their single thread driver setup, it cannot keep the shaders fed with GRAPHICS workloads, bottlenecking Fury X at 1080p for example. DX's multi-thread rendering solves that. Async Compute is a bonus, like icing on the cake because now any compute task that needs to be done, can be done asynchronously in DX12 on GCN, thus, removing the graphics rendering bottlenecks, leading to a performance improvement.

If they are saying next-gen console ports will use Async Compute even more (why not? Sony in particular pushed for 8 ACEs in their APU), it'll be quite normal to see R290X matching 980Ti due to the speed bonus of the 8 ACEs.

 

[railven]

Well the easiest option for PC ports will just have a slider in graphics option, if they use Async Shaders for Global Illumination, Dynamic Lights or High-res Shadow Maps, the slider will be enable/disable. Removing a feature takes more effort as is making a vendor specific path.

Similar to the GameWorks situation in current games where there are options, like HBAO, Enhanced Godrays, Fur/HairWorks etc. Slider is the easiest way to ensure the cross-platform game runs well on more hardware.

As to Ashes/Oxide, this is the important point:



The underline is something people misunderstand about async compute, they think its extra stuff, for low utilization GPUs to use. It's NOT. Utilization has nothing to do with it because a shader can do both graphics & compute workload simultaneously as they require different calculations. This is one of the key points in AMD's DX12 Async Compute presentation. The problem is there's no way to do it in DX11. When people talk about low efficiency of GCN on DX11, it's also about their single thread driver setup, it cannot keep the shaders fed with GRAPHICS workloads, bottlenecking Fury X at 1080p for example. DX's multi-thread rendering solves that. Async Compute is a bonus, like icing on the cake because now any compute task that needs to be done, can be done asynchronously in DX12 on GCN, thus, removing the graphics rendering bottlenecks, leading to a performance improvement.

If they are saying next-gen console ports will use Async Compute even more (why not? Sony in particular pushed for 8 ACEs in their APU), it'll be quite normal to see R290X matching 980Ti due to the speed bonus of the 8 ACEs.

Unfortunately, you can't ignore MSFT's Xbone in this equation. We've already seen devs hold back the PS4 version of some major games (Destiny) to keep parity with the Xbone version. Also, the games Sony produce/sponsor won't see much face time on PC. The ones that they've announced as cross platform PS4-PC aren't going to be visual stunners (SF5).

MSFT's gimped hardware is a big issue in the console space and no one wants to address it (at least in the gaming media). Even in the tech articles AT's own article tip-toed around the memory system differences and GPU difference to the point of saying something sort of like "with the SRAM, MSFT might just make the GPU difference not so big" which as devs went on to state - hell no the GPU is gimped, the memory system is gimped, and now we got to gimp everything else MSFT will get angry.

When you look at the overall difference of the hardware, PS4 version running at 1080p@30 vs Xbone 900p@30, you know there is still power under the PS4 hood, but they don't want to touch it.

TL;DR:
Only devs really exploiting the PS4 hardware difference are first party and you'll never see those games outside a PS4. The ones that are going PS4-PC exclusive aren't visually stunning when compared to the first party work.