Nvidia Ampere Discussion [2020-05-14]

OpenCL on NV h/w has never been very good so still - we need more data.

 

Aren't now AMD ALUs more complete than Nvidias technically?. All can make int ops, meanwhile now only half of them in Ampere.

 

I think the problem on turing was a lot of the int32 alu sat idle. I believe the CUs in AMD would be the same where they have dedicated fp and int units, no?

 

I think we kind of expected this type of utilization though, because they doubled fp32 alu without doubling anything else. I would not expect this to improve to 90% or anything like that.

 

what do you mean? Sorry, I don't understand.... Do you mean that if a cuda core is going to perform both int32 and fp32 ops at the same time, the resources of that cuda core are halved? Or that it isn't as efficient?

afaik, native integer cores appeared for the first time ever in Turing, that's why only Turing graphics card and the newer ones allow for the famous Integer Scaling.

 

Yes, same as Pascal. I think the prevailing assumption is that those combined FP and INT pipelines share transistors to some extent so one pipeline isn’t completely idle. No idea if that’s true though.

Nvidia clearly thought it made sense to split the FP and INT functionality into separate pipelines for whatever reason.

 

FP32+FP32+INT32 is physically bigger than FP32+[FP32|INT32], it needs another real datapath inside the SM and the three units could not be scheduled at the same time with the current scheduler. Remember, the FP32-INT32 SIMD is not physically separated but combined in one SIMD.

 

I was wrong. It can be any number of INT instructions in multiples of 16 if i understood the replies correctly. So 112+16, 80+48 etc. The Computerbase article had me thinking it was either 128FP or 64FP + 64INT with no other combinations.

 

It helps alot in ray tracing, even in software ray tracing, this is the reason GTX Turing performs better than Pascal in ray tracing despite having fewer resources, and this is also the reason Turing surpasses both RDNA 1 and Pascal in software ray tracing (such as CryEngine and World of Tanks).

 

This might be cost optimisation: the fixed overheads of an SM partition such as the instruction decoder can be scaled up for relatively little cost while getting a large increase in theoretical throughput. Presumably the fixed overheads grew due to the addition of tensor cores, so then the step to make these two instructions co-issue in Turing seems low cost (well, then there's the compiler). The addition of tensor cores forced them to add overhead and so normal shader instruction processing saw a big change?

 

https://www.techpowerup.com/271907/corsair-working-on-direct-12-pin-nvidia-ampere-power-cable

 

That's a reasonable take. End result seems quite unbalanced though.

 

Quick question: What would happen, if there were more schedulers for feeding more of [FP32|FP32+INT32|TC|L/S|SFU] per clock (i.e. 3 schedulers/dispatch) with the occasional [RT|TMU] thrown in the mix?
Right, Powaaahhhh!

 

Fermi will happen.

 

There probably wouldn't be any real benefit. The TMU, SFU + L/S pipelines execute over many clocks.

 

I don't understand what's so unbalanced then?

 

Flops vs everything else (bandwidth, geometry, RT)

 

Kepler: hold my underfed 192 FMA lanes...

 

Here we go again ...

Ethereum Miners Eye NVIDIA’s RTX 30 Series GPU as RTX 3080 Offers 3-4x Better Performance in Eth

https://www.hardwaretimes.com/ether...x-3080-offers-3-4x-better-performance-in-eth/

 

Soon you'll look at that $1500 price tag as being a bargain compared to the $2400 or higher... Le Sigh.