Ashes of the Singularity User Benchmarks Thread

[iiiankiii]

Who cares if Maxwell supports DX12. Pascal will wash all Maxwell's BS away. Just like how Maxwell washed away all of Kepler's BS. People will forget. That's Nvidia moto.

 

[tential]

Even Project car did not market nvidia that much.
Now i think some people doubts should be cleared about Oxide.Therefore, their main priority is only AMD.

Rewriting history I see....

 

[selni]

Maybe what the Oxide guy said has something to do with it.

http://www.overclock.net/t/1569897/...ingularity-dx12-benchmarks/1200#post_24356995



You have to wonder how they suddenly found this performance just before the benchmark launched. AMD should probably take a closer look at the game to see if there's any more cheating there.

Again that post just says DX11 performs better and they don't understand why yet. Could it be nvidia cheating? Sure I guess (and if AMD finds conclusive evidence of that, go ahead and publish it), but it doesn't exactly seem to be the most likely explanation (why cheat at one codepath of benchmark only?).

Game specific optimization isn't exactly an uncommon practice for either dGPU company - and given how different their architectures tend to be is almost necessary. It's not a stretch to believe that nvidia did a lot of work on it and that the DX12 codepath being used is not optimal for their architecture.

 

[DarkKnightDude]

Apparently this was mentioned on the Nvidia subreddit:

There is a motion-to-photon min lag of 36ms with Maxwell cards. This is well above the minimum of 20ms advised by John Carmack for a non-puking VR experience. AMD seems to be obtaining around 11ms of motion-to-photon lag.

Related perhaps to DX12/VR?

 

[tential]

I sense some very unhappy maxwell owners. And some very very happy pascal owners!

Do you want to link or mention who said that?

 

[Silverforce11]

https://www.reddit.com/r/pcmasterra...aming_nvidia_gpus_do_not_support_dx12/cum3xow

AMD's Robert Hallock:

I think gamers are learning an important lesson: there's no such thing as "full support" for DX12 on the market today.

There have been many attempts to distract people from this truth through campaigns that deliberately conflate feature levels, individual untiered features and the definition of "support." This has been confusing, and caused so much unnecessary heartache and rumor-mongering.

Here is the unvarnished truth: Every graphics architecture has unique features, and no one architecture has them all. Some of those unique features are more powerful than others.

Yes, we're extremely pleased that people are finally beginning to see the game of chess we've been playing with the interrelationship of GCN, Mantle, DX12, Vulkan and LiquidVR.

Also for any doubters of the high-similarities of all the next-gen-API (Vulkan = Mantle 2.0), look at this from Tim Foley's (NV) presentation at SIGGRAPH 2015:

 

[DarkKnightDude]

I sense some very unhappy maxwell owners. And some very very happy pascal owners!

Do you want to link or mention who said that?

If you're talking to me, this was actually from a thread a week ago on VR with Maxwell.

https://www.reddit.com/r/nvidia/comments/3i6dks/maxwell_cant_do_vr_well_an_issue_of_latency/

 

[Azix]

Performance Optimizations
Batman™: Arkham Knight - Performance and quality/stability updates
Ashes of the Singularity - Performance optimizations for DirectX® 12

http://support.amd.com/en-us/kb-articles/Pages/latest-catalyst-windows-beta.aspx

new beta drivers for AMD. ANyone ran the benchmark on this yet?

 

[DarkKnightDude]

http://support.amd.com/en-us/kb-articles/Pages/latest-catalyst-windows-beta.aspx

new beta drivers for AMD. ANyone ran the benchmark on this yet?

I might give them a shot, haven't tried the benchmark yet though.

 

[Carfax83]

Apparently this was mentioned on the Nvidia subreddit:



Related perhaps to DX12/VR?

That's likely without using asynchronous warp.

 

[Carfax83]

AsyncCompute should be used with caution as it can cause more unpredicatble performance and requires more coding effort for synchronization.

Looks like Epic is warning developers about using AC haphazardly, as there are many pitfalls. Oxide should take note here.

If that Oxide dev didn't even know that Maxwell supported asynchronous compute, then what else doesn't he know?

This just goes to show that low level APIs are nothing to fool around with, and should only be used by very experienced graphics programmers..

 

[Silverforce11]

AsyncCompute should be used with caution as it can cause more unpredicatble performance and requires more coding effort for synchronization.

Looks like Epic is warning developers about using AC haphazardly, as there are many pitfalls. Oxide should take note here.

If that Oxide dev didn't even know that Maxwell supported asynchronous compute, then what else doesn't he know?

This just goes to show that low level APIs are nothing to fool around with, and should only be used by very experienced graphics programmers..

Do you realize Dan Baker was a chief engineer and designer of DX9/10 at MS for 6 years?

Then him and his fellow team were involved in making multiple game engines, the recent ones powering Civ 5 & Civ BE.

DX12 gives developers a lot of responsibility because they go to the hardware, fully exposed, close-to-the-metal. Console-like.

