Big Navi might still be faster than the 3080

SolarNova · September 25, 2020

Using the 3080 vs 2080ti performance delta of about 30% (2080ti + 30% = 3080)

Then Taking the 5700XT Vs 2080ti as a baseline of about 40% (5700XT + 40% = 2080ti)

Thus we need about a 70% improvement (5700XT + 70% = 3080)

Absolute best case with 100% scaling.

40CU up to 80CU (100%)

15% from core clocks based on console clocks vs 5700XT

5% from improved IPC

Thats 120% over the 5700Xt which would certainly beat the 3080 hands down.

In fact with the 3090 being roughly 15% at most better than the 3080 at 4k, that puts 80CU Big Navi even better than the 3090 in this scenario.

However, things dont scale perfectly.

More likely

40CU to 80CU 70% improvement

10% From clocks

5% from IPC

Thats 85%, but that still puts it handily above the 3080 and on par with the 3090.

Worst case

40CU to 80CU 50% improvement

10% from clocks

0% IPC

A 60% improvement would put it below the 3080 but above the 2080ti and likely above the 3070.

I suspect , AMD 80 CU Navi, if not constrained by the memory bandwidth which is a possibility based on current leaks, could very well go toe to toe with the 3090, and hopefully for a much lower price.

schwellmo92 · September 25, 2020

4 hours ago, porina said:

128MB sounds awfully small. Remember Intel Iris Pro graphics? That had 128MB of eDRAM to act as a cache, but that was on iGPUs from 5+ years ago.

Such a small quantity might make sense if it was L1 cache, since it would be spread over a lot of cores. In searching for the term "infinity cache" I'm lead to an AMD patent apparently describing... something. It's too early in my morning for me to read patent-speak. Not easy at the best of times, but on an initial skim of the first part of the document, it sounds like pooling of L1 from a second set of CUs to help with the active set. I'm wondering if this is more a compute feature than a gaming feature.

The Iris Pro cache was L4, shared with both the CPU and GPU, only 50GB/s and once exhausted fell back to DDR3 system ram at like 25GB/s. I would expect the infinity cache to have considerable throughput and low latency, it looks like it'll be a pooled L1 cache, and the fallback GDDR6 VRAM would be somewhere in the neighbourhood of 500GB/s. So I don't think it's very fair to compare to the Iris Pro implementation.

Edited September 25, 2020 by schwellmo92

porina · September 25, 2020

6 minutes ago, schwellmo92 said:

The Iris Pro cache was L4, shared with both the CPU and GPU, only 50GB/s and once exhausted fell back to DDR3 system ram at like 25GB/s. I would expect the infinity cache to have considerable throughput and low latency, it looks like it'll be a pooled L1 cache, and the fallback GDDR6 VRAM would be somewhere in the neighbourhood of 500GB/s. So I don't think it's very fair to compare to the Iris Pro implementation.

It was more to give an indication of how small it was. The thing is, if Infinity Cache is at L1, it will be more to help with doing effective work on the data, but it does nothing to help the data get there in the first place. My skim reading of the AMD patent made it sound like it was "borrowing" L1 from other CUs, so if that is the case it wouldn't be a new pool to tap from. This makes it sound like a compute optimisation, not a graphical throughput optimisation. L1 is also a funny area, since it is very tightly connected to the execution units it is hard to do much to it without starting to impact latency.

schwellmo92 · September 25, 2020

14 minutes ago, porina said:

It was more to give an indication of how small it was. The thing is, if Infinity Cache is at L1, it will be more to help with doing effective work on the data, but it does nothing to help the data get there in the first place. My skim reading of the AMD patent made it sound like it was "borrowing" L1 from other CUs, so if that is the case it wouldn't be a new pool to tap from. This makes it sound like a compute optimisation, not a graphical throughput optimisation. L1 is also a funny area, since it is very tightly connected to the execution units it is hard to do much to it without starting to impact latency.

As far as I can tell the CU's will have both dedicated and shareable L1. The shareable L1 will dynamically pool and adjust based on hit rates and latency. It's hard to know at the moment how effective if at all this will so I guess we'll just have to wait and see.

leadeater · September 25, 2020

11 hours ago, GDRRiley said:

I wouldn't be so sure. its down to bandwidth

Yes which is why it's not possible on 256bit, unless AMD has access to double the data rate GDD6X Nvidia has it's not happening on 256bit, not ever.

Nvidia outright has superior memory compression so they get vastly more effective bandwidth out of raw bandwidth than AMD does, AMD is not going to give higher performance with less effective memory bandwidth it's just not possible.