Grafikkarten-Generationen im Test: Testergebnisse und Architekturunterschiede

Leistung in 1.920 × 1.080 und 2.560 × 1.440

Bevor ein kleiner Deep Dive der Veränderungen von GCN5 nach RDNA 3 folgt, geht dieser Abschnitt auf die Leistungsunterschiede in Full HD und WQHD ein. Diese Leistungsunterschiede sind in der Folge für die kurze Erläuterung der Architekturunterschiede wichtig und veranschaulichen, was bestimmte Änderungen zwischen den Generationen bewirkt haben.

Zu sehen ist, dass es von der Vega 56 bis hin zur 6700 XT relativ normale Generationssprünge von bis zu 37 Prozent gibt – in gewissen Spielen verhält sich das anders, darauf wird separat eingegangen. Erst die 7800 XT legt einen großen Sprung von fast 60 Prozent hin. Auffällig ist, dass der Sprung zwischen der 6700 XT und 7800 XT in WQHD mit 59 Prozent größer ist als mit 50 Prozent in Full HD – und auch das hat seine Gründe. 5700 XT und 6700 XT legen in Full HD bei den Durchschnitts-FPS ähnlich gut zu wie in WQHD.

Änderungen GCN 5 zu RDNA 1

Die 5700 XT verliert zur Vega 56 ca. 29 Prozent an Shadern (2.560 gegen 3.584) und baut beim Takt zwischen 30 bis 40 Prozent auf. Am Ende gleicht das den Verlust an Rechenleistung fast aus und die Vega 56 ist auf dem Papier nur ca. 7 Prozent schneller (TFLOPS). Dennoch ist die 5700 XT in Spielen im Mittel 36 Prozent voraus bei den Durchschnitts-FPS und kann auch um 30 Prozent bei den Perzentil-FPS zulegen. Warum?

Das soll kein ausführlicher Deep Dive werden, doch die Unterschiede erklären. Die Hauptunterschiede sind im Treiber und im Aufbau der Compute-Unit (CU) zu suchen.

GCN brachte 2012 eine CU, die aus vier Textureinheiten besteht, dazu kommen eine Skalar-ALU und vier Vektor-ALUs. Die Vektor-ALUs können 16 × 32 Bit (SP-FP) zur gleichen Zeit berechnen. Natürlich müssen die 16 Werte den gleichen Operator haben, sonst funktioniert das nicht.

AMD hatte zu diesem Zeitpunkt den Treiber auf Wave64 aufgebaut. Wave bezeichnet bei AMD, wie viele Werte pro Befehl zusammenkommen müssen. Für die Neugierigen unter euch: Nvidia nennt das ganze WARP.

Wer aufgepasst hat, kommt pro CU auf 64 Shader (4 × 16) und es erscheint logisch, dass eine CU einen Wave64-Befehl pro Takt abarbeiten kann. Das ist allerdings falsch. Ein Wave64-Befehl wird auf je einer Vec16-ALU ausgeführt – und das in vier Takten. Pro CU werden für die volle Auslastung also vier Wave64-Befehle benötigt. Diese Situation führte folglich dazu, dass GCN im Allgemeinen und speziell auch Vega immer ein Auslastungsproblem hatten und ihre Rechenleistung nie in FPS umsetzen konnten.

Mit RDNA ist AMD diese Probleme angegangen und hat sowohl den Aufbau der GPU allgemein als auch die Struktur der CU geändert. So löste RDNA das ROP-Limit (Raster-Operation-Pipeline), das bis dahin relativ starr bei 64 lag. Das wirkt sich allerdings erst bei RDNA 2 aus. Interessanter sind die Änderungen im Treiber (was die anfänglichen eher instabilen Treiber erklärt) und in der CU.

Die Umstrukturierung der CU bestand darin, dass die vier Vec16-ALUs durch zwei Vec32-ALUs ersetzt werden, und es kam eine zweite Skalar-ALU hinzu. Statt wie bisher vier Wave64-Befehle pro CU werden nur noch zwei Wave64-Befehle benötigt. Ebenso sinken die benötigten Takte von 4 auf 2. Dazu kommt, dass ein Wave64-Befehl, der weniger/gleich 32 Werte hat, in einem Takt ausgeführt werden kann.

