Question Speculation: RDNA2 + CDNA Architectures thread

[uzzi38]

All die sizes are within 5mm^2. The poster here has been right on some things in the past afaik, and to his credit was the first to saying 505mm^2 for Navi21, which other people have backed up. Even still though, take the following with a pich of salt.

Navi21 - 505mm^2

Navi22 - 340mm^2

Navi23 - 240mm^2

Source is the following post: https://www.ptt.cc/bbs/PC_Shopping/M.1588075782.A.C1E.html

 

[coercitiv]

Also claims that AMD put fake info in the MAC and Linux firmware dumps to throw people off.

The things people do to build an audience and the things people would believe to get excited.

There's enough bullproduct in these slides to fertilize Mars.

 

[TitusTroy]

will Big Navi be more gaming focused compared to Ampere?...and will it be better for 1440p compared to Ampere?...Nvidia seemed to overload their new cards with compute performance vs strictly gaming and it seems best served at 4K resolution...

I would love to go with AMD this generation but I bought a 1440p 144hz G-Sync monitor 2 years ago and I don't see myself upgrading anytime soon...

 

[DisEnchantment]

I know this guy isn't anyone's favorite "source", but its been a slow couple days, so why not?

He seems to be doubling down on the on die cache rumor and claims HBM for consumer cards is a no go .

Also claims that AMD put fake info in the MAC and Linux firmware dumps to throw people off.

What a load of trash. Why do you put it here.
Linux 5.9 already sailed. If AMD put fake stuffs there then none of the RDNA2 HW is going to work. What is the point of issuing a drm fix for 5.9 even. Why even bother upstreaming anything.
Yet he heard of "rumors" about 32CU and 40CU, wonder where those came from.
Different CU design for N22 and N23? Sure.

 

[PhoBoChai]

will Big Navi be more gaming focused compared to Ampere?...and will it be better for 1440p compared to Ampere?...Nvidia seemed to overload their new cards with compute performance vs strictly gaming and it seems best served at 4K resolution...

I would love to go with AMD this generation but I bought a 1440p 144hz G-Sync monitor 2 years ago and I don't see myself upgrading anytime soon...

GA102 is really good for workstation apps and rendering, where the 2x FP32 shines and without graphics bottlenecks even the RT cores can flex their power as seen in chaos vray, where 3080 with 68 SM is 2x faster than 2080Ti with the same SM count.

So yeah it definitely seems like NV went ballz deep on datacenter & workstation design for Ampere.

 

[TitusTroy]

GA102 is really good for workstation apps and rendering, where the 2x FP32 shines and without graphics bottlenecks even the RT cores can flex their power as seen in chaos vray, where 3080 with 68 SM is 2x faster than 2080Ti with the same SM count.

So yeah it definitely seems like NV went ballz deep on datacenter & workstation design for Ampere.

so even the upcoming RTX 3070 won't change anything?...it'll still be heavily focused on compute performance vs gaming?

 

[BlitzWulf]

What a load of trash. Why do you put it here.

Boredom

 

[Qwertilot]

so even the upcoming RTX 3070 won't change anything?...it'll still be heavily focused on compute performance vs gaming?

We'll see soon enough Same architecture of course but it might balance out a bit differently. They'll certainly have to tame the power draws much more aggressively in the mid range chips.

Given how large those various markets are for them now, its easy to see why they might have built out the top gaming chip at least to have a considerable focus on compute stuff.

 

[soresu]

OMG yes. I have no idea how Monolith went backwards, not just in terms of gameplay but arguably along various graphical dimensions, with each FEAR game. And the original FEAR runs like total *** on modern systems too.

There is an effort started to fix up a source code release of the LithTech Jupiter engine, but sadly I would not expect it to be stable and feature complete anytime soon given the rate of improvement thus far.

 

[PhoBoChai]

so even the upcoming RTX 3070 won't change anything?...it'll still be heavily focused on compute performance vs gaming?

I think the 3070 will be more efficient for graphics because it's going to have the 6 GPC layout, which means 6 graphics pipelines where it counts, and while its SM may have or may not, 2x FP32 potential, it at the least has basically the same graphics potential as the 3080 with 6 GPC too, just fewer SMs.

 

[beginner99]

Linux 5.9 already sailed. If AMD put fake stuffs there then none of the RDNA2 HW is going to work. What is the point of issuing a drm fix for 5.9 even. Why even bother upstreaming anything.

Since I have no clue how this works, can't AMD just fix it later on? i mean what distros actually ship with 5.9 kernel? They must be able to fix it else anyone say on Ubuntu 20.04 (Kernel 5.4) couldn't use a new AMD GPU. So there certainly is a mechanism to fix this later on?

 

[andermans]

The new cache is a given at this point, with the unified L1$ design in RDNA 1 opening possibilities for the changes that the dynamic CU cache patent and research paper showed. I don't think it will be a large ESRAM 128mb as rumored. Just larger L1$ and larger L2$ will do the job fine.

I don't think most of the research papers and patents are too relevant for memory bandwidth though. They're mostly about the L0<->L1<->L2 path while for memory bandwidth the main mitigation would be increasing the effective capacity of the last level cache, either by making L2 larger or introducing a new L3. Don't get me wrong, L0<->L1<->L2 improvements could be interesting for performance (especially for raytracing which is pretty hard on the cache hierarchy), but they don't solve the problem everyone seems to be worried about.

 

[Glo.]

Since I have no clue how this works, can't AMD just fix it later on? i mean what distros actually ship with 5.9 kernel? They must be able to fix it else anyone say on Ubuntu 20.04 (Kernel 5.4) couldn't use a new AMD GPU. So there certainly is a mechanism to fix this later on?

Ubuntu NEVER updates their ISO's. If you have a ISO with Kernel 5.4 - that is what you will get.

You have to wait for next version of the OS, in order to get the desired update, and that is only if you have Ubuntu Shipped with latest kernel. Ubuntu 20.10 will have "only" 5.8 kernel.

Pop!_OS has different approach, despite it being based on the same OS - Ubuntu. Pop always updates their ISO, on their website, with latest hardware support. For example - you couldn't for some time run RX 590 with latest Ubuntu, but if you had latest ISO of Pop!_OS - it worked out of the box.

 

[andermans]

Since I have no clue how this works, can't AMD just fix it later on? i mean what distros actually ship with 5.9 kernel? They must be able to fix it else anyone say on Ubuntu 20.04 (Kernel 5.4) couldn't use a new AMD GPU. So there certainly is a mechanism to fix this later on?

For small fixes you can backport to older kernels, but generally Ubuntu updates some components of LTS releases with a HWE package which includes some driver stuff from a new normal release. IIRC the a new kernel is also included in this. Though I guess Ubuntu 20.10 might be getting 5.8?

(As per the poster above I'm not sure those updates get included in the ISO but they should be available as online updates. Worst comes to worst you'll get the basic vesa? support until you update your packages)

 

[PhoBoChai]

I don't think most of the research papers and patents are too relevant for memory bandwidth though. They're mostly about the L0<->L1<->L2 path while for memory bandwidth the main mitigation would be increasing the effective capacity of the last level cache, either by making L2 larger or introducing a new L3. Don't get me wrong, L0<->L1<->L2 improvements could be interesting for performance (especially for raytracing which is pretty hard on the cache hierarchy), but they don't solve the problem everyone seems to be worried about.

It's all related.

When you stress L2 less with repetitive L1 spill overs, the L2 is more effective for data and texture cache, so you have to visit memory more often, thereby placing stress on memory bandwidth.

Making L1 and L2 work better, increases their hit rate, reduces their duplication. Cache that hits more and can store more useful data will reduce the need on off-chip memory, so you don't need as much bandwidth for the same perf. aka, better bandwidth efficiency.

Classic example of cache reducing memory bandwidth requirements, first Xbox One, then Xbox One X. 32MB of cache only and it did wonders, like DDR system RAM wonders.

 

[Heartbreaker]

I know this guy isn't anyone's favorite "source", but its been a slow couple days, so why not?


He seems to be doubling down on the on die cache rumor and claims HBM for consumer cards is a no go .

Also claims that AMD put fake info in the MAC and Linux firmware dumps to throw people off.

View attachment 30722


View attachment 30723


View attachment 30724


View attachment 30726


View attachment 30727

Hate these clickbait channels and refuse to watch them, but you put up slides so I don't have to. So kudos.

Basically I don't see anything unique. He seems to be just re-spinning the current rumor set. But clickbait gotta be generating the clicks...

 

[DisEnchantment]

Since I have no clue how this works, can't AMD just fix it later on? i mean what distros actually ship with 5.9 kernel? They must be able to fix it else anyone say on Ubuntu 20.04 (Kernel 5.4) couldn't use a new AMD GPU. So there certainly is a mechanism to fix this later on?

They can make packages for older kernel versions for sure. But someone has to backport the commits to the older trees.
However, attempts to autosel sienna/navy commits to older trees by MS dev Sasha Levin was nacked by AMD's Alex deucher

[PATCH AUTOSEL 5.8 52/63] drm/amdgpu: disable gfxoff for navy_flounder

lists.freedesktop.org

