Question Speculation: RDNA3 + CDNA2 Architectures Thread

[uzzi38]

Man I have been dying to make this one for a while now.

First rumours for RDNA3 are here so new thread time!

Just going to start off with this one for now: kopite7kimi on Twitter: "@VideoCardz Ah, I mean a simple mcm design with 10240 cores is not enough. Because the lift from RDNA2 to RDNA3 is much bigger than from RDNA1 to RDNA2. We should expect many big improvements in GFX11. 🤔" / Twitter

 

[jpiniero]

For 7500 XT, AMD can give it 96 bit bus(6GB VRAM), and sell it for over 200$(250-270).

As I've been saying do not expect a new dGPU from anybody (other than Intel, until they give up) less than $400, maybe even $450. A part lower than N33 would only make sense as an mobile only OEM product... and after Navi 24 not really getting any OEM deals it doesn't look like it'd be worth it.

 

[Aapje]

AMD seems to have improved H.264 for RDNA 2: https://codecalamity.com/amd-re-introduces-the-b-frame/

Hopefully this means that RDNA 3 will catch up a bit with their encoding.

 

[leoneazzurro]

Do we get 64 SPs(shaders) per SIMD32 or there is 2x more SIMD32 per CU?

SIMD32=vector unit, it is capable to do 32 FP32 FMA per cycle.

RDNA2 CU= 2xSIMD32

RDNA3 CU =4xSIMD32

examples:

N22=40CU, 80 SIMD32, 2560 shaders ("single units" capable to execute FP32 FMA operations). Organized in 20 Workgroups (WGP), 2 SE (shader Engines), 10 WGP per SE

N33=32CU, 128 SIMD32, 4096 shaders, organized in 16 WGP, 2 SE, 8 WGP per SE (latest rumors)

 

[Aapje]

As I've been saying do not expect a new dGPU from anybody (other than Intel, until they give up) less than $400, maybe even $450. A part lower than N33 would only make sense as an mobile only OEM product... and after Navi 24 not really getting any OEM deals it doesn't look like it'd be worth it.

I disagree. Once the silicon shortages end, the lower end will become a more interesting market again for them to compete in.

 

[jpiniero]

I disagree. Once the silicon shortages end, the lower end will become a more interesting market again for them to compete in.

The low end will be APUs. Maybe even the mid range.

 

[Aapje]

The low end will be APUs. Maybe even the mid range.

Lower mid range then. I mean the $200 - $400 GPU range.

 

[TESKATLIPOKA]

SIMD32=vector unit, it is capable to do 32 FP32 FMA per cycle.

RDNA2 CU= 2xSIMD32

RDNA3 CU =4xSIMD32

examples:

N22=40CU, 80 SIMD32, 2560 shaders ("single units" capable to execute FP32 FMA operations). Organized in 20 Workgroups (WGP), 2 SE (shader Engines), 10 WGP per SE

N33=32CU, 128 SIMD32, 4096 shaders, organized in 16 WGP, 2 SE, 8 WGP per SE (latest rumors)

Let's try once more.

On the previous page, It was pretty much confirmed that there is a second 32 lane VALU in a SIMD, right?
A 32 lane VALU is part of SIMD32, If I understand It correctly. That would mean 2x 32 lane VALU per SIMD. I don't know If SIMD32 will be called as SIMD64 in RDNA3 or something similar.
You on the other hand are saying that SIMD32 was doubled per CU in RDNA3. Now, which one is the correct answer?

 

[leoneazzurro]

Let's try once more.

On the previous page, It was pretty much confirmed that there is a second 32 lane VALU in a SIMD, right?
A 32 lane VALU is part of SIMD32, If I understand It correctly. That would mean 2x 32 lane VALU per SIMD. I don't know If SIMD32 will be called as SIMD64 in RDNA3 or something similar.
You are saying that SIMD32 was doubled per CU in RDNA3. Now which one is the correct answer?

