computerbaseAshes of the Singularity Beta1 DirectX 12 Benchmarks

Page 14 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

.vodka

Golden Member
Dec 5, 2014
1,203
1,537
136
Well, it remains to be seen how nV's path on the upcoming DX12 games behaves vs AMD's. This is embarrassing for them.


What a disaster for nV, supposing Pascal fixes their actual DX12 shortcomings that's still a HUGE installed hardware base that's gimped in the new paradigm should devs decide to use certain features... This is gonna be fun... I mean, it already is.
 

airfathaaaaa

Senior member
Feb 12, 2016
692
12
81
Well, it remains to be seen how nV's path on the upcoming DX12 games behaves vs AMD's. This is embarrassing for them.


What a disaster for nV, supposing Pascal fixes their actual DX12 shortcomings that's still a HUGE installed hardware base that's gimped in the new paradigm should devs decide to use certain features... This is gonna be fun... I mean, it already is.
the problem is that its not a disaster they knew about it since forever

http://blogs.nvidia.com/blog/2014/03/20/directx-12/

(4 years working with microsoft as of 2014) they decided to milk the cow as long as they could and just DOA maxwell1.0 and 2.0 a year after pascal arrived

what i think happened is that either ms pushed hard for dx12 or ms and amd pushed hard for the adoptation of dx12 as quickly as possible
 

Mahigan

Senior member
Aug 22, 2015
573
0
0
Well Pascal is what Maxwell v2 20nm was supposed to be. When 20nm didn't pan out, nvidia took some of the things in Pascal and launched them as Maxwell V2. Pascal will add the remaining components namely, fp16 at twice the rate of fp32, Unified Memory (NVLink) and then go one step further an include the HBM2 memory which was supposed to debut with Volta.

See here:
b85ed522714a9b5c12c7aa0511618237.jpg
Roadmap pre-Pascal (pre TSMC 20nm boondoggle).

Notice no "Pascal"? That's because it was created once 20nm didn't pan out for TSMC.

See here:
171a979933b3ba65e92196fa7d3c344e.jpg
Roadmap post-Pascal (post TSMC 20nm boondoggle).

Pascal is not a new architecture, it is what was missing from Maxwell V2. NVLink and fp16 mean basically nothing to gamers. There are no fp32 CUDA core enhancements per clock either (those made their debut with Maxwell V2).

Pascal is thus very much oriented towards the Datacentre market. Aside from the die shrink allowing more CUDA cores, beefier front end and HBM2... It's the same architecture just a beefier version of Maxwell V2 where gamers are concerned.

Have a look:
9b5e9321f0fb351bb2ff3a4fb3360b02.jpg
The only thing worthy of a gamers attention is the 3D Memory (HBM2).

So what could nvidia have added to Pascal that they didn't?

Asynchronous compute engines? Hardware based scheduling? Increase fp32 performance per CUDA core? Finer-grained pre emption? Etc etc but Volta will bring some of those.

On the AMD front,

fa6711bd724c4f58d028d6f13e96e142.jpg

Polaris is bringing brand new geometry processing units, new memory controller, new Command Processor, new CUs and thus improved FP32 performance per clock, improved caching, dedicated 4k media processor and a re-organized front end.

So Pascal doesn't appear to be bringing enough features to gamers. I mean Fiji was nipping at the GTX 980 Tis heals. With a new command processor, DX11 CPU overhead is fixed on Polaris. Improved geometry processors means that nvidia's tessellation strength is gone. Improved CUs means that AMDs Polaris can now tackle a wider array of shaders with improved performance per clock thus limiting the impact of nvidia optimized shaders. Improved performance per watt negates nvidia's strength in that dept. AMD hired Scott Wasson in order to improve their frame pacing. Multimedia cores for Shadowplay-like accelerated 4K video capture. HDR feature for improved color reproduction (new Display Engine).

AMD is going for the jugular with Polaris. Nvidia is sitting on their laurels with Pascal in the gaming dept.

So no worries about your Maxwell V2 going obsolete. It won't. But one thing is for sure, don't be surprised if Polaris out performs Pascal.
 
Last edited:

Glo.

Diamond Member
Apr 25, 2015
5,930
4,991
136
Mahigan, do you think that performance of GCN4 GPUs will reflect performance from Maxwell GPUs?

So like 2048 GCN4 core GPU would reflect 2048 CUDA core Maxwell GPU?
 

Mahigan

Senior member
Aug 22, 2015
573
0
0
For compute and assuming the same clock speeds, GCN4 should be faster all around, per clk and per core, than previous GCN iterations. Meaning that in compute instances where GCN1,2,3 had a lead over Maxwell, that lead will increase and in instances where GCN1,2,3 were slower than Maxwell, that deficit will be reduced significantly.

