News CDNA Whitepaper - Unterschiede zu RDNA

User-News

Von E555user

Hinweis: Diese "User-News" wurde nicht von der Planet 3DNow! Redaktion veröffentlicht, sondern vom oben genannten Leser, der persönlich für den hier veröffentlichten Inhalt haftet.
Während mit der Vorstellung des ersten CNDA Beschleunigers mit der Bezeichnung MI100 vorwiegend Marketing-Informationen zur Produktwerbung präsentiert wurden hat AMD ohne grosses Aufhebens ein Whitepaper zu CDNA veröffentlicht.

Auch wenn man mit CDNA eine reine Compute-Lösung abseits des Gaming-Marketes von RDNA anbieten will sind einige Bezüge zu den Gaming-GPUs noch gegeben. Im Block-Diagramm spricht man beispielsweise noch von Shader-Engines und der Multimedia Block ist auch noch nach wie vor vorhanden.
Bildschirmfoto 2020-11-17 um 10.14.03.png

So stellt sich die Frage in wie weit sich CDNA in der ersten Auflage von RDNA unterscheidet. Das Whitepaper klärt auf. AMD schreibt dazu
Unlike the graphics-oriented AMD RDNA™ family, the AMD CDNA family removes all of the fixed-function hardware that is designed to accelerate graphics tasks such as rasterization, tessellation, graphics caches, blending, and even the display engine. However, the AMD CDNA family retains dedicated logic for HEVC, H.264, and VP9 decoding that is sometimes used for compute workloads that operate on multimedia data, such as machine learning for object detection.7 Removing the fixed-function graphics hardware frees up area and power to invest in additional compute units, boosting performance and efficiency.
Das Whitepaper erklärt, dass die GPU in 4 Compute Engines gegliedert ist (4 ACEs), auf die sich 120 CUs verteilen.

Bei den Compute Units ergibt sich dann ein deutlicher Unterschied. Während bei RDNA auf die Entwicklung einer Dual-Compute Unit gesetzt wurde, bei der sich die zusammengefassten Units den L1 Cache teilen und davon profitieren, hat man bei CDNA die GCN Compute Unit um die Grafik-Typischen Elemente erleichtert und dafür in den Rechenwerken zusätzliche Instruktionen implementiert. Neu spricht man hier deshalb von der Enhanced Compute Unit.

Bildschirmfoto 2020-11-17 um 10.22.12.png


Im Vergleich dazu die entsprechenden Diagramme des RDNA Whitepaper.
Bildschirmfoto 2020-11-17 um 10.27.26.png

Bildschirmfoto 2020-11-17 um 10.27.50.png

