AMDs CDNA-3-Compute-Architektur
(chipsandcheese.com)- AMD CDNA 3 ist eine Compute-GPU-Architektur, die Schwächen von CDNA 2 ausgleichen soll, das zwar im FP64-Supercomputing erfolgreich war, gegenüber der H100 aber bei AI-Leistung und der Größe integrierter GPUs zurücklag
- Die MI300X stellt über 8 XCDs insgesamt 304 Compute Units wie eine einzelne GPU bereit und verringert damit den Aufwand, Workloads wie bei der MI250X auf zwei GPUs mit getrennten Speicherpools aufzuteilen
- Die Speicherhierarchie wurde mit 256 MB Infinity Cache, 4 MB L2 pro XCD und 32 KB L1 nahe der CU neu aufgebaut und bietet theoretisch 17,2 TB/s Cache-Bandbreite, wobei in einer einheitlichen Speicherkonfiguration die Die-to-Die-Links zum Flaschenhals werden können
- Die Execution Units führen eine Struktur nahe Dual-Issue und eine höhere Zahl pro SIMD verfolgbarer Threads ein, um die FP32-Auslastung zu steigern; zudem verdoppelt sich der Durchsatz für Matrixoperationen pro CU gegenüber der vorherigen CDNA-Generation
- Die zentralen Änderungen von CDNA 3 betreffen Speicherhierarchie und Packaging; die MI300X ist mit stark erhöhter Infinity-Fabric-Bandbreite so ausgelegt, dass mehrere Chiplets wie ein einzelner großer Beschleuniger erscheinen
Die Lücke, auf die CDNA 3 zielt
- AMD entwickelt seine Architektur weiter, um Nvidia im GPU-Compute-Markt einzuholen, und hat dabei Terascale 3, GCN sowie die Trennung von CDNA und RDNA durchlaufen
- Die auf CDNA 2 basierenden MI250X und MI210 gewannen mehrere Supercomputer-Aufträge, darunter ORNLs Frontier, das im November 2023 Platz 1 der TOP500 belegte
- CDNA 2 bot solide und kosteneffiziente Leistung bei FP64-Compute, doch die H100 liefert bessere AI-Leistung und eine größere integrierte GPU
- CDNA 3 wurde entwickelt, um diese Lücke zu verkleinern, indem AMD fortschrittliches Packaging, Infinity Fabric, den aus der RDNA-Familie stammenden Infinity Cache und verbesserte Compute Units kombiniert
GPU-Layout der MI300X
- Die MI300X nutzt eine Chiplet-Struktur, bei der der Compute-Bereich in Accelerator Complex Die (XCD) aufgeteilt ist
- Ein XCD erfüllt eine ähnliche Rolle wie der Graphics Compute Die (GCD) von CDNA 2/RDNA 3 oder der Core Complex Die (CCD) bei Ryzen
- Da CDNA-Produkte keine dedizierte Grafikhardware der RDNA-Familie enthalten, scheint AMD die Bezeichnung geändert zu haben
- Jedes XCD besitzt physisch 40 CDNA-3-Compute-Units, von denen in der MI300X 38 pro XCD aktiviert sind
- Ein XCD verfügt über 4 MB L2-Cache, die von allen CUs dieses Dies genutzt werden
- Mit 8 XCDs bietet die MI300X insgesamt 304 Compute Units
- Das ist deutlich mehr als die 220 CUs der MI250X, und die MI300X kann diese CUs als einzelne GPU bereitstellen
- Bei der MI250X hatte jede GPU einen separaten Speicherpool, sodass Programmierer die Arbeit direkt auf zwei GPUs aufteilen mussten
- Die Nvidia H100 stellt 132 Streaming Multiprocessors (SM) als eine integrierte GPU bereit, verwendet dafür aber den traditionellen Ansatz eines großen monolithischen Dies für den Compute-Bereich
- Die H100 teilt das L2 in zwei Instanzen; ein einzelner SM kann zwar die gesamten 50 MB L2 nutzen, Zugriffe über 25 MB hinaus verursachen jedoch eine Performance-Einbuße
- Das XCD der MI300X nutzt die L2-Kapazität anderer XCDs nicht für Caching, weshalb Nvidias Ansatz bei der Nutzung der Cache-Kapazität effizienter ist
Strukturvergleich mit Ponte Vecchio
- Intels Ponte Vecchio (PVC) verwendet Compute Tiles als grundlegende Compute-Blöcke, was grob den XCDs von CDNA 3 entspricht
- Das Base Tile von PVC umfasst ähnlich wie das IO-Die von CDNA 3 einen großen Last-Level-Cache und HBM-Speichercontroller
- Auch eine PVC-Karte kann wie die MI300X als einzelne GPU mit einheitlichem Speicherpool bereitgestellt werden
- Unterschiede zwischen beiden Strukturen zeigen sich bei Chiplet-Größe, Cache-Anordnung und Die-zu-Die-Links
- Das Compute Tile von PVC besteht aus 8 Xe Cores und ist damit kleiner als ein CDNA-3-XCD mit 38 CUs
- Intel reduziert den Bedarf an Cross-Die-Traffic mit größerem L1-Cache statt eines größeren Caches für das gesamte Compute Tile
- Wird ein 2-Stack-Ponte-Vecchio als integrierte GPU genutzt, liefert die EMIB-Bridge nur 230 GB/s, sodass sich die HBM-Bandbreite beim Striping über alle Speichercontroller nur schwer vollständig ausnutzen lässt
- Intel bietet APIs, mit denen sich die GPU in einer NUMA-Konfiguration behandeln lässt
- In der physischen Umsetzung benötigt CDNA 3 hohe Bandbreite zwischen den IO-Dies, während PVC mit EMIB-Links geringerer Bandbreite auskommt; dafür ist das Design wegen vier Die-Typen und unterschiedlicher Prozesse bzw. Foundries komplex
- Die MI300X nutzt nur zwei Die-Typen, und sowohl 6 nm als auch 5 nm stammen aus TSMC-Prozessen
Infinity Cache und Speicherengpässe
- Die Compute-Leistung ist seit Jahrzehnten schneller gewachsen als die Speicherleistung, und auch GPUs reagieren wie CPUs mit ausgefeilteren Cache-Strategien
- CDNA 2 nutzte eine traditionelle zweistufige Cache-Hierarchie mit 8 MB L2 und HBM2e, doch bei der MI250X war die Bandbreitenknappheit stärker als bei der Nvidia H100
- CDNA 3 ergänzt den aus RDNA 2 übernommenen Infinity Cache
- Der Infinity Cache der MI300 wird in den technischen Unterlagen als Memory Attached Last Level (MALL) bezeichnet, also als speicherseitiger Cache
- Er liegt weiter von den Compute Units entfernt als L1 und L2 und ist an die Speichercontroller angebunden
- Der gesamte Speicher-Traffic läuft durch den Infinity Cache, und auch IO-Traffic sowie die Kommunikation zwischen Peer-GPUs profitieren von dessen Bandbreite
- Da er stets den aktuellen Zustand des DRAM sieht, muss er keine Cache-Kohärenzaufgaben wie Snoop-Verarbeitung übernehmen
- Speicherseitige Caches haben üblicherweise höhere Latenzen, weshalb AMD sowohl bei CDNA 3 als auch bei RDNA 2 mehrfache L2-Caches im MB-Bereich einsetzt, um die Compute Units abzuschirmen
Kapazität und theoretische Bandbreite des Infinity Cache
- Der Infinity Cache von CDNA 3 ist wie bei RDNA 2 als 16-way set associative aufgebaut
- Die Implementierung in CDNA 3 ist stärker auf Bandbreite als auf Kapazität optimiert
- Er besteht aus 128 Slices
- Jeder Slice hat 2 MB Kapazität und eine Lese-Bandbreite von 64 Byte pro Takt
- Alle Slices zusammen liefern 8192 Byte pro Takt, was bei 2,1 GHz 17,2 TB/s entspricht
- Der 128 MB große Infinity Cache von RDNA 2 bietet über alle Slices hinweg 1024 Byte pro Takt und theoretisch 2,5 TB/s bei 2,5 GHz
- Laut den Die-Shots scheinen die Infinity-Cache-Slices von RDNA 2 4 MB Kapazität und 32 Byte pro Takt zu liefern
- Die MI300X kann auch bei Workloads mit geringer Compute-Dichte ordentliche Leistung erzielen, sofern genügend Infinity-Cache-Hits erreicht werden
- Baut man mit der theoretischen Bandbreite des Infinity Cache ein Roofline-Modell auf, kann die MI300X ihre gesamte FP64-Leistung bereits bei 4,75 FLOPs pro geladenem Byte erreichen
- Bei ausschließlicher Nutzung von DRAM wären 14,6 bis 15 FLOPs pro geladenem Byte erforderlich
Grenzen der Cross-Die-Bandbreite
- Die Infinity Fabric der MI300X erstreckt sich über 4 IO-Dies, von denen jedes mit 2 HBM-Stacks und den zugehörigen Cache-Partitionen verbunden ist
- Wenn die MI300X als einzelne logische GPU mit einheitlichem Speicherpool arbeitet, kann die Bandbreite der Die-to-Die-Verbindungen die volle theoretische Bandbreite des Infinity Cache begrenzen
- Der Flaschenhals einer einzelnen IO-Die-Partition wird in der Bandbreitenrechnung sichtbar
- An den beiden Kanten zu benachbarten IO-Dies stehen 2,7 TB/s Ingress-Bandbreite zur Verfügung
- Die 2 an dieses IO-Die angebundenen XCDs können 4,2 TB/s Infinity-Cache-Bandbreite nutzen
- Wenn L2-Miss-Anfragen gleichmäßig über alle Dies gestriped werden, müssen 3/4 beziehungsweise 3,15 TB/s von Peer-Dies kommen
- Da 3,15 TB/s über 2,7 TB/s liegen, begrenzt die Cross-Die-Bandbreite die Cache-Bandbreite
- Wenn in der einheitlichen Konfiguration alle Dies maximale Infinity-Cache-Bandbreite anfordern, benötigen Übertragungen zwischen diagonal gegenüberliegenden Dies 2 Hops und verbrauchen zusätzliche Ingress-Bandbreite
- Teilt man die MI300X in mehrere NUMA-Domänen auf, kann die aggregierte Infinity-Cache-Bandbreite höher ausfallen
- Eine hohe L2-Hit-Rate verringert die Wahrscheinlichkeit solcher Engpässe, und bei niedriger Infinity-Cache-Hit-Rate bieten die Die-to-Die-Links der MI300X genügend Bandbreite für den HBM-Traffic
Kohärenz zwischen XCDs und Verhalten von L2
- Um die Infinity Cache muss man sich hinsichtlich der Kohärenz keine Sorgen machen, aber der L2-Cache erfordert eine separate Behandlung
- Normale GPU-Speicherzugriffe folgen einem relaxed coherency model, aber Programmierer können mit Atomics die Ordnung zwischen Threads erzwingen
- Speicherzugriffe auf AMD-GPUs können mit dem GLC-Bit (Global Level Coherent) markiert werden
- Bei früheren AMD-GPUs wurden Atomics und kohärente Zugriffe in L2 verarbeitet
- Ein Load mit gesetztem GLC-Bit umgeht L1 und holt die neuesten Daten aus L2
- Beim MI300X kann sich die neueste Cacheline jedoch im L2 eines anderen XCD befinden, sodass dieser Ansatz allein nicht ausreicht
- CDNA 3 platziert wie Ryzens Infinity Fabric einen Coherent Master (CM) an der Verbindung zwischen XCD und I/O-Die und neben jedem Speichercontroller einen Coherent Slave (CS) zusammen mit einem Infinity-Cache-Slice
- Aus der Ryzen-Dokumentation geht hervor, dass der Coherent Slave Hardware für Probe-Filter und die Verarbeitung atomarer Transaktionen enthält
- Auch der MI300X scheint eine ähnliche CS-Implementierung zu besitzen
- Wenn ein kohärenter Write beim CS ankommt, muss jeder kohärente Read diesen Write sehen können, egal auf welcher GPU der Thread läuft
- In einer einfachen Implementierung müsste der CS den L2 aller XCDs abfragen
- Der Probe-Filter verfolgt, welcher XCD die betreffende Line gecacht hat, und vermeidet so unnötigen Probe-Traffic
- Im CDNA-3-Whitepaper steht, dass der Snoop-Filter groß genug ist, um die L2-Caches mehrerer XCDs abzudecken
- Innerhalb eines XCD verhält sich CDNA 3 jedoch ähnlich wie frühere GPUs
- Ein normaler Speicher-Write invalidiert nicht automatisch die Line im Peer-Cache wie bei einer CPU
- Der Code muss explizit das Writeback einer dirty L2-Cacheline und die Invalidation einer non-local L2-Line im Peer-L2 anfordern
- Die zugehörige LLVM-Dokumentation erklärt für das GFX942-Target die Verwendung von
buffer_wbl2 sc1undbuffer_inv sc0 sc1
Verbesserungen bei L2- und L1-Cache
- Jedes MI300X-XCD besitzt einen 4 MB großen L2-Cache in der Nähe der Compute Units
- L2 besteht aus 16 Slices
- Jeder 256-KB-Slice liefert 128 Byte Bandbreite pro Takt
- Bei 2,1 GHz entspricht das 4,3 TB/s pro XCD
- Der MI300X hat ein höheres Verhältnis von L2-Bandbreite zu Rechenleistung als H100 und MI250X
- Da jedes XCD einen eigenen L2 besitzt, steigt bei CDNA-3-Produkten mit mehr XCDs auch die L2-Bandbreite ganz natürlich
- So vermeidet man das Problem, viele Compute Units an einen großen Cache anzubinden und dabei die Bandbreite aufrechtzuerhalten
- Bei PVC steigt mit zusätzlichen Compute Tiles auch der Bandbreitenbedarf an den gemeinsamen L2 des Base Tile
- Die PVC-Struktur ist aus Cache-Sicht einfach, weil L2 der einzige Kohärenzpunkt ist und als Backstop für L1-Misses dient
- Die hohe Bandbreite des MI300X-L2 erreicht sie jedoch nicht
- Auch der L1 von CDNA 3 wurde mit Fokus auf Bandbreite verbessert
- Der L1-Durchsatz steigt von 64 Byte auf 128 Byte pro Takt
- Die L1-Kapazität wächst ebenfalls von 16 KB auf 32 KB
- Ein größerer Cache kann die Hit-Rate verbessern, die durchschnittliche Speicherzugriffslatenz senken und die Auslastung der Ausführungseinheiten erhöhen
- Da das Holen von Daten aus L2 oder darüber hinaus Energie kostet, kann eine höhere Hit-Rate auch die Energieeffizienz verbessern
- Ponte Vecchio bleibt bei L1 dennoch stark
- Jeder Xe Core liefert 512 Byte pro Takt
- Die L1-Kapazität beträgt 512 KB
- Memory-bound-Kernel, die in L1 passen, können auf Intels Architektur gut laufen
- Allerdings fehlt ein Mid-Level-Cache auf Ebene des Compute Tile, weshalb die Leistung stark einbrechen kann, sobald Daten nicht mehr in L1 passen
Scheduling und Ausführungseinheiten
- CDNA 3 verbessert nicht nur die Chiplet- und Cache-Struktur, damit der MI300X wie eine einzelne GPU erscheint, sondern entwickelt auch die Compute-Unit-Architektur schrittweise weiter, um die FP32-Auslastungsprobleme von CDNA 2 anzugehen
- CDNA 2 verarbeitet FP64 nativ und bot über packed execution die doppelte FP32-Rate
- Der Compiler musste zwei FP32-Werte in benachbarte Register packen und dieselbe Instruktion darauf ausführen
- Wenn Programmierer nicht explizit Vektoren verwendeten, war das für den Compiler oft schwer zuverlässig umzusetzen
- CDNA 3 umgeht dieses Problem mit einem flexibleren Dual-Issue-Mechanismus
- Er scheint eher einer Erweiterung der Multi-Issue-Funktionen von GCN zu ähneln als dem VOPD/Wave64-Ansatz von RDNA 3
- Der CU-Scheduler wählt in jedem Takt eines der vier SIMDs aus und prüft, ob dort ein ausführungsbereiter Thread vorhanden ist
- Wenn mehrere Threads bereit sind, konnte GCN bis zu fünf davon an die Ausführungseinheiten senden
- Das Dual-Issue von CDNA 3 dürfte weniger vom Compiler als davon profitieren, dass der Programmierer mit großer Dispatch-Größe genügend thread-level parallelism sichtbar macht
- Wenn ein SIMD mehr Threads gleichzeitig ausführt, steigt die Wahrscheinlichkeit, zwei Threads mit FP32-Instruktionen gleichzeitig zu finden
- Für den vollen FP32-Durchsatz sind mindestens zwei aktive Threads pro SIMD nötig
- In der Praxis ist wegen Speicher- oder Ausführungslatenzen jedoch meist eine noch höhere Occupancy erforderlich
- AMD erhöht die Zahl der Threads, die ein CDNA-3-SIMD verfolgen kann, deutlich von 8 auf 24
- Eine Vergrößerung der Kapazität der Vektor-Registerdatei wurde nicht erwähnt, obwohl diese Kapazität häufig die Zahl der Threads begrenzt, die ein SIMD gleichzeitig halten kann
- Die Multi-Issue-Fähigkeit könnte daher am besten bei einfachen Kernels mit geringer Register-Nutzung pro Thread funktionieren
- Dual-Issue kann auch die Bandbreite der Registerdatei zum Problem machen
- Das packed FP32 von CDNA 2 nutzte breite Registerdatei-Ports, die 64-Bit-Werte transportierten, sodass keine zusätzlichen Reads nötig waren
- Separate Instruktionen können auf unterschiedliche Register verweisen und dadurch mehr Reads erfordern
- AMD erklärt, dass das Source Caching über die Generationen verbessert wurde, sodass ein einzelner Read aus dem Vektorregister mehr nachgelagerte Vektor- oder Matrix-Operationen bedienen kann
- Wahrscheinlich geschieht das über einen größeren Register-Cache, der Port-Konflikte entschärft und die Ausführungseinheiten mit Daten versorgt
Matrix-Operationen und KI-Leistung
- Mit der Verbreitung von Machine Learning ist die Bedeutung der Matrixmultiplikation gestiegen, und Nvidia investierte stark in diesen Bereich, indem es in Volta und Turing Tensor Cores hinzufügte
- AMDs CDNA unterstützte ebenfalls Matrixmultiplikation, aber zeitgenössische Nvidia-Architekturen investierten stärker in den Matrix-Durchsatz für niedrig präzise Datentypen wie FP16
- Der MI300X verdoppelt den Matrix-Durchsatz pro CU gegenüber früheren CDNA-Generationen
- Das Chiplet-Design des MI300X ermöglicht sehr viele CUs und steigert so den Gesamtdurchsatz
- Nvidia bleibt dank hoher Matrix-Leistung pro SM ein starker Wettbewerber, und CDNA 3 setzt AMDs Linie fort, Nvidia mit starker Vektor-FP64-Leistung unter Druck zu setzen und zugleich eigenständig hohe KI-Leistung zu liefern
Änderungen beim Instruktions-Cache
- Die Compute Unit muss nicht nur auf den Datenspeicher zugreifen, sondern auch die Instruktionen selbst aus dem Speicher laden
- GPU-Code war traditionell einfach und der Codeumfang klein, sodass die Bereitstellung von Instruktionen vergleichsweise leicht war
- CDNA 2 und RDNA-GPUs nutzten weiterhin einen Instruktions-Cache von 32 KB, CDNA 3 erhöht diesen jedoch auf 64 KB
- auch die Assoziativität steigt von 4-way auf 8-way
- das erhöht die Trefferquote des Instruktions-Caches bei größeren und komplexeren Kernels
- AMD scheint Fälle im Blick gehabt zu haben, in denen CPU-Code einfach auf die GPU portiert wurde
- komplexer CPU-Code kann auf der GPU zur Belastung werden
- GPUs können die Latenz von Instruktions-Cache-Misses nur schwer durch weitreichendes Instruction Prefetching und präzise Branch Prediction verbergen
- ein größerer Instruktions-Cache hilft dabei, große Kernels aufzunehmen, und eine höhere Assoziativität reduziert Conflict Misses
- Die Instruktions-Cache-Instanz von CDNA 3 wird wie bei CDNA 2 von zwei Compute Units gemeinsam genutzt
- GPU-Kernels laufen normalerweise mit einer Work Size, die groß genug ist, um viele Compute Units auszulasten, daher ist das gemeinsame Nutzen des Instruktions-Caches eine effiziente Verwendung von SRAM
- wenn mehr Compute Units sich eine Cache-Instanz teilen, könnte es schwierig werden, die Anforderungen an die Instruktions-Bandbreite zu erfüllen
Unterschiede zwischen MI300X und MI300A
- Die größte Änderung von Generation zu Generation bei CDNA 3 ist die Speicherhierarchie, und die eigentliche Kernverbesserung liegt in der Ergänzung von Infinity Cache
- Das Hauptproblem des MI250X war, dass es eher zwei GPUs ähnelte, die sich dasselbe Paket teilen, als einer einzelnen GPU
- die Bandbreite zwischen den beiden GCDs lag bei 200 GB/s pro Richtung
- AMD kam zu dem Schluss, dass diese Bandbreite nicht ausreicht, damit der MI250X wie eine einzelne GPU erscheint, und erhöhte deshalb die Die-to-Die-Bandbreite deutlich
- MI300 erhöht die gesamte East-West-Bandbreite auf 2,4 TB/s pro Richtung und steigert sie damit gegenüber MI250X um das Zwölffache
- die gesamte North-South-Bandbreite ist mit 3,0 TB/s pro Richtung noch höher
- durch diese Erhöhung der Bandbreite kann MI300 nicht wie beim MI250X als zwei Beschleuniger, sondern als ein großer integrierter Beschleuniger erscheinen
- Die gesamte Ingress-Bandbreite eines einzelnen IO-Dies von 4,0 TB/s passt fast zu den 4,2 TB/s, die zwei XCDs nutzen können, weshalb das in der Praxis kein großes Problem darstellt
- ein einzelner IO-Die kann allerdings nicht die gesamte Speicherbandbreite von 5,3 TB/s ausschöpfen
- das ist ähnlich wie bei Ryzen 7000, wo ein einzelnes CCD die DDR5-Bandbreite wegen der Begrenzungen von Infinity Fabric nicht vollständig nutzen kann
- beim MI300X ist der Bandbreitenbedarf am höchsten, wenn alle Dies zusammenarbeiten; in diesem Fall verbraucht jeder Die etwa 1,3 TB/s, sodass es kein Problem ist, drei Viertel davon über Cross-Die-Links zu beziehen
- MI300A ist eine „Big-Iron“-APU, die denselben Base Die wiederverwendet und 6 CDNA3-XCDs mit 24 Zen-4-Kernen kombiniert
- CPU und GPU können sich denselben Speicheradressraum teilen
- zur Aufrechterhaltung der Kohärenz zwischen CPU und GPU müssen Daten nicht mehr über einen externen Bus kopiert werden
1 Kommentare
Meinungen auf Hacker News
Technisch gesehen haben AMD-Consumer-Karten eine hervorragende Rechenleistung. UE5 rendert Dreiecks-Meshes zum Beispiel per Compute statt über die Grafik-Pipeline: https://www.youtube.com/watch?v=TMorJX3Nj6U
Außerdem priorisiert nVidia Raytracing und DLSS gegenüber Rechenleistung und Speicherbandbreite, weshalb AMD-Karten oft vor vergleichbaren nVidia-Karten liegen.
Das Problem ist, dass kein Tech-Unternehmen D3D- oder Vulkan-Backends zu AI-Bibliotheken wie PyTorch hinzufügen will. nVidia tut es nicht, weil der Status quo gut für sie ist, und Intel und AMD tun es nicht, weil sie statt offener GPU-APIs CUDA durch ihre eigenen proprietären Alternativen ersetzen wollen
Allerdings ist das weder unausgereifte Produktsegmentierung noch ein Problem der übergeordneten Architektur. Spezialisierte Produkte sind in ihrem Bereich besser als Allzweckprodukte. Die Nachfrage nach Karten, die sowohl Compute als auch Gaming gut können, ist klein; solche Leute gibt es, aber es sind weniger als diejenigen, die sich nur um eine Seite kümmern.
Die Wirkung der Aufspaltung von GCN in RDNA und CDNA war sofort sichtbar. Vergleicht man die Radeon VII (GCN 5) mit der RX 5700 XT (RDNA 1), liegen sie in Spielen dicht beieinander, wobei die Radeon VII im Durchschnitt leicht vorn liegt, während die RX 5700 XT in Compute-Benchmarks deutlich zurückfällt. Beide nutzen TSMC 7 nm, aber die RX 5700 XT hat weniger Shader (2560 gegenüber 3840), einen kleineren Die (251 gegenüber 311 mm2) und niedrigere Leistungsaufnahme (225 gegenüber 300 W), was zeigt, dass ihre Gaming-Effizienz viel besser ist. Wegen geringerer Leistungsaufnahme, weniger Lärm und eines um mehrere Hundert Dollar niedrigeren Preises war sie für Gamer eine deutlich attraktivere Karte.
CDNA-Karten scheinen für Gaming nötige Komponenten wie Render Output Units zu fehlen. Daher gibt es keine offizielle Unterstützung für DirectX, OpenGL oder Vulkan. Ich habe noch nie von einem Fall gehört, in dem jemand darauf Spiele zum Laufen gebracht hätte. Stattdessen ist ihre Rechenleistung so gut, dass mehrere Unternehmen diese Karten trotz des überwältigenden CUDA-Ökosystems statt nVidia kaufen. 2013 schaffte es ein GCN-basierter Supercomputer in die Top 100, und das war das einzige GCN-basierte Top-100-System. Heute nutzen 8 der 10 energieeffizientesten Supercomputer CDNA-Beschleuniger, und auch der insgesamt schnellste Supercomputer auf Platz 1 verwendet CDNA
https://www.tomshardware.com/news/amd-enables-rocm-and-pytor...
Im Kern ist AMD ein Hardwareunternehmen (wie auch Lisa Sus Werdegang zeigt) und hat nicht schnell genug akzeptiert, dass CUDA der entscheidende Schlag ist. Ich erinnere mich daran, wie @Bridgman bei Phoronix immer wieder Rückzugsgefechte führte, um Entwickler bei der Stange zu halten. Das war ein Kampf, den man nur verlieren konnte.
Bis zu einem gewissen Grad ist das verständlich. Die Hardwaregeneration der 80er/90er denkt instinktiv, dass Hardware im Stack ganz oben steht, und AMDs Führung, einschließlich Su, stammt komplett aus dieser Richtung.
Kodura verstand, dass nVidia AMD überflügelte, weil CUDA auch auf Consumer-Karten läuft. Deshalb setzte er sich gegen Lisa Su für die Radeon VII ein, und diese Karte war über Jahre hinweg bis vor sehr Kurzem die einzige Consumer-Karte, die ROCm unterstützte. Kurz darauf wurde er faktisch entlassen, und auch die ausgezeichnete RVII wurde schnell eingestellt. Danach kam Wang und zementierte die Trennung zwischen Consumer- und Profi-Karten.
Jetzt versucht AMD verzweifelt, das zurückzudrehen, aber es ist zu spät. Es gibt mehrere Akteure, die konkurrieren wollen, aber im Grunde sind nur AAPL und Metal wirklich erwähnenswert.
AMD hat seine Chance verpasst
Trotzdem dürfte das der Verbreitung von AMD-Karten für Compute-Workloads nicht geholfen haben. Das Tolle an CUDA ist, dass man keine spezielle Beschleunigerkarte braucht, um CUDA-Code zu entwickeln
Wenn sie GPUs mit eigenem Geld oder Forschungsetats zum selben Preis wie normale Verbraucher kaufen müssten, hätte es vielleicht anders ausgesehen.
Persönlich halte ich die Art, wie NVidia in akademische und universitäre Forschungsumgebungen vordringt, für sehr unethisch
Danach wartete das Unternehmen weiter und setzte mehrmals darauf, dass der Markt für die von ihm geschaffenen Produkte „kommen“ würde.
In den letzten Jahren ist genau das tatsächlich passiert, was sich auch im Aktienkurs widerspiegelt. Andere Akteure liegen im Grunde 10 Jahre zurück, und angesichts der aktuellen Überhitzung und der Popularisierung von AI/ML-Workflows scheint es fast unmöglich, dass noch jemand aufholt
CUDA-Code lief dagegen auch mit neuen Generationen von Nvidia-Karten weiter
Die meisten kaufen bei Firmen wie Exxact oder Supermicro A6000 oder höher zu Endkundenpreisen
Seit der V100-Ära, also seit den DGX-1-Systemen, habe ich wohl nie gesehen, dass Forschende kostenlose GPUs bekommen hätten
Anders als CPUs versuchen GPUs nicht, das direkt auszugleichen. Stattdessen akzeptieren sie höhere Latenzen und parallelisieren im Vergleich zu CPUs viel breiter bzw. radikaler; zahlreiche parallele Pseudo-Threads sorgen für Latenzverbergung
Diesen Effekt sieht man zum Beispiel auch in Vorträgen zur Optimierung von GPU-Code
https://www.olcf.ornl.gov/wp-content/uploads/2019/12/03-CUDA...
Ein Beispiel dafür ist die Animation ab Folie 11
Das heißt, viele Aufgaben können rein in Registern und LDS abgearbeitet werden, und Zugriffe auf den globalen Speicher sind deutlich seltener als bei CPUs, wo nahezu alles im globalen Speicher liegt und es ungefähr 16 Architekturregister gibt
Trotzdem bleibt globaler Speicher ein Problem. Denn es geht nicht nur um Latenz, sondern auch um Bandbreite. Deshalb haben RDNA2 und Ada große Mengen an Last-Level-Cache hinzugefügt. Das dient auch dazu, Latenzen besser zu verbergen, der Hauptzweck ist aber die Rolle als Bandbreitenverstärker
Very Long Instruction Word (VLIW) bezeichnet eine Instruction-Set-Architektur, die darauf ausgelegt ist, Parallelität auf Befehlsebene (ILP) zu nutzen. Eine typische Central Processing Unit (CPU) lässt ein Programm in der Regel nur festlegen, welche Befehle in welcher Reihenfolge ausgeführt werden sollen; ein VLIW-Prozessor erlaubt es dem Programm dagegen, explizit anzugeben, welche Befehle parallel ausgeführt werden sollen. Dieses Design zielt darauf ab, höhere Leistung zu erzielen und zugleich die Komplexität zu vermeiden, die anderen Ansätzen innewohnt
Zu den traditionellen Methoden zur Steigerung der Prozessorleistung gehören Pipelining, bei dem Befehle in Teilschritte zerlegt und einige davon gleichzeitig ausgeführt werden, superskalare Architekturen, bei denen einzelne Befehle zur unabhängigen Ausführung an verschiedene Teile des Prozessors geschickt werden, und sogar Out-of-Order Execution, bei der Befehle in einer anderen Reihenfolge als im Programm ausgeführt werden. Diese Ansätze machen die Hardware komplex, weil der Prozessor intern alle Entscheidungen treffen muss
https://en.wikipedia.org/wiki/Very_long_instruction_word
Das lief nicht gut. Deshalb nannte man ihn Itanic
Die Annahme war, dass der Compiler Abhängigkeiten statisch gut genug erkennen könne, um mehrere sequentielle Ausführungspfade und einige Verzweigungspfade in denselben Befehl zu packen. In der Praxis stellte sich jedoch heraus, dass Compiler das nicht leisten konnten; deshalb ließ man den Prozessor dynamisch in einem sequentiellen Befehlsstrom nach Abhängigkeiten und parallelisierbaren Befehlen suchen
Das erfordert viel Arbeit, viele Chip-Ressourcen und viel Energie. Und es funktioniert nur bis zu einem gewissen Punkt gut; danach stößt man auf abnehmende Erträge. Genau dort scheinen wir heute zu sein
Es geht nicht um die Sprache, in der Befehle gesendet werden, sondern um die Art der Verarbeitung selbst
Und man sollte im Hinterkopf behalten, dass Begriffe wie VLIW4 oder VLIW5 bestimmte Implementierungen bezeichnen
https://en.wikipedia.org/wiki/Single_instruction,_multiple_d...
0: https://en.m.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud
1: https://trends.google.com/trends/explore?date=all&q=Compute&...