Nvidia Pascal Reviews [1080XP, 1080ti, 1080, 1070ti, 1070, 1060, 1050, and 1030]

[Infinisearch]

And async needs to be tailored for different hardware, each hardware gen needs different paths.

How does that work...? In D3D12 you just create a compute queue and submit work to it to get the async part, so what do you mean by tailor?

 

[Razor1]

GCN (different versions of GCN) and Maxwell 2 and Pascal all have different utilization patterns. Async compute relies on under utilized ALU's, so if you don't code for different architectures, you are not going to get "best" benefits for Aynsc Compute on different architectures.

 

[Deleted member 13524]

I Don't even know why people get so worked up with Ashes. Its not a pretty game. In fact it's downright ugly and it's not popular either.

AOTS is an RTS that is capable of working with a number of combat units that we've never seen before, ever.
It was designed to deliver that, and that it delivered. It's a fact that the game didn't aspire to be the prettiest game ever (though Brad Wardell in the game's post-mortem admitted he wished he could've pressed for more funds to be spent on artwork).
However:

If you were ever a RTS fan and cringed at an artificially limited amount of playable units, this picture would leave you really happy.


And you can be damn sure it's a popular game.
It's definitely moving a lot more copies in the PC than any of the UWP-exclusive games that you and others have mentioned above.

 

[Infinisearch]

GCN (different versions of GCN) and Maxwell 2 and Pascal all have different utilization patterns. Async compute relies on under utilized ALU's, so if you don't code for different architectures, you are not going to get "best" benefits for Aynsc Compute on different architectures.

What I'm saying is the API doesn't expose any way to vary anything... either you're using async compute or you aren't.

 

[Razor1]

AOTS is an RTS that is capable of working with a number of combat units that we've never seen before, ever.
It was designed to deliver that, and that it delivered. It's a fact that the game didn't aspire to be the prettiest game ever (though Brad Wardell in the game's post-mortem admitted he wished he could've pressed for more funds to be spent on artwork).
However:

If you were ever a RTS fan and cringed at an artificially limited amount of playable units, this picture would leave you really happy.


And you can be damn sure it's a popular game.
It's definitely moving a lot more copies in the PC than any of the UWP-exclusive games that you and others have mentioned above.

I love RTS's and I have to say AOTS is not a great RTS, in my opinion they should have focused more on game play and story line than their engine technology. What I feel its a great DX12 tech demo for what their engine is capable of for future RTS's on their engine.

 

[Razor1]

What I'm saying is the API doesn't expose any way to vary anything... either you're using async compute or you aren't.

Oh yeah I didn't mean anything from an API perspective.

 

[MDolenc]

How does that work...? In D3D12 you just create a compute queue and submit work to it to get the async part, so what do you mean by tailor?

And if you do that you'll end up somewhere between say -75% and +100%. And if you're just doing that, you don't even need to create a compute queue.
On the other hand to take predictable advantage of this you'll need to put some fences that will ensure only intended draws are running with intended compute kernels (in a separate queue). But of course run time of these two parts won't be the same on different hardware due to different hardware configurations. Just compare 390X to Fury X for example. If you match graphics run time to compute run time on 390X it will go out of wack on Fury X by compute part finishing early due to virtually same graphics resources and quite a few more CUs.

 

[CarstenS]

AOTS is an RTS that is capable of working with a number of combat units that we've never seen before, ever.
It was designed to deliver that, and that it delivered.

I am wondering about that, actually. I know the developers tout that, but the benchmark itself does not show that many units. Medieval series had large armies, Empire Earth as well and even in Age of Empires you could set 200 Units per player in a 4-man Multiplayer and that was almost 20 years ago.

And you can be damn sure it's a popular game.
It's definitely moving a lot more copies in the PC than any of the UWP-exclusive games that you and others have mentioned above.

Can this be true? I know there's a gog.com-version as well...
http://steamspy.com/app/228880
https://steamdb.info/app/228880/graphs/

- oh and sorry for OT... :|

 

[Infinisearch]

And if you're just doing that, you don't even need to create a compute queue.

Are you sure about that, IIRC you need a compute queue to get the 'multi-engine' benefit? As far as fences and barriers go, you could use optional fences to ensure what runs at the same time but I'm having a hard time seeing an advantage in this.

 

[Infinisearch]

Oh yeah I didn't mean anything from an API perspective.

Then how would you code a custom path per hardware type?

 

[Razor1]

