Werbung
Advertorial / Anzeige:
Compute Units, Workgroup-Prozessoren, Matrixeinheiten, Raytracing-Beschleuniger – all das sind Begrifflichkeiten für die GPU-Architekturen bei AMD. Zusammengefasst und in immer neuen Iterationsschritten umgesetzt werden die Funktionen in den RDNA-Architekturen. RDNA steht dabei für Radeon DNA. Inzwischen sind wir bei Generation vier, sprich RDNA 4, angekommen.
Die RDNA-4-Architektur und die dazugehörigen Grafikkarten der Radeon-RX-9070-Serie basieren alle auf der größten GPU, die AMD in dieser Generation plant, der Navi-48-GPU. Einen größeren Ausbau wird es nicht geben. Damit verabschiedet sich AMD vom Multi-Chiplet-Ansatz der RDNA-3-Generation, denn die Navi-48-GPU ist ein monolithischer Chip mit Abmessungen von 357 mm², gefertigt bei TSMC in N4P. Ein Graphics Chiplet Die (GCD) und mehrere Memory Chiplet Dies (MCD) gibt es somit nicht. Diese wurden bei der Vorgängergeneration in 5 bzw. 6 nm gefertigt.
Zudem gibt es noch die Navi-44-GPU mit einem kleineren RDNA-4-Ausbau. Diese kommt bei den Radeon-RX-9060-Karten zum Einsatz und stellt einen etwas kleineren Ausbau dar.
Interessant an dieser Stelle ist aber nicht nur der Vergleich der Chipgrößen und Anzahl der Transistoren, sondern vor allem, dass es AMD offenbar zusammen mit TSMC gelungen ist, die Transistordichte deutlich zu erhöhen. Der für NVIDIA angepasste 4N-Prozess liegt beispielsweise in dieser Hinsicht etwas hinter dem von AMD verwendeten N4P zurück.
Grundsätzliche Ziele der RDNA-4-Architektur sind die Steigerung der Rechenleistung, angefangen mit der klassischen Rasterizer-Leistung, aber auch der Raytracing- und KI-Leistung. Dazu wurden Änderungen in der Speicher-Hierarchie vorgenommen, welche die entsprechenden Anforderungen decken sollen.
Die Navi-48-GPU setzt sich aus vier Shader Engines zusammen, die jeweils acht Workgroup-Prozessoren enthalten, welche wiederum zwei Compute Units aufweisen. Dies ergibt insgesamt 64 Compute Units (CUs). Die grundlegende Struktur entspricht der RDNA-3-Generation.
Wesentliche Komponenten neben den CUs sind die Raytracing-Beschleuniger der dritten Generation, die Matrix-Beschleuniger der dritten Generation sowie eine neue Media- und Display-Engine.
Innerhalb der Compute Units bleibt die Ausführung zweier Vektor-Operationen mit 32 Bit (Dual SIMD Vector Units) unverändert. Die Matrixeinheiten unterstützen aber 2x FP16-Operationen mit der Möglichkeit, FP8- und FP4-Rechenoperationen auszuführen und deren Anzahl entsprechend zu verdoppeln oder zu vervierfachen. Mittels Sparcity können teilweise leere Matrizen schneller verarbeitet werden. Sparcity (oder Sparsität) beschreibt das Phänomen, dass eine Matrix überwiegend aus Nullen besteht, wodurch spezialisierte Algorithmen die fehlenden Werte ignorieren können und so Speicher- sowie Rechenzeit erheblich sparen. Die Skalar-Einheiten können neben 32 Bit breiten Operationen auch Float32 ausführen.
Den Vektor- und Skalar-Einheiten stehen 192 bzw. 8 kB an Register Files zur Verfügung. Beim Cache verfügt jede Einheit über 16 kB für Skalar-Operationen und 32 kB für Dual-Shader insgesamt. Hinzu kommt ein 128 kB großer Shared Cache. Insgesamt bietet die Navi-48-GPU 8 MB L2-Cache. Darüber hinaus steht der Infinity Cache mit 64 MB zur Verfügung.
Die verbesserten Raytracing-Beschleuniger führen doppelt so viele Strahlenberechnungen durch wie in der RDNA-3-Architektur. Dazu verfügen die Raytracing-Beschleuniger über eine zweite Intersection Engine. Neu ist ein dedizierter Hardwareblock namens “Ray Transform”, der Rechenoperationen übernimmt, welche in der Vorgängergeneration durch die Shader durchgeführt wurden. Dies entlastet die Shadereinheiten und verbessert deren Rechenleistung. Die Raytracing-Beschleuniger greifen auf den 128 kB großen Shared Cache der Dual-CUs zu.
Die Einführung von BVH8 flacht die Baumstruktur ab, wodurch Berechnungen mit weniger Schritten zur Ermittlung des Schnittpunkts gelangen. Dies reduziert zudem den erforderlichen Speicher für den BVH-Tree sowie die Cache-Bandbreite.
Die Bounding Volume Hierarchy (BVH) stellt eine Grundkomponente der Raytracing-Berechnung dar. Sie organisiert die Szene hierarchisch in umschließende Volumina, die Objekte oder Gruppen enthalten. Beim Raytracing hilft die BVH, die Anzahl der Schnittpunkttests zu reduzieren, indem Strahlen zuerst gegen größere Volumina getestet werden, bevor sie auf detailliertere Objekte treffen. Wenn ein Strahl ein Volumen nicht schneidet, können alle darin enthaltenen Objekte übersprungen werden, was die Berechnung erheblich beschleunigt. Die BVH wird meist als Baumstruktur implementiert, wobei jeder nicht-blattförmige Knoten zwei oder mehr Unterknoten mit kleineren Bounding Volumes enthält.
Eine neue Funktion innerhalb des BVH sind die Oriented Bounding Boxes (OBB). Diese orientieren sich in ihrer Größe an der zugrundeliegenden Geometrie. Somit enthalten die Boxen weniger leeren Raum und richten sich nach den 3D-Strukturen aus. Dadurch können einige Operationen während der Strahlenberechnung schneller abgebrochen werden, da der Strahl kein 3D-Objekt mehr trifft oder dies früher erkannt wird. AMD verzeichnet eine Leistungsverbesserung von etwa 10% durch die Nutzung von OBB.
Mit der RDNA-4-Architektur erfolgen auch Änderungen bei der Reihenfolge gewisser Raytracing-Rechenoperationen und der Verarbeitung der zugehörigen Speicherzugriffe. Ein Rendering-Prozess stellt keine gleichmäßige Abfolge von Rechenoperationen dar.
Daten im Cache werden von den Shadern in Form von Wave-Operationen nun auch in einer weniger strikten Reihenfolge abgefragt. Cache-Hits und Misses können sich gegenseitig beeinflussen. AMD reduziert diese gegenseitige Beeinflussung.
Das beschriebene Out of Order Memory, Instance Transform als neuer Hardwareblock und Oriented Bounding Boxes tragen zu einem geringen Teil zu den Verbesserungen der Raytracing-Beschleuniger bei. Den größeren Anteil machen die verdoppelten Intersection-Einheiten aus. Die Verhältnisse sind abhängig vom jeweiligen Workload.
Die Asynchronität mittels Out of Order Memory existiert auch auf Shader-Ebene in den Registern. Mit der RDNA-4-Architektur gibt es hier ebenfalls Verbesserungen. Bisher teilten sich die Shader je nach Operation unterschiedlich große Bereiche der Register selbst zu und adressierten dabei immer den maximalen Umfang des Worst Case.
Mit der RDNA-4-Architektur erfolgt diese Zuweisung nun dynamisch. Somit werden die Register Files effizienter genutzt und mehr Berechnungen können gleichzeitig ausgeführt werden.
Textureinheiten
In den Shadereinheiten werden Shader programmiert, die Berechnungen bestimmter Werte durchführen. Vertex-Shader führen geometrische Berechnungen und dynamische Veränderungen von Objekten durch. Geometry-Shader berechnen aus Punkten, Linien und Dreiecken die endgültige Geometrie und den Aufbau der Objekte. Tessellation-Shader unterteilen sogenannte Primitives wie Dreiecke weiter.
Die Textureinheiten oder Texture Mapping Units (TMU) sind dafür zuständig, dass alle Flächen mit den entsprechenden Texturen belegt werden. Textureinheiten sind dedizierte Recheneinheiten einer GPU. Bei der RDNA-4-Architektur kommen je Dual-Compute-Unit zwei Textureinheiten zum Einsatz. Die erforderlichen Daten für eine Textureinheit liegen im Grafikspeicher und können von dort gelesen oder geschrieben werden. Da Textureinheiten heute Bestandteil der Grafikpipeline sind und nicht mehr externe Recheneinheiten darstellen, können Objekte mehrfach von der Textureinheit verwendet werden.
Für das Rendering eines Objekts genügt eine einzelne Textur nicht mehr. Es gibt mehrere Ebenen, die beispielsweise eine 3D-Optik auf einer flachen Textur erzeugen können. Während Objekte früher mehrfach berechnet und jeweils von der Textureinheit mit einer spezifischen Textur belegt wurden, reicht heute ein einzelner Renderprozess aus. Die Textureinheit kann aus einem Buffer heraus mehrfach auf dieses Objekt zugreifen.
Speichercontroller
Eine hohe Speicherbandbreite ist genauso wichtig wie die Rechenleistung der GPU selbst. Nur wenn Daten schnell vom Grafikspeicher zur GPU transportiert und darin zurückgeschrieben werden können, lassen sich Berechnungen entsprechend zügig durchführen. Dies wird als Backend in Form der GPU-Rechenleistung und als Frontend in Form der Cache-Hierarchie und Speicheranbindung bezeichnet. Jede GPU-Architektur wird entsprechend ausgelegt und profitiert teilweise stärker von hoher Speicherbandbreite als andere. Unabhängig davon streben alle Hersteller eine möglichst hohe Speicherbandbreite an. Der Speichercontroller spielt dabei eine entscheidende Rolle.
Neben Änderungen in den Compute Units finden sich auch solche im Aufbau der Cache-Hierarchie bis hin zum Grafikspeicher. Jede Dual-Compute-Unit besitzt 16 kB an Skalar- und 32 kB an Shader-Instruction-Cache. Hinzu kommen 128 kB an Shared Memory und zweimal 32 kB an L0-Cache.
Die Ebene darüber stellt 8 MB an L2-Cache zur Verfügung, gefolgt von 64 MB an L3-Cache oder wie AMD diesen nennt: Infinity Cache. Diese Angaben gelten für die Navi-48-GPU. Bei der kleineren Navi-44-GPU fallen die Kapazitäten für den L2- und Infinity Cache halb so groß aus.
Nun folgen die Speichercontroller, von denen AMD in der Navi-48-GPU 16x 16 Bit verbaut, was insgesamt zu einem 256 Bit breiten Speicherinterface führt. Bei der Navi-44-GPU sind es 8x 16 Bit und demnach 128 Bit insgesamt. Die Speicherbandbreite liegt beim verwendeten GDDR6 bei 640 bzw. 322,2 GB/s.
Advertorial / Anzeige:
