TEST

Endlich wieder ein Duell auf Augenhöhe

Radeon RX 6800 und Radeon RX 6800 XT im Test - Die RDNA-2-Architektur

Portrait des Authors


Werbung

Eines der Ziele mit RDNA 2 war die Steigerung des Leistung/Watt-Verhältnisses und diese bereits mehrfach erwähnte Hürde wurde auch genommen. Letztendlich erreicht hat man sogar +54 % für die Radeon RX 6800 XT und satte 65 % für die Radeon RX 6900 XT. Nun kennen wir solche Steigerungen aus der CPU- und GPU-Entwicklung, meist gehen diese aber mit einer Reduzierung der Fertigungsgröße einher, was für Big Navi bzw. RDNA 2 nicht der Fall ist.

Eine der Maßnahmen ist die Auslegung der Architektur auf einen höheren Takt. Bereits ab Werk takten die Radeon-RX-6000-Karten mit bis zu 2.250 MHz. Aber auch 2,4 oder 2,5 GHz sollen je nach Kühlung und Lastzustand möglich sein. Solche Taktraten kennen wir für moderne GPU-Designs bislang noch nicht. Möglich wird dies durch die Erfahrung bei den Prozessoren, wo man einen ähnlichen Weg gegangen ist. Design-Ansätze der CPU- und GPU-Entwicklung flossen hier zusammen und so konnten beide Seiten der Entwicklung davon profitieren.

AMD hat für Big Navi den gewünschten Betriebspunkt gesucht und gefunden. Bei gleicher Leistung pro CU wäre eine Taktsteigerung von 30 % möglich oder bei gleichem Takt eine um 50 % verbesserte Leistung pro CU.

Das um mehr als 50 % gesteigerte Leistung/Watt-Verhältnis setzt sich also aus mehreren Komponenten zusammen. Der höhere Takt fügt +16 % hinzu. Die Leistungsoptimierungen im Hinblick auf den Verbrauch (Clock Gating, Clock Tree Splitting und Clock Tree Gating - also die Reduzierung des Taktes in nicht verwendeten Bereichen der GPU) der einzelnen Funktionseinheiten weitere 17 % und der Infinity Cache hat mit seiner Reduzierung der Latenzen und schnelleren Zugriffe die restlichen 21 % beigesteuert.

Die Effizienzsteigerung wird aber auch durch eine neue Cache-Hierarchie möglich und dazu führt man den Infinity Cache ein. Dieser 128 MB große Cache ist als großer Zwischenpuffer zwischen dem L2-Cache und dem Grafikspeicher vorgesehen.

Die Big-Navi-GPUs besitzen 26,8 Milliarden Transistoren und werden weiterhin in 7 nm gefertigt. Natürlich wird AMD hier zusammen mit seinem Partner TSMC an einige Stellschrauben gedreht haben, es bleibt aber bei den nominellen 7 nm der ersten Navi-Generation. Die Größe des Chips gibt AMD mit 519,8 mm² an. Zum Vergleich: Die GA102-GPU von NVIDIA kommt auf 28 Milliarden Transistoren, die kleinere GA104-GPU auf 17,4 Milliarden Transistoren und das bei Größen von 628,4 mm² bzw. 392,5 mm².

An I/O bieten die Karten die Unterstützung von PCI-Express 4.0 und ein 256 Bit breites Speicherinterface für die Anbindung des Grafikspeichers. Dieses 256 Bit breite Speicherinterface wirkt zunächst etwas schmal, der Infinity Cache fängt die "fehlende" Bandbreite aber auf und bietet zudem weitere Vorteile, die auch ein breiteres Speicherinterface nicht hätte bieten können.

Die Instruction-Pipeline der RDNA-2-Architektur beginnt weiterhin mit den Command Prozessoren, vier Async Compute Engines, die im Front-end die Aufteilung der Rechenaufgaben übernehmen. Diese verteilen die Tasks dann an die 80 Compute Units mit jeweils 64 Stream Prozessoren. Hinzu kommen 320 Textur-Einheiten (vier pro CU) und 80 Ray Accelerators (Raytracing-Beschleuniger), von denen also pro CU einer vorhanden ist. Der Geometry Processor kann acht Pre-Cull und vier Post-Cull Prims pro Taktzyklus verarbeiten.

Die verbesserten Render-Backends (RB+) sorgen dann für die Ausgabe der Pixel und die korrekte Anordnung des Renderings. Die Render-Backends sind nun in der Lage acht 32-Bit-Pixel pro Taktzyklus zu verarbeiten, was einer Verdopplung entspricht. Über das Variable Rate Shading (VRS) können die Render-Backends noch effektiver arbeiten, was die Effizienz erhöht.

RDNA 2 Compute Units

