Arcturus (7nm, Compute-NextGen, 2020)

[Berniyh]

Ganz blöd geraten:
Vielleicht haben die bei der ganzen Rückportiererei von CUDA Code auf ROCm in den letzten 2-3 Jahren einfach festgestellt das es für HPC eher mehr Vector FP64/FP32 braucht und der ganze AI Kram dann eben doch am Ende überwiegend besser/einfacher über Matrix FP32 rennt weil die anderen Formate halt doch eher recht exotisch sind!?

:conf:
Dann würde sich doch trotzdem die Frage stellen: warum macht Nvidia das nicht auch so?

[Troyan]

nVidia macht es schon. Die Compiler übersetzen Matrizen-Berechnungen automatisch auf die TensorCores. Das FP32 nicht unterstützt wird, hat etwas mit der Relevanz zu tun. FP64 für HPC und FP32 für DL-Training. Da jedoch TF32 als Genauigkeit aus nVidia's Sicht ausreichend ist, existiert keine Notwendigkeit mehr für FP32.

[basix]

Da jedoch TF32 als Genauigkeit aus nVidia's Sicht ausreichend ist, existiert keine Notwendigkeit mehr für FP32.

Die Frage ist hier: Sehen das die Kunden / Benutzer auch so? Das wird sich nun anhand der Verkaufszahlen/Verbreitung der beiden Karten herausstellen. AMD hat zumindest einige HPC Wins einstreichen können.

CB hat es eigentlich ganz gut beschrieben: A100 adressiert einen etwas anderen Markt als Arcturus. Arcturus fokussiert eher auf "herkömmliche" Science mit etwas AI Zusatz und bei Nvidia ist es in etwa umgekehrt. Damit umgeht man fürs erste die direkte Konkurrenz mit Nvidia ein wenig und startet in einem anderen Anwendungsbereich ins HPC Accelerator Geschäft. Und man muss auch sehen: Arcturus ist bei ML/AI schneller als V100 (von den HW Daten her). Wenn hier die SW mitspielt hat man dennoch ein starkes Angebot bezüglich ML/DL.

Edit:
Was ist eigentlich der Unterschied zwischen Tensor Cores und Matrix Cores? Es werden bei beiden ja Matrizen verarbeitet. Oder ist das nur eine unterschiedliche Bezeichnung für mehr oder minder das selbe?

[AffenJack]

Die Frage ist hier: Sehen das die Kunden / Benutzer auch so? Das wird sich nun anhand der Verkaufszahlen/Verbreitung der beiden Karten herausstellen. AMD hat zumindest einige HPC Wins einstreichen können.


Dem Großteil der Kunden reicht schon BFloat16, nicht umsonst wurde das als neues Format von Google etabliert und von fast allen übernommen. TF32 holt dann noch paar zusätzliche Leute ab. Der Kreis der Leute die FP32 braucht ist sehr gering. In ML/DL wird man keine Blumentöpfe gewinnen.

Die HPC Wins kommen durch die pure DP Leistung ohne Matrix Operationen und das attraktive Preisverhältnis. Code muss nicht auf Nvs FP64 Tensor Cores angepasst werden und dann hat Arcturus ordentlich Durchsatz.

[Gipsel]

Was ist eigentlich der Unterschied zwischen Tensor Cores und Matrix Cores? Es werden bei beiden ja Matrizen verarbeitet. Oder ist das nur eine unterschiedliche Bezeichnung für mehr oder minder das selbe?Eigentlich schon. Tensor ist im Prinzip vom Begriff her allgemeiner (ein Tensor erster Stufe wird als Vektor dargestellt, ein Tensor zweiter Stufe durch eine eine Matrix usw.). Aber das, was in den Tensor-/Matrix-Cores gemacht wird, sind Operationen auf zweidimensionalen Arrays (also Matrizen oder Tensoren zweiter Stufe), im Wesentlichen beschleunigen die schlicht die Berechnung eines Matrixprodukts.

[Locuza]