The patch (but also Kepler some posts ago) said that there were 2 SIMD32 per CU in RDNA2, now they are 4. Scalar units are probably doubled as well.
So it seems it's 4xSIMD32 per CU, not 2xSIMD64. Now, if at hardware level they are in reality four 32-wide units, a couple of 64-wide FP unit or a single 128-wide FP unit, we don't know and we'll probaby not know for a big while. From the software side they seems to be seen as 4xSIMD32, and I did not see any indication these are asymmetrical units (that is, some of them only capable of certain operations).

 

[Timorous]

Yes the 7700XT will be a cutdown N32. One interesting thing about the Navi3x MCM design is that when they cutdown VRAM/cache they will actually ship less silicon! This makes configurations like 320-bit 7900XT and 192-bit 7700XT much more palatable for AMD.

So that means the memory PHYs are in the cache dies.

To me that would mean N31 should have 384MB cache because a 64MB + 64bit makes more sense to me. It would give what is likely to be the 192bit N32 based 7700XT part 192MB of cache. A 32MB / 64bit setup would only be 96MB which is less than N33 is meant to have.

 

[Glo.]

As I've been saying do not expect a new dGPU from anybody (other than Intel, until they give up) less than $400, maybe even $450. A part lower than N33 would only make sense as an mobile only OEM product... and after Navi 24 not really getting any OEM deals it doesn't look like it'd be worth it.

I don't expect 600 SKU to exceed 400$, IF it will not have 12 GB RAM, or more.

If its 8 GB RAM - they won't price it at more than 400$.

 

[leoneazzurro]

So that means the memory PHYs are in the cache dies.

That was obvious for me, and I wrote it months ago

 

[jpiniero]

Lower mid range then. I mean the $200 - $400 GPU range.

They'll just sell RDNA 2 and/or nothing if the Flood happens.

I don't expect 600 SKU to exceed 400$, IF it will not have 12 GB RAM, or more.

The 6650 XT's MSRP is $400. Obviously whatever the 7600 ends up being (unless it's a straight RDNA 2 rebrand) is going to be more than that.

 

[Kepler_L2]

AMD can still cut down heavily the N33 die, into 3 SKUs.

If Kepler is correct, and N33 is going to be 7600 Series, then we are looking at 7600 XT, 7600, and potentially - 7500 XT.


However, we know that it was required for AMD to disable pairs of CPUs in order to get usable dies.

Is it possible that AMD is required to disable pairs of WGPs now?

7600 XT - 32 CUs,
7600 - 24 CUs,
7500 XT - 16 CUs, or...
7600 XT - 32 CUs,
7600 - 28 CUs,
7500 XT - 24 CUs?

For 7500 XT, AMD can give it 96 bit bus(6GB VRAM), and sell it for over 200$(250-270).

It's still the same CU pairs as before. Full N33 is 32 CUs, cutdown models will be 28 and 24 CUs. Also don't expect the 7500XT anytime soon

32CU instead of 40CU is not a downgrade when the performance increases by a lot. The real downgrade is 8GB Vram. If It had 12GB, then I don't think 8 PCIe4 lanes would really matter.


Do we get 64 SPs(shaders) per SIMD32 or there is 2x more SIMD32 per CU?

It's technically 2x SIMD32+32 per CU now.

 

[Glo.]

Full N33 is 32 CUs, cutdown models will be 28 and 24 CUs. Also don't expect the 7500XT anytime soon

Im ok with 7500 XT being released in 2023 . Like in 2H of 2023, thats fine by me.

Also 24 CUs - 3072 ALUs.It would be faster than RX 6700 XT, and touching the RX 6800, if what we know about N33 performance will manifest itself in the GPUs.

 

[Mopetar]

I disagree. Once the silicon shortages end, the lower end will become a more interesting market again for them to compete in.

The low end will be APUs. Maybe even the mid range.

The low end will be the flood of mining cards that eventually hit the market. Both AMD and NVidia know that there's little point in trying to compete against that. Assuming the prices aren't out of control there are going to be a lot of people who wound up settling for a midrange card that will be looking to upgrade as well, so expect a healthy used market.

