Twitterer Kepler_L2 hat nun auch noch die Mengen an Infinity Cache für die ersten drei RDNA4-Grafikkarten offengelegt – welche auf 64, 64 & 48 MB lauten. Anders formuliert bekommt die erste Salvage-Version noch dieselbe Menge an Infinity Cache wie das Spitzen-Modell, die zweite Salvage-Version mit abgespecktem Speicherinterface muß hingegen auch mit einem kleineren Infinity Cache auskommen. Denkbarerweise sind beide Chip-Teile auch technisch miteinander gekoppelt, so dass eine Abspeckung beim Speicherinterface diesen Schnitt beim Infinity Cache automatisch nach sich zieht. Zudem bestätigt diese Information letztlich nochmals den Punkt, dass diese drei RDNA4-Grafikkarten allesamt Navi-48-basiert sein werden: Denn 48 MB Infinity Cache wäre für den Navi-44-Chip eindeutig zu viel, wenn das Spitzenmodell von Navi 48 "nur" bei 64 MB stehen soll. Gemäß früheren Informationen ist Navi 44 im übrigen mit 32 MB Infinity Cache zu erwarten.

64
64
48
Quelle:  Kepler_L2 @ X am 27. August 2024

Damit kann nachfolgende Portfolio-Austellung zur Radeon RX 8000 Serie um ein weiteres Hardware-Detail bereichert werden. Interessanterweise beißt sich bisher keines der zuletzt aufgetauchten Leaks grundsätzlich mit den früheren Gerüchten zum einen von Twitterer 'All The Watts!!' und zum anderen erst jüngst von YouTuber 'Moore's Law Is Dead'. Einzig kann man sagen, dass letzterer sich die Möglichkeit zu einem größeren Infinity Cache (≤96MB) herausgenommen hatte – worin die nun berichteten 64 MB aber rein technisch durchaus hineinpassen. Die Differenz beider früheren Gerüchte liegt viel eher in der Performance-Erwartung, worauf 'All The Watts!!' komplett verzichtete, man jedoch allgemein einen eher maßvollen Performance-Sprung (gegenüber Navi 32) erwartete, während 'Moore's Law Is Dead' ein (gemäß der Hardware-Ansetzung) vergleichsweise hohes Performance-Level für Navi 48 prognostizierte.

Passend hierzu hat sich dann sogar noch Twitterer All The Watts!! mit einer der typisch kryptischen Spezifikations-Angaben gemeldet, mittels welcher alles vorstehende nochmals untermauert wird und zudem auch noch ein weiteres Detail abfällt: Die Datenrate der größten Navi-44-Lösung soll bei 18 Gbps liegen. Im übrigen deuten die damit zuletzt in großer Häufigkeit aufgetauchten RDNA4-Leaks darauf hin, dass AMD nunmehr seine rein internen Tests zu RDNA4 abgeschlossen hat und die Arbeit mit seinen Grafikkarten-Partnern aufnimmt – was nachfolgend üblicherweise in solcherart Leaks resultiert. Damit scheint AMD durchaus auf dem Weg, erste RDNA4-Grafikkarten tatsächlich vielleicht noch dieses Jahr realisieren zu können. Versprochen werden kann dies damit aber nicht, dafür fehlen noch genauere Anhaltspunkte, bei welchem Schritt im Release-Zeitplan zur Radeon RX 8000 Serie man derzeit gerade steht.

Daneben hatte 'All The Watts!!' den vorgenannten Tweet auch noch um Daten zu den AMD-APUs "Strix Halo" und "Sonoma Valley" angereichert, ein Nachtrag enthält dann Daten zu "Kraken Point". Jene Tweets sind teilweise schwer zu lesen, offenbar sind hier auch Angaben zur Anzahl der CPU-Kerne sowieso zum offiziellen Speicher-Support enthalten. Letztlich hat sich eine vernünftige Auflösung zu diesen Zahlenketten finden lassen, mit einer Auslassung: Die zweite Zahl zu Strix Halo ("04") ist nicht wirklich zuordenbar. Gemäß dem zu sehenden Schema bei den anderen beiden APUs könnte es sich um zusätzliche Dense-CPU-Kerne handeln – was allerdings angesichts bereits 16 vorhandener Performance-Kerne leicht übertrieben erscheint und zudem bislang auch von keinem anderen Gerücht zu "Strix Point" jemals erwähnt wurde. Wahrscheinlicher ist somit, dass sich hierfür noch eine andere Aufklärung findet.

Im Zuge der neuen Quartalszahlen hat nVidia dann doch eine gewisse Verzögerung bei HPC/AI-Blackwell zugegeben – etwas, was man vorher noch energisch abgestritten hatte. Aber auch die neue offizielle Sprachregelung ist auf maximale Beruhigung ausgerichtet und muss somit faktisch übersetzt werden, um zum wahren Kern vorzustoßen. Denn die "neue Fertigungs-Maske" zugunsten einer besseren Fertigungsausbeute hat man nicht aus Lust & Laune aufgelegt, schließlich verschiebt so etwas den gesamten Zeitplan üblicherweise um grob ein Quartal. Vielmehr war vorher die Fertigungsausbeute wohl derart niedrig, dass man sowieso nicht wirklich gut lieferbar gewesen wäre – weswegen man lieber zum Mittel der bewußten Verzögerung zum Zweck später besseren Lieferbarkeit greift. Denkbarerweise gab es damit (wohl) keinen Fehler im eigentlichen Blackwell-Design, dafür musste nVidia aber an der Maske selber herumdockern – denkbarerweise wurden Abstände verändert, Massetransistoren hinzugesetzt, eventuell auch mehr Redundanz verbaut und ähnliche Maßnahmen, die nichts an der Architektur ändern.

We executed a change to the Blackwell GPU mask to improve production yields.
Quelle:  nVidias CFO Colette Kress gegenüber Analysten am 28. August 2024, wiedergegeben von Lithos @ X
 
The change to the mask is complete. There were no functional changes necessary.
Quelle:  nVidias CEO Jenen Huang gegenüber Analysten am 28. August 2024, wiedergegeben von The Motley Fool

Prinzipiell ist dies also das gleiche, als hätte nVidia ein neues Chip-Stepping aufgelegt – auch dies bedingt eine neue Maske und muß zumindest teilweise wieder neu validiert werden. Bis dies erledigt ist, hat nVidia immerhin noch die laufende Fertigung mit der vorherigen Blackwell-Chipfertigungsmaske bzw. deren Produktionsergebnis – dies reicht, um Samples zu den nVidia-Partnern zu schicken, was somit die Zeitplanverzögerung reduzieren hilt. Für die Massenauslieferung von HPC/AI-Blackwell wird nVidia dennoch mit grob einem Quartal Verzögerung rechnen müssen, ganz wie es die Gerüchte bereits kundgetan hatten (und nVidia es seinerzeit dementierte). Wie damals schon erwähnt, hat dies alles nichts mit "Consumer-Blackwell" auf Basis der "GB20x"-Grafikchips zu tun, welche die GeForce RTX 50 Grafikkarten-Serie bilden werden. Jene weisen auch keine so großen Chips auf wie im HPC/AI-Segment auf (oberhalb 800mm²) und dürften daher kaum in derartige Probleme mit der Fertigungsausbeute laufen.