Die Launch-Analyse zu Ryzen 5000G wurde auf Seite 2 mit ein paar weiteren Werten zur iGPU-Performance samt (nachfolgend abgebildeter) Performance-Vergleichstabelle aktualisiert. Die neu hinzugetragenen Werte kommen von GeForce GT 1030 sowie Radeon RX 550 – und helfen somit, die bisherige Performance-Einordnung der Ryzen 7 5700G iGPU im 3DCenter FullHD Performance-Index mit weiterem Zahlenmaterial etwas solider zu gestalten. Auch die neuen Werte deuten letztlich darauf hin, dass die Ryzen 7 5700G iGPU grob dem Performance-Bild einer GeForce GTX 750 Ti (210%) entsprechen sollte – und damit knapp über den untersten Einsteiger-Lösung Radeon RX 550 & GeForce GT 1030 herauskommt, welche AMD und nVidia rein praktisch bis jetzt noch vertreiben (sofern verfügbar), trotz dass deren Architektur-Unterbau inzwischen schon reichlich älter ist.

Gegenüber aktuellen Gaming-Einstiegslösungen ist die Performance der besten iGPU am Markt natürlich mindestens um den Faktor x2 zurückhängend, gegenüber dem (zukünftig) kleinsten Modell von RDNA2 & Ampere läuft es wahrscheinlich eher mindestens auf Faktor x3 hinaus (Navi 24 mit nur 16 Shader-Clustern an einem 64-Bit-Interface dürfte kaum schneller als eine Radeon RX 5500 XT herauskommen). AMDs NextGen-APU bei "Rembrandt" mit 12 Shader-Clustern der RDNA2-Architektur dürfte hierauf dann einiges oben drauf legen können, kommt aber sicherlich auch erst in Verbindung mit DDR5-Speicher so richtig aus dem Startblock. Mittels der neuen Speichersorte sollten sich die APUs zumindest kurzfristig etwas näher an die Performance von Desktop-Grafikkarten heranrobben können – bis dann die 5nm-Generation ab Ende 2022 antritt und den Performance-Horizont von Desktop-Grafikkarten wiederum maßgeblich verschieben wird.

In Ergänzung der News von letzten Freitag soll noch auf eine andere Auslegungsform zum MCD von Navi 31/32 hingewiesen werden, welche sich aus der Foren-Diskussion zur Meldung ergab: Danach kann man die zugrundeliegende Formulierung "fuckton of MCD" nicht nur in Richtung mehrerer Einzelchips auslegen – sondern auch in Richtung einer großen Cache-Menge auf allerdings einem Einzelchip. Die in der Freitags-News dargebrachte Auflösung eines MCD bestehend aus mehreren Einzelchips ist damit keineswegs so sicher, wie dort notiert wurde – beide Möglichkeiten existieren weiterhin. Natürlich würde eine Aufsplittung in Einzelchips aus der Sicht einer höheren Yield-Rate in der Chipfertigung besser kommen und entspricht auch sonst AMDs Tendenz, die Chips so kleinteilig wie möglich aufzuteilen – aber es sind halt auch andere Auslegungen denkbar und damit nicht vom Tisch.

MCDs are the cache dies.
Two GCD and fuckton of MCD.
Quelle:  Bondrewd @ Beyond3D-Forum am 1. August 2021

Beispielsweise ergab sich aus der Foren-Diskussion ein interessanter Ansatzpunkt, wie man das GCD von Navi 31 doch noch für Navi 32 weiterverwenden könnte: Normalerweise gibt es für eine Salvage-Lösung keinerlei extra Chipnamen, sondern nur andere Chipversionen (Navi 31 XT, Navi 31 XL). Doch in diesem Fall könnte man eine Salvage-Lösung des Navi-31-GCDs mit einem eigenen, nur für Navi 32 verwendeten MCD kombinieren – und dann würde sich wiederum der extra Chipname "Navi 32" rechtfertigen, weil wenigstens zum Teil ein nirgendwo anders benutzter Chip (das N32-MCD) eingesetzt wird. Aus Sicht der Kostenlage erscheint diese These jedoch eher grenzwertig, denn damit würde man zwei GCDs um jeweils –33% beschneiden, nur um einen eigenen, etwas kleineren MCD einsetzen zu können. Den wenigsten Verschnitt hat nach wie vor die Auflösung von zwei unterschiedlichen GCDs bei Navi 31 & 32 sowie MCDs aus Einzelchips, womit die jeweiligen Spitzenlösungen gänzlich ohne deaktivierte Chipteile auskommen können.

An der grundsätzlichen Hardware-Power der drei Navi-3X-Chips ändern diese Diskussionen zur Auslegungen der Chip-Gestaltung im übrigen nichts – jene dienen eher dem besseren Verständnis, was AMD hierbei genau macht. Generell wird Navi 33 somit ein monolithischer Chip mit 5'120 FP32-Einheiten. Darüber gibt es dann nur noch Chiplets aus jeweils 2 GCDs und eben dem bewußten MCD. Dabei soll Navi 32 mit 10'240 FP32-Einheiten gegenüber Navi 33 die nominelle Hardware-Power glatt verdoppelt, während Navi 31 mit 15'360 FP32-Einheiten "nur" noch +50% auf Navi 32 oben drauf legt. Diese Aufteilung mag auf den ersten Blick wenig symetrisch aussehen, hat aber eventuell zwei Begründungen: Erstens könnten die MCM-Konstrukte nicht ganz so effektiv wie der monolithische Chip sein, womit man unter MCM-Bedingungen eventuell etwas mehr FP32-Einheiten für dieselbe Performance ansetzen muß.

Und zweitens ist es sogar ziemlich üblich, bei den kleineren Chips im Portfolio glatte Hardware-Verdopplungen anzusetzen, den absoluten Spitzenchip dann hingegen mit geringerem Abstand zum zweitkleinsten Chip auszuführen. Ein perfektes Beispiel hierfür ist nVidias Maxwell-Serie, wo zwischen GM206 und GM204 eine Verdopplung der FP32-Einheiten vorliegt, der für Ti- und Titan-Karten verwendete GM200-Chip hingegen nur +50% mehr FP32-Einheiten gegenüber dem GM204 aufweist. Sicherlich könnte man dies auch anders (mehr symetrisch) gestalten, aber dann müsste entweder der Spitzenchip in technisch schwierig zu beherrschende Größenklassen gehen – oder halt der zweitbeste Chip deutlich kleiner werden, welcher jedoch oftmals wichtig ist für den Wettbewerb der Grafikchip-Entwickler untereinander. AMDs Aufteilung der Navi-3X-Chips macht so gesehen sehr viel Sinn: Navi 33 dürfte grob die Performance von Navi 21 bieten, Navi 32 bringt die Generations-typische Performance-Verdopplung – und Navi 33 setzt dem ganzen (Titan-mäßig) einen oben drauf.