Ashes of the Singularity User Benchmarks Thread

[tential]

Hmmm,do they even need support?
I mean as long as you have head tracking on your goggles and can bind this to your mouse which is used for free looking anyway I don't see any reason why it shouldn't work.
In sim games you are sitting in a seat anyway and there is no movement except for the vehicle.

I really don't know, so I asked haha.

I mean that's wild I dunno if I could handle vr racing or flying in space.....

Thank God mmos didn't have vr as a kid lol. I'd have never left.

I'll be more excited for vr come 2016-2017 right now it's a little out of my price range for the kit given the other pc gaming things I still need.

 

[.vodka]

Games are bound to start using more compute power right? I think it is too soon to call GCN a mistake

GCN still keeps pulling rabbits out of its hat, even after all this time, throughout its three revisions so far. The last word you could use to qualify GCN is "mistake".

Not flawless (Tesselation, DX11 performance vs nV's) by any means, but definitely solid. It hasn't shown cracks as bad as Kepler's (and seemingly Maxwell's) so far after the test of time/evolving software.


nV's silence on the matter is interesting. They're a very noisy company, and had for example a response to the 970's 3.5+0.5GB fiasco in little time. This other issue, however...

It's certainly fun to watch, there's still lots of popcorn to prepare for the rest of it.

 

[3DVagabond]

No, because it is a strategy game with an insane amount of units,the only way to get the most out of the parallelism of the amd cards is to use insane amounts of units so that all the ACEs get used.
The only type of game where you can do this is in strategy games like here where you have a lot of small units that follow larger units up to the units the player actually controls.

The only other way would be to raise polygon count by making more detailed models of everything and no dev is gonna go, hey lets make development cost sky rocket by doing much much more work so that the 1% of market share that has killer rigs can be happy about something.

Baker states that AotS isn't a poster child for a sync compute. Consoles are making much more use of it. So,no it's not because it has some unreasonable amount of units pushing a sync compute beyond real world levels. There isn't even any reason for us to think one has anything to do with the other. A sync compute doesn't even have to be used in that metric at all. It could be used for For lots of different tasks.

 

[Silverforce11]

And Sebbi confirms it:

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

Test is useless on GCN as a performance metric. Test is as the other guys say, a test for functional Async (parallel execution) or not.

Jawed said: ↑
Apart from that I can't help wondering if the [numthreads(1, 1, 1)] attribute of the kernel is making AMD do something additionally strange.

If the compiler is good, it could either skip the vector units completely by emitting pure scalar unit code (saving power) or emitting both scalar + vector in an interleaved "dual issue" way (the CU can issue both at the same cycle, doubling the throughput).

Benchmarking thread groups that are under 256 threads on GCN is not going to lead into any meaningful results, as you would (almost) never use smaller thread groups in real (optimized) applications. I would suspect a performance bug if a kernel thread count doesn't belong to {256, 384, 512}. Single lane thread groups result in less than 1% of meaningful work on GCN. Why would you run code like this on a GPU (instead of using the CPU)? Not a good test case at all. No GPU is optimized for this case.

Also I question the need to run test cases with tens of (or hundreds of) compute queues. Biggest gains can be had with one or two additional queues (running work that hits different bottlenecks each). More queues will just cause problems (cache trashing, etc).

Like said earlier, there's no way 50ms latency for performing a simple compute task is real. No game that uses compute would exceed 20 fps if its true. There's no way that AMD can get VR latency down to 11ms as they claim & demoed.

And to top it off, it's not even stressing Fury X like its stressing Maxwell 2 cards:
https://forum.beyond3d.com/posts/1869703/

And another user with Maxwell 2 confirms the prior results, this test when in Async Mode (the latter portion of the test) for NV GPUs stresses the CPU in alternate cycles with GPU usage dropping. The driver is intercepting the async call and sending the compute task for the CPU to do.

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

If this test is a correct tool to identify functional Async Compute, then it means Maxwell does "support" Async Compute, since the spec does not define the method to support parallel execution. NV's approach is software emulation, using the CPU to do the lifting. Which is fine and good until there's a lot of Compute and CPU usage bombs. Exactly as Oxide have said regarding issues with high CPU usage on Maxwell when its driver is emulating.

 

[dzoni2k2]

And Sebbi confirms it:

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

Test is useless on GCN as a performance metric. Test is as the other guys say, a test for functional Async (parallel execution) or not or not.






