Der bekannte Twitterer 'Kepler_L2' zeigt im AnandTech-Forum eine technische Unterlage, welche immerhin 9 Raster-Engines (Shader-Engines) beim gestrichenen RDNA4-Spitzenchip bestätigen. Allgemein wird dies aufgelöst in dieser Form, als dass jener RDNA4-Spitzenchip aus drei GCDs bestehen sollte, welche somit jeweils mit 3 Raster-Engines antreten – somit insgesamt 9 Raster-Engines für den Spitzenchip. Bislang wurde jener gemäß einem früheren Gerücht seitens 'RedGamingTech' als mit insgesamt 144 Shader-Clustern beschrieben, sprich 48 CU pro GCD. Eine weiterführenden Aussage von 'adroc_thurston' im selben AnandTech-Forenthread spricht allerdings von "bedeutsam oberhalb 200" Shader-Clustern. Hierzu kamen schnell Annahmen von möglicherweise 216 Shader-Cluster auf – korrekt sind laut Twitterer All The Watts!! allerdings gleich 288 Shader-Cluster für den sich "Navi 40" nennenden Chip. Somit wurde dies seinerzeit wohl falsch aufgefasst: Es sind nicht 48 CU pro GCD, sondern 48 WGP pro GCD – mit somit 96 CU pro GCD.

Navi32   30WGP(60CU)   256bit   GDDR6
Navi31   48WGP(96CU)   384bit   GDDR6
Navi36   60WGP(120CU)   384bit   GDDR6   ←×
Navi44   16WGP(32CU)   128bit   GDDR6
Navi48   32WGP(64CU)   256bit   GDDR6
Navi41   96WGP(192CU)   256bit   GDDR7   ←×
Navi40   144WGP(288CU)   384bit   GDDR7   ←×
Navi50   >144WGP(288CU)   >384bit   GDDR7   ←RDNA5
Quelle:  Kenjin Yoshi @ Twitter am 28. April 2024 — in Erklärung des Tweets von All The Watts!!, samt eigener Korrektur bei "Navi 50"
Hinweis: Das × zeigt letztlich gestrichene Chips an.

Dies macht es nochmals mehr schade, dass AMD dieses MultiChip-Projekt gestrichen und mittels "Navi 48" stattdessen eine monolithische Midrange-Lösung angesetzt hat, in absoluter Nichtbesetzung des HighEnd-Segments innerhalb der Radeon RX 8000 Serie. Schließlich ist die Differenz zwischen ursprünglichem Plan und letztlicher Realisierung nunmehr ganz enorm: Geplant war RDNA4 einstmals auf bis zu 288 Shader-Cluster, realisiert wird es nunmehr auf bis zu 64 Shader-Cluster. Dabei dürfte das Problem weniger in der Anzahl der Shader-Cluster gelegen haben, sondern der MultiChip-Ansatz war wohl nicht in der gewünschten Zeit marktreif zu bekommen, AMD hat jenen somit auf RDNA5 vertagt und als "Plan B" bei RDNA4 nur das allernötigste realisiert, was in der Kürze der Zeit möglich war. Wahrscheinlich steht hier auch die Absicht AMDs im Raum, die RDNA4-Grafikkarten später im RDNA5-Zeitalter weiterbenutzen zu können, sich bei RDNA5 dann rein nur noch auf MultiChip-Konstrukte zu konzentrieren.

An dieser Stelle liegt wohl der einzige Fehler der vorstehend abgebildeten Daten-Interpretation seitens Twitterer Kenjin Yoshi vor: Im Original von All The Watts!! werden die Spezifikationen zu "Navi 50" nicht exakt notiert, sondern es wird nur gesagt: "größer als Navi 40" – sprich mehr Shader-Cluster als 288. Inwiefern AMD dies (nach dem Fehlschlag der ursprünglichen RDNA4-Pläne) tatsächlich realisiert, steht auf einem anderen Blatt. Vielleicht versucht man erst einmal, das kleinere Brötchen zu backen und letztlich nur diese bereits für Navi 40 geplanten Spezifikationen dann für Navi 50 zu realisieren. Das wahrscheinlich wirklich treffende Vorzeichen wäre somit "≥" – und nicht ">". Hardware-Enthusiasten würden sicherlich gern sehen, was AMD mit einem Grafikchip mit 288 Shader-Clustern aka 36'864 FP32-Einheiten (nach FP32-Verdopplung) ausrichten kann. Und auch wenn sich diese Meldung letztlich um gestrichene Chip-Projekte handelt (wie auch "Navi 36", welcher im übrigen wiederum von 'RedGamingTech' korrekt vorhergesagt wurde), so kann man hieraus zumindest die grobe Entwicklungs-Richtung von Navi 50 bzw. der RDNA5-Chipfamilie mitnehmen.

