Wie Gaming-Ampere die verdoppelte Anzahl an Shader-Einheiten erreicht

Mit den Gaming-Lösungen der Ampere-Generation [1] fuhr nVidia bei seinem "GeForce Special Event [2]" schwere Geschütze auf: Mehr als verdoppelte Anzahl an CUDA-Cores (Shader-Einheiten), das 1,7fache an Shader-Rechenkraft samt einer Performance-Projektion von grob dem Doppelten gegenüber Turing. Die vorherigen Annahmen zu Gaming-Ampere lagen zwar bei der Anzahl der gebotenen Shader-Cluster richtig, haben jedoch – bis auf vereinzelte frühere Gerüchte [3] – bis zuletzt jene (mehr als) Verdopplung der FP32-Performance nicht auf dem Plan gehabt. Dabei war es zuerst etwas unklar, wie nVidia dies konkret realisierte: Gerade weil die Tendenz der Grafikchip-Entwickler klar in Richtung kleinerer Shader-Cluster mit (relativ) weniger Recheneinheiten pro Shader-Cluster ging, erschien eine plötzliche Entwicklung in die andere Richtung hin schwer vorstellbar. Genau dies hat nVidia jedoch tatsächlich getan: Die Shader-Cluster (SM) von Ampere tragen laut einer offiziellen nVidia-Aussage auf Reddit [4] nunmehr gleich 128 FP32-Einheiten – anstatt wie bei der vorhergehenden Turing-Generation [5] nur 64 FP32-Einheiten.

The Ampere SM includes new datapath designs for FP32 and INT32 operations. One datapath in each partition consists of 16 FP32 CUDA Cores capable of executing 16 FP32 operations per clock. Another datapath consists of both 16 FP32 CUDA Cores and 16 INT32 Cores. As a result of this new design, each Ampere SM partition is capable of executing either 32 FP32 operations per clock, or 16 FP32 and 16 INT32 operations per clock.
Quelle:  nVidias Tony Tamasi auf Reddit [4] am 2. September 2020

Wie dem nachfolgenden (inoffiziellen) Blockschaltbild zu entnehmen, bezieht sich diese Verdopplung jedoch allein auf die FP32-Recheneinheiten. Die andere Einheiten wurden weitgehend nicht verdoppelt, darunter auch die mit der Turing-Architektur eingeführten INT32-Recheneinheiten. Eine Verdopplung liegt laut nVidia zudem noch beim gesharten Speicher sowie der Anbindung des Level1-Caches vor: Letzterer steigt von 64 auf 128 Bytes/Clock und erzielt damit eine (augenscheinlich gemessene) nahezu-Verdopplung der L1-Bandbreite von 116 auf 219 GB/sec. Bei der Ansteuerung des ganzen musste hingegen nichts verändert werden: Der Scheduler einer SM-Partition (ein Viertel eines Shader-Clusters) konnte schon unter Turing mit 32 Threads umgehen, um ergo die 16 FP32- und 16 INT32-Einheiten einer SM-Partition auch gleichzeitig mit Aufgaben befüttern zu können. Bei Ampere ist diese Eigenschaft sehr wertvoll, damit im Maximalfall die 32 FP32-Einheiten pro SM-Partition bzw. 128 FP32-Einheiten pro insgesamten Shader-Cluster auch wirklich gleichzeitig arbeiten können.

[6]
nVidia Turing SM vs. Ampere SM [7] (abgebildet ist jeweils nur eine Einviertel-Partition pro SM)

Eine beachtbare Einschränkung gibt es aber dennoch: Im reinen FP32-Modus sind die extra INT32-Einheiten dann nicht mehr nutzbar. Konnte Turing noch 64 FP32- samt 64 INT32-Einheiten gleichzeitig pro Takt und Shader-Cluster arbeiten lassen, sind es bei Ampere entweder nur 128 FP32-Einheiten oder 64 FP32- samt 64 INT32-Einheiten gleichzeitig pro Takt und Shader-Cluster. nVidia tauscht somit die 64 INT32-Operationen pro Takt und Shader-Cluster von Turing optional in 64 zusätzliche FP32-Einheiten bei Ampere um – die Gesamtsumme bleibt jedoch bei 128 Rechenoperationen pro Takt und Shader-Cluster. Und dies bedeutet natürlich auch, dass selbst rein nominell und unter bestmöglichen Randbedingungen niemals eine Performance-Verdopplung mit Ampere (auf gleicher Anzahl an Shader-Clustern und gleichen Taktraten) erreichbar sein kann. Faktisch verliert nVidia zuerst einmal den INT32-Vorteil der Turing-Architektur, ehe es zur Verdopplung der FP32-Einheiten geht. Und natürlich kann Ampere dann, wenn im Game-Code INT32-Berechnungen abzuleisten sind, den Vorteil der nominell verdoppelten FP32-Einheiten nicht nutzen.

