Seite 2: Die RDNA-Architektur

Die RDNA-Architektur sieht Verbesserungen zum GCN-Design in zahlreichen Bereichen vor. AMD spricht zwar von einer völlig neuen Architektur, im Grunde aber gibt es viele Bereiche, die sich sehr ähnlich sind. Die Micro-Architektur mag eine andere sein, wie aber die Schnittstellen und Software mit dieser umgehen, ähnelt doch sehr dem GCN-Design.

Wie auch bei den Ryzen-Prozessoren will AMD einen großen Schritt in der Effizienz des Designs gemacht haben. Zum einen trägt die Fertigung in 7 nm dazu bei (etwa 25 %), zum anderen aber auch Verbesserungen in der Art und Weise wie die GPU den Takt regulieren kann (15 %) und ein Großteil fällt in den Bereich der Architektur-Verbesserungen, auf die wir nun eingehen wollen.

AMD sieht für die Navi-GPUs drei Säulen als die wichtigsten Neuerungen vor. Dies wären die neue Display Engine für die Ausgabe des Bildes, eine Media Engine für das De- und Encoding von Videos sowie die RDNA-Architektur, auf die wir nun genauer eingehen wollen.

Der Vollausbau der Navi-10-GPU sieht 40 Compute Units, bzw. 2.560 Shadereinheiten vor. Die Anzahl der Scaler-Prozessoren wurde auf 80 verdoppelt. Gleiches gilt für die 160 64 Bit breiten Bilinear Filter Units, deren Anzahl eben falls verdoppelt wurde. Hinsichtlich der Caches hat AMD einen L1-Cache mit einer Größe von 512 kB hinzugefügt. Der L2-Cache ist mit 4 MB identisch geblieben.

Die Compute Units sind grundsätzlich neu aufgebaut, weisen aber noch immer eine Verwandtschaft zum GCN-Design auf. Es gibt nun aber pro Compute Unit zwei Scalar Units und ebenso zwei Scheduler. Dies ist besonders dann von Bedeutung, wenn zwei CUs zu einem Workgroup-Prozessor zusammengefasst werden. Sinn macht dies, wenn gewisse Workloads zuvor auf zwei CUs aufgeteilt werden mussten, sich diese aber besser in einer CU bearbeiten lassen. 

Pro Single Cycle (Takt) kann in einer SIMD32-Einheit eine Wave32-Berechnung durchgeführt werden. Damit verdoppelt AMD den Durchsatz, denn zuvor waren die SIMDs nur in der Lage, eine Wave16-Berechnung pro Takt durchzuführen. Für Wave32 mussten im GCN-Design zwei SIMDs nacheinander die Berechnungsschritte ausführen. Durch die Dual-CUs, bzw. das Pooling der CUs wird eine Wave32-Berechnung nun gleichzeitig in zwei SIMD16-Einheiten durchgeführt.

Analog gilt dies nun für Wave64 in der RDNA-Architektur, denn anstatt dies in vier Taktzyklen in vier SIMD16-Schritten auszuführen, kann dies nun in zwei Taktzyklen geschehen. Abhängig vom Workload können im Dual-Mode sowohl Wave32 als auch  Wave64 ausgeführt werden.

Der direkte Vergleich des Aufbaus zeigt die Änderungen, aber auch die Ähnlichkeiten von GCN und RDNA. Kümmerte sich zuvor ein Schedular um vier SIMD-Einheiten, sind es nun zwei Scheduler für zwei zusammengeschaltete SIMD-Einheiten. Durch die Mehrzahl an Decode- und Issue-Einheiten können die Recheneinheiten zudem besser mit Daten versorgt werden und sind besser ausgelastet.

Wichtig ist diese Änderung in der Art und Weise wie die Pipeline abgearbeitet wird – vor allem aus folgendem Grund: Die Vega-Architektur ist im Grunde auf eine hohe Compute-Leistung ausgelegt. Lastet ein Workload diese zu 100 % aus, ist die Vega-Architektur extrem effizient. Viele aufwändige und parallele Aufgaben kann sie sehr gut und schnell verarbeiten, viele kleinere und weniger aufwändige hingegen weniger gut. Gerade Spiele sind aber selten ein Workload, der immer wieder die gleichen Berechnungen mit einem großen Durchsatz voraussetzen. Hier gilt es eher viele kleine Berechnungen möglichst schnell abarbeiten zu können. Parallelen zur Single-Threaded-Leistung bei den Prozessoren sind hier sicherlich am anschaulichsten.

Jeder Steam-Prozessor, bzw. jede SIMD-Einheit besteht aus einer FP32- und zwei FP16-Recheneinheiten. Diese möglichst gut auszulasten sind Punkte, auf die wir oben bereits eingegangen sind. Fast alle Änderungen in diesem Bereich beziehen sich darauf, für eine bessere Auslastung zu sorgen.

Dass AMD die Vega-Karten in Form der Radeon-Pro- und Radeon-Instinct-Modelle weiterbetreiben wird, zeigt das Verhältnis der FP32- zur FP64-Rechenleistung. Die Navi-Karten haben eine Rechenleistung von 9,75 (Radeon RX 5700 XT) bzw. 7,95 TFLOPS (Radeon RX 5700). Für FP64-Berechnungen liegt die Rechenleistung bei einem Verhältnis von 1/16.

Bereits angesprochen haben wir die Tatsache, dass die RDNA-Architektur unter anderem einen neuen L1-Cache vorsieht. Zudem hat AMD den Aufbau der Cache-Hierarchie verändert. Der L2-Cache ist in zwei Subslices zu jeweils acht Partionen aufgeteilt. Aus 16x 256 kB ergeben sich die 4 MB an gesamtem L2-Cache. Per Infinity Fabric ist der L2- mit dem neuen L1-Cache verbunden. Dieser ist wieder in Blöcken mit einer Größe von 128 kB aufgeteilt. 

Der L1-Cache dient als Zwischenpuffer und soll häufige Datenzugriffe über den L2-Cache reduzieren. Entsprechend schnell ist dieser angebunden. Das Zusammenfassen der CUs verdoppelt die zur Verfügung stehende Bandbreite an dieser Stelle. Gleichzeitig verdoppelt AMD die Anzahl der ALUs insgesamt und macht die Register im Schnitt doppelt so breit.

Das Thema Async Compute geht AMD ebenfalls noch einmal an und will seinen Vorsprung in DirectX 12 und Vulkan in dieser Hinsicht weiter ausgebaut haben. In den Simulationen und normalisiert sieht AMD die RDNA-Architektur gegenüber dem eigenen GCN-Design deutlich im Vorteil. Dies ist aber nicht nur Folge der zahlreichen Architektur-Verbesserungen, sondern auch eines besseren Clock-Gatings. Außerdem konnte AMD einige Bereiche der Architektur reduzieren, die notwendig waren, um bei der Vega-Architektur die höheren Taktraten zu erreichen. Aufgrund der Fertigung in 7 nm ist dies in dieser Form nicht mehr notwendig.