Laut Twitterer Kepler_L2 sind für AMDs RDNA3-MCDs erste Einträge in Linux-Treibern aufgetaucht, welche gute Hinweise auf die dahinterliegende Technik liefern. So werden für Navi 31 ganze 6 dieser MCDs genannt, was wohl die Existenz eines 384-Bit-Speicherinterfaces bestätigt. Die MCDs hängen technisch in jedem Fall mit dem Speicherinterface zusammen, ein MCD steht dabei für ein 64-Bit-Teilinterface (6 x 64 Bit = 384 Bit). Bislang war allerdings unklar, ob die MCDs das Speicherinterface auch selber tragen. Die Namenswahl mit "Memory Complex Die" oder "Memory Controller Die" legt dies sicherlich nahe, allerdings konnte man sich bisher ein ausgelagertes Speicherinterface bei Grafikchips nicht so recht vorstellen. Laut Kepler_L2 soll dies allerdings tatsächlich derart passiert: Ein MCD soll ein 64-Bit-Teilinterface tragen – samt 32 MB Infinity Cache:

MCD accidentally leaked in first patch, now renamed to "UMC_Node".
(Link #1 + Link #2)
Quelle:  Kepler_L2 @ Twitter am 13. Juli 2022
 
32MB + 64-bit MC normally, +32MB 3D V-Cache on some models.
Quelle:  Kepler_L2 @ Twitter am 13. Juli 2022

Dies ist allerdings klar der Auslegungs-Teil des Ganzen – im Gegensatz zur Größe des Speicherinterface, womit frühere Gerüchte bestätigt werden. Sehr interessant ist dann auch noch der zweite Teil jener Auslegung: Denn es soll einen optionalen weiteren Infinity Cache geben, welcher in Form von "3D V-Cache" daherkommt – sprich mit draufgepappten Cache-Bausteinen, wie beim Ryzen 7 5800X3D. Damit sollen dann insgesamt 384 MB Infinity Cache bei Navi 31 möglich sein, welcher in der default-Variante allerdings nur 192 MB trägt. Hier bekommt AMD also eine gute Möglichkeit zur Produkt-Differenzierung an die Hand, gleichzeitig wird die Standard-Variante (von Navi 31) etwas billiger herzustellen sein. Wirklich bestätigt ist diese Auslegung natürlich nicht, auch in den von AMD gelieferten Linux-Patches findet sich zu den Punkten Cache-Größe und optionalem 3D V-Cache kein Hinweis.

Auf Navi 32 kann man diese Informationen derzeit leider nur interpolieren, genaueres zu diesem Grafikchip fehlt weitgehend. Aller Vermutung nach ist AMD bei Navi 32 die gleichen Schritte gegangen wie bei Navi 31: Anzahl der Shader-Cluster runter, Taktrate rauf – und dafür auch Speicherinterface hoch und Menge des Infinity Caches nach oben. Navi 32 dürfte demzufolge bei einem 256-Bit-Speicherinterface landen, mit default-mäßig 128 MB Infinity Cache und optional weiteren 128 MB Infinity Cache per 3D V-Cache. Ob dann auch Navi 33 eine Extra-Ladung "Infinity Cache" tragen kann, ist ungewiss, aber eher unwahrscheinlich: Der 3D V-Cache ist bei RDNA3 augenscheinlich zur Verwendung auf den MCDs gedacht – und könnte somit für ein rein monolithisches Design wie Navi 33 technisch bedingt nicht geeignet sein.

Laut nochmals Kepler_L2 kann man sich ein solches Design von GCD und MCD vergleichsweise einfach aufgebaut vorstellen: Ein GCD in der Mitte, die MCDs drum herum angeordnet – fast wie das frühere Design des Fiji-Chips mit seinem HBM-Speicher Seite an Seite zum Grafikchip. Der extra 3D V-Cache dürfte dann auf die MCDs gestappelt sein – schon allein deshalb, weil dort deren Anbindung liegt (beim Ryzen 7 5800X3D wird genauso der 3D V-Cache direkt auf den Chip-Teil mit dem Level3-Cache oben drauf gepappt). Das ganze ist dann Fürwahr ein echtes Chiplet-Design, in der Spitze sollte es somit bis zu 13 Einzelchips bei Navi 31 geben. Für eine Dual-GCD-Variante von Navi 32 könnte es sogar auf bis zu 18 Einzel-Chips hinauslaufen – sofern jenes Konzept jemals realisiert wird.

AMD Navi 31 Varianten ohne/mit extra 3D V-Cache (inoffiziell)
PS: Reines Gedankenspiel, nicht basierend auf offiziellen Daten ... Variante ohne extra 3D V-Cache entnommen von Kepler_L2