2

Gerüchteküche: Aktualisierte (niedrigere) Hardware-Spezifikationen zu AMDs Navi 31 & 32

Nochmals Twitterer Greymon55 hat im Laufe des Tages zuerst kryptische Hinweise und dann klare Worte bezüglich einer Spezifikations-Änderung bei den kommenden AMD-Grafikchips "Navi 31" und "Navi 32" abgegeben. Jene sollten laut schon seit letztem Sommer bekannten Daten ursprünglich mit 60 bzw. 40 WGPs sowie daraus resultierend 15'360 bzw. 10'240 FP32-Einheiten antreten. Zum Tape-Out sind beide Grafikchips dann jedoch mit 48 bzw. 32 WGPs respektive 12'288 bzw. 8192 FP32-Einheiten gegangen – sprich, jeweils um 20% kleiner als ursprünglich erwartet. An den Spezifikationen von "Navi 33" mit 16 WGPs sowie 4096 FP32-Einheiten ändert sich hingegen nichts – wobei jener Chip ursprünglich auch mal mit 20 WGPs gehandelt wurde, die hierbei augenscheinlich genauso vorgenommene 20%ige Abspeckung schlicht nur viel länger bereits bekannt war.

12288
8192
4096

Quelle:  Greymon55 @ Twitter am 2. Mai 2022
 
This is a change to 31 and 32.
33 maintain original specifications.

Quelle:  Greymon55 @ Twitter am 2. Mai 2022
 
My idea is that maybe 15360 was indeed planned at the beginning, but due to scale effect, 12228 was finally chosen as the optimal point to tape out.
Quelle:  Greymon55 @ Twitter am 2. Mai 2022
 
The original target was 75T FP32, although the scale has been reduced, it can still be around 75T at 3GHz now.
Quelle:  Greymon55 @ Twitter am 2. Mai 2022

Oder anders formuliert: Die ursprünglich vorliegenden Hardware-Spezifikationen – welche seinerzeit ohnehin von verschiedenen Quellen derart vermeldet wurden – waren somit nicht Nonsens oder gar "falsch", sondern schlicht ein früherer Design-Entwurf von AMD. Selbigen hat AMD dann allerdings nicht zur Reife des Tape-Outs geführt, sondern sich für eine nominell kleinere Lösung mit 20% weniger FP32-Einheiten entschieden (die "Shader-Engines" und damit Raster-Engines sowie das Speicherinterface bleiben jeweils gleich). Im Fall von Navi 33 drang diese Information bereits vor einiger Zeit durch, bei Navi 31 & 32 dauerte es halt bis jetzt, damit diese Änderung bekannt wurde. So etwas kann passieren, wenn man Spezifikationen von vor dem Designende in die Hände bekommt – jene müssen prinzipbedingt nicht final sein. Die aktuell gemeldeten Spezifikationen müssten hingegen final sein – da zum Tape-Out-Stand gemeldet, nach welchem es (üblicherweise) keine Hardware-Änderungen mehr gibt.

alte Spezifikation neue Spezifikation
AMD Navi 31 6 SE, 60 WGP, 120 CU, 15'360 FP32
256 Bit GDDR6 Speicherinterface
6 SE, 48 WGP, 96 CU, 12'288 FP32
256 Bit GDDR6 Speicherinterface
AMD Navi 32 4 SE, 40 WGP, 80 CU, 10'240 FP32
192 Bit GDDR6 Speicherinterface
4 SE, 32 WGP, 64 CU, 8'192 FP32
192 Bit GDDR6 Speicherinterface
SE = Shader Engine, WGP = Workgroup Processor, CU = Compute Unit (Shader-Cluster)
Anmerkung: Angaben zu noch nicht vorgestellter Hardware basieren auf Gerüchten & Annahmen

Dabei ist diese nominell kleinere Hardware-Lösung keineswegs mit weniger Hardware-Power zu verwechseln. Denn dem alten Design-Entwurf von AMD lagen klar niedrigere Taktraten zugrunde, bis zuletzt wurde Navi 31 auf grob 2.5 GHz Takt eingeschätzt. Laut dem Twitterer lag AMDs Designziel für Navi 31 bei 75 TFlops – welches man mit 15'360 FP32-Einheiten auf 2442 MHz erreicht, mit "nur" 12'288 FP32-Einheiten hingegen auf 3052 MHz. Dies passt zum vorherigen Gerücht von Taktraten knapp oberhalb 3 GHz bei Navi 31 – womit sich letztlich ein ganz einfacher Tausch zwischen alter und neuer Spezifikation ergibt: AMD hat ein paar Hardware-Einheiten weniger gegen höhere Taktraten eingetauscht – mit der Zielsetzung, letztlich dieselbe Rohleistung zu erzielen. Und gelingt dies, ergibt dieser Tausch zudem eine etwas höhere Recheneffizienz – denn höhere Taktraten skalieren immer, während mehr Hardware-Einheiten diesbezüglich immer an gewisse Widerstände stoßen.