Neben diesem Umbau in Hardware war AMD 2019 bemüht darum, den Treiber von Wave64 auf Wave32 umzubauen.

All diese Änderungen führten dazu, dass sich die 5700 XT trotz nominell niedrigerer Rechenleistung sowohl von der Vega 64 als auch eben von der Vega 56 absetzen kann.

Änderungen RDNA 1 zu RDNA 2: Takt und Cache helfen

Während der Wechsel von GCN5 zu RDNA 1 wirklich radikal war, ist der nun folgende Schritt überschaubar. Die 6700 XT kann sich in diesem Test um ca. 35 bis 45 Prozent absetzen und das kommt fast ausschließlich durch die Taktsteigerung von ebenjenen 33 bis 44 Prozent – je nach Ausgangsbasis.

Die große Überraschung war der Infnity-Cache von 96 MB. Dieser verhalf RDNA 2 zu einem ordentlichen Sprung bei der Effizienz, obwohl die 5700 XT und die 6700 XT im N7-Prozess bei TSMC vom Band liefen. Egal ob CPU oder GPU: Speichertransfers kosten nicht nur Zeit, sondern sind auch energieintensiv.

Abseits des Infinity-Caches brachte RDNA 2 noch die RT-Kerne, um die geht es in diesem Test aber nicht.

Als Ganzes betrachtet ist die RDNA-2-Generation langweilig und es verwundert auch nicht, dass RDNA 2 knapp ein Jahr nach RDNA erschien. Es ist wahrscheinlich, dass RDNA ein Zwischenschritt war, dass AMD den Treiber für RDNA 2 also finalisieren konnte.

Änderungen RDNA 2 zu RDNA 3: Etwas Terascale, bitte!

Erst Navi 32 kann sich wirklich stark vom Vorgänger absetzen. 50 Prozent mehr Shader schlagen immer durch. Der Takt nimmt etwas ab, das kann allerdings vernachlässigt werden. 50 Prozent mehr Shader (nominell) reichen am Ende für eine Leistungssteigerung von 45 bis 65 Prozent. Ein guter Wert.

Bereits in der Tabelle finden sich dabei zwei Angaben zu den Shadern der Navi 32: einmal die 3.840 und in Klammern die 7.680. Welche der beiden Zahlen ist denn nun richtig? Beide. Denn anders als bei Nvidia mit Ampere können 3.840 der 7.680 Shader nicht einfach so genutzt werden, sondern es müssen einige Umstände zutreffen. Und hier schließt sich der Kreis zur anfangs angeprochenen Terascale-Architektur.

AMD hat mit RDNA 3 in den Vec32 einen zweiten Pfad eingeführt. Die neuen Vec-ALUs verhalten sich unter bestimmten Umständen wie eine Vec64-ALU, eine Vec32+32-ALU oder eine Vec32-ALU – je nach Situation und abhängig davon, was so an Wave-Befehlen kommt. Entsprechend kann RDNA 3 in bestimmten Szenarien auch mehr zulegen, als es die 50 Prozent mehr an CUs/Shader darlegen.

Eine Vec32-ALU kann einen Wave64-Befehl jetzt in einem statt in zwei Takten abarbeiten. Das kann in Zukunft gerade beim Raytracing immer wichtiger werden. Sollte es keinen Wave64-Befehl geben, kann die neue ALU theoretisch zwei Wave32-Befehle bearbeiten, das unterliegt allerdings einigen Limitierungen. Der Einfachheit halber werden die Limitierungen an dieser Stelle nur grob umrissen. Es können nur FP32/SP-Berechnungen durchgeführt werden. Um zwei Berechnungen durchzuführen, müssen sie im selben Kontext stattfinden und dazu voneinander unabhängig sein.

AMD bezeichnet die neuen Vec32-ALUs als Dual-Issue-VALU. Es gibt X- und Y-Operation, die zur gleichen Zeit ausgeführt und in einer Vector-Operation (VOP) verpackt werden. Ein Konzept, das aus Terascale-Zeiten bekannt ist. Der Compiler für RDNA 3 erzeugt ein „Very Long Instruction Word“ aus zwei unabhängigen Operationen: VLIW2.