I suspect we'll eventually see an N34 that's designed for the mobile market but also fills in the low end of the desktop market. APUs are starting to get good enough that casual gamers or anyone just building a gaming rig for a young kid could get by without a discrete card.

 

[xilli_fiberbit]

We have the ID now https://www.coelacanth-dream.com/posts/2022/07/09/dcn3_1_4-apu/ for the NAVI 3x familly :

GC IP ver	GFX ID	AMDGPU_FAMILY	Type
11.0.0	gfx1100 (Navi31)1	AMDGPU_FAMILY_GC_11_0_0 (FAMILY_GFX1100)	dGPU
11.0.1	gfx1103	AMDGPU_FAMILY_GC_11_0_2 (FAMILY_GFX1103)	APU
11.0.2	gfx1102 (Navi32)	AMDGPU_FAMILY_GC_11_0_0 (FAMILY_GFX1100)	dGPU
11.0.3?	gfx1101 (Navi33)?	AMDGPU_FAMILY_GC_11_0_0 (FAMILY_GFX1100)?	dGPU?

The GFX1103 seems to be for Phoenix Point

 

[Kepler_L2]

This was known already.

Tensile/Tensile/Common.py at 3b4026af1fe0fdbd6c618a50bf4ff18451c61c9e · ROCm/Tensile

Stretching GPU performance for GEMMs and tensor contractions. - ROCm/Tensile

github.com

 

[jpiniero]

I suspect we'll eventually see an N34 that's designed for the mobile market but also fills in the low end of the desktop market.

A theoretical $400 N34 desktop GPU would get killed by The Flood. Not worth it unless they think they can get enough mobile dGPU OEM deals for it. Which right now nVidia pretty much owns.

Even like the Ryzen gamimg laptops almost entirely come with Ampere, and the very small amount of Radeon ones would likely want to include N33 and not anything slower.

 

[DisEnchantment]

Actually more crazy stuff are there but not sure if they are just placeholders for future SoC.
e.g.
32 threads in the Texture Addressing Unit which perform RT with traversal capability, texture (i.e. BVH) load capability.

Seems nobody is interested to pick up on the info from this driver patch not sure if it is widely deemed as inaccurate.

TCP --> Texture Cache Processor
TC --> Texture Cache
PERF_SEL_XXX is a perf event mask value, which can be used for performance monitoring during development or when profiling a game etc.

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/include/soc21_enum.h#L17622

TA --> Texture Addressing Unit
This block fetches BVH data from the TC (Texture Cache, which apparently got bigger in RDNA3)

TA_PERF_SEL_image_bvh_8_input_vgpr_instructions = 0x000000bc,
TA_PERF_SEL_image_bvh_9_input_vgpr_instructions = 0x000000bd,
TA_PERF_SEL_image_bvh_11_input_vgpr_instructions = 0x000000be,
TA_PERF_SEL_image_bvh_12_input_vgpr_instructions = 0x000000bf,
TA_PERF_SEL_image_bvh_1_op_burst = 0x000000c8,
TA_PERF_SEL_image_bvh_2to3_op_burst = 0x000000c9,
TA_PERF_SEL_image_bvh_4to7_op_burst = 0x000000ca,
TA_PERF_SEL_image_bvh_ge8_op_burst = 0x000000cb,

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/include/soc21_enum.h#L18030

TD --> Texture Data Unit. Ray Intersection Unit is present here.