Couple that with the ability of masking through parallelism (such as what one can do with Async compute) and we have an architecture, in GCN4, which will not only compete with Maxwell in terms of compute performance per SIMD but add increased utilization to the mix by way of the ACEs (exposed in OpenCL code as well).

Compute wise, Polaris will only further solidify AMDs lead in that dept. Something tells me that the Polaris based firepro's will have some nice DP performance too.

The one area I see nvidia retaining a hardware lead is in half precision scenarios. Polaris will like process fp16 at the same rate as fp32 whereas Pascal will process fp16 at twice the rate of fp32.

Software wise, nvidia holds a commanding lead with CUDA over AMDs reliance on OpenCL.

Of course compute continues to play second fiddle to Graphics. The static Graphics pipeline is an area where I think nvidia will continue to lead in terms of pixel fillrate.
 
Last edited:

sontin

Diamond Member
Sep 12, 2011
3,273
149
106
Well Pascal is what Maxwell v2 20nm was supposed to be. When 20nm didn't pan out, nvidia took some of the things in Pascal and launched them as Maxwell V2.

Nonsense. nVidia never had the intention to use 20nm for their GPUs.

Notice no "Pascal"? That's because it was created once 20nm didn't pan out for TSMC.
So and Volta was the 20nm chip or what? o_O

Pascal is not a new architecture, it is what was missing from Maxwell V2. NVLink and fp16 mean basically nothing to gamers. There are no fp32 CUDA core enhancements per clock either (those made their debut with Maxwell V2).
Nothing of it was announced for Maxwell. You even posted the roadmaps which show that HBM, nVLink and other features will be introduced with the 2016 architecture. :\

Pascal is thus very much oriented towards the Datacentre market. Aside from the die shrink allowing more CUDA cores, beefier front end and HBM2... It's the same architecture just a beefier version of Maxwell V2 where gamers are concerned.
"Gamers are concerned"? Wow. AMD cards dont even support FL12_1 and yet nVidia users are concerned. :D

So what could nvidia have added to Pascal that they didn't?
You have no clue what nVidia will improve or introduce. And yet you are making all the assumptions from nothing.

So no worries about your Maxwell V2 going obsolete. It won't. But one thing is for sure, don't be surprised if Polaris out performs Pascal.
Fiji was supposed to be much better than GM200 and yet it gets beaten all over the place. Your postings dont make any sense. You sound like a guy from the marketing department of AMD. nVidia never said one word about Maxwell. The introduction was a huge surprise because nobody ever thought of the possiblity of such a huge improvement on the same node.

Maybe you should stop writing about things you dont know instead of hyping AMD like there will be no tomorrow.
 
Last edited:

Leadbox

Senior member
Oct 25, 2010
744
63
91
"Gamers are concerned"? Wow. AMD cards dont even support FL12_1 and yet nVidia users are concerned. :D
Given the ASCompute debacle, I think we should view any talk or claim of supporting any dx12_1 features coming from a certain IHV with a lot of skepticism.
 

ShintaiDK

Lifer
Apr 22, 2012
20,378
145
106
Given the ASCompute debacle, I think we should view any talk or claim of supporting any dx12_1 features coming from a certain IHV with a lot of skepticism.

MS confirmed it. Full FL12.1 support, then you can try make up as much FUD as possible in defence of AMD.
fl121.png
 
Last edited:

3DVagabond

Lifer
Aug 10, 2009
11,951
204
106
Given the ASCompute debacle, I think we should view any talk or claim of supporting any dx12_1 features coming from a certain IHV with a lot of skepticism.

12_1 is not an API it's a feature set. It's just a few features that are not included in the original spec for DX12.
 

Leadbox

Senior member
Oct 25, 2010
744
63
91
MS confirmed it. Full FL12.1 support, then you can try make up as much FUD as possible in defence of AMD.
fl121.png

One could hack in software support for a feature, like async compute for example, but when you go to use it, the hardware will fall flat on it's face. AMD could probably do the same with _1 part of dx12 it wont be very useful when one goes to use it. You can query the hardware and it will return yes to supporting something this way, but it wont be very useful (read async compute on nvidia hardwares)
 

Leadbox

Senior member
Oct 25, 2010
744
63
91
12_1 is not an API it's a feature set. It's just a few features that are not included in the original spec for DX12.

I always felt they were added to make nvidia look like they contributed to the spec, but that's just me.
 

ShintaiDK

Lifer
Apr 22, 2012
20,378
145
106
One could hack in software support for a feature, like async compute for example, but when you go to use it, the hardware will fall flat on it's face. AMD could probably do the same with _1 part of dx12 it wont be very useful when one goes to use it. You can query the hardware and it will return yes to supporting something this way, but it wont be very useful (read async compute on nvidia hardwares)

