Nvidia asynchronous computer vs amd asynchronous compute

[MorganO]

I heard a while back that amd gpus have HARDWARE enabled async compute whereas nvidia can only do it through software or something,  hence amd gpus benefitting so much from DX12 is this correct in which case AMD gpus 'last longer' than nvidia gpus?  Is this correct? 

[Mira Yurizaki]

AMD has the advantage that it can switch workloads much faster than NVIDIA due to having hardware schedulers (which is what ACEs really are). The downside is you need to feed AMD large batches of jobs to keep the GPU satiated. NVIDIA uses a software scheduler (that is, it sorts things ahead of time) in order to use a simpler hardware scheduler. The downside is there's a non-trivial penalty for switching workloads (though that might be mitigated to a degree in Pascal) and NVIDIA's architecture prefers smaller job batches.

 

While I'm not going to look too much into this claim since I did some research into this and holy crap it's a minefield of fanboys on either side, someone described AMD's architecture like a Pentium 4 with HyperThreading while NVIDIA's was described as an AMD Athlon XP back in the day. If you optimized for Intel, the AMD chip would suffer and vice versa.

 

I wouldn't say AMD "lasts longer", but their full potential doesn't get realized for a while.

 

EDIT: I'd like to also point out that "Asynchronous Compute" is not a required feature of DX12 and I cannot find any DX12 literature that mentions it.

[Dabombinable]

1 minute ago, M.Yurizaki said:

AMD has the advantage that it can switch workloads much faster than NVIDIA due to having hardware schedulers (which is what ACEs really are). The downside is you need to feed AMD large batches of jobs to keep the GPU satiated. NVIDIA uses a software scheduler (that is, it sorts things ahead of time) in order to use a simpler hardware scheduler. The downside is there's a non-trivial penalty for switching workloads (though that might be mitigated to a degree in Pascal) and NVIDIA's architecture prefers smaller job batches.

 

While I'm not going to look too much into this claim since I did some research into this and holy crap it's a minefield of fanboys on either side, someone described AMD's architecture like a Pentium 4 with HyperThreading while NVIDIA's was described as an AMD Athlon XP back in the day. If you optimized for Intel, the AMD chip would suffer and vice versa.

 

I wouldn't say AMD "lasts longer", but their full potential doesn't get realized for a while.

TBH, its been over 3 years since the R9 200 series was released, and the theoretical compute performance of it still isn't reached-it will probably take another couple of years for that to happen. If the end of support for the Radeon/Mobility Radeon HD series is anything to go by-support was ended at the end of 2015 due to AMD not being able to get any more performance out of the GPU.

[Mira Yurizaki]

I also wanted to add. I edited my post and added this:

Quote

EDIT: I'd like to also point out that "Asynchronous Compute" is not a required feature of DX12 and I cannot find any DX12 literature that mentions it.

You might go "so why is AMD making such a big deal about it?" Asynchronous compute is simply an implementation to take advantage of something DX12 and Vulkan now offer: multiple job queues.

 

Likewise, DirectX 10 did not require unified shaders, but ATI and NVIDIA did both anyway because implementing it would take advantage of what DX10 required. To quote AnandTech:

Quote

We haven't seen unified shaders yet because we didn't need or want them. Up to SM2.0, vertex shaders had a higher precision requirement than pixel shaders. While 32bit floating point was required for compliance at the vertex level, 24bit was all that was needed for full precision in pixel shaders. Partial precision hints were added to accommodate 16bit pixel shaders on NVIDIA hardware. It wouldn't have been practical at the launch of DX9 to require that all shader units be 32bit. The same goes for including pixel oriented features in the vertex shader hardware: the API didn't support it, so there was no need to include it. The R300 GPU is 218mm^2 with only 107 Million transistors, and adding any more complexity than necessary would have certainly produced a much larger chip than they would have been able to handle on the 150nm process employed at the time. These days, we are able to do much more in the same space: ATI's latest chip, the RV570, is about 230mm^2 and has 330 Million transistors.

The reason why AMD created ACEs in the first place was they wanted basically a jack-of-all-trades GPU that could do both compute and graphics. NVIDIA started off with this, but when the GeForce 600 series came around, games probably weren't taking advantage of GPGPU compute all that much and so figured focusing on graphics would be better for the consumer side and they wanted to focus on energy efficiency because like it or not, mobile was king and servers wanted something that didn't jack up their HVAC bills.

 