TD_PERF_SEL_ray_tracing_bvh4_sclk_en = 0x00000016,
TD_PERF_SEL_ray_tracing_bvh4_ip_sclk_en = 0x00000017,
TD_PERF_SEL_ray_tracing_bvh4_box_sclk_en = 0x00000018,
TD_PERF_SEL_ray_tracing_bvh4_tri_sclk_en = 0x00000019,
TD_PERF_SEL_sampler_and_nofilter_sclk_on_bvh4_sclk_off = 0x0000001d,
TD_PERF_SEL_sampler_and_bvh4_sclk_on_nofilter_sclk_off = 0x0000001e,
TD_PERF_SEL_nofilter_and_bvh4_sclk_on_sampler_sclk_off = 0x0000001f,
TD_PERF_SEL_ray_tracing_bvh4_pkr_full = 0x00000030,
TD_PERF_SEL_ray_tracing_bvh4_pkr_full_due_to_arb = 0x00000031,
TD_PERF_SEL_total_num_ray_tracing_bvh4_instr = 0x00000052,
TD_PERF_SEL_total_num_ray_tracing_bvh4_instr_with_perf_wdw = 0x00000053,
TD_PERF_SEL_ray_tracing_bvh4_threads_per_instruction_is_0 = 0x0000006c,
TD_PERF_SEL_ray_tracing_bvh4_threads_per_instruction_is_1 = 0x0000006d,
TD_PERF_SEL_ray_tracing_bvh4_threads_per_instruction_is_2 = 0x0000006e,
TD_PERF_SEL_ray_tracing_bvh4_threads_per_instruction_is_3to4 = 0x0000006f,
TD_PERF_SEL_ray_tracing_bvh4_threads_per_instruction_is_5to8 = 0x00000070,
TD_PERF_SEL_ray_tracing_bvh4_threads_per_instruction_is_9to16 = 0x00000071,
TD_PERF_SEL_ray_tracing_bvh4_threads_per_instruction_is_17to31 = 0x00000072,
TD_PERF_SEL_ray_tracing_bvh4_threads_per_instruction_is_32 = 0x00000073,
TD_PERF_SEL_ray_tracing_bvh4_fp16_box_node = 0x00000074,
TD_PERF_SEL_ray_tracing_bvh4_fp32_box_node = 0x00000075,
TD_PERF_SEL_ray_tracing_bvh4_tri_node = 0x00000076,
TD_PERF_SEL_ray_tracing_bvh4_dropped_box_node = 0x00000077,
TD_PERF_SEL_ray_tracing_bvh4_dropped_tri_node = 0x00000078,
TD_PERF_SEL_ray_tracing_bvh4_invalid_box_node = 0x00000079,
TD_PERF_SEL_ray_tracing_bvh4_invalid_tri_node = 0x0000007a,
TD_PERF_SEL_ray_tracing_bvh4_box_sort_en = 0x0000007b,
TD_PERF_SEL_ray_tracing_bvh4_box_grow_val_nonzero = 0x0000007c,
TD_PERF_SEL_ray_tracing_bvh4_num_box_with_inf_or_nan_vtx = 0x0000007d,
TD_PERF_SEL_ray_tracing_bvh4_num_tri_with_inf_or_nan_vtx = 0x0000007e,
TD_PERF_SEL_ray_tracing_bvh4_num_box_that_squashed_a_nan = 0x0000007f,
TD_PERF_SEL_ray_tracing_bvh4_num_box_misses = 0x00000080,
TD_PERF_SEL_ray_tracing_bvh4_num_tri_misses = 0x00000081,
TD_PERF_SEL_ray_tracing_bvh4_num_tri_tie_breakers = 0x00000082,
TD_PERF_SEL_burst_bin_bvh4_1 = 0x00000095,
TD_PERF_SEL_burst_bin_bvh4_2to8 = 0x00000096,
TD_PERF_SEL_burst_bin_bvh4_9to16 = 0x00000097,
TD_PERF_SEL_burst_bin_bvh4_gt16 = 0x00000098,
TD_PERF_SEL_burst_bin_bvh4_box_nodes_1 = 0x00000099,
TD_PERF_SEL_burst_bin_bvh4_box_nodes_2to4 = 0x0000009a,
TD_PERF_SEL_burst_bin_bvh4_box_nodes_5to7 = 0x0000009b,
TD_PERF_SEL_burst_bin_bvh4_box_nodes_8to16 = 0x0000009c,
TD_PERF_SEL_burst_bin_bvh4_box_nodes_gt16 = 0x0000009d,
TD_PERF_SEL_burst_bin_bvh4_tri_nodes_1 = 0x0000009e,
TD_PERF_SEL_burst_bin_bvh4_tri_nodes_2to8 = 0x0000009f,
TD_PERF_SEL_burst_bin_bvh4_tri_nodes_9to16 = 0x000000a0,
TD_PERF_SEL_burst_bin_bvh4_tri_nodes_gt16 = 0x000000a1,
TD_PERF_SEL_burst_bin_bvh4_dropped_nodes_1 = 0x000000a2,
TD_PERF_SEL_burst_bin_bvh4_dropped_nodes_2to8 = 0x000000a3,
TD_PERF_SEL_burst_bin_bvh4_dropped_nodes_9to16 = 0x000000a4,
TD_PERF_SEL_burst_bin_bvh4_dropped_nodes_gt16 = 0x000000a5,
TD_PERF_SEL_burst_bin_bvh4_invalid_nodes_1 = 0x000000a6,
TD_PERF_SEL_burst_bin_bvh4_invalid_nodes_2to8 = 0x000000a7,
TD_PERF_SEL_burst_bin_bvh4_invalid_nodes_9to16 = 0x000000a8,
TD_PERF_SEL_burst_bin_bvh4_invalid_nodes_gt16 = 0x000000a9,