You are looking for an excuse to continue your FUD.
 
Feb 19, 2009
10,457
10
76
I don't think we should concern ourselves with what Pascal has or not because we lack information to even go there. It's a pure guess and it's pointless.

We can play an interesting hypothetical analysis, not about the hardware, but the outcomes.

1. Pascal supports hardware parallel engines capable of processing Asynchronous Compute/Shaders. It may even be excellent at it (similar to when NV jumped onboard with Tessellation).

2. Pascal is an ehanced Maxwell 2 with mix-mode throughput added and wider setups for more DP compute. It lacks hardware parallel engines capable of AC/AS.

What would be the outcome for games in 2016 - 2018 for #1 and #2?

That's the interesting discussion point, IMO. Rather than making claims for Pascal hardware itself due to lack of info.

Edit: Here's my analysis. It won't matter to NV whatsoever, they will still rule the marketshare and AMD will still struggle. Why do I think this? Pretty simple.

#1 NV sponsored games will push more compute effects, running them in parallel enables zero performance loss for hardware that can handle many queues in parallel. GCN is fixed at 8x ACEs and may be bottlenecked. As a BONUS, performance of Kepler/Maxwell in these new DX12 games will be majorly gimped, promoting a mass upgrade from NV GPU owners to next-gen Pascal. NV profits go to the moon!

#2 NV sponsored games will push DX11 for the PC port, or if its DX12, disable AC/AS feature. GCN does not benefit greatly and Pascal pulls ahead easily.

It's actually a win-win scenario for NV. The only scenario where AMD gets better is if Polaris knocks it out of the park and literally stomps on Pascal, very unlikely to happen. Anyone disagree with that? ;)
 
Last edited:

Tapoer

Member
May 10, 2015
64
3
36
Yes, obvious that Maxwellv2 got full FL12.1 support :)

Is it obvious?
One thing is what drivers say it supports (can be emulation), other thing is what hardware supports.

Maxwellv2 should also support AC, the drivers said it, the major tech sites said it, but when software came to use it, Maxwellv2 didn't deliver.

I know (and everyone) that you are very optimistic when it comes to Nvidia, but it's better to wait for software to use FL12.1 before jumping to conclusions.
 
Feb 19, 2009
10,457
10
76
The big question is how bad or good these ports will be. Its not looking rosy on that front yet. And with DX12 the question about how will new uarchs be supported is also one of the dark horses. It could be GCN 1.0/1.1 vs GCN 1.2 with Mantle in BF4 all over again. Or even worse. The running on weaker CPUs dream is already shattered to pieces.

Mantle was a proof of concept. Once it was shown to work, they moved to get it into Metal, Vulkan and DX12. There's no need to keep working on Mantle, waste of $$.

Also, weaker CPUs on consoles, it isn't as if their GPUs are capable of 60 fps at 1080p in good looking games to bottleneck the CPU. A bunch of weak cores can push 30 fps and even that the Xbone's GPU struggle and has to down-res to 720/900p just to get acceptable FPS.

Really, take a conroe quad core, like Q6600, in almost every game its capable of pushing FPS that would bottleneck weak GPUs of 7850 class. GPU bound.

Edit: Incase the point was loss, DX12's multi-thread rendering if used right, boosts many-core CPUs on consoles. Really well threaded games in DX12 will benefit PC as well. There's a win-win scenario for DX12 programming for Xbone to PC because techniques to extract peak performance from weaker hardware benefits stronger hardware too!
 
Last edited:

ShintaiDK

Lifer
Apr 22, 2012
20,378
145
106
Mantle was a proof of concept. Once it was shown to work, they moved to get it into Metal, Vulkan and DX12. There's no need to keep working on Mantle, waste of $$.

Also, weaker CPUs on consoles, it isn't as if their GPUs are capable of 60 fps at 1080p in good looking games to bottleneck the CPU. A bunch of weak cores can push 30 fps and even that the Xbone's GPU struggle and has to down-res to 720/900p just to get acceptable FPS.

Really, take a conroe quad core, like Q6600, in almost every game its capable of pushing FPS that would bottleneck weak GPUs of 7850 class. GPU bound.

Quantum Break is 1080p. The first DX12 on Xbox One.
 
Feb 19, 2009
10,457
10
76
Because people are talking here that nVidia doesnt support Async Compute. It is necessary to point out that Async Shaders is not Async Compute. Exactly the same with DX12 API and DX12 feature levels.

I think it's a common cross-reference. Even developers use both to describe the same thing.

The idea is to run compute while graphics is running, not after graphics is done, etc.