This part of the pipeline is of variable latency and results are written back asynchronously. Not saying RDNA 3 will or will not do it, but the intersection performance can still be scaled vertically as long as the memory hierarchy can sustain it. Evidently TMU in RDNA1 had doubled the FP16 texture filtering rate (and 4x GCN 1 if my memory served me right), while all macro ratios stayed the same (lane:TMU).
One can also argue that if they are happy to throw xtors at 2x scalar+vector throughput, they might also be inclined to throw xtors at hardware traversal. There is no apparent causation, so extrapolation works both directions.
Putting four SIMDs into a single CU with two CUs in a WGP possibly stretches the crossbars (or ring bus, as you've suggested) and theoretically requires a beefier LDS, along with more L0 cache. It all multiplies.One can also argue that if they are happy to throw xtors at 2x scalar+vector throughput, they might also be inclined to throw xtors at hardware traversal. There is no apparent causation, so extrapolation works both directions.
They could also double the LDS size without doubling the bandwidth (so 4 SIMDs sharing the existing 2 128B/cycle datapaths). This can at least enable more concurrent workgroups on a CU/WGP.
I only see >2x possible with absurd power draw or some type of multi-GPU situation akin to Crossfire.
There is just no way it will be anywhere near 90 TFLOPS in the same vein that a 6900xt is 23.
Yes, I was referring to a beefier LDS. But it sounds like you might be describing a pair of LDSs, each the size of an RDNA 2 LDS, one LDS being private to each CU.
Not private, or else WGP will stop being WGP. I meant a possibility of keeping the current data path arrangement (2 arrays of 32 32B banks; one shared request/response bus per CU; i.e. 4 SIMDs sharing, up from 2 today), while increasing the size of individual banks (1024 entries from 512).
Which is why I shake my head at the continued existence of the WGP + CU combination... Sharding texture L0, TMU and RA within a WGP seems problematic.
Certainly as the count of client SIMDs for LDS increases, this concept of "bank-alignment coalescing" becomes more attractive. Once the GPU is past simple 1:1 mappings for LDS banks, the variable latencies involved make this coalescing more productive, so more clients = more win.
Explain your train of thought. Navi21 with 5120 units is 520mm² and N6 is only a tiny shrink over N7.
I’m no trinibwoy, but in comparison to Navi21 on 7nm, the number of CUs has shrunk by 20%, the memory I/O is halved, and the cache may or may not be halved too (I hope to God not given the memory interface). Since TSMC additionally claims that the 6nm tweak offer 18% higher logic density, the potential for a smaller die than 440mm2 seems to be there. Of course, since we don’t know exactly what RDNA3 adds that may require additional gates, or to what extent, it really is anybodys guess at this point.
It's on N6, pretty cheap/reasonable for that die size.
Well yes, all those cuts and then you add back in the extra RDNA3 increases. It sounds very reasonable to me.