TA/TD/TC/TCP is per CU. They feed the SIMDs with texture data basically. Therefore Ray Unit is sitting on top of data itself.

From the above perf events, it seems to me like (speculation/guess follows)
The TA can do burst BVH data fetch (e.g. image load insts) from the Texture Cache or from the Cache Hierarchy. The Texture Data Unit containing the Ray Intersection Unit can traverse the BVH nodes, it can drop nodes from the tree, it can bin the nodes on the tree to check which it traverse next.
Compared to RDNA2 where the shader in the SIMD has to check the result from the TD each time and load a new value in the VGPR for the TA to fetch the data again and provide to the TD.
And for a total of up to 32 threads in the TD doing the BVH4 tests at once.
It seems somewhat similar to this AMD patent (also it was a refile of a provisional application, somebody seems to be in a hurry), about opportunistically performing ray box tests on multiple paths of the BVH tree and drop unneeded nodes early on.
20210209832 BOUNDING VOLUME HIERARCHY TRAVERSAL

https://www.freepatentsonline.com/y2021/0209832.html

Such operations can only be done if the TD has ability to traverse the BVH tree and can simultaneously trigger multiple Ray box tests on multiple nodes associated with a starting BVH node. Drop nodes which are not to be tested anymore and bin the nodes where the next ray box tests are to be done (or to be dropped)
The Ray Intersection tests provide the starting node in the op amdgcn_image_bvh_intersect_ray

https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/AMDGPU/SIISelLowering.cpp#L7637

 

[Kepler_L2]

Seems nobody is interested to pick up on the info from this driver patch not sure if it is widely deemed as inaccurate.

TCP --> Texture Cache Processor
TC --> Texture Cache
PERF_SEL_XXX is a perf event mask value, which can be used for performance monitoring during development or when profiling a game etc.

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/include/soc21_enum.h#L17622

TA --> Texture Addressing Unit
This block fetches BVH data from the TC (Texture Cache, which apparently got bigger in RDNA3)

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/include/soc21_enum.h#L18030

TD --> Texture Data Unit. Ray Intersection Unit is present here.


TA/TD/TC/TCP is per CU. They feed the SIMDs with texture data basically. Therefore Ray Unit is sitting on top of data itself.

From the above perf events, it seems to me like (speculation/guess follows)
The TA can do burst BVH data fetch (e.g. image load insts) from the Texture Cache or from the Cache Hierarchy. The Texture Data Unit containing the Ray Intersection Unit can traverse the BVH nodes, it can drop nodes from the tree, it can bin the nodes on the tree to check which it traverse next.
Compared to RDNA2 where the shader in the SIMD has to check the result from the TD each time and load a new value in the VGPR for the TA to fetch the data again and provide to the TD.
And for a total of up to 32 threads in the TD doing the BVH4 tests at once.
It seems somewhat similar to this AMD patent (also it was a refile of a provisional application, somebody seems to be in a hurry), about opportunistically performing ray box tests on multiple paths of the BVH tree and drop unneeded nodes early on.
20210209832 BOUNDING VOLUME HIERARCHY TRAVERSAL