@Locuza: hm interessant, danke für die Info.
Wenn also Einträge in den FW Dateien hier und da falsch sind (oder sein können), dann muss man evtl. auch Navi 31 unter einem anderen Licht betrachten ob der Tatsache, dass die Daten eigentlich zu identisch zu Navi 21 sind.
Bei Navi31 auf jeden Fall.
Je näher die GPU zum Release ist, desto wahrscheinlicher ist die Richtigkeit, wobei bei Arcturus das relativ spät noch falsch dastand bzw. ich weiß gar nicht, ob gewisse Strukturen richtig zugeordnet worden sind.


Was sind AGPR's?
Ja, gleiche Frage. Im Whitepaper stehen 128kB vGPRs pro SIMD (512kB pro CU). Aber da ist auch die Beschreibung von bf16 falsch. So wer weiß...
Das weiß ich auch nicht. :redface:
Ich habe es flapsig als AI Registers interpretiert, denn ansonsten fällt mir keine gute Alternative ein, wofür das A stehen sollte.

In den Treiber-Commits zu Arcuturs im letztem Jahr stand Folgendes indem Bezug:
" VGPR and AGPR have the same encoding, but SrcA and SrcB operands of mfma
instructions use acc[01] modifier bits to distinguish. These bits are
encoded as a virtual 9th bit of the register for these operands.

--

// Prefer VGPRs over AGPRs in mAI instructions where possible.
// This saves a chain-copy of registers and better ballance register
// use between vgpr and agpr as agpr tuples tend to be big.

// Scan for MFMA long latency instructions and try to add a dependency
// of available SALU instructions to give them a chance to fill MFMA
// shadow. That is desirable to fill MFMA shadow with SALU instructions
// rather than VALU to prevent power consumption bursts and throttle."

[Berniyh]

Das weiß ich auch nicht. :redface:
Aus llvm:
https://github.com/RadeonOpenCompute/llvm-project/blob/amd-stg-open/llvm/docs/AMDGPUUsage.rst
1088-1129 SGPR64-SGPR105 32 Scalar General Purpose Registers.
1130-1535 Reserved Reserved for future Scalar General Purpose Registers.
1536-1791 VGPR0-VGPR255 32*32 Vector General Purpose Registers when executing in wavefront 32 mode.
1792-2047 Reserved Reserved for future Vector General Purpose Registers when executing in wavefront 32 mode.
2048-2303 AGPR0-AGPR255 32*32 Vector Accumulation Registers when executing in wavefront 32 mode.
2304-2559 Reserved Reserved for future Vector Accumulation Registers when executing in wavefront 32 mode.
2560-2815 VGPR0-VGPR255 64*32 Vector General Purpose Registers when executing in wavefront 64 mode.
2816-3071 Reserved Reserved for future Vector General Purpose Registers when executing in wavefront 64 mode.
3072-3327 AGPR0-AGPR255 64*32 Vector Accumulation Registers when executing in wavefront 64 mode.
3328-3583 Reserved Reserved for future Vector Accumulation Registers when executing in wavefront 64 mode.


Hat AMD doch schön dokumentiert. ;)

[Locuza]

Gut zu wissen :)
Interessant das 32x32 definiert ist, da fragt man sich, ob früher oder später eine ähnliche Matrix-Unit in RDNA wandert und AMD es ähnlich wie Nvidia ausnutzt.

[Gipsel]

Gut zu wissen :)
Interessant das 32x32 definiert ist, da fragt man sich, ob früher oder später eine ähnliche Matrix-Unit in RDNA wandert und AMD es ähnlich wie Nvidia ausnutzt.Das sind 32x 32bit für Wavefront32 (64x 32bit für Wave64), genau wie die VGPRs.

[Savay]

Moment...war die 32er Wavefront nicht eigentlich nen neuer Modus für RDNA?!
Macht das CDNA dann am Ende zu ner Art GCN RDNA Hybrid?

[Gipsel]

Moment...war die 32er Wavefront nicht eigentlich nen neuer Modus für RDNA?!
Macht das CDNA dann am Ende zu ner Art GCN RDNA Hybrid?Nein, das kann man daran genau so wenig was ablesen wie Matrixeinheiten für RDNA (die bei CDNA auch Vektorregister benutzen und keine anders organisierten Matrixregister). Die Einträge da decken offenbar alle Fälle ab: GCN, RDNA und CDNA.

[basix]

Gibt es zur Instinct MI100 mittlerweile ein Review und Benchmarks?

[dildo4u]