Like said earlier, there's no way 50ms latency for performing a simple compute task is real. No game that uses compute would exceed 20 fps if its true. There's no way that AMD can get VR latency down to 11ms as they claim & demoed.

And to top it off, it's not even stressing Fury X like its stressing Maxwell 2 cards:
https://forum.beyond3d.com/posts/1869703/

And another user with Maxwell 2 confirms the prior results, this test when in Async Mode (the latter portion of the test) for NV GPUs stresses the CPU in alternate cycles with GPU usage dropping. The driver is intercepting the async call and sending the compute task for the CPU to do.

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

If this test is a correct tool to identify functional Async Compute, then it means Maxwell does "support" Async Compute, since the spec does not define the method to support parallel execution. NV's approach is software emulation, using the CPU to do the lifting. Which is fine and good until there's a lot of Compute and CPU usage bombs. Exactly as Oxide have said regarding issues with high CPU usage on Maxwell when its driver is emulating.

Fact that Maxwell 2 can't do async compute might not be a huge deal even though we may see 290X competing even with 980Ti in games with heavy async compute use.

A much bigger problem is if Pascal can't do it either. If it can't Nvidia lost the DX12 round.

 

[.vodka]

It's hard to think that nV hasn't designed Pascal with AC in mind. GCN (and all its public documentation) in the PS4/XB1 and Mantle as an API should have given them the heads up years ago, back in the design phase. We forum goers see this, their engineers more than likely did, much earlier too.

If not, well, it's going to be bad for the green team and their actual 80% dGPU marketshare (at least for the Maxwell part of it, the rest will have to upgrade). Just read how thrilled game devs are at what this feature enables. I don't think they'll let another GF FX debacle happen. But then, s**t happens from time to time, and they've been caught with their pants down twice with Maxwell so far (evidence points to such a conclusion on this particular time, the fact they don't come out to make things clear doesn't help either. This could change once they do.). No, three times with Kepler's performance dropping off a cliff lately / GCN doing some spectacular catch up work to compete with Maxwell and its DX11 prowess.

There's also the gameworks wildcard in the middle, we've seen the detrimental effect it has on games that make extensive use of its libraries for anything other that isn't nV's latest and greatest.


Interesting times ahead with lots of DX12 games in the horizon that have been said by their devs to make use of AC (DX, TR, etc). If I owned a nV card, I'd start to worry if the AotS situation repeats in those under DX12 mode. DX11 performance will probably be fine, though, yet I don't know if what's enabled by AC in these games will be available under DX11. Real, built from the ground up for DX12 games that leave DX11 out for good (post PS4/XB1/GCN?) will probably require Pascal or Arctic Islands GPUs (let's hope these do all the DX12 features left out by either camp right now, AC/ROV/CR), but the first wave will be handled by today's hardware. We'll see.

 

[3DVagabond]

I wonder if after Kepler's performance decline in current games, and then if Maxwell does the same, will the nVidia faithful be upset enough to not just buy into another round of forced obsolescence?

 

[DarkKnightDude]

Has Nvidia said anything about this async compute thing yet? If they are staying quiet, that itself might be very telling.

 

[antihelten]

Fact that Maxwell 2 can't do async compute might not be a huge deal even though we may see 290X competing even with 980Ti in games with heavy async compute use.

A much bigger problem is if Pascal can't do it either. If it can't Nvidia lost the DX12 round.

This isn't entirely true, as the DX12 round will almost certainly extend beyond Pascal.

