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.
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.
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:
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.
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.