AMD Radeon HD 7970 im Test: Powerprotz mit Paperlaunch

Auch wenn heute mit der Radeon HD 7970 die erste Grafikkarte erscheint, die auf AMDs neuer Graphics Core Next Architektur basiert, sind die Details dieses neuen Designs schon länger bekannt. Um Entwicklern genügend Zeit zu geben, ihre Software bestmöglich auf die neue Hardware anzupassen, stellte AMD die GCN-Architektur bereits im Juni auf dem Fusion Developer Summit 2011 vor. Laut Eric Demers, CTO von AMDs Grafiksparte, hätte man auch die Very Long Instruction Word (VLIW) Architektur, die mit der Radeon HD 2000 eingeführt wurde, noch weiter verfeinern können, um aus ihr noch mehr Grafikperformance herauszuholen. Doch gerade bei GPGPU-Berechnungen war das Potenzial des VLIW-Ansatzes beschränkt. Anstatt also eine alte Technologie nochmals aufzubohren, entschied man sich, in eine völlig neue Architektur zu investieren.

Doch auch wenn sicherlich niemand etwas gegen eine höhere Rechenleistung und zusätzliche Flexibilität einzuwenden hat, erwartet man von High-End Desktop-Grafikkarten nach wie vor zuallererst hohe Gaming-Performance und gute Darstellungsqualität. Für AMD lautete die Herausforderung deshalb, eine GPU mit weiter gefasstem Aufgabenfeld zu entwickeln, dabei aber auch die 3D-Performance zu erhöhen. Um das zu erreichen, musste man sich von der VLIW-Architektur abwenden und etwas Neues entwickeln: Graphics Core Next.

Graphics Core Next ist effizienter

AMDs VLIW-Architektur ist sehr effizient, wenn es darum geht, Grafikberechnungen auszuführen. Ihr Compiler ist darauf hin optimiert Sklalarberechnungen abzubilden, wie sie z.B. für Matrix-Vektor-Multiplikationen in 3D-Transformationen häufig benötigt werden. Eine Schwäche offenbart sich aber dann, wenn skalare Berechnungen anstehen, wie sie in allgemeineren Berechnungen zu finden sind. Der Compiler muss dann eine Menge Aufwand betreiben, um den Code bestmöglich zu optimieren. Dabei muss er sich ab und an auch auf Vermutungen stützen.

Manchmal kommt es aber vor, dass eine Befehlsliste, auch Wavefront genannt, nicht ausgeführt werden kann, bis eine andere Wavefront abgearbeitet worden ist. In diesem Fall spricht man von einer Abhängigkeit. Das Problem besteht nun darin, dass der Compiler die Warteschlange der Wavefronts im Nachhinein nicht mehr umsortieren kann, und so verliert man oft wertvolle ALU-Rechenzeit, während Befehle darauf warten, dass Abhängigkeiten aufgelöst werden. 

Im folgenden theoretischen Beispiel sehen wir, wie eine Radeon HD 6970 mit seiner VLIW4-SIMD-Einheit und deren je 16 Shader-Prozessor-Gruppen eine Wavefront Warteschlange abarbeiten würde, die auch Abhängigkeiten enthält. Zur Erinnerung: Jeder Shader Prozessor enthält vier ALUs, was bei 16 SPs insgesamt 64 ALUs pro SIMD-Einheit macht.

Wie man sehen kann, tut sich die VLIW-Architektur mit Abhängigkeiten schwer. Wavefronts warten unnötig lange in der Warteschlange während freie ALUs Däumchen drehen und auf Arbeit warten.

Wie optimiert man also die Anzahl der skalaren Berechnungen, die man pro Taktzyklus durchführen kann? AMDs Antwort darauf nennt sich “Compute Unit”, oder kurz: CU. Jede CU besitzt ihren eigenen Hardware-Scheduler, der Wavefronts bestimmten Vector Units (VUs) zuteilen kann. Zu einem gewissen Grad kann das sogar out-of-order geschehen, was Flaschenhälse aufgrund von Abhängigkeiten vermeiden hilft.

Die Compute Unit übernimmt die Rolle, die bei AMD-GPUs bislang die SIMD-Einheiten innehatten. Jede CU enthält vier Vector Units, die wiederum 16 ALUs enthalten. Macht insgesamt 64 ALUs pro AU. Die Anzahl der ALUs ist also bei SIMD und CU gleich. Der eigentliche Unterschied ist aber, dass jede VU einzeln mit Arbeit versorgt werden kann. Das funktionierte bei den Shader Processors einer SIMD-Einheit nicht.

Genau darin liegt der Schlüssel zu einer höheren Rechenleistung, da nun jede VU in der Lage ist, verschiedene Wavefronts abzuarbeiten, wenn in der Warteschlange eine Abhängigkeit auftritt:

In unserem Beispiel kann dieselbe Wavefront, die auf einer SIMD-Einheit einer VLIW4-GPU noch sechs Takte benötigte, bei Graphics Core Next in vier Taktschritten ausgeführt werden. Die neue Architektur ist in solchen Berechnungen also deutlich effizienter als die alte VLIW-Generation, und laut AMD kann die Radeon HD 7970 dank besserer Auslastung eine bis zu 7,5 Mal so hohe theoretische Rechenleistung erreichen wie die HD 6970. Wie groß der Vorsprung in der Praxis ausfällt, hängt vor allem von der Compiler-Effizienz ab, und in manchen Aufgaben ist die Radeon HD 7970 nur wenig schneller als ihre Vorgängerin, wenn man das Ergebnis bei gleicher Taktrate betrachtet. In unseren Tests streuten die Ergebnisse jedenfalls recht stark. Aufgrund der Ergebnisse unserer synthetischen Tests können wir aber sagen, dass die potenzielle Rechenleistung von Graphics Core Next definitiv höher liegt als bei VLIW4.

Ein tieferer Blick in die Compute Unit

Wie bereits erwähnt, löst die CU die bisherigen SIMD-Einheiten ab, wie sie bei AMD seit der Radeon HD 2000 zum Einsatz kamen. Zur Erinnerung: Eine CU besteht aus vier Vector Units, die ihrerseits 16 ALUs und eine Registereinheit enthalten. Und wie wir wissen, kann jede Vector Unit unabhängig von den anderen operieren.

Schauen wir uns diese Vector Units aber noch ein wenig genauer an. Im Gegensatz zum vereinfachten Taktzyklus in unserem obigen Beispiel kann jede Vector Unit pro Takt ein Viertel einer Wavefront abarbeiten. Eine mit vier VUs ausgestattete CU kann daher alle vier Takte vier Wavefronts ausführen, was einer Wavefront pro Takt und CU entspricht. Die Vector Units lassen sich auch skalar programmieren, und jede operiert in einem Vektor-Modus.

Über die Skalareinheit der CUs, die vor allem für Code-Verzweigungen und Berechnungen mit Adressenverweisen zuständig ist, haben wir noch gar nicht gesprochen. Diese Aufgaben könnten zwar auch die Vector Units übernehmen, aber indem die Skalareinheiten sich darum kümmern, erlauben sie es den VUs, ihre beträchtliche Rechenkraft sinnvoller einzusetzen.

Jede CU verfügt zudem noch über vier Textureinheit, die an einem 16 KB großen Lese/Schreib-Cache hängen, der also doppelt so groß ist, wie der Lese-Cache der VLIW4-Chips. Bislang wurde der L1-Cache nur zum Einlesen von Texturen verwendet. Jetzt kann er bidirektional genutzt werden.

Ebenfalls interessant...