Pro CU können bestimmte Operationen für jeden Taktzyklus ausgeführt werden. Dahinter stecken natürlich auch dedizierte Funktionseinheiten, die mit den entsprechenden Genauigkeiten arbeiten. Der Fokus liegt natürlich auf FP16 und FP32 sowie INT32, da dies für ein 3D-Rendering die am häufigsten vorkommenden Operationen sind. 256 FP16 und INT16-Berechnungen können pro Takt gemacht werden. Für FP32- und INT32-Berechnungen sind es 128. Die hohen Genauigkeiten wie FP64 deckt AMD mit RDNA 2 kaum ab und spricht hier von acht Operationen pro Taktzyklus und CU. Neben gleichen Operanden können die Compute Units auch Mixed-Precision-Operationen ausführen.

Die Ray Acceleratoren können vier Box- oder eine Triangle-Intersecion pro Taktzyklus berechnen. Auch AMD beschleunigt also die Berechnungen in der Bounding Volume Hierarchy (BVH) mittels dedizierter Recheneinheiten. Eine solche Berechnung durch einen Ray Accelerator ersetzt in etwa 1.500 Rechenoperationen aus dem ISA-Befehlssatz, die sonst durch die Compute Units hätten ausgeführt werden müssen. Bei der BVH wird eine Szene in immer kleinere Blöcke aufgeteilt und diese wiederum werden den Primitives zugewiesen. Letztendlich muss der Strahl nur noch in den Blöcken betrachtet werden, die er auf dem Weg zum Primitiv kreuzt. BVH verwendet nun eine Hierarchie, welche genau aufzeigt, für welchen Block und letztendlich welches Primitiv die Berechnung für das Ray Tracing durchgeführt werden muss.

Mesh Shading

Eine der neuen Funktionen der RDNA-2-Architektur ist das Mesh Shading, wie es in DirectX 12 Ultimate vorgesehen und ist und auch von NVIDIA ab den Turing-Karten unterstützt wird. 3D-Szenen mit vielen Objekten werden häufig durch die Geometrieberechnungen limitiert, was wiederum durch die Leistung des Prozessors limitiert wird.

In sogenannten Workgroups können Geometriedetails viel effizienter verarbeitet werden und passen sich auch der zur Verfügung stehenden Rechenleistung an bzw. können das Level of Detail automatisch in Abhängigkeit zum Abstand des Objektes bestimmen. In eine ähnliche Kerbe schlägt auch das Sampler Feedback, wo zum Beispiel nur noch Texturinformationen geladen und verwendet werden, die auch wirklich sichtbar sind und berechnet werden müssen. Dazu muss aber zumindest teilweise ein Rendering stattfinden, damit der Sampler weiß, welche Daten er braucht und welche nicht. Über das Feedback wird das Rendering also effektiver, da nicht sichtbare Details auch nicht berechnet werden und Ressourcen verbrauchen.

Variable Rate Shading

Einfach gesagt handelt es sich beim Variable Rate Shading um eine "Kompression" für das Shading in den Render-Backends. Für das Variable Rate Shading wird der Frame in mehrere Blöcke aufgeteilt. Abhängig vom Inhalt des jeweiligen Frame und der Geschwindigkeit, in der sich Änderungen zum nächsten Frame ergeben, können diese Blöcke unterschiedlich groß sein. Es gibt daher unterschiedliche Methoden des Variable Rate Shading.

Beim Content Adaptive Shading geht es um den Inhalt des jeweiligen Frames. Das Motion Adaptive Shading bewertet auch die Bewegungen und Änderungen von Frame zu Frame. Beim Foveated Rendering spielt die Betrachungsrichtung des Nutzers in einer VR-Umgebung eine Rolle, da nur die Bereiche in voller Detailstufe berechnet werden müssen, die auch im Fokus des Betrachters liegen. Das Lens Optimized Rendering passt das Rendering an die Gegebenheiten der Linse in einer VR-Brille an. 

Ray Accelerators

AMD verwendet die Ray Accelerators, um bestimmte Berechnungen im Zusammenspiel mit Raytracing-Effekten zu beschleunigen. Wie bereits erwähnt, können diese vier Box- oder eine Triangle-Intersection pro Taktzyklus berechnen und sind in etwa um den Faktor zehn effektiver, als wenn diese Berechnungen zusätzlich auf den Shadern hätten ausgeführt werden müssen.

Über den Treiber spricht AMD die DXR-Schnittstelle von Microsoft an, genau wie NVIDIA dies für sein RTX-Technik bzw. die RT Cores tut. Auch AMD führt eine Hybrid-Rendering-Pipeline ein, die klassische Rasterization- und Raytracing-Berechnungen gleichzeitig ausführen kann. Neben den klassischen Effekten wie den Reflexionen sind auch hier Berechnungen wie die globale Beleuchtung (Global Illumination) und die Berechnung von Schatten (Ray-traced Soft Shadows) möglich.

Im Unterschied zur NVIDIAs RT Cores können die Ray Accelerators aber nur die Triangle Intersection, also den Schnittpunkt in einem Dreieck hardwarebeschleunigt berechnen, während es bei NVIDIA auch Traversals, also die Durchquerungen, sind. Die Traversals muss AMD also in den Shadern ausführen.