YES they should use it with caution, no doubts about it. People less talented with programming will use off-the-shelf engines like Unity, UE4, CryTek, Frostbite, etc.

A very good article for folks wanting some background:
http://thegametechnician.com/2015/08/31/analysis-amds-long-game-realization/

ps. Oxide didn't know about Async Compute in Maxwell, cos the driver was allowing them to expose it, "faking" its functionality. When they tried, it was a disaster so they disabled it at the request of NV.

 

[PPB]

Now oxide programmers arent experienced...... Yeah right.


That particular dev statement only shows that nvidia doesnt have async compute in the strict sense of the word, as they tried to implement AC under NV and went horribly. You can state anything on paper, but if on practice that feature is FUBAR, you can safely say it is not what was said. This is the case with AC on maxwell. It kinda is there, but you better not use it because the results are underwelming.

 

[selni]

AsyncCompute should be used with caution as it can cause more unpredicatble performance and requires more coding effort for synchronization.

Looks like Epic is warning developers about using AC haphazardly, as there are many pitfalls. Oxide should take note here.

If that Oxide dev didn't even know that Maxwell supported asynchronous compute, then what else doesn't he know?

This just goes to show that low level APIs are nothing to fool around with, and should only be used by very experienced graphics programmers..

Just reads like a standard "asynchronous code is hard" boilerplate warning imo rather than something specific to DX12 async compute.

 

[PhonakV30]

AsyncCompute should be used with caution as it can cause more unpredicatble performance and requires more coding effort for synchronization.

Looks like Epic is warning developers about using AC haphazardly, as there are many pitfalls. Oxide should take note here.

If that Oxide dev didn't even know that Maxwell supported asynchronous compute, then what else doesn't he know?

This just goes to show that low level APIs are nothing to fool around with, and should only be used by very experienced graphics programmers..