Man sieht deutlich den gleichen Ursprung und erkennt folgende Unterschiede
  • Enhanced vs. Dual Compute Unit
  • CU ohne Texture Filter&Mapping vs. CU mit Texture Filter&Mapping (bzw. künftig RayAccelerator - RA)
  • 10 Wave Controller 64er Wavefront vs. 20 Wave Controller 32er Wavefront
  • 4 ACE, HWS und DMA vs. dergleichen mit Geometry Processor und Graphics Command Processor
  • Erweiterte Instruktionen (SFUx4) vs. Transcendental Instruktionen (Trans.Unit x8')
  • Matrix SIMD vs. "nur" std. SIMD
  • Scalar Register 3.2KB vs. 10KB
  • 8MB L2 Cache in 32 Slices vs. 4MB L2 Cache in 4 Slices
  • Caches und Register mit ECC vs. ohne ECC
  • HBM Memory Controller vs. GDDR Memory Controller
  • XGMI Links für Infinity Fabric vs. nur PCIe4

Die grösste Neuerung sind also die Matrix-Operationen (Matrix Math Ops) für welche man Matrix Core Engines entwickelt hat:
Bildschirmfoto 2020-11-17 um 16.08.34.png

These Matrix Core Engines add a new family of wavefront-level instructions, the Matrix Fused Multiply-Add or MFMA. The MFMA family performs mixed-precision arithmetic and operates on KxN matrices using four different types of input data: 8-bit integers (INT8'), 16-bit half-precision FP (FP16), 16-bit brain FP (bf16), and 32-bit single-precision (FP32). All MFMA instructions produce either 32-bit integer (INT32) or FP32 output, which reduces the likelihood of overflowing during the final accumulation stages of a matrix multiplication.
Man vermeidet den Begriff Tensor und führt eher die Nomenklatur im üblichen Namensschema für ISA-Funktionen als MFMA fort. Das Ergebnis zweier multiplizierter Matritzen kann hier als 32bit Int oder Float dargestellt werden. Soweit unterscheidet sich das nicht von Nvidias Tensor-Ops, die aber bei Ampere zusätzliche Werte in der Verarbeitung zulassen (FP64, TF32, bfloat16, FP16, INT8, INT4, INT1). Ein Vergleich im tatsächlichen Durchsatz bei gleichermassen unterstützten Operationen wäre sicherlich interessant.

Mit Bezug auf die grundlegende Auslegung fällt auf, dass man bei RDNA mit der 32 Wavefront bei dem hoch dynamischen Gaming Code auf die Skalierungsprobleme mit grosser Anzahl Compute-Units reagiert hat. Bei CDNA bleibt es beim GCN bzw. Vega Ansatz, da man sich hier bei gleichbleibenden Algorithmen für die "Shader"-Auslasung durch die 64 Wavefront wohl eine höhere Effizienz erhofft.

Bildschirmfoto 2020-11-17 um 12.46.17.png
Nicht unerwähnt sollen die XGMI Schnittstellen bleiben, die es beim CDNA Design ermöglicht mehrere GPUs in einem Speicher-Kohärenten System zusammen zu fassen.
Jede GPU hat drei XGMI Links um einen 4er Cluster mit direkter Verbindung ohne zusätzliche Hops beim Datenzugriff bilden zu können.

Mit dem Relaunch von GPUOpen.com wurde diese Webseite um das professional Compute-Thema erleichtert. An dessen Stelle ist für ROCm im Kern eine zentrale Webseite für die Online-Dokumentation getreten. Diese entspricht wohlmöglich mehr den Erwartungen der Zielgruppe, ROCm fokusiert sich auf Linux und wird mit CDNA und der MI100 auch auf einen neuen Versionsstand 4.0 gehoben. (zur Zeit jedoch als 3.9.1 noch nicht in der Dokumentation). Die Seite wird auf GitHub für die Community offen gepflegt. Zuletzt gab es einen erweiterten Support für mehr Linux-Distros.
The AMD ROCm 4.0 software stack is the culmination of years of effort by AMD to provide an open, standards-based, low-friction ecosystem that enables productivity creating portable and efficient high-performance applications for both first- and third-party developers.
Das Whitepaper nimmt den kommenden Sprung auf eine neue Major Version vorweg und verspricht eine für die Entwickler offene Plattform, die dann wie geplant erstmals ein komplettes Ökosystem mit allen in der CUDA Welt gängig genutzten Tools und Bibliotheken nutzt. Siehe dazu auch die Marketing-Slides aus den News von pipin.

Auf den AMD-Technology Seiten ist CDNA mittlerweile auch zu finden.
Diskussionen zum Thema sind hier im Forum gut aufgehoben.
 
Zuletzt bearbeitet:

pipin

Administrator
Teammitglied
Mitglied seit
16.10.2000
Beiträge
17.702
Renomée
7.697
Standort
East Fishkill, Minga, Xanten
  • SIMAP Race
  • QMC Race
  • RCN Russia
  • Spinhenge ESL
  • Docking@Home
  • BOINC Pentathlon 2019
  • SETI@Home Intel-Race II
  • THOR Challenge 2020
Interessant ist noch, dass der Vollausbau wohl bei 128 CUs liegen soll.
Damit will man dann wohl noch genug teildefekte Chips verwertbar haben.

Die Topologie mit 4 GPUs in einem Verbund war ja schon länger klar, da die Exascale-Supercomputer ja in dem Verhältnis 1x CPU + 4 GPU angekündigt waren.

Allerdings habe ich auch schon Slides gesehen (leider nicht veröffentlichbar), die andere Konfigurationen zeigen, in denen mehr GPUs zusammengeschaltet werden.

CDNA ist auf jeden Fall ermutigend gestartet, man muss halt schauen, wie schnell man das Software-Ökosystem ausgebaut bekommt und die nächsten Iterationen werden hoffentlich so wie bei Zen dann immer deutlich besser.
 
Oben Unten