But now game developers are caring more about GPGPU compute, and so AMD found its smoking bullet. NVIDIA just has to play catch up in that regard. However, ACEs are not immediately better than a software based scheduler. When done properly, a software based scheduler can go toe-to-toe with a hardware based one. An example of this is NVIDIA's Project Denver and the Elbrus 2000.

 

Okay that's enough from me.

[MorganO]

10 minutes ago, M.Yurizaki said:

I also wanted to add. I edited my post and added this:

You might go "so why is AMD making such a big deal about it?" Asynchronous compute is simply an implementation to take advantage of something DX12 and Vulkan now offer: multiple job queues.

 

Likewise, DirectX 10 did not require unified shaders, but ATI and NVIDIA did both anyway because implementing it would take advantage of what DX10 required. To quote AnandTech:

The reason why AMD created ACEs in the first place was they wanted basically a jack-of-all-trades GPU that could do both compute and graphics. NVIDIA started off with this, but when the GeForce 600 series came around, games probably weren't taking advantage of GPGPU compute all that much and so figured focusing on graphics would be better for the consumer side and they wanted to focus on energy efficiency because like it or not, mobile was king and servers wanted something that didn't jack up their HVAC bills.

 

But now game developers are caring more about GPGPU compute, and so AMD found its smoking bullet. NVIDIA just has to play catch up in that regard. However, ACEs are not immediately better than a software based scheduler. When done properly, a software based scheduler can go toe-to-toe with a hardware based one. An example of this is NVIDIA's Project Denver and the Elbrus 2000.

 

Okay that's enough from me.

Very interesting, although now you explain it to me,  maybe I heard it wrong? 

[Mira Yurizaki]

6 minutes ago, KOMTechAndGaming said:

Very interesting, although now you explain it to me,  maybe I heard it wrong? 

The hardware part about AMD and the software part about NVIDIA isn't wrong. One of the main issues perhaps is that NVIDIA's ecosystem makes it easier for developers to achieve most of the GPU's potential, while for AMD, it's harder to do. They'll eventually get it, but it's not going to happen right away.

 

It's a poor comparison, but it's probably similar to the PS3 and the Xbox 360. The PS3 indeed had a very powerful CPU for its time, but it was a nightmare to program for to get the most out of it. On the other hand, the Xbox 360's CPU was more straight forward, but less powerful. So initially, Xbox 360 versions of games played better than their PS3 counterparts.

[MorganO]

1 minute ago, M.Yurizaki said:

The hardware part about AMD and the software part about NVIDIA isn't wrong. One of the main issues perhaps is that NVIDIA's ecosystem makes it easier for developers to achieve most of the GPU's potential, while for AMD, it's harder to do. They'll eventually get it, but it's not going to happen right away.

 

It's a poor comparison, but it's probably similar to the PS3 and the Xbox 360. The PS3 indeed had a very powerful CPU for its time, but it was a nightmare to program for to get the most out of it. On the other hand, the Xbox 360's CPU was more straight forward, but less powerful. So initially, Xbox 360 versions of games played better than their PS3 counterparts.

Ok,  I understand better now,  is it also a reason amd cards run hotter/less efficient  than nvidias cards? I mean i think nvidia are targeting efficiency/less heat at the expense of slightly less performance whereas a amd is more 'raw'  performance at the cost of efficiency and heat(not so much efficiency with polaris)? 

[Mira Yurizaki]

Just now, KOMTechAndGaming said:

Ok,  I understand better now,  is it also a reason amd cards run hotter/less efficient  than nvidias cards?

That depends on what AMD was doing in the first place. There is some evidence that could be the case since NVIDIA's cards ran pretty hot during their "Jack of all trades" design era.

Just now, KOMTechAndGaming said:

I mean i think nvidia are targeting efficiency/less heat at the expense of slightly less performance whereas a amd is more 'raw'  performance at the cost of efficiency and heat(not so much efficiency with polaris)? 

More or less.

[MorganO]

12 minutes ago, M.Yurizaki said:

That depends on what AMD was doing in the first place. There is some evidence that could be the case since NVIDIA's cards ran pretty hot during their "Jack of all trades" design era.

More or less.

Ok,  thank you for your helpful information