Someone replied to that.this quote was from Razor over beyond3d (https://forum.beyond3d.com/posts/1869185/)

D3D12 should be used with caution as it requires more coding effort.

DX12 code >>> AC code.

 

[Erenhardt]

AsyncCompute should be used with caution as it can cause more unpredicatble performance and requires more coding effort for synchronization.

Looks like Epic is warning developers about using AC haphazardly, as there are many pitfalls. Oxide should take note here.

This just goes to show that low level APIs are nothing to fool around with, and should only be used by very experienced graphics programmers..

Very unpredictable boost up to 30%. Mindblowing. Its like semi-generational leap in performance thanks to a single feature supported by all AMD GCN GPUs and APUs.

Epic's long experience at creating a pitfall of an engine is certainly something to have in mind. They are designing their next gen engine to not haphazardly use more than 4 CPU threads. Something like AC is way beyond their scope for sure as creating graphical effects is apparently too hard for them so they used closed source libraries from nv...

If that Oxide dev didn't even know that Maxwell supported asynchronous compute, then what else doesn't he know?

How long did that support last is the question! Just until first beta benchmark. NV dropped the support immediately after results were in, demanding to disable this feature as it is no longer supported.

 

[Carfax83]

Do you realize Dan Baker was a chief engineer and designer of DX9/10 at MS for 6 years?

Yes I know who Dan Baker is, which is why I am surprised that they managed to get such poor results with Maxwell's Asynchronous Compute function. It's as though they only optimized it for AMD, but not for NVidia..

YES they should use it with caution, no doubts about it. People less talented with programming will use off-the-shelf engines like Unity, UE4, CryTek, Frostbite, etc.

All of these engines will eventually support DX12.

ps. Oxide didn't know about Async Compute in Maxwell, cos the driver was allowing them to expose it, "faking" its functionality. When they tried, it was a disaster so they disabled it at the request of NV.

Right, it's faked.... Sorry but that's ridiculous

You hold beyond3d in high esteem right? Well you should know that the application that MDolenc created tests explicitly for Asynchronous Compute capability.

And guess what, it shows that Maxwell 2 does use Asynchronous Compute. Both Maxwell and GCN have asynchronous compute capability, but GCN obviously has a stronger implementation.

That doesn't necessarily mean it's better though. Maxwell 2 might not require dedicated asynchronous compute engines like GCN 1.2 does, as it does not have an underutilization problem..

Also the CUDA developer toolkit for Maxwell apparently mentions asynchronous compute as well.

 

[selni]

Very unpredictable boost up to 30%. Mindblowing. Its like semi-generational leap in performance thanks to a single feature supported by all AMD GCN GPUs and APUs.

Epic's long experience at creating a pitfall of an engine is certainly something to have in mind. They are designing their next gen engine to not haphazardly use more than 4 CPU threads. Something like AC is way beyond their scope for sure as creating graphical effects is apparently too hard for them so they used closed source libraries from nv...

That 30% number was quoted on an unspecified console though, and isn't the PS4 GPU configuration far far heavier on dedicated asynch compute engines than comparable PC GPUs?

Not to discount the increase, but given the hardware configuration it's perhaps not surprising (and not directly comparable to PC either)

 

[Carfax83]

That particular dev statement only shows that nvidia doesnt have async compute in the strict sense of the word, as they tried to implement AC under NV and went horribly. You can state anything on paper, but if on practice that feature is FUBAR, you can safely say it is not what was said. This is the case with AC on maxwell. It kinda is there, but you better not use it because the results are underwelming.

The test benchmark that MDolenc on beyond3d forums created tests explicitly for Asynchronous compute, and it shows that yes, Maxwell is indeed capable of it..

If Oxide optimized their game for AMD's AC implementation, then of course it's going to run horribly for NVidia hardware as NVidia has a different implementation. AMD has a much more robust implementation, but that's not an indication of superiority.

GCN might REQUIRE dedicated ACEs to achieve maximum throughput as it has a much bigger problem with underutilization, but Maxwell likely does not..

 

[Erenhardt]

That 30% number was quoted on an unspecified console though, and isn't the PS4 GPU configuration far far heavier on dedicated asynch compute engines than comparable PC GPUs?

Not to discount the increase, but given the hardware configuration it's perhaps not surprising (and not directly comparable to PC either)

PS4 is more or less GCN1.1 (similar to hd7790) and Xbone is like GCN1.0. The apis are different, exposing what dx11 can't do.

You hold beyond3d in high esteem right? Well you should know that the application that MDolenc created tests explicitly for Asynchronous Compute capability.

And guess what, it shows that Maxwell 2 does use Asynchronous Compute. Both Maxwell and GCN have asynchronous compute capability, but GCN obviously has a stronger implementation.

Don't mix simultaneous graphics and compute running in async pipelines with multiple compute queues running concurrently with rendering.

No async compute:

with async compute:

On the first graph (maxwell) you can see that it does run multiple compute tasks at once (31) but not simultaneously with graphics as it adds additional time.

In simple words, graphics task needs to stop for compute tasks (31) to be processed.

GCN does graphics in the and compute as the same time which is shown at the bottom graph.

Values can't be compared as it is unknown what and how it is executed.

 

[Carfax83]

That 30% number was quoted on an unspecified console though, and isn't the PS4 GPU configuration far far heavier on dedicated asynch compute engines than comparable PC GPUs?

Not to discount the increase, but given the hardware configuration it's perhaps not surprising (and not directly comparable to PC either)

Yes that's correct. 30% was for consoles, but the dedicated ACEs for the PS4 are the same as for comparable PC GPUs.. Does that mean that you can achieve a similar performance gain on the PC though, I'm not certain..

The PS4 uses HUMA, which should theoretically increase the gains for AC compared to the PC which uses NUMA.

 

[Carfax83]

On the first graph (maxwell) you can see that it does run multiple compute tasks at once (31) but not simultaneously with graphics as it adds additional time.

The overall time in MS is still lower for NVidia than it is for AMD, especially for the 31 queue depth and under workload.

 

[TheELF]

Do you realize Dan Baker was a chief engineer and designer of DX9/10 at MS for 6 years?

And this gives him access to secret nvidia insider info how?
(hardware plans for gpus)

If they wrote async especially for GCN (they are working with amd so why shouldn't they) and just run the exact same code for maxwell then of course it must be maxwell's fault if it runs slower right?
No way that you have to code differently for a different architecture right?

 

[Silverforce11]

The overall time in MS is still lower for NVidia than it is for AMD, especially for the 31 queue depth and under workload.

Preliminary data does not show Kepler/Maxwell capable of async compute.

The overall time is not a benchmark, yet. They are still working through and trying to understand what's going on.

https://forum.beyond3d.com/posts/1869207/

You can use it as a benchmark if you want. I would see what they have to say once they've gained more insights.

ie.
1ms (Graphics) + 1ms (Compute) = 2ms = NO async execution.
1ms + 0.5ms = 1ms = Async execution
1ms + 1ms = 1ms = Async execution

Once they reach a conclusion with more data, and the guys at b3d make a statement regarding async compute on GCN/Maxwell, then we can gather round and eat our words if we were wrong. Okay?

 

[ThatBuzzkiller]

Yes that's correct. 30% was for consoles, but the dedicated ACEs for the PS4 are the same as for comparable PC GPUs.. Does that mean that you can achieve a similar performance gain on the PC though, I'm not certain..

The PS4 uses HUMA, which should theoretically increase the gains for AC compared to the PC which uses NUMA.

FYI, Unified virtual memory =/= asynchronous compute ...

What you just spouted was rubbish ...

If anything the gains should be even bigger on PC with a GPU like Fiji since it has an even more skewed compute to graphics ratio than the consoles ...

Compared to the PS4, Fiji has only DOUBLED it's graphics capabilities like only having twice as many rasterizers, ROPs, and edge setup units. Compute on the other hand for Fiji has QUADRUPLED in comparison to the PS4 on it's shading power so it should make sense that Fiji should see bigger gains because "asychronous compute" is just a way to do a "FREE compute SHADER" when that's what AMD is advertising it as ...

Sure Fiji has 4 times as many samplers as the PS4 does but games today are COMPUTE bound and not graphics bound ...