Schätze mal fast alle Server Anbieter werden auf die neuen Epyc Modelle warten um Systeme mit MI100 zu bauen.

[mksn7]

Nah, der Vektor-L1 hatte auch schon bei GCN (oder schon bei den VLIW-Architekturen der Texture-L1) eine Bandbreite von 64Byte pro Takt.

Ich bin gerade dabei das dochmal selbst von Hand zu messen. Ich komm aber ums Verrecken nicht höher als 3416 GB/s, bei 60 CU und 1.8GHz entspricht das 31,6 B/cycle, was halt schon sehr genau auf 32B/cycle passen würde.

Ich weiß auch nicht so genau, ob das an den spezifischen loads liegt? Ich benutze HIP auf einer Radeon VII.

Das was ich an Dokumentation gesehen habe, hätte ich auch so interpretiert dass 64B/cycle möglich sind.

(mehr über den Messcode in spoiler)

Ich berechne ganz oft "sum += B[i] * C[i]" auf sehr kleinen arrays. Die Schleifen über i sind komplett geunrolled, und außenrum gibts noch eine Iterationsschleife.

Der generierte Maschinencode der inneren Schleife sieht eigentlich gut aus, hier nur die Variante mit 4 Summanden und 8 Loads, ich hab das auch noch mit mehr Elementen (soviel wie in den Cache reingeht), aber das ist kein Unterschied.


BB1_1:
v_mov_b32_e32 v7, s13
v_add_co_u32_e64 v8, s[0:1], s12, v2
v_mov_b32_e32 v10, s7
v_add_co_u32_e32 v6, vcc, s6, v2
v_addc_co_u32_e64 v9, s[0:1], v7, v5, s[0:1]
v_addc_co_u32_e32 v7, vcc, v10, v5, vcc
global_load_dwordx2 v[10:11], v[6:7], off
global_load_dwordx2 v[12:13], v[8:9], off
global_load_dwordx2 v[14:15], v[8:9], off offset:512
global_load_dwordx2 v[16:17], v[6:7], off offset:512
global_load_dwordx2 v[18:19], v[6:7], off offset:1024
global_load_dwordx2 v[6:7], v[6:7], off offset:1536
global_load_dwordx2 v[20:21], v[8:9], off offset:1024
global_load_dwordx2 v[8:9], v[8:9], off offset:1536
s_add_i32 s4, s4, -1
s_add_u32 s6, s6, s2
s_addc_u32 s7, s7, s3
s_add_u32 s12, s12, s2
s_addc_u32 s13, s13, s3
s_cmp_lg_u32 s4, 0
s_waitcnt vmcnt(6)
v_fma_f64 v[3:4], v[10:11], v[12:13], v[3:4]
s_waitcnt vmcnt(4)
v_fma_f64 v[3:4], v[16:17], v[14:15], v[3:4]
s_waitcnt vmcnt(1)
v_fma_f64 v[3:4], v[18:19], v[20:21], v[3:4]
s_waitcnt vmcnt(0)
v_fma_f64 v[3:4], v[6:7], v[8:9], v[3:4]
s_cbranch_scc1 BB1_1




Edit: Mit single precision komme ich auf 56B/cycle. Die Radeon VII hat natürlich nur 1/4 DP Durchsatz, aber das sollte hier kein Limiter sein. Außer sie haben die Rate für double loads auch halbiert, was aber irgendwie keinen Sinn macht.

[vinacis_vivids]

Gibt es zur Instinct MI100 mittlerweile ein Review und Benchmarks?


Koi Computers Announces Integrations with AMD Instinct MI100 GPUs for AI, Deep Learning
https://www.hpcwire.com/off-the-wire/koi-computers-announces-integrations-with-amd-instinct-mi100-gpus-for-ai-deep-learning/

ORNL Advance Galaxy
Simulations with AMD
Instinct™ MI100 GPUs

https://cdn11.bigcommerce.com/s-d88a2/content/ornl-amd-Instinct-mi100-case-study.pdf

Kostenlose reviews wirds aus Konstengründen nicht geben. Welcher normalo interessiert sich denn schon für eine Simulation des Universums :freak:

[Thunder99]

Wer ist denn hier schon normal? :freak:

[basix]

Welcher normalo interessiert sich denn schon für eine Simulation des Universums :freak:

Ich ;D

Wer ist denn hier schon normal? :freak:
:naughty:

[Nightspider]

Brauchen eventuell einen neuen Thread?

https://twitter.com/KOMACHI_ENSAKA/status/1363640350737199106

https://pbs.twimg.com/media/EuyfpdyVoAEPvAf?format=jpg&name=medium

https://pbs.twimg.com/media/Euv09NWU4AU9TVH?format=png&name=small

[Leonidas]

Frage ist, ob das "MCM" nicht eher auf zwei "MI100" auf einem Interposer hindeutet.

[mboeller]

AMD Trento?

Was könnte das sein? Milan ist ZEN3, und Genoa ZEN4

[AffenJack]

Trento ist wohl die Custom CPU für Frontier.

Zwei MI100 auf nem Interposer würden die Leistungsdaten von MI200 nicht schaffen, die man für Frontier versprochen hat. Zuviel Stromverbrauch. Eher 2 5nm 80 CU Chiplets für ein MCM. Das erklärt auch die ganzen 5nm 2021 Gerüchte von AMD. Trento könnte ebenso 5nm sein, wobei da auch 6nm passen würden.

[vinacis_vivids]

MI200 mit CDNA2 MCM uArch könnte 2021, also dieses Jahr noch erscheinen?

https://wccftech.com/amd-instinct-mi200-cdna-2-gpu-accelerator-mcm-architecture-2021-launch-rumor/

[basix]

AMD Trento?

Was könnte das sein? Milan ist ZEN3, und Genoa ZEN4
Trento ist wohl die Custom CPU für Frontier.

MI200 mit CDNA2 MCM uArch könnte 2021, also dieses Jahr noch erscheinen?

https://wccftech.com/amd-instinct-mi200-cdna-2-gpu-accelerator-mcm-architecture-2021-launch-rumor/



Trento könnte also Zen 3 CCDs + 3rd Gen Infinity Architecture IOD sein?

[Leonidas]

Zwei MI100 auf nem Interposer würden die Leistungsdaten von MI200 nicht schaffen, die man für Frontier versprochen hat. Zuviel Stromverbrauch. Eher 2 5nm 80 CU Chiplets für ein MCM. Das erklärt auch die ganzen 5nm 2021 Gerüchte von AMD. Trento könnte ebenso 5nm sein, wobei da auch 6nm passen würden.


Jap. So macht das alles Sinn.

[basix]

Frontier sollte so ca. 40-50 TFLOPs FP64 pro Kilowatt schaffen (1.5 EFLOPs / 30-40MW). Das wird auch mit etwas niedrig taktenden MI100 schwer (CPUs, Networking und Kühlung sind im Energieverbrauch auch dabei), ausser man geht in Richtung 1.0 GHz anstatt 1.5 GHz. 5nm ist die naheliegendste Auflösung.