https://www.freepatentsonline.com/y2021/0209832.html

Such operations can only be done if the TD has ability to traverse the BVH tree and can simultaneously trigger multiple Ray box tests on multiple nodes associated with a starting BVH node. Drop nodes which are not to be tested anymore and bin the nodes where the next ray box tests are to be done (or to be dropped)
The Ray Intersection tests provide the starting node in the op amdgcn_image_bvh_intersect_ray

https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/AMDGPU/SIISelLowering.cpp#L7637

Aren't these the same in gfx10.3 and gfx11?

 

[DisEnchantment]

Aren't these the same in gfx10.3 and gfx11?
View attachment 64322View attachment 64323

Holy crap yeah this was added in PAL in Nov 18 2020

Update pal from commit: de257fd · GPUOpen-Drivers/pal@b1e752d

* Support Navi21

github.com

But RDNA2 TD definitely does not do box binning, it sends everything to shader.
Shader has to do everything, manual pretty much states that it returns only the result of box tests. Provide nodes, ray direction, ray origin, inv direction in VGPR and once executed the MIMG op returns sorted nodes in destination VGPR, that's it.
Well, seems RDNA3 is still a mystery after all.

 

[Mopetar]

A theoretical $400 N34 desktop GPU would get killed by The Flood. Not worth it unless they think they can get enough mobile dGPU OEM deals for it. Which right now nVidia pretty much owns.

I don't really see it coming until after the flood subsides. As you point out there's not a lot of point in it financially. I doubt we see it until the latter part of the RDNA3 lifecycle if at all.

Since N32 is modular to an extent there's an easier opportunity for AMD to use the more heavily binned parts for the laptop market. Their APUs are more than good enough for a big chunk of the market.

Perhaps we see it as a pipe cleaner product for 3/4 nm node GPUs.

 

[tomatosummit]

I don't really see it coming until after the flood subsides. As you point out there's not a lot of point in it financially. I doubt we see it until the latter part of the RDNA3 lifecycle if at all.

Since N32 is modular to an extent there's an easier opportunity for AMD to use the more heavily binned parts for the laptop market. Their APUs are more than good enough for a big chunk of the market.

Perhaps we see it as a pipe cleaner product for 3/4 nm node GPUs.

I agree
They can sit on n34 until it's needed and maybe will wait for N4 as it's a pretty high volume mainstream chip to take advantage of a half node.
But how bad is the amd (~6700) flood going to be compared to what nvidia pumped out with great abandon on their samsung node?
There is a possibility of nvidia's flood remaining in the market for much longer that would require an amd response, would it be prudent for a navi34 or making new navi22 cards? Maybe the 6750xt will stick around for longer than it deserves.

 

[biostud]

Or once Intel opens the floodgates of ARC GPUs

 

[Frenetic Pony]

Summary Time based on official information and scouring patents and patch notes (because the leakers should just be considered a joke at this point with how much each and every one of them has double backed and contradicted themselves).

RDNA3:
50% performance per watt boost in ideal situations (almost certainly mobile to mobile comparison).
Much better raytracing performance through new hybrid texture/raytracing unit, probably around/better than(??) Nvidia 3xxx performance.
Much higher power draw on the high end, probably 450(ish) watts for launch at max.
Chiplet based architecture, quite plausibly a bunch of smaller 5nm "compute" chiplets that have all the shader/geo/rt stuff hooked up to one or more "Universal Memory" chips that have the memory bus and possibly media engines(??) might be 6nm, and then more chiplets for SRAM (infinity) cache stacked on top.
4 current models, with lowest end possibly being APU only (possibly still a chiplet for APU version). Unclear how "binning" will work and what constitutes a different "model" with chiplets. Unclear if there's a low end monolithic chip, no guarantees either way.
New CU architecture contributes to better perf/watt, probably contributes to better perf/mm as well.