On Mon, Aug 24, 2020 at 12:36 PM Sasha Levin <sashal at kernel.org> wrote:
>
> From: Jiansong Chen <Jiansong.Chen at amd.com>
>
> [ Upstream commit 9c9b17a7d19a8e21db2e378784fff1128b46c9d3 ]
>
> gfxoff is temporarily disabled for navy_flounder,
> since at present the feature has broken some basic
> amdgpu test.
>
> Signed-off-by: Jiansong Chen <Jiansong.Chen at amd.com>
> Reviewed-by: Tao Zhou <tao.zhou1 at amd.com>
> Signed-off-by: Alex Deucher <alexander.deucher at amd.com>
> Signed-off-by: Sasha Levin <sashal at kernel.org>

Support for this chip does not exist in 5.8 or any other older trees.
Please drop this.

Alex

So officially RDNA2 will work only on Kernel 5.9 and above. So I highly doubt AMD committed fake stuff to 5.9 just for "confusing leakers".
There are many reasons for this, one being additional ROCm support in kfd was added and new changes for Sienna/Navy was based on that.

 

[Shivansps]

WTF, does someone really belived AMD commited fake stuff to the Linux kernel?! There is no way that the commited stuff is fake, what it could happen is that it could be a device for another market.

 

[leoneazzurro]

Not only that, but the most recent leaks came not from Linux, but by MacOS... Now imagine if Apple allows AMD to put fake Ids and info in their stuff...

 

[Glo.]

They can make packages for older kernel versions for sure. But someone has to backport the commits to the older trees.
However, attempts to autosel sienna/navy commits to older trees by MS dev Sasha Levin was nacked by AMD's Alex deucher

[PATCH AUTOSEL 5.8 52/63] drm/amdgpu: disable gfxoff for navy_flounder

lists.freedesktop.org

So officially RDNA2 will work only on Kernel 5.9 and above. So I highly doubt AMD committed fake stuff to 5.9 just for "confusing leakers".
There are many reasons for this, one being additional ROCm support in kfd was added and new changes for Sienna/Navy was based on that.

Which means that it will be the same story with RDNA2 GPUs on Ubuntu as it was for RX 590.

They won't work, out of the box. You have to have different Radeon GPU, update the kernel and Mesa to latest versions and only after that you can swap GPUs. It will be same thing for both: 20.10 and 20.04.

 

[andermans]

Which means that it will be the same story with RDNA2 GPUs on Ubuntu as it was for RX 590.

They won't work, out of the box. You have to have different Radeon GPU, update the kernel and Mesa to latest versions and only after that you can swap GPUs. It will be same thing for both: 20.10 and 20.04.

Shouldn't just the vesa fallback work for updating the drivers though? no need for another card.

 

[raghu78]

What a load of trash. Why do you put it here.
Linux 5.9 already sailed. If AMD put fake stuffs there then none of the RDNA2 HW is going to work. What is the point of issuing a drm fix for 5.9 even. Why even bother upstreaming anything.
Yet he heard of "rumors" about 32CU and 40CU, wonder where those came from.
Different CU design for N22 and N23? Sure.

Well said. These youtubers with so called exclusive info are just pathetic. Bunch of clowns.

 

[Saylick]

At the end of the day, the only hard data we have so far is that RDNA 2 can clock as high as 2.23 GHz (from PS5 info), and has 50% perf/W than RDNA 1, which was confirmed based on the Xbox Series X HotChips presentation where they got 52 CUs @ 1.825 GHz using only a 130-140W TDP. That's it. We can extrapolate from those two data points however we want. Technically speaking, even the idea of Navi 21 being 80 CUs isn't even confirmed publicly or officially in any form.

 

[Glo.]

At the end of the day, the only hard data we have so far is that RDNA 2 can clock as high as 2.23 GHz (from PS5 info), and has 50% perf/W than RDNA 1, which was confirmed based on the Xbox Series X HotChips presentation where they got 52 CUs @ 1.825 GHz using only a 130-140W TDP. That's it. We can extrapolate from those two data points however we want. Technically speaking, even the idea of Navi 21 being 80 CUs isn't even confirmed publicly or officially in any form.

We also have specs from MacOS Kexts.

 

[Vixis Rei]

I don't see a problem with posting videos from the youtubz. This is the speculation thread after all, not the 100% accurate thread.

Their opinion is no more better or worse then ours, they are just people after all and we'll see where the chips lay after release.

I enjoy me some thoughtful speculation.

 

[thigobr]

Fake stuff into kernel and MacOS is pure nonsense! All of those needed to be validated with test hardware.Unless they have parts that won't be supported out of the gate what's there should be true. Maybe some of those SKUs won't make to Production but they were part of the plan at some point.