The API just gives access to the hardware features, but the programmer has to code for each hardware differently, like MDolenc stated.

 

[Infinisearch]

There's no way to do this in regards to async compute.

edit - besides fences and barriers but that really doesn't provide much control over execution.

 

[Grall]

Could the driver/GPU hardware not detect automatically when shader hardware starts going idle, and automatically supply with work from async queue?

 

[Razor1]

You don't have complete control, you have to estimate what is going on. Until there is a better way to do it in hardware (if that ever happens), this is the way it has to be done for now.

 

[DavidGraham]

AOTS is an RTS that is capable of working with a number of combat units that we've never seen before, ever.
It was designed to deliver that, and that it delivered. It's a fact that the game didn't aspire to be the prettiest game ever (though Brad Wardell in the game's post-mortem admitted he wished he could've pressed for more funds to be spent on artwork).
However:

If you were ever a RTS fan and cringed at an artificially limited amount of playable units, this picture would leave you really happy.


And you can be damn sure it's a popular game.
It's definitely moving a lot more copies in the PC than any of the UWP-exclusive games that you and others have mentioned above.

That is not true, Rise of Tomb Raider is vastly more popular than any other DX12 title. It sold more copies on PC than the Xbox. It is followed by Quantum break and Hitman. Ashes is far behind any of them.
http://www.dsogaming.com/news/rise-...er-on-pc-than-on-xbox-one-in-its-first-month/

 

[MDolenc]

Are you sure about that, IIRC you need a compute queue to get the 'multi-engine' benefit? As far as fences and barriers go, you could use optional fences to ensure what runs at the same time but I'm having a hard time seeing an advantage in this.

Yes, I'm pretty damn sure about this (and there are numbers to prove it in the D3D12 Async thread ).
People in general don't seem to have much sense just how bad running a memory access intensive draw calls and a memory access intensive compute kernel concurrently (thus trashing L1/L2 caches) really is. Though even a simple texture fillrate * 8 (for R8G8B8A8 read and write) to get bandwidth requirements should point out just how important this thing is.
A separate compute queue enables you to submit compute work to GPU and that compute work to will wait for some GPU event (graphics queue reaching a certain point) without CPU intervention.

 

[lanek]

AFAIK, Return of the Tomb Raider is the only game whose DX12 brought a performance deficit to both AMD and nvidia cards (but with AMD losing more performance, or it wouldn't be a gameworks title), while also losing support for Crossfire and bringing only VXAO which is never enabled in these large-scale comparisons.
The devs themselves admitted that the only optimization feature they could take out of the DX12 was better multi-core utilization, which is worthless because this was probably the most threaded and least cpu-dependant game of all time in its original DX11 version.


In all fairness, benching ROTR in DX12 mode is just ridiculous.

Let say they could provide both tests at least

 

[Deleted member 13524]

That is not true, Rise of Tomb Raider is vastly more popular than any other DX12 title.

ROTR isn't a UWP-exclusive game, and neither is Hitman. I can only wonder where you're getting the assumption that quantum break got more PC sales than AOTS, especially given its mediocre reviewer scores, terrible user scores and being sold in a platform that no one associates to high-profile games.

 

[DavidGraham]

ROTTR was a Dx11 game with Dx12 tacked on. Fable uses UE4 which is also primarily a Dx11 engine with Dx12 added on, AFAIK. GeOW uses UE4 also doesn't it? AOTR and Hitman were designed with Dx12 from the ground up

Hardly, all engines on the market were DX11, they added DX12 paths later on. ashes engine was also DX11 but had Mantle pathway which were later modified to involve DX12.

 

[DavidGraham]

ROTR isn't a UWP-exclusive game, and neither is Hitman. I can only wonder where you're getting the assumption that quantum break got more PC sales than AOTS, especially given its mediocre reviewer scores, terrible user scores and being sold in a platform that no one associates to high-profile games.

Mediocre maybe, but it was the most successful new IP for Microsoft, it topped sales charts for a while.

And you just can't claim Ashes is popular, nobody even hears of the game except in benchmark suits. It has little media coverage.

You also can't claim it has the highest number of units on screen. Many other RTS games used large number of units, Medival, Total Wars, Supreme Commander, Planetary Annihilation, even Command and Conquer could feature such massive numbers in large matches. So I dont know what makes Ashes so special. It's the same situation as StarSwarm or whatever, a showcase for something that is neither specific or extraordinary.