Der YouTube-Kanal von Hardware Unboxed hat sich die Performance-Auswirkungen von Intels "Baseline-Profil" zugunsten der Stabilitäts-Probleme von Prozessoren der 13. & 14. Core-Generation angesehen. Hierbei kam einmal die Asus- und einmal die Gigabyte-Ausführung zum Einsatz – wobei immer noch nicht 100%ig klar ist, ob die Gigabyte-Ausführung mit einem PL2 von nur 188 Watt überhaupt korrekt ist im Sinne dessen, dass Gigabyte dies so wollte. Insofern ist nicht sicher, ob die Benchmarks zu Gigabytes Baseline-Profil wirklich wertbar sind. Jene schlagen schließlich auch im Spiele-Feld deutlich zu, mit einem gemittelten Performance-Verlust von über –11% bei den Minimum-Frameraten. Das Baseline-Profil von Asus, welches zumindest dem Augenschein nach eher der Intel-Spezifikation entspricht, kommt da mit knapp –5% wesentlich besser weg. Dies wäre wohl verzeihbar, wenn nicht die Multithread-Performance bei Anwendungs-Benchmarks bemerkbar schlechter ausfallen würde, auch hier gibt es (bei Asus) wieder einen Abschlag von –9% unter dem Cinebench 2024.

Beide Effekte zusammengenommen lassen sich schwer als "marginale Differenz" wegwischen – womit Intel inzwischen voll drin ist in der Diskussion, inwiefern man nicht eigentlich mit den letzten Prozessoren-Veröffentlichungen sowohl Fachpresse als auch Anwender über die wahre Performance in die Irre geführt hat. Rein de jure kann sich Intel aus dieser Frage immer herauswinden, denn gemäß eines 2019er Interview mit Intel-Fellow Guy Therien gegenüber AnandTech betrachtet Intel den Betrieb mit seitens des Mainboard-Hersteller hochgesetzten Spezifikationen als "in-spec", somit kein Overclocking und damit innerhalb der Garantie liegend. Dies bedeutet auch, dass wenn man auf einem anderen Mainboard mit eventuell demselben CPU-Exemplar dieselben Settings manuell einstellt, dies dann de-jure Overclocking ist und damit außerhalb der Garantie liegt. Was hier Overclocking und was hier "in-spec" ist, entscheiden somit Intel und der Mainboard-Hersteller gemeinsam – was immer bedeutet, dass die default-Settings eines bestimmten Mainboards als "in-spec" gelten, egal wie hoch jene liegen mögen.

We’re going to be very crisp in our definition of what the difference between in-spec and out-of-spec is. There is an overclocking 'bit'/flag on our processors. Any change that requires you to set that overclocking bit to enable overclocking is considered out-of-spec operation. So if the motherboard manufacturer leaves a processor with its regular turbo values, but states that the power limit is 999W, that does not require a change in the overclocking bit, so it is in-spec.
Quelle:  Intel-Fellow Guy Therien gegenüber AnandTech, veröffentlich am 25. Juli 2019

Damit bekommt Intel womöglich das Problem vom Tisch, dass frühere Benchmark-Werte jetzt eventuell als "erschummelt" angesehen werden. Die Stabilitäts-Probleme werden mit dieser Erklärung jedoch nicht gelöst – und wenn tatsächlich das Baseline-Profil die Lösung sein soll, dann fängt die Sache erneut von vorn an bzw. befindet sich Intel in einem Zirkelschluß, wo die Lösung des einen Problems automatisch das andere Problem auslöst – und umgekehrt. Ganz besonders dann, wenn Intel tatsächlich das Baseline-Profil zum neuen default-Standard machen will, wird es kritisch: Denn was aus Stabilitäts-Sicht derzeit von sehr vielen Nutzern gefordert wird, verändert die Prozessoren-Performance (zumindest die der Spitzen-Modelle) nicht unerheblich, womit sich deren Anwender dann fragen können, wo die schönen Performance-Versprechen der seinerzeitigen Launch-Reviews geblieben sind. Wenn selbige dann nur noch in einem unsupporteten Modus zu erreichen wären, welcher faktisch Overclocking und damit Garantie-Verlust darstellt, winken schon die Sammelklagen.

Eine denkbare Auflösung hierzu wäre, wenn Intel sein Baseline-Profil als neuen default-Standard durchsetzt, die Mainboard-Hersteller aber das Recht bekommen, eigene Profile zu definieren, welche von der Garantie abgedeckt sind. Damit könnten jene Nutzer ohne Stabilitäts-Probleme (sicherlich die große Mehrheit) weiterhin diejenigen Einstellungen nutzen, die der Mainboard-Hersteller als zweckmäßig ansieht, welche jener ausgebiebig getestet hat und selber auch Garantie darauf gibt. Etwas Pech haben die Nutzer mit Stabilitäts-Problemen, jene müssten Intels Baseline-Profil nutzen und hätten somit in der Silizium-Lotterie einfach eine Niete gezogen. Zumindest wäre jenen Nutzern dann aber wieder ein stabiler PC-Betrieb möglich, was eigentlich den wichtigeren Punkt darstellt. Davon abgesehen findet Intel vielleicht noch einen besseren Weg als das Baseline-Profil – oder aber man kann die eigentliche Ursache dieser instabil laufenden Prozessoren erkennen und mit einer wirklich zielgerichten Lösung bekämpfen.