Jetzt wäre meine Frage: CDNA1 oder CDNA2? In einer News (https://videocardz.com/newz/amd-instinct-mi200-mcm-based-accelerator-to-launch-this-year)steht was von GFX90A anstatt GFX908 und Full Rate FP64. Und gerade für HPC ist IFA3 sehr wertvoll. Deswegen tippe ich auf CDNA2, auch wenn CDNA1 noch sehr jung ist. 5nm, Full Rate FP64, identische CU-Anzahl und ~identische Taktraten: Mörderische FP64 pro Watt. 2x MI100 ergäbe 23.0 TFLOPs bei 300W. Mit 46 TFLOPs bei 600W + CPU + Kühlung kommt man in den Bereich, wo das passen könnte.

[davidzo]

Trento ist wohl die Custom CPU für Frontier.

Zwei MI100 auf nem Interposer würden die Leistungsdaten von MI200 nicht schaffen, die man für Frontier versprochen hat. Zuviel Stromverbrauch. Eher 2 5nm 80 CU Chiplets für ein MCM. Das erklärt auch die ganzen 5nm 2021 Gerüchte von AMD. Trento könnte ebenso 5nm sein, wobei da auch 6nm passen würden.

Trento ist = Badami: https://twitter.com/ExecuFix/status/1327377480995500032

Also Zen3 7nm.
Wahrscheinlicher ist dass Trento gegenüber Milan ein paar HPC spezifische Extensions bekommt. Ein bisschen so wie cooperlake gegenüber Skylake.
Das kann mit dem Vergabeverfahren für den Großauftrag zusammenhängen, dass die einfach bestimmte Extensions wie AVX-512, VNNI oder bfloat-16 gefordert haben. 2021 ist aber zu früh für Genoa und für AMD ist es einfacher einfach den FPUblock von Zen3 auszutauschen oder zu erweitern.

Deswegen tippe ich auf CDNA2, auch wenn CDNA1 noch sehr jung ist. 5nm, Full Rate FP64, identische CU-Anzahl und ~identische Taktraten: Mörderische FP64 pro Watt. 2x MI100 ergäbe 23.0 TFLOPs bei 300W. Mit 46 TFLOPs bei 600W + CPU + Kühlung kommt man in den Bereich, wo das passen könnte.

Ja, wie immer AMD die nächste CDNA auskopplung nennt, CDNA1 rev2, CDNA1.5 oder CDNA2 ist alles glaube ich nur eine Marketingfrage. Es ist halt weiterhin GFX90x. 5nm ist sehr wahrscheinlich und wird wenn dann auch immer erst bei GPUs genutzt. Und das Layout wird dann komplett synthetisiert wie immer bei AMDs ersten Chips in einem neuen Verfahren. Erwarte keine besonders hohen Taktraten, aber niedrigen Verbrauch und Flächenbedarf.

Für CPUs braucht man zu viel custom design, das dauert viel länger als rein synthetisiertes design mit cad tools. Und für APUs scheint AMD auch nur noch custom designte IP zu nehmen, selbst wenn die älter ist, siehe Navi vs RDNA1 bei renoir und cezanne.

[Leonidas]

Da es neuer Node ist, dürfte man das sicher gleich mit neuem Chip- und Architektur-Namen würdigen, auch wenn sich intern wenig geändert hat.

Aber damit erklären sich nicht nur die 5nm-Kontingente von AMD bei TSMC in 2021 - sondern somit wird "Arcturus 2" auch der 5nm-Pipecleaner für AMD. Gut für nachfolgenden RDNA3-Chips, dass man da schon Erfahrungen sammeln kann.

[Sunrise]

Man merkt inmer wieder, wie flexibel und schnell AMD auf Kundenwünsche reagiert, sowas geht nur mit einem sehr guten Zeitmanagement und Vorplanung.

Ich denke AMD wird dann wiedermal die erste 5nm HPC-GPU liefern, so ähnlich wie auch bei Vega20. Nur erwarte ich da dieses Mal deutlich mehr, da das nicht nur ein relativ (einfacher) Shrink sein sollte, aber man nutzt zu Anfang sicher nicht das maximale Potential des Nodes, bleibt dafür aber in einem gewissen Budget, kann weitere Verbesserungen einbringen und reitet die Erfolgswelle mit 5nm weiter, zudem ist man aktuell ja sowieso kapazitätslimitiert und damit ebnet man den Weg auch für RDNA3, der ja gänzlich anders werden soll.

Ich bin mal gespannt, ob das Teil schon auf dem speziell mit TSMC angepassten Node kommt, den TSMC hat ja in verschiedenen Interviews/Calls durchblicken lassen, dass HPC-Kunden da sehr starke Nachfrage signalisierten.

[basix]

Ich bin mal gespannt, ob das Teil schon auf dem speziell mit TSMC angepassten Node kommt, den TSMC hat ja in verschiedenen Interviews/Calls durchblicken lassen, dass HPC-Kunden da sehr starke Nachfrage signalisierten.

Ich gehe davon aus, nämlich N5P. Etwas anderes macht nicht so viel Sinn.

[vinacis_vivids]

Hoffentlich kommt noch ein Abklatsch von Acturius in 7nm mit Display-Engine raus.
32GB HBM², 1229 GB/s Bandbreite, 100 CUs = 6400SP, 2.0 Ghz GPU-CLK, 25.6 Tflop/s fp32, 100 Tflop/s fp16, 12.5 Tfop/s fp64
Mit so ner GPU kann man allerlei Dinge anstellen.

[Piefkee]

Frontier sollte so ca. 40-50 TFLOPs FP64 pro Kilowatt schaffen (1.5 EFLOPs / 30-40MW). Das wird auch mit etwas niedrig taktenden MI100 schwer (CPUs, Networking und Kühlung sind im Energieverbrauch auch dabei), ausser man geht in Richtung 1.0 GHz anstatt 1.5 GHz. 5nm ist die naheliegendste Auflösung.

Jetzt wäre meine Frage: CDNA1 oder CDNA2? In einer News (https://videocardz.com/newz/amd-instinct-mi200-mcm-based-accelerator-to-launch-this-year)steht was von GFX90A anstatt GFX908 und Full Rate FP64. Und gerade für HPC ist IFA3 sehr wertvoll. Deswegen tippe ich auf CDNA2, auch wenn CDNA1 noch sehr jung ist. 5nm, Full Rate FP64, identische CU-Anzahl und ~identische Taktraten: Mörderische FP64 pro Watt. 2x MI100 ergäbe 23.0 TFLOPs bei 300W. Mit 46 TFLOPs bei 600W + CPU + Kühlung kommt man in den Bereich, wo das passen könnte.

Mi200 = CDNA2 >>Frontier
Mi300 = CDNA3 >> El caption (speku)

Cpu von Frontier ist Zen3 CCD mit Zen4 IO ( DDR5) + HBM
CPU von el caption = Zen4 CCD + Zen4 IO + HBM

[davidzo]

Man merkt inmer wieder, wie flexibel und schnell AMD auf Kundenwünsche reagiert, sowas geht nur mit einem sehr guten Zeitmanagement und Vorplanung.

Umgekehrt wird ein Schuh draus: Flexibel auf Kundenwünsche reagieren kann man nur wenn nicht zu viel vorgeplant und gemanaged ist. Mehr Management / Planung frisst solche Flexibilität auf und mehr Pläne heißt meistens auch dass mehr Deadlines gerissen werden.
Jim Keller hat das ganz gut auf den Punkt gebracht was gutes management ausmacht: Nämlich eben nicht ein Framework vorgeben und und Pläne machen nach denen die Leute zu arbeiten haben, sondern immer wieder kreatives Chaos stiften, was die "haben wir schon immer so gemacht"-Mentalität einer großen Corporation aufbricht.
https://youtu.be/G4hL5Om4IJ4?t=1485

AMD arbeitet intern zumindest in einigen Dev-Teams mit SCRUM und in short Sprints. Das bedeutet extrem wenig Vorrausplanen, teilweise nur um wenige Wochen und wenn langfristig etwas definiert wird, dann sehr inkonkret in form von "user stories" und nicht in form von vor-definierten Funktionen. Das bedeutet auch klare Rollenverteilung und dass das Management sich nicht in Engineeringentscheidungen einmischt oder in laufende sprints hineingrätscht, sondern eher den Vermittler zwischen dem Kunden und dem Engineeringteam spielt und auch ansonsten eher als externer Stakeholder auftritt und nicht als "Besitzer" oder "Chef" des Teams.
Der Vorteil dieser Art von Projektmanagement ist, dass man effektiver auf die Kundenwünsche eingehen kann weil man jeden Sprint neue bzw. geänderte Wünsche berücksichtigen kann und nicht einmal am Anfang alles festlegt und dann daran gebunden ist. Auch sind solche Projekte meistens schneller in der Ausführung als Wasserfall-Projektmanagement, da man flexibler auf unknown unknowns reagieren kann, die bei Wasserfall gleich eine Verschiebung der gesamten Prozesskette verursachen.

btw, zu AMDs produktentwicklung in seiner Zeit sagt Keller dass die intern viel modularisiert haben, so dass IP ganz unterschiedlicher Herkunft und Zwecke einfach zusammen gepackt werden kann und funktioniert: https://youtu.be/G4hL5Om4IJ4?t=2322

[Iscaran]

Codename Aldebaran für den Nachfolger(?) von Arcturus.
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Aldebaran-Linux-Posted
"This patch set adds support for the Aldebaran GPU. This
includes support for all of the IP blocks on the ASIC."
https://lists.freedesktop.org/archives/amd-gfx/2021-February/059694.html

Auch HBM2E dürfte da wohl dazugehören:
drm/amdgpu: correct vram_info for HBM2E
drm/amd/pm:add aldebaran support for getting bootup values
drm/amdpgu: add ATOM_DGPU_VRAM_TYPE_HBM2E vram type

Außerdem VCN2.6:
drm/amdgpu: add Aldebaran to the VCN family
drm/amdgpu/vcn2.6: Add vcn2.6 support

UND MCM-Design für Aldebaran ist bestätigt durch die Treiberinfos meint jemand im Phoronix-Forum:
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1240920-amd-radeon-aldebaran-gpu-support-published-for-next-gen-cdna
Angeblich weil der Eintrag:
drm/amd/pm: Enable performance determinism on aldebaran
Auf einer per-die Basis operiert.

EDIT: Ich denke die Info stammt aus der Patch-Note selbst:
https://gitlab.freedesktop.org/agd5f/linux/-/commit/c33f48b92f8861ff6842872c1d6843ac930606d0
Performance Determinism is a new mode in Aldebaran where PMFW tries to
maintain sustained performance level. It can be enabled on a per-die
basis on aldebaran. To guarantee that it remains within the power cap,
a max GFX frequency needs to be specified in this mode. A new
power_dpm_force_performance_level, "perf_determinism", is defined to enable
this mode in amdgpu. The max frequency (in MHz) can be specified through
pp_dpm_sclk. The mode will be disabled once any other performance level
is chosen.

Es gibt noch kein extra Aldebaran Topic oder ?

[Leonidas]

Ist als reiner HPC-Beschleuniger vermutlich zu uninteressant. Eventuell könnte man einen generellen Thread für HPC-Beschleuniger aufmachen, da gibt es ja auch andere außer AMD, NV & Intel.

[fondness]

Naja, der Arcturus Thread hat jetzt nicht so wenig Beiträge. :)

[BoMbY]

Ich würde vielleicht einfach diesen Thread umbenennen in sowas wie:

AMD CDNA (Arcturus/MI100; Aldebaran/MI200; ...)

[basix]

Trento könnte also Zen 3 CCDs + 3rd Gen Infinity Architecture IOD sein?

Noch zu dem Thema Trento: Könnte eigentlich auch >8 CCDs sein. Compute Density ist enorm wichtig bei HPC. z.B. 12x CCDs und 400W pro CPU.

[mksn7]

Ich bin gerade dabei das dochmal selbst von Hand zu messen. Ich komm aber ums Verrecken nicht höher als 3416 GB/s, bei 60 CU und 1.8GHz entspricht das 31,6 B/cycle, was halt schon sehr genau auf 32B/cycle passen würde.

Ich weiß auch nicht so genau, ob das an den spezifischen loads liegt? Ich benutze HIP auf einer Radeon VII.

Das was ich an Dokumentation gesehen habe, hätte ich auch so interpretiert dass 64B/cycle möglich sind.

(mehr über den Messcode in spoiler)

Ich berechne ganz oft "sum += B[i] * C[i]" auf sehr kleinen arrays. Die Schleifen über i sind komplett geunrolled, und außenrum gibts noch eine Iterationsschleife.

Der generierte Maschinencode der inneren Schleife sieht eigentlich gut aus, hier nur die Variante mit 4 Summanden und 8 Loads, ich hab das auch noch mit mehr Elementen (soviel wie in den Cache reingeht), aber das ist kein Unterschied.


BB1_1:
v_mov_b32_e32 v7, s13
v_add_co_u32_e64 v8, s[0:1], s12, v2
v_mov_b32_e32 v10, s7
v_add_co_u32_e32 v6, vcc, s6, v2
v_addc_co_u32_e64 v9, s[0:1], v7, v5, s[0:1]
v_addc_co_u32_e32 v7, vcc, v10, v5, vcc
global_load_dwordx2 v[10:11], v[6:7], off
global_load_dwordx2 v[12:13], v[8:9], off
global_load_dwordx2 v[14:15], v[8:9], off offset:512
global_load_dwordx2 v[16:17], v[6:7], off offset:512
global_load_dwordx2 v[18:19], v[6:7], off offset:1024
global_load_dwordx2 v[6:7], v[6:7], off offset:1536
global_load_dwordx2 v[20:21], v[8:9], off offset:1024
global_load_dwordx2 v[8:9], v[8:9], off offset:1536
s_add_i32 s4, s4, -1
s_add_u32 s6, s6, s2
s_addc_u32 s7, s7, s3
s_add_u32 s12, s12, s2
s_addc_u32 s13, s13, s3
s_cmp_lg_u32 s4, 0
s_waitcnt vmcnt(6)
v_fma_f64 v[3:4], v[10:11], v[12:13], v[3:4]
s_waitcnt vmcnt(4)
v_fma_f64 v[3:4], v[16:17], v[14:15], v[3:4]
s_waitcnt vmcnt(1)
v_fma_f64 v[3:4], v[18:19], v[20:21], v[3:4]
s_waitcnt vmcnt(0)
v_fma_f64 v[3:4], v[6:7], v[8:9], v[3:4]
s_cbranch_scc1 BB1_1




Edit: Mit single precision komme ich auf 56B/cycle. Die Radeon VII hat natürlich nur 1/4 DP Durchsatz, aber das sollte hier kein Limiter sein. Außer sie haben die Rate für double loads auch halbiert, was aber irgendwie keinen Sinn macht.

Ich hab das nochmal auf einer MI100 nachgemessen, aber da ist das Ergebnis leider genau das Gleiche. Also weder lag es an einer künstlichen Limitierung, noch hat sich da bei CDNA messbar etwas geändert

[basix]

Sooo, da AMD gestern den V-Cache vorgestellt hat: Wäre das was für CDNA2? Damit träte man in Konkurrenz mit Intels Rambo-Cache auf Ponte Vecchio. 8-12hi ist vermutlich das Maximum. Ergibt bei 64MB Slices allerdings bereits 512...768MByte. Packt man pro Memory Controller (4-6x HBM2e) so einen V-Cache drauf, landet man bei 2048...3072 oder 3072...4608 MByte an Cache. Es gab irgendwann mal von Nvidia ein Paper (finde es leider gerade nicht), wo der Performance Uplift bei ML/AI bei ca. 1...2GByte shared LLC schon nahe am theoretischen Maximum war.

Da der V-Cache pro Stack ~2TB/s liefern soll, hätte man 8...12 TByte/s Bandbreite aus dem LLC.

[mksn7]

Sooo, da AMD gestern den V-Cache vorgestellt hat: Wäre das was für CDNA2? Damit träte man in Konkurrenz mit Intels Rambo-Cache auf Ponte Vecchio. 8-12hi ist vermutlich das Maximum. Ergibt bei 64MB Slices allerdings bereits 512...768MByte. Packt man pro Memory Controller (4-6x HBM2e) so einen V-Cache drauf, landet man bei 2048...3072 oder 3072...4608 MByte an Cache. Es gab irgendwann mal von Nvidia ein Paper (finde es leider gerade nicht), wo der Performance Uplift bei ML/AI bei ca. 1...2GByte shared LLC schon nahe am theoretischen Maximum war.

Da der V-Cache pro Stack ~2TB/s liefern soll, hätte man 8...12 TByte/s Bandbreite aus dem LLC.

8-12 TB/s ist in der Größenordnung der L1 cache Bandbreite einer MI100 heute, und deutlich mehr als die L2 Bandbreite. Soviel Bandbreite kann niemals verwertet werden, vor allem nicht wenn der noch ein wenig Latenz hat. Soviel Bandbreite würde nur zu einem deutlich größeren Chip passen.

[basix]

Ich gehe bei CDNA2 auch von deutlich grösser aus ;) 1.5x oder 2x

A100 80GB hat 2TB/s Speicherbandbreite. V100 L2$ wurde mit 2.155 TB/s (https://arxiv.org/pdf/1903.07486.pdf) gemessen und A100 soll laut Nvidia 2.3x Bandbreite haben, was ~5TB/s entspricht. Jetzt denke dir eine hypothetische 16k Shader-Core GPU vor (2x MI100) und die 8...12TB/s hören sich nicht mehr so wahnwitzig an ;) Speziell, wenn man noch stärker in Richtung ML/AI geht.

[w0mbat]

CDNA2 hat auf jeden Fall mehrere dies:

On aldebaran, only primary die fetches valid power data. Show power/energy values as 0 on secondary die. Also, power limit should not be set through secondary die.
https://lists.freedesktop.org/archives/amd-gfx/2021-June/065161.html