AMD: RDNA 3 Speculation, Rumours and Discussion

Wow this seems epic. My dream of a ROP-less GPU gets closer. If it truly is ROP-less then that'll make my year.

 

Because it's die space that's doing nothing a lot of the time.

It's similar to how GPUs changed from having dedicated vertex shader ALUs and dedicated pixel shader ALUs, in favour of a unified design. This was done because the old design always led to ALUs sat doing nothing because of an imbalance between vertex compute workload and pixel compute workload. Either the vertex ALUs were fully occupied and the pixel shaders were wasting time, or vice versa.

So ROPs are die space that's spending a lot of time, per frame, doing nothing. Sure, there are bursts of "full utilisation", like shadow buffer fill, but those bursts don't bottleneck the entire duration of frame rendering.

 

Looks like quite a lot of die space to me in Navi 21.

 

Yeah.

+20%

 

Sorry, I made a mistake. That's a picture of Navi 10, not Navi 21.

So, in that picture, the RBEs take up about 20% of the die space used by WGPs, or, an area equivalent to about 8 CUs. Navi 21 has twice the CUs and twice the RBEs, so in Navi 21 it's also 20%.

 

When you say difficult, do you mean algorithm or quantity of work? Is your concern about ordering? Or volume of cache/buffer data required while fragments are in flight?

With some kind of tiled rasterisation, triangle ordering and blending mode is clear before the first fragment shader instruction is issued. That information could live for the lifetime of the fragment, until it is written to the render target. Yes, it's an overhead, but the buffering required to perform tiled rasterisation is already a substantial overhead, what with vertex attributes having an indeterminate lifetime.

I think delta colour compression might be the most fiddlesome aspect of deleted ROPs.

In the end, I'm working on the theory that RDNA 3 GPUs have a fat cache hierarchy (starting at L1, where RDNA currently seems weak) that will support tiled rasterisation and perhaps ray sorting/grouping, so this might extend naturally to ROP-less hardware. It seems to me one of the key mistakes AMD has been making is to keep L1 and LDS separate from each other and effectively to lock them in size - NVidia's floating boundary seems much smarter to me and it seems crucial to tiled rasterisation in those GPUs.

Thinking about it, I'm kind of surprised NVidia hasn't already done a ROP-less consumer GPU (i.e. ignoring data-centre GPUs which might have rasterisers), since robust tiling has been around for so long. Well, as the quantity of compute in a GPU crosses a threshold, then it seems to make no sense to retain ROPs, so Ada/RDNA 3 might be where we see the ROP-less revolution. Fingers-crossed.

Meanwhile, I'm going to assume Arc is just a market-beta GPU, to get Intel past the curse of Larrabee.

 

AMD clearly supports it on D3D. "Performance is bad" is not an excuse for never making performance better. See tessellation. See, hopefully, ray tracing!

Tiling,...

Remember hardware isn't magic. There is no class of algorithms that hardware gets access to that software is entirely blocked from. Even if the algorithm is dependent upon a piece of hardware or is dependent upon a memory layout.

This slide deck is fun:

Implementing old-school graphics chips with Vulkan compute (themaister.net)

He covers the options really nicely and dives into obscure topics such as subgroups and quad_perm on AMD.

AMD GCN Assembly: Cross-Lane Operations - GPUOpen

You would expect AMD to make use of these low-level intrinsics in a ROP-less implementation.

NGG culling replaces hardware culling in RDNA 3. NGG has taken its time but it got there eventually (according to rumours) ...

Yet, somehow, GPUs keep gaining ALU lanes as process nodes improve and the amount of transistors per unit die area increases. And, clock frequencies keep increasing too.

 

We know that a CU in Navi 21 is about 2mm². So 80 of them take about 160mm² (less than 1/3 of the die).

At TSMC, 5nm has a scaling of 84%, "worst case", claimed versus 7nm. So Navi 21 CUs would be 90mm².

So the simple baseline for 12,288 ALU lanes that is the hot topic of current rumours would amount to 216mm². Add 30% for shader engine stuff, such as fine-grained rasterisation, RBEs and L2 cache, to get to 281mm².

Splitting that into two GCDs we get around, say, 150mm² per GCD.

Then I suppose we'd be looking at around 125mm² for each of 4 cache chiplets (assuming they each have about 20mm² of GDDR PHY) and maybe another 150mm² for an IO chiplet (which also has global work scheduling responsibilities), all on 6nm.

So that's about 900 to 950mm² of GPU chiplets, with about 300mm² at 5nm, assuming that 7 chiplets is still the rumour.