DX10 had a 2 years and 9 months lifetime (vista to W7)
DX11 (and it's updates) had a 5 years and 9 months (W7 to W10)

As such I would expect DX12 to have a lifetime of at least 3-4 years, if not longer. Add to this that the release of compatible games tend to lag after the release of a new DX version, and we probably won't see games moving to any potential new DX version within at least the next 5 years. Pascal will be obsolete much sooner than that.

Of course if Nvidia doesn't fix async compute in Pascal, it would still be a potentially fairly huge issue for them.

 

[Silverforce11]

It's hard to think that nV hasn't designed Pascal with AC in mind. GCN (and all its public documentation) in the PS4/XB1 and Mantle as an API should have given them the heads up years ago, back in the design phase. We forum goers see this, their engineers more than likely did, much earlier too.

Yes I do agree with this sentiment. NV would have known for certain what was in consoles, what's in Mantle etc years ago.

The question here is did they know ahead of time, years ago, that DX12 would be so similar to Mantle? If they knew, Pascal will be great at Async Compute.

 

[3DVagabond]

Yes I do agree with this sentiment. NV would have known for certain what was in consoles, what's in Mantle etc years ago.

The question here is did they know ahead of time, years ago, that DX12 would be so similar to Mantle? If they knew, Pascal will be great at Async Compute.

I'm of he belief that they didn't know anything about DX12 years ago. YMMV.

With that said, I did read somewhere (s/a IIRC) that Pascal will do async compute.

 

[TheELF]

Of course if Nvidia doesn't fix async compute in Pascal, it would still be a potentially fairly huge issue for them.

There is nothing to be fixed, you can get all of the nvidia card's power with only one stream(you can see this with the dx11 results) so of course you get no additional speed out of async compute and it might even slow things down because issuing a lot more commands then necessary is always a bad idea.

The only thing nvidia can do is add additional and otherwise absolutely useless compute units that would just sit there doing nothing except for using up power for the sole purpose of getting better numbers in async compute benchmarks.

 

[antihelten]

There is nothing to be fixed, you can get all of the nvidia card's power with only one stream(you can see this with the dx11 results) so of course you get no additional speed out of async compute and it might even slow things down because issuing a lot more commands then necessary is always a bad idea.

The only thing nvidia can do is add additional and otherwise absolutely useless compute units that would just sit there doing nothing except for using up power for the sole purpose of getting better numbers in async compute benchmarks.

You really ought to stop digging.

 

[Hitman928]

In order to better show results that represent the test and avoid confusion, I reworked my plots to better represent the test results. Basically, the closer the orange line is to the blue line, the worse the results (for asynchronous compute), the closer it is to the yellow line, the better the results. Sometimes there are results below the yellow line, this shouldn't be happening and is probably an artifact of how the time samples are being taken or something. I think this also shows that the test still isn't perfect by any means, but should be able to show behavior when trying to enable asynchronous compute on a card.

 

[PhonakV30]

AMD demoed 11ms VR in E3 and yet some of users believe 50ms!!! Overall AMD LiquidVR is far better than Nvidia GameworkVR ( I refer to this:
http://forums.anandtech.com/showpost.php?p=37649545&postcount=231
http://forums.anandtech.com/showpost.php?p=37649572&postcount=242
and best of all :

http://forums.anandtech.com/showpost.php?p=37649656&postcount=246 )

Robert Hallock :

We've been talking to developers about ≤10ms VR latency in LiquidVR for quite a while. If there was an inherent 50ms latency, then you'd never get to 60 FPS (16ms).


they say Maxwell is faster that proved by beyond3d's Test but they can't answer to this question that :

why Kepler/Maxwell struggles with VR?
(From Silverforce11 : http://forums.anandtech.com/showpost.php?p=37649660&postcount=247)

I am sick of those denial.If maxwell has AC , sure it has but not like in DX12.We talk about Parallel Workload.
Asynchronous Compute in DX12 = execute a graphics and compute queue in parallel workload
If you don't believe then What exactly is AC in Dx12?

 

[Silverforce11]

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

Sebbbi:

This benchmark is valid for testing async compute latency. This is important for some GPGPU applications.

It is important to notice that this benchmark doesn't even try to measure async compute performance (GPU throughput). This is the most important thing for improved graphics rendering performance in games. As this thread is called "DX12 performance thread", I just wanted to point this out.

People ignore what the creator of the program made it for as well as other programmer's input and they jump to conclusion, seeing lower graphs = NV better!!!!! When in fact its broken.

 

[Pottuvoi]

This isn't entirely true, as the DX12 round will almost certainly extend beyond Pascal.

DX10 had a 2 years and 9 months lifetime (vista to W7)
DX11 (and it's updates) had a 5 years and 9 months (W7 to W10)

As such I would expect DX12 to have a lifetime of at least 3-4 years, if not longer. Add to this that the release of compatible games tend to lag after the release of a new DX version, and we probably won't see games moving to any potential new DX version within at least the next 5 years. Pascal will be obsolete much sooner than that.

Of course if Nvidia doesn't fix async compute in Pascal, it would still be a potentially fairly huge issue for them.

Considering that we still haven't got drivers which expose all DX11.3 features, It's quite early to say it's lifetime has passed.

Also there will be place for DX11 for a long time due to the requirements needed from programmers for DX12. (Same goes to OpenGL and Vulkan.)

 

[antihelten]

Considering that we still haven't got drivers which expose all DX11.3 features, It's quite early to say it's lifetime has passed.

Also there will be place for DX11 for a long time due to the requirements needed from programmers for DX12. (Same goes to OpenGL and Vulkan.)

True, although I was mainly thinking of the pre-W10 versions of DX11. But as you said even those versions will be around for quite some time to come.

 

[railven]

I wonder if after Kepler's performance decline in current games, and then if Maxwell does the same, will the nVidia faithful be upset enough to not just buy into another round of forced obsolescence?

Kidding me? AMD could only be so lucky. Years arguing with NV users, they won't change even if NV kills their dog.

The neutrals could be swayed over, but AMD has to really sell the product (I now consider myself neutral, no more blindly buying AMD's top card, yes - I dropped my open Radeon bias.)

I'm seeing people turn away from Radeon products solely just on AMD's marketing image. That is something they really need to address. Performance numbers mean jack if everyone things you're not worth the money (especially now with AMD not chasing perf / cost like they use to).

 

[Silverforce11]

Kidding me? AMD could only be so lucky. Years arguing with NV users, they won't change even if NV kills their dog.

ot, but I still laugh when I recall seeing this guy on [H] forum say "I'll never switch to AMD, not even if NV rapes my wife and burn down my house!"... so I understand that sentiment.

It's true AMD needs to market better, but there is going to be backlash from their fans who value bang for buck.

Fury X/Nano is the perfect example. Performance not there for the $650. If they wanted to charge the same as the faster 980Ti, they should have marketed how awesome DX12 is and how they paved the road for all the next-gen APIs. Basically they can sell their tech as more "future-proof" and the masses will eat that up. But no, they did no such thing, they hype up water cooling and now with Nano, form factor. Meh, form factor doesn't deserve such a ridiculous premium. I don't buy it.

 

[pejx]

Indeed. "Future proof" has me sold. This forum discussion has led me to sell my 2x980 SLI on EBay and order a Fury X (currently a 4 week waiting time on Amazon.de)

 

[Gikaseixas]

Indeed. "Future proof" has me sold. This forum discussion has led me to sell my 2x980 SLI on EBay and order a Fury X (currently a 4 week waiting time on Amazon.de)

This is funny
I went with 980ti because of the wait. If Fury X was available I would have gone AMD again but 980ti is an excellent alternative and I needed to enjoy my gaming now.

The neutrals could be swayed over, but AMD has to really sell the product

That's the problem, they don't have units to sell so they lose business to NV. I'm a prime example of that

 

[Dribble]

WCCFTech has actually done some fairly sensible analysis of this for once: http://wccftech.com/async-shaders-give-amd-big-advantage-dx12-performance-oxide-games/

They conclude for people with a decent cpu the benefits of DX12 will be pretty small, which tbh is what most techies are expecting (other then fanboys looking for something else to argue about). It's not like DX10 or DX11 proved magically much faster then DX9 in the end, and I assure you there were just as many posts back in the day claiming DX10 in particular would do amazing things.

 

[Hitman928]

Another result from a 980 Ti which doesn't show the weird cpu spike behavior like the one before.

It's also much more consistent with other Maxwell cards.

Something weird going on with the first 980 Ti results from before, but these are pretty consistent with all the other Maxwell results being posted @ beyond3d.

 

[Hitman928]

WCCFTech has actually done some fairly sensible analysis of this for once: http://wccftech.com/async-shaders-give-amd-big-advantage-dx12-performance-oxide-games/

They conclude for people with a decent cpu the benefits of DX12 will be pretty small, which tbh is what most techies are expecting (other then fanboys looking for something else to argue about). It's not like DX10 or DX11 proved magically much faster then DX9 in the end, and I assure you there were just as many posts back in the day claiming DX10 in particular would do amazing things.

WCCFtech once again shows they don't know what they're talking about. . .

other publications, registered a performance loss with Nvidia hardware running the DX12 version of the benchmark compared to DX11. We learned later-on that this was down to a hardware feature called Asynchronous Shaders/Compute.

Asynch compute was disabled for Nvidia in the game, so how could it cause the performance degradation? They should know this, they have all the quotes in previous articles.