Für die Turing-Architektur hatte nVidia seinerzeit [8] eine durchschnittliche INT32-Nutzung unter (seinerzeit) aktuellen) Spielen von 36 INT32-Berechnungen pro 100 FP32-Berechnungen angegeben, in Extremfällen wie Battlefield V hinaufgehend auf 50 INT32-Berechnungen pro 100 FP32-Berechnungen. Das Verhältnis dürfte heutzutage irgendwo dazwischen liegen – allerdings ist nicht klar, ob der insgesamt dabei herauskommende Performance-Effekt durch diese zusätzlich ablaufenden INT32-Berechnungen tatsächlich ähnlich groß ausfällt, wie diese Angaben suggerieren. Nachdem, was vom Performance-Sprung zwischen Pascal & Turing bekannt ist, dürften die extra INT32-Einheiten in der Praxis eigentlich kaum etwas ausgemacht haben: Zwischen Pascal und Turing sorgen primär die höhere Anzahl an FP32-Einheiten sowie eine bessere Einheiten-Auslastung durch kleinteilige Shader-Cluster für die bekannte Mehrperformance.

Dagegen sind jedoch andere bremsende Effekt bei Ampere zu beachten: Die Verdopplung der FP32-Recheneinheiten im Shader-Cluster verlagert die Problematik wiederum von Rechenpower auf Auslastung. Denn gingen die letzten nVidia-Architekturen eher in die Richtung von Shader-Clustern mit immer weniger Recheneinheiten und immer mehr Kontroll-Logik zur Erhöhung der Einheiten-Auslastung, geht es nunmehr in die Richtung von blank mehr Recheneinheiten und kaum zusätzlicher Kontroll-Logik (vorbehaltlich dessen, was nVidia noch genaueres zur Ampere-Architektur verlauten läßt). Der neue Ansatz von Ampere geht klar entgegen einer bestmöglichen Auslastung und zugunsten einer höheren Nominal-Performance, welche allerdings in der Praxis kaum wirklich zu erreichen ist. Hieran ergibt sich ganz automatisch, dass von Ampere (auf gleicher Anzahl an Shader-Clustern und gleichen Taktraten) keineswegs eine Performance-Verdopplung erwartet werden kann – selbst dann nicht, wenn genügend Speicherbandbreite zur Verfügung stehen sollte. Faktisch wurden von den bedeutsamen Grafikchip-Komponenten nur die FP32-Einheiten verdoppelt, während die Raster-Engines und mutmaßlich auch die Texturen-Einheiten weiterhin in (normiert auf dieselbe Anzahl an Shader-Clustern) gleichen Anzahl zur Verfügung stehen.

Bezogen auf einen einzelnen CUDA-Core sollte die Ampere-IPC somit bemerkbar gegenüber der Turing-IPC zurückgehen – aber natürlich kann man diesen Nachteil einstecken, wenn man praktisch mehr als eine Einheiten-Verdopplung aufbietet und mittels GDDR6X-Speicher (nur bei GeForce RTX 3080 & 3090) auch eine satte Steigerung der Speicherbandbreite liefert. Insbesondere für den eigentlichen Einsatz-Zweck der Ampere-Grafikkarten ist diese Konstruktion wohl ziemlich gut gelungen, denn RayTracing [9] verlangt nach besonders viel purer FP32-Rechenleistung. Bei echten NextGen-Spielen könnte sich aber auch ohne RayTracing-Einsatz ein ähnlicher Effekt einstellen, dass das Gewicht der FP32-Rechenleistung weiter zunimmt – und es damit zugunsten von Ampere geht. Die Spiele-Entwickler müssen an dieser Stelle im übrigen mitnichten speziell auf diese Ampere-Eigenheiten optimieren, der Effekt ergibt sich ziemlich automatisch bei entsprechend aufwendig gestalteter Spiele-Grafik. Die Ampere-Architektur bzw. der Punkt der verdoppelten FP32-Einheiten ist somit sicherlich eine Veränderung direkt zugunsten von NextGen-Grafik – welche man mit dem anstehenden Start des nächsten Konsolen-Zyklus durchaus erwarten darf.

Nachtrag vom 3. September 2020

Zur kürzlichen Meldung über die verdoppelte Anzahl an Shader-Einheiten bei Gaming-Ampere sind noch zwei relevante Nachträge zu bringen: Zum einen liegt der auf gleicher Anzahl an Shader-Einheiten normierte Performancegewinn zwischen Pascal [10] und Turing [5] augenscheinlich bei ca. +30%, zu ermessen an den fast Hardware-gleichen GeForce GTX 1080 und GeForce RTX 2070 Super Grafikkarten. Ein kleinerer Teil hiervon geht noch weg wegen leicht unterschiedlicher Taktraten und kleineren Hardware-Differenzen, aber grob liegt der auf die reine Anzahl an Shader-Einheiten normierte Turing-Effekt bei ca. +25%. Dies ist dann das, was Turing mittels seiner besseren Shader-Cluster herausholt, welche zum einen mehr Verwaltungslogik führen und zum anderen eben noch die INT32-Einheiten an Bord haben. Doch dies ist dann beachtbar weniger, als was nVidia mit seiner Aussage angegeben hatte, nachdem auf 100 FP32-Berechnungen immerhin 36 INT32-Berechnungen kommen sollen.