Aber natürlich sparen weniger Hardware-Einheiten auch Chipfläche und sind somit aus wirtschaftlicher Sicht immer vorzuziehen – sofern man die höheren Taktraten mit vertretbaren Aufwand erreichen kann und dafür nicht gerade den Stromverbrauch explodieren lassen muß. Abseits dieser Punkte, welche erst später geklärt werden können, liegt mit dieser Spezifikations-Änderung also mitnichten ein tatsächlicher Hardware-Rückschritt vor: Die Anzahl der Hardware-Einheiten fällt zwar wirklich niedriger aus, aber sinngemäß wird dieselbe Performance wie mit dem größeren Hardware-Ansatz angepeilt – dies ist also kein wirklicher Rückschritt. Natürlich kommt es damit nicht zu einem Navi-31-Chip mit 92 TFlops FP32-Rechenleistung, wie es am Wochenende breit kolporiert wurde. Doch war dieser Wert sowieso nur hochgerechnet auf Basis der alten Hardware-Spezifikation samt neuer Taktraten-Angabe – was natürlich nicht zusammenpasst, zu diesem Zeitpunkt jedoch noch nicht offensichtlich war.

Die für AMD somit doch wieder gegenüber nVidia niedrigere FP32-Rechenleistung bringt zudem einen anderen "Problempunkt" wieder ins Lot: Denn bislang kam AMD innerhalb der Ampere/RDNA2-Generation jeweils mit deutlich weniger FP32-Rechenleistung aus, beispielsweise ist die Radeon RX 6900 XT mit nur 23 TFlops minimal schneller als die GeForce RTX 3080 12GB mit (real) ~33 TFlops. Selbiges Verhältnis zieht sich dann durch alle Vergleiche zwischen Radeon RX 6000 und GeForce RTX 30 Grafikkarten. Jetzt dürfte dieses Verhältnis innerhalb der kommenden Ada/RDNA3-Generation sicherlich nicht ganz exakt derart ausfallen – aber dennoch wäre es arg verwunderlich, wenn sich (auf angenommen gleicher TFlops-Zahl) plötzlich ein totales Gleichnis in der Ausnutzung der zur Verfügung stehenden FP32-Rechenpower ergeben sollte. Wenn nach den neuen Spezifikationen Navi 31 bei 71-76 TFlops herauskommt, AD102 hingegen bei 97-107 TFlops und beide Grafikchips grob im selben Performance-Feld spielen, dann sieht dies vom heutigen Erfahrungsstand aus doch deutlich griffiger aus.

AMD RDNA3 FP32-Rechenleistung nVidia Ada
Navi 31
12'288 FP32 @ 2.9-3.1 GHz
= 71-76 TFlops  (–20%) = 97-107 TFlops  (+25%) AD102
18'432 FP32 @ 2.7-2.9 GHz
Navi 32
8192 FP32 @ 2.9-3.1 GHz
= 48-51 TFlops  (–15%) = 55-62 TFlops  (+18%) AD103
10'752 FP32 @ 2.7-2.9 GHz
Navi 33
4096 FP32 @ 2.8-3.0 GHz
= 23-25 TFlops  (–43%) = 39-45 TFlops  (+75%) AD104
7680 FP32 @ 2.7-2.9 GHz
auf nVidia-Seite im Minimum-Wert durchgehend mit kleineren Hardware-Abspeckungen gerechnet
Anmerkung: reine Hochrechnungen auf Basis unbestätiger Hardware-Daten

Nach wie vor bleibt damit auch erhalten, dass für die nachfolgenden Chip-Duelle bereits gewisse Favoriten zu sehen sind: Insofern Navi 31 und AD102 grob bei derselben Performance herauskommen sollten, dann dürfte Navi 32 in seinem Duell mit AD103 einen leichten Vorteil haben – weil bei der reinen FP32-Rechenleistung näher an AD103 heranliegend als Navi 31 an AD102. Navi 33 wird hingegen weiterhin große Problem haben, sich mit dem AD104-Chip zu messen – jener ist geradezu überdeutlich bei der FP32-Rechenleistung von Navi 33 entfernt. Schließlich kommt Navi 33 gerade einmal mit einer ähnlichen FP32-Rechenleistung wie der kleinere AD106-Chip daher – und wird sich damit voraussichtlich eher in der Performance-Mitte zwischen AD106 und AD104 wiederfinden, keineswegs dem AD104 Konkurrenz machen können. Jener Unterschied ist so groß, dass selbiger auch schon zu früheren Zeiten mit inzwischen überholten Spezifikations-Angaben offensichtlich war.

Nachtrag vom 4. Mai 2022

YouTuber RedGamingTech wirft eine weitere denkbare Änderung an den RDNA3-Chips "Navi 31 & 32" in die Runde: Jene könnten beim Wechsel der Spezifikationen auf einen 20% kleineren Hardware-Ansatz auch das zweite GCD verloren haben. Der grundsätzliche MCM-Ansatz würde über die MCDs und eventuell ein extra I/O-Die bestehen bleiben, nur gibt es halt nicht mehr 2x 30 WGP pro GCD, sondern nur 1x 48 WGP in einem einzelnen GCD (bzw. 1x 32 WGP bei Navi 32). Inwiefern dies zutrifft, muß sich später erweisen, generell falsch ist der Ansatz nicht. Immerhin umgeht AMD damit die Skalierungs-Probleme von zwei GCDs, auch der Stromverbrauch für den Daten-Transfer zwischen mehreren GCDs entfällt. Allerdings würde damit das einzelne GCD um so größer und wäre somit der Effekt günstigerer Herstellungskosten durch viele kleine Chiplets nicht mehr zu erreichen.