Immerhin bleibt die Verwaltungslogik bei der nachfolgenden Ampere-Architektur gleich (oder wird sogar besser), es entfällt allein der Effekt des INT32-Performancegewinns, sofern man den doppelten FP32-Durchsatz aktiviert. Selbiger liegt demzufolge irgendwo in den genannten +25% drin, die genaue Höhe wird sich natürlich kaum jemals ermitteln lassen. Eine grobe Schätzung von +10-20% führt dazu, dass der Rechenleistungs-Zugewinn von Turing zu Ampere auf ca. +65-80% geschätzt werden kann, in diesem Fall normiert auf die Anzahl der Shader-Cluster. Wieviel davon wirklich auf die Straße gebracht wird, bleibt noch abzuwarten – die aktuell herumschwirrenden Benchmarks kommen alle von nVidia selber oder sind unter von nVidia kreierten Bedingungen entstanden (#1 [2], #2 [12] & #3 [13]) und demzufolge schwierig zu werten. Die grundsätzliche Höhe des (derzeit) augenscheinlichen Performance-Zugewinns von Gaming-Ampere läuft jedoch durchaus auf die Möglichkeit hin, jenen realen Zuwachs an Rechenleistung (wie gesagt ca. +65-80%, normiert per Shader-Cluster) nahezu in dieser Höhe auch in der Spiele-Praxis zu sehen.

Der andere Nachtrag betrifft die rein technische Ausgestaltung der Shader-Cluster von Ampere bzw. der dort verbauten Recheneinheiten. Ein im 3DCenter-Forum schreibender nVidia-Mitarbeiter hat hierzu zuletzt wiederholt darauf hingewiesen, dass nVidias Blockschaltbilder und Angaben zur Anzahl an "CUDA-Cores" eher denn schematisch zu sehen sind. nVidias Angaben sollen in Bezug auf die damit erreichbare Rohleistung zwar korrekt sein, aber die eigentliche Hardware-Gestaltung im Silizium weicht wohl doch teilweise von den Blockschaltbildern ab. Denkbar beispielsweise, dass jene CUDA-Cores nicht wirklich einzeln vorliegen, sondern immer Teil eines größeren Rechenwerks sind, welches mehrere CUDA-Cores umfasst. Denkbar auch, dass die einzelnen FP32- und INT32-Einheiten letztlich dieselbe Einheit bilden, welche einfach zu beiden Rechenoperationen (nicht gleichzeitig) in der Lage ist. Inwiefern nVidia hierzu noch genauere Informationen herausgibt, bleibt abzuwarten: Demnächst werden wohl tiefergehende Technik-Artikel zu Ampere auf Basis entsprechender Whitepapers erscheinen, allerdings hat sich nVidia bislang noch nie genauer in die Karten blicken lassen als bis zur Tiefe der Viertel-Partition eines Shader-Clusters.

Nachtrag vom 4. September 2020

Mit dem Freitag-Abend sind erste Technik-Artikel zu Gaming-Ampere seitens ComputerBase [14], Hardwareluxx [15] und PC Games Hardware [16] erschienen, welche über viele Details jener Grafikchip-Architektur aufklären. Damit bestätigen sich auch die zuletzt an dieser Stelle [17] getroffenen Angaben zu den größeren Ampere-Chips GA104 & GA102 – was die zusätzlich getroffenen Angaben zu den kleineren Ampere-Chips GA106 & GA107 nochmals glaubwürdiger macht, selbst wenn jene derzeit nicht offiziell bestätigt sind. Hinzugekommen in der tabellarischen Aufstellung ist nun noch eine Angabe zum Level2-Cache, zudem konnte die Anzahl der RT-Cores bestätigt werden. Wie nVidia die Verdopplung der FP32-Einheiten in den Shader-Clustern realisiert, wurde zwar auch schon an dieser Stelle beschrieben, nVidias offizielles Blockschaltbild eines GA102 Shader-Clusters zeichnet das ganze dann jedoch sogar nochmals eleganter: Der zweite Datenpfad mit FP32 oder INT32 wird einfach als eine (gemeinsame) Einheit abgebildet. Ob dies technisch wirklich so realisiert wurde, ist unklar – aber zumindest ist es somit einfacher verständlich, wo die Differenz in den Shader-Clustern von Turing [5] und Ampere [1] liegt:

[18]
nVidia Turing Shader-Cluster (SM) [19]

[20]
nVidia Gaming-Ampere Shader-Cluster (SM) [21]