AMD - Aldebaran: CDNA2 GPU, MCM, 3rd Gen Infinity Architecture, HBM2e [Archiv]

mksn7

2021-07-02, 10:43:56

@Locuza:
Auf full rate FP64 habe ich auch schon spekuliert. Ist das deine Speku oder gibt es Indizien dazu?

Ich dachte damals full rate fp64 macht keinen Sinn, weil fp64 = fp32 rate keinen Sinn macht. Jup, deswegen ist es full rate fp64 und double rate fp32...

Dann steigt aber hoffentlich die L1 cache Bandbreite auch entsprechend! Bei dem Trauerspiel CDNA bis jetzt braucht es jetzt schon ein Verhältnis von 4:1 DP FlIns:load (floating point instructions pro load), und das auch nur wenn man die offizielle rate von 64B/Takt annimmt, Bei den exakt 32B/Takt die ich geschafft hab zu messen sind das sogar 8:1 FlIn:ld.

Recht viele codes produzieren eher so ein 1:1 oder 1:2 Verhältnis.

Und was ich noch erwarte / spekuliere: V-Cache. 2...4 Stacks pro Die (entweder je Speichercontroller oder je zwei Controller auf einen V-Cache zusammengefasst). Sonst wird es schwierig, bei full rate FP64 die Engines zu füttern. Selbst mit HBM2e @ 3.2 GT/s kommt man "nur" auf 3.2 TByte/s. Das ist gerade mal doppelt so viel wie bei A100 und das bei ~5x FP64 FLOPS (z.B. 224 CUs @ 1.75 GHz @ 500W = 50 TFLOPs FP64). Wenn du dann noch mit 2x FP64 Rate über deine Matrix Units v2 rechnest, wird es mit Byte/FLOP dann endgültig knapp.

Mit deinen Daten ist das eine machine balance von 15.7 Flops/B, im Vergleich zu den 8 Flop/B einer V100. Für die meisten codes macht das wahrscheinlich gar nicht soviel aus, die sind dann statt sehr sehr memory bound eben sehr sehr sehr memory bound. An die 1.75 Ghz mag ich nicht so ganz glauben, jedenfalls nicht ausgehen von dem ich von einer MI100 kenne.
Anekdotische Daten aus der Erinnerung: Ein code mit ~6 TFlop/s (von 11.5 Pmax) hängt im 300W TDP limit, und dann throttelt der Takt auch schon von 1.51 GHz auf ~1.3 GHz. Macht eine Effizienz von 20 GFlops/W. Codes die nicht gleichzeitig noch viel Daten durch die Speicherhierarchie schaufeln brauchen da vielleicht noch ein bisschen weniger Strom, aber auch auf der Green500 haben die besten Systeme nur ~30 GFlop/W.

50 TFlop/s bei 500W wären dann 100 GFlop/W, also schon ein Rießenschritt. Was ist bzgl Fertigungsverfahren bei MI200 bekannt? Aber es ist ja auch noch nicht klar was sich and der Architektur noch alles ändert. Vielleicht kommt ja was von der RDNA Effizienzmagie um der zugrundeliegenden GCN Architektur auf die Sprünge zu helfen.

Aber ja, im HPC nix mit Infinity Cache oder V-Cache oder irgendwas zu machen wäre eine Rießenverschwendung. In dem Feld hätte ich das viel eher erwartet als im Gamingbereich.

basix

2021-07-02, 11:16:44

100 GFlop/W sind ja nur für MI200. Das System hat sicher weniger. CPUs, Networking und Kühlung kommt noch obendrauf. Bei 1.5 ExaFlop/s von Frontier benötigt man ~50 GFlop/W bei 30MW Systemverbrauch. Aber ja, 100 GFlop/W sind eher das Maximum, was möglich ist. Und wie du mit deinem Beispiel zeigst, real beim Anwender kommt dann evtl. weniger an.

Fertigung der Chiplets ist vermutlich N5(P). Etwas anderes würde mich überraschen.

AffenJack

2021-07-02, 11:41:56

Ich dachte damals full rate fp64 macht keinen Sinn, weil fp64 = fp32 rate keinen Sinn macht. Jup, deswegen ist es full rate fp64 und double rate fp32...

Mal einfach so gefragt, wo ist eigentlich der Unterschied ob man nun Full Rate FP64 und Double FP32 geht oder es wie Nvidia gemacht hätte und die FP32 Units verdoppelt, somit bei AMDs 1:2 DP :FP32 doch das gleiche Verhältniss gehabt hätte?

basix

2021-07-02, 12:09:02

Irgendwie findet man von MI100 keine schlauen Benchmarks. Aber hier als Referenz zwei HPC System von Dell, eines mit MI100 und eines mit A100.
https://infohub.delltechnologies.com/p/hpc-application-performance-on-dell-emc-poweredge-r7525-servers-with-the-amd-mi100-accelerator/
https://infohub.delltechnologies.com/p/hpc-application-performance-on-dell-poweredge-r7525-servers-with-nvidia-a100-gpgpus-1/

A100 erreicht ~12 TFLOPs in Linpack über Tensor-FP64.

Locuza

2021-07-02, 13:21:06

Die Dies werden gem Schaubikd per Die to Die Crosslinks verbunden. Weiß man wie genau mit welcher Technologie das gemacht wird bspw Interposer oder mit Stacking und ob die kolportierten N3x Dies ähnlich verbunden werden?
Bei Aldebaran mit hoher Wahrscheinlichkeit Interposer. TSMC kann bis 2500mm2 gehen und ein Interposer wird wegen HBM sowieso benötigt.
Was genau AMD umsetzen wird ist meines Wissens nicht bekannt.
In dem Aspekt habe ich auch auf eine Interposerlösung spekuliert, weil das zum bisherigen Design-Flow passen würde.
CoWoS-L mit Silicon Bridge, konzeptionell das gleiche wie Intels EMIB, soll mit einer größeren Anzahl an Chips in Q2 2021 qualifiziert sein:
https://images.anandtech.com/doci/16031/Advanced%20Packaging%20Technology%20Leadership.mkv_snapshot_16.44_%5B2020.08.25_ 14.14.27%5D.jpg
https://www.anandtech.com/show/16031/tsmcs-version-of-emib-lsi-3dfabric

Zeitlich gesehen ist AMD iirc völlig vorne dran mit der 3D-Integration vom Cache, aber CDNA2 ist ein großes Projekt und soll Ende 2021 an einen Supercomputer ausgeliefert werden.
Ich bin da etwas pessimistischer eingestellt.

@Locuza:
Auf full rate FP64 habe ich auch schon spekuliert. Ist das deine Speku oder gibt es Indizien dazu?

Und was ich noch erwarte / spekuliere: V-Cache. 2...4 Stacks pro Die (entweder je Speichercontroller oder je zwei Controller auf einen V-Cache zusammengefasst). Sonst wird es schwierig, bei full rate FP64 die Engines zu füttern. Selbst mit HBM2e @ 3.2 GT/s kommt man "nur" auf 3.2 TByte/s. Das ist gerade mal doppelt so viel wie bei A100 und das bei ~5x FP64 FLOPS (z.B. 224 CUs @ 1.75 GHz @ 500W = 50 TFLOPs FP64). Wenn du dann noch mit 2x FP64 Rate über deine Matrix Units v2 rechnest, wird es mit Byte/FLOP dann endgültig knapp.

Und V-Cache würde der Energieeffizienz gut tun.

Edit:
Ah, sind nur 1024 FLOPS/clk für FP16. Wäre auf den gesamten Chip gesehen ähnlich viele TFLOPS wie bei A100, aber mit doppelter Anzahl Compute Cores. Und INT8/INT4 bekommt wirklich kein zusätzliches Speedup? Wäre schade.
Full-Rate FP64 und Packed FP32 werden von den LLVM-Patches für Aldebaran gelistet:

"def FeatureISAVersion9_0_A : FeatureSet<
[FeatureGFX9,
FeatureGFX90AInsts,
FeatureFmaMixInsts,
FeatureLDSBankCount32,
FeatureDLInsts,
FeatureDot1Insts,
FeatureDot2Insts,
FeatureDot3Insts,
FeatureDot4Insts,
FeatureDot5Insts,
FeatureDot6Insts,
Feature64BitDPP,
FeaturePackedFP32Ops,
FeatureMAIInsts,
FeaturePkFmacF16Inst,
FeatureAtomicFaddInsts,
FeatureMadMacF32Insts,
FeatureSupportsSRAMECC,
FeaturePackedTID,
FullRate64Ops]>;"

Quelle:
https://github.com/llvm/llvm-project/commit/a8d9d50762c42d726274d3f1126ec97ff96e2a22#diff-9cb5014474ced79f5a4786ac64c4ffcdd456f2630288bbc523180772848713e9R933
_________

Ich selber erwarte keinen V-Cache bei großen Chips, würde das Ganze noch einmal deutlich komplexer gestalten, die Yields sehen sicherlich schlechter aus und strukturelle Stabilität wäre ein noch größeres Thema.

3.2 Gbps würden pro Chip immerhin 33% mehr Bandbreite darstellen, als bei CDNA1.
Fraglich ist auch, wie hoch die Taktraten ausfallen werden, im Optimalfall wird es nicht deutlicher dramatischer ausfallen.
_________

Rein von den gelisteten Instruktionen für Machine Learning sind "nur" FP64-Operationen dazu gekommen und BFLOAT16 fällt doppelt so schnell aus.
Der Rest ist identisch, gleiche FP32-Rate, INT8 nach wie vor nur so schnell wie FP16 und INT4-Support gibt es nach wie vor nicht.

General-Compute, FP64-Powerhouse, eine bessere Systemarchitektur mit Unified Memory und Cache Coherence waren augenscheinlich AMD's Zielpunkte, low precision matrix ops dagegen nicht.

[...] Was ist bzgl Fertigungsverfahren bei MI200 bekannt? Aber es ist ja auch noch nicht klar was sich and der Architektur noch alles ändert. Vielleicht kommt ja was von der RDNA Effizienzmagie um der zugrundeliegenden GCN Architektur auf die Sprünge zu helfen.

[...]
Fertigung der Chiplets ist vermutlich N5(P). Etwas anderes würde mich überraschen.
Interessanterweise sprechen AMDs Roadmap nur von "Advanced Node" in Bezug auf CDNA2 und RDNA3, während man bei Genoa 5nm bestätigt hat.
Mal sehen, ob AMD mit ihren Entscheidungen überrascht.

LasterCluster

2021-07-02, 14:27:13

Mal einfach so gefragt, wo ist eigentlich der Unterschied ob man nun Full Rate FP64 und Double FP32 geht oder es wie Nvidia gemacht hätte und die FP32 Units verdoppelt, somit bei AMDs 1:2 DP :FP32 doch das gleiche Verhältniss gehabt hätte?

Packed FP32 ist doch nicht einfach double rate, oder? Ich dachte immer, dass es Code Anpassungen braucht um den boost zu nutzen wie bei RPM

mksn7

2021-07-02, 14:58:52

Packed FP32 ist doch nicht einfach double rate, oder? Ich dachte immer, dass es Code Anpassungen braucht um den boost zu nutzen wie bei RPM

Die Frage ist, ob die Registerbreite auf 8B ausgedehnt wird. Wenn ja, dann dürfte es genauso sein wie bei packed fp16, dass die Operanden in der oberen/unteren Hälfte des gleichen Registers stehen.

Sonst könnte es auch möglich sein, für jeden Operandenslot zwei unterschiedliche Register anzugeben. Dann ist es die Verantwortung des compilers, zwei unabhängige, gleiche fp32 Operationen zu finden und in die gleiche Operation zu packen.

fondness

2021-07-02, 16:24:30

Das allererste Posting dieses Threads sollte am Anfang kurz ein paar Fakten zu diesem Chip notieren - damit klarer ist, worüber es hier geht.

Sorry, habs eingefügt.

Aktuell bekannte Daten:
- Zweite Gen Compute-only Architektur von AMD
- Verkaufname: AMD Instinct MI200
- 2 Chip MCM
- 256 CUs / 16.384 SPs
- 8192 bit HBM-Interface
- 128GB HBM2e
- Full-Rate FP64
- 3rd Gen Infinity Architecture mit hoher Bandbreite und memory coherence zu AMDs EPYC Genoa
- Launchdatum: Ende 2021

Falls jemand noch Anmerkungen hat bitte melden :)

Bei angenommenen 2Ghz Takt wäre man also bei unfassbaren 64TFLOPS FP64 Leistung :eek:. Oder hab ich mich da verrechnet?! Eine Nvidia A100 kommt auf nichtmal 10 TFLOPs.

fondness

2021-07-02, 16:55:14

Interessanterweise sprechen AMDs Roadmap nur von "Advanced Node" in Bezug auf CDNA2 und RDNA3, während man bei Genoa 5nm bestätigt hat.
Mal sehen, ob AMD mit ihren Entscheidungen überrascht.

Ich würde auf 6nm tippen. Damals war glaube ich der 6nm Fertigungsprozess noch nicht offiziell, das würde auch erklären, warum AMD von "Advanced Node" spricht.

mksn7

2021-07-02, 16:55:53

Woher kommen die 2 GHz? So hoch geht der Takt bestimmt nicht, jedenfalls nicht unter Last.

Die MI100 hat auch nur 120 CUs, angeblich sogar der Vollausbau.

Locuza

2021-07-02, 17:06:20

1,5 GHz Spitzentakt sind es bei der MI100 bei 300W Total-Board-Power.
Bei doppelter CU-Anzahl kann man von niedrigeren Takten ausgehen, vor allem ohne 5nm müssten wohl starke Einschnitte gemacht werden.

Laut Treiber-Einträgen bei der L2$-Konfiguration gibt es nur (aktive) 14 CUs pro Shader-Engine.
Bei acht SEs wären es dann 112 CUs pro Chip, 8 weniger als bei der MI100 mit 120 Einheiten.
Insgesamt 2x112 CUs = 224 CUs.

fondness

2021-07-02, 17:18:44

Woher kommen die 2 GHz? So hoch geht der Takt bestimmt nicht, jedenfalls nicht unter Last.

Die MI100 hat auch nur 120 CUs, angeblich sogar der Vollausbau.

War nur eine Annahme, deshalb schrieb ich "bei angenommenen 2Ghz Takt", das konnte man eben schön im Kopf rechnen :).

1,5 GHz Spitzentakt sind es bei der MI100 bei 300W Total-Board-Power.
Bei doppelter CU-Anzahl kann man von niedrigeren Takten ausgehen, vor allem ohne 5nm müssten wohl starke Einschnitte gemacht werden.

Laut Treiber-Einträgen bei der L2$-Konfiguration gibt es nur 14 CUs pro Shader-Engine.
Bei acht SEs wären es dann 112 CUs pro Shader-Engine, 8 weniger als bei MI100 mit 120 Einheiten.
Insgesamt 2x112 CUs = 224 CUs.

Okay, danke für die Infos. Allerdings würde ich eher auf deutlich mehr als 300W tippen, als auf viel weniger als 1,5Ghz. A100 liegt ja auch schon bei 400W. Irgendwann wird weniger Takt auch nicht mehr energieeffizienter und bei 300W hätte man wohl eher weniger CUs verbaut.

Das wären dann also bei 224CUs und 1,5Ghz Takt noch immer ~43TFLOPs FP64 Leistung.

Zossel

2021-07-02, 17:42:43

Rein von den gelisteten Instruktionen für Machine Learning sind nur "FP64"-Operationen dazu gekommen und BFLOAT16 fällt doppelt so schnell aus.

In dem Markt sind auch neue/weitere Player unterwegs: https://www.golem.de/news/mlperf-training-google-und-graphcore-ueberholen-nvidia-2107-157783.html

Locuza

2021-07-02, 20:47:51

In Bezug auf Graphcore gab es Heute die folgenden Analysen zu deren stark Cherry/Fantasy-Picked Marketingaussagen in Bezug auf ihren MLPerf1.0 "Sieg":
https://www.servethehome.com/graphcore-celebrates-a-stunning-loss-at-mlperf-training-v1-0/
https://semianalysis.substack.com/p/graphcore-looks-like-a-complete-failure

Perf/mm² stinkt mächtig gegenüber GA100 ab, Perf/Watt ist deutlich schlechter und die Leistung ebenso.
Zusätzlich gewinnt Nvidia auch deutlich bei der Perf/$, wenn man nicht den fiktiven Listenpreis von 299K annimmt, sondern was man wirklich über Rabatte für ganze Cluster bekommt oder von verkauften OEM-Maschinen, wo letztere laut Servethehome bei 130-180K liegen sollen.

Ein allgemein wichtiges Stichwort ist natürlich die Software.
Es hängt sehr viel davon ab und selbst die beste HW kann als zahnloser Tiger enden.

Mal sehen wie es AMD und Intel in den nächsten Jahren hierbei ergehen wird.
AMD werkelt seit Ewigkeiten an ROCm und rund ist das Ganze noch lange nicht, aber immerhin hat man den Frontier und El Capitan Supercomputer-Deal für sich verbuchen können.
Das garantiert eine gewisse Abnahmemenge und eine Zusammenarbeit mit vielen Fakultäten, was auch den Software-Stack voran treiben wird.
Mit Xilinx könnte man auch noch gewisse Inference-Marktsegmente für sich gewinnen, zumindest wenn man deren Marketingaussagen glauben möchte, haben FPGAs handfeste Vorteile gegenüber anderen Architekturen.

Und immer mehr spielt auch die ganze Systemarchitektur eine wichtige Rolle, die immer mehr aus einer Hand kommt, wo der ganze HW/SW-Stack optimiert und passend konfiguriert ist.

Unicous

2021-07-05, 20:41:16

https://i.imgur.com/9y2ZZY4.png

128GB.:freak:

Skysnake

2021-07-05, 20:48:26

Tja AMD klotzt jetzt halt mal

basix

2021-07-06, 00:05:52

8 HBM Stacks ;)

=============================================

-> 50 PFlops, 200k CPU Cores, 750 MI-Next GPUs

-> 200'000 Cores: Epyc 7763 mit 64C macht ~2.05 TFLOPs in HPL (Linpack, AMD Bestcase Angabe) oder ~1.6 TFLOPs (gemessen): https://4youdaily.com/technology-and-it-market-news/amd-epyc-milan-review-zen-evolution-using-epyc-7763-and-epyc-7543/

-> CPU PFlops = 200kC / 64C * 2.05 TFlops = 6.4 PFlops

-> GPU PFlops = 50 PFlops - 6.4 PFlops = 43.6 PFlops

-> Pro GPU TFlops = 43.6 PFlops / 750 MI-Next GPUs = 58.1 TFlops pro GPU :eek:

Ich glaube, das Ding macht wirklich 50 TFlops FP64 pro GPU ;)

Edit:
Ich tippe auf 768 GPUs. Das wären 12 Cabinets à 8x 3U Racks mit jeweils 8x GPUs.

=============================================

Zur "Advanced Node" Geschichte: Ich erwarte stark N5(P). Wäre unter Umständen N6 auch denkbar? Arcturus scheint ca. 750mm2 gross zu sein. Bei N6 hat man immerhin 1.18x Logic Scaling. Das reicht evtl. für die Updates am Chip, wird aber dann sehr gross werden.

mksn7

2021-07-06, 11:20:03

Wenn man noch bedenkt dass die Linpack Flops nicht 100% der theoretischen Flops sind und dass beim scaling auch nochmal ein bisschen was draufgeht, müssten die Ppeak pro GPU ja noch höher sein.

Bei 90% Linpack- und Scalingeffizienz kommt man bei 58 TFlop/s / (0.9*0.9) / (2*110*256) = 1.16 GHz als Takt dafür raus. Das klingt nicht so unrealistisch für einen Takt im sweet spot.

Ich bin trotzdem noch ein wenig ungläubig. Das wäre schon ein sehr deutlicher Effizienzgewinn.

basix

2021-07-06, 14:02:50

Wie kommst du auf deine Rechnung für den Takt?

Ich komme bei 58 TFlops und 224 CUs @ Fullrate FP64 auf 2.023 GHz. Auf 2.25 GHz bei 90% Effizienz.

-> Oder rechnest du, dass die CUs und Matrix Cores parallel laufen und die effektive FP64 rate nochmals verdoppelt wird?

mksn7

2021-07-06, 16:35:49

basix

2021-07-06, 20:52:44

Eine CU hat doch nur 64 Compute-Cores? Würde bei FMA und Fullrate also 128 Flops / Takt / CU geben, oder verstehe ich da was falsch?

Nakai

2021-07-06, 23:07:41

Eine CU hat doch nur 64 Compute-Cores? Würde bei FMA und Fullrate also 128 Flops / Takt / CU geben, oder verstehe ich da was falsch?

Full rate DP und Double Rate SP.

basix

2021-07-07, 10:07:02

Wir reden doch von FP64 TFlops. Fullrate FP64 ergibt 2 Flops pro Compute Core, da FMA. 64 * 2 = 128 Flops/Clk pro CU.

Ausser eben, du rechnest die 128 Flops/Clk der Matrix v2 Units noch obendrauf (wenn das parallel überhaupt geht). Falls es parallel geht, ergibt die abartig hohe FP64-Leistung Sinn. Sonst sind die dazu notwendigen Taktraten mMn zu hoch.

mksn7

2021-07-07, 11:57:33

Ich gehe von 128 vector fp64 flops/cycle/CU und 256 matrix fp64 flops/cycle/CU aus. Die matrix unit hat nochmal den doppelten Durchsatz, aber parallel können die bestimmt nicht verwendet werden.

Nakai

2021-07-07, 12:36:55

Ich gehe von 128 vector fp64 flops/cycle/CU und 256 matrix fp64 flops/cycle/CU aus. Die matrix unit hat nochmal den doppelten Durchsatz, aber parallel können die bestimmt nicht verwendet werden.

Definitiv. Da werden die gleichen ALUs/FPUs dahinter stecken.

Wir reden doch von FP64 TFlops. Fullrate FP64 ergibt 2 Flops pro Compute Core, da FMA. 64 * 2 = 128 Flops/Clk pro CU.

Und bei FP32 wären das 256 Flops/Clk pro CU.

Alles auf dem Papier, natürlich.

basix

2021-07-07, 15:01:00

256 Flops/Clk bei FP32 ist mir schon klar, nur gibt man HPC/Linpack Leistung mit FP64 Flops an. Und dann passt das mit 128 Flops/Clk eben nur mit hohen Taktraten oder die Matrix Units helfen mit.

@mksn7:
Locuza schreibt in seinem Schaubild 128 Flops/Clk für die Matrix Units hin. Doppelten Durchsatz gibt es bei Nvidia A100, aber allem Anschein nach nicht für Aldebaran.

Locuza

2021-07-07, 16:30:31

Basierend auf der unterstützen Matrix-Größe für FP64 sind es 128 FLOPs/clk.
Wie die normalen Vektor-SIMDs aussehen, konnte ich nicht direkt ableiten, weswegen ich keine Durchsatznummern oder SP-Counts angegeben habe.

Es ist eine Diskussion seit vielen Jahren, wie die Einheiten genau aufgebaut sind.
Verwendet GCN dedizierte FP64-Einheiten oder Multi-Precision ALUs?
Die Diskussion kam vor allem auf, seitdem Nvidia bei GK110 dedizierte FP64-ALUs angegeben hat.

Rein konzeptionell stelle ich mir das wie bei Zen1 bei Multi-Precision ALUs vor.
Jede FP32-ALU werkelt 2-16 mal so lange an FP64-Instruktionen herum, wofür es ein paar extra Schaltungen braucht.

Die andere Option wäre es, dedizierte Hardware für FP32 und FP64-Instruktionen zu haben, bei RDNA hat AMD auf den Diagrammen DP-Units separat eingezeichnet (Seite 9).
https://www.amd.com/system/files/documents/rdna-whitepaper.pdf

Bei CDNA1 hat AMD selbst für FP16 eine eigene Box gezeichnet und es gibt sicherlich keine separaten FP16-ALUs (Seite 6):
https://www.amd.com/system/files/documents/amd-cdna-whitepaper.pdf

Geht man davon aus, dass es dedizierte FP64-ALUs gibt, dann hat AMD bei Half-Rate SIMD8 verbaut für FP64 (64 FLOPs/clk).
Jetzt stellt sich die Frage was CDNA2 gemacht hat?
Möglicherweise es gibt keine getrennten SIMD-Einheiten mehr und nur noch native FP64-ALUs?
Es könnten hierbei aber nach wie vor SIMD8-Einheiten verbaut werden, was dann eben Full-Rate bzw. den normalen Durchsatz darstellen würde und FP32 wäre ohne Packed-Math nicht schneller, sondern auch Full-Rate (64 FLOPs/clk für FP64 oder FP32).
Bei FP16-Instruktionen müssten die ALUs aber dann "Quad-Packed" durchführen können, falls man da nicht an Durchsatz verlieren möchte und Packed-Math hängt davon ab, dass man die gleichen Operationen bündeln kann, es wäre kein direkter Ersatz für die Fähigkeit bei jeder SIMD-Lane eine einzelne Operation durchführen zu können.
Und in dem Bezug habe ich nichts auffälliges bei den Compiler-Patches gesehen.

Also vielleicht dann ein heftiges FP64-Upgrade auf der SIMD-Seite?
Statt SIMD8, eben SIMD16, damit würde sich der FP64-Durchsatz erhöhen und mit Packed-Math könnte man auch den FP32-Durchsatz verdoppeln (128 FLOPs/clk für FP64 und 256 FLOPs/clk für FP32).
Das würde aber natürlich die Hardwarekosten erhöhen und gibt es dann noch separate FP32 SIMD16-Einheiten, die packed math für FP16 können?
In Bezug auf den maximalen FLOP-Durchsatz bei FP64 gäbe es dann keinen Unterschied, ob man die normalen Vec-ALUs verwendet oder die Matrix-Engines, beides würde bei 128 FLOPs/clk liegen.

PS: Bei dem Supercomputer Perlmutter (AMD Milan + Nvidia A100) hat man den theoretischen FP64-Durchsatz angegeben:
https://docs.nersc.gov/systems/perlmutter/system_details/

Für das Setonix-System habe ich folgende Zahlen genommen:

CPU-Seite:
16 FP64 FLOPs pro CPU-Kern x 200.000 (Kerne, /64 = 3125 Milan CPUs) x 2.45 GHz = 7.84 PetaFLOPs.

GPU-Seite
128 FP64 FLOPs pro CU x 750 (GPUs) x 112 CUs x 2 (Chips pro GPU) x 1.5 GHz = 32.23 PFLOPs.

Zusammen wären es ~ 40 PFLOPs.
Die Taktraten könnten ein Tick höher sein oder es wird beim finalen System einfach ein gutes Stück mehr Hardware verbaut, da man 200.000+ CPU-Kerne und 750+ GPU-Module angibt.

Linmoum

2021-07-27, 23:19:12

Initial shipments of next-generation AMD Instinct accelerators featuring 2nd Gen CDNA architecture
https://d1io3yog0oux5.cloudfront.net/_30f5ada49786953e0d93203550c61bd0/amd/db/778/6647/file/AMD+Q2%2721+Financial+Results+Slides.pdf

basix

2021-07-27, 23:19:59

AMD hat gerade ihre Quartalszahlen bekannt gegeben (https://ir.amd.com/financial-information). Interessanter Takeaway:
"Initial shipments of next-generation AMD Instinct accelerators featuring 2nd Gen CDNA architecture"

Edit:
waaaa, 30sec zu spät :D

Ach ja: Jahresprognose von +50% Y/Y (Q1/2021) auf neu +60% angehoben :eek:

Leonidas

2021-07-28, 10:21:33

D.h. Tape-out müsste eigentlich Anfang 2020 gewesen sein. Frage ist dann: Tatsächlich schon 5nm?

fondness

2021-07-28, 10:32:40

D.h. Tape-out müsste eigentlich Anfang 2020 gewesen sein. Frage ist dann: Tatsächlich schon 5nm?

Ich tippe weiter auf 6nm.

Nightspider

2021-07-28, 11:15:00

Hatte man nicht auch 5nm Kapazitäten von Huawei bekommen?

AffenJack

2021-07-28, 11:51:17

Ich tippe weiter auf 6nm.

Das habe ich irgendwo bei Twitter oder b3d auch schonmal gelesen. Aber da frage ich mich, wie groß das Ding dann ist? Oder kommt man mit dem EUV Prozess näher an die 7nm Mobile Transistordichten heran und kann brauchte deswegen 5nm nicht?

Bei N33 gehen die Infos ja auch Richtung 6nm. Das macht nur Sinn, wenn 6nm mit EUV eine spürbare Verbesserung gegen 7nm DUV bringt.

Leonidas

2021-07-28, 11:52:30

AMD-Patent: Data flow in a distributed graphics processing unit architecture
https://twitter.com/Underfox3/status/1420239683519492098

mboeller

2021-07-28, 13:55:37

D.h. Tape-out müsste eigentlich Anfang 2020 gewesen sein. Frage ist dann: Tatsächlich schon 5nm?

Bondrewd im RDNA3 Speku-Thread:

Depends on how AMD implements stuff too!
CDNA1 to CDNA2 PPA will be funny given iso node.

upps, link vergessen:
https://forum.beyond3d.com/threads/amd-rdna-3-speculation-rumours-and-discussion.62092/page-25#post-2216915

basix

2021-07-28, 15:07:49

fondness

2021-07-29, 09:03:53

Zuletzt wohl eher bei RDNA2 gesehen?! Oder was ist mit PPA gemeint?

basix

2021-07-29, 09:33:20

RDNA2 war in dieser hinsicht auch top. Aber Maxwell hatte +100% Perf/W draufgelegt ;)

PPA = Power-Performance-Area --> Das magische Dreieck der Chipeigenschaften
https://en.wikichip.org/wiki/power-performance-area

reaperrr

2021-07-29, 09:50:57

Aber Maxwell hatte +100% Perf/W draufgelegt ;)
Aber auch nur, weil Kepler (warum auch immer) ne reine Weiterentwicklung der Consumer-Fermis war und ebenfalls 1/3 der ALUs schlecht ausgelastet hat sowie relativ viele TMU hatte, die beide trotzdem viel Platz gebraucht und Saft gesoffen haben.

Maxwell SMs basierten wieder mehr auf dem SM-Aufbau von GF100 (nur halt mit 4 normalen ALU je 1 Hochtakt-ALU), der von der Auslastung und Effizienz auch schon bei Kepler mMn einiges in Sachen PPA gebracht hätte.

Will sagen, 128 ALU und 8 TMU je SM hätten sie auch schon bei Kepler haben und dafür dann halt mehr SM verbauen können, damit hätten sie bei unwesentlich mehr Transistoren und Verbrauch vmtl. merklich bessere IPC je ALU erzielt.
Maxwell's großer Sprung kommt zu einem wesentlichen Teil davon, wie ineffizient das SM-Design von Kepler war, wo NV mMn einfach viel unnötig verschenkt hat.

Solche fundamentalen Schwächen im Aufbau hatte RDNA1 nicht, was den Sprung von RDNA2 umso beeindruckender macht.

mczak

2021-07-29, 15:07:09

Will sagen, 128 ALU und 8 TMU je SM hätten sie auch schon bei Kepler haben und dafür dann halt mehr SM verbauen können, damit hätten sie bei unwesentlich mehr Transistoren und Verbrauch vmtl. merklich bessere IPC je ALU erzielt.
Maxwell's großer Sprung kommt zu einem wesentlichen Teil davon, wie ineffizient das SM-Design von Kepler war, wo NV mMn einfach viel unnötig verschenkt hat.

Solche fundamentalen Schwächen im Aufbau hatte RDNA1 nicht, was den Sprung von RDNA2 umso beeindruckender macht.
Das ist korrekt, man kann aber sagen rdna hatte dafür Schwächen beim physikalischen Design. Wie fundamental die waren ist natürlich schwierig zu beurteilen, dass da aber punkto Frequenz und Stromaufnahme rdna2 viel besser dasteht ist schon ein Indiz dass die relativ gross waren.

aufkrawall

2021-07-29, 15:16:04

RDNA2 war in dieser hinsicht auch top. Aber Maxwell hatte +100% Perf/W draufgelegt ;)

Nein, es waren real +38-45% bessere Perf/W GTX 980 vs. 780 Ti:
https://cdn.mos.cms.futurecdn.net/2dGKAQLa3ohRcqejZJgo93.png

RDNA2 war ein größerer Sprung, es waren hier mit 5700 XT UV vs. 6800 UV ~60% bessere Perf/W.

vinacis_vivids

2021-07-29, 15:29:45

Taktratensprung
Fiji 1050Mhz -> Vega 1677Mhz +59,7% (Big Chip)
Polaris 1340Mhz -> RDNA1 2050Mhz + 52,9% (Mid-Range)
Vega 1677Mhz -> RDNA2 2500Mhz + 49,0% (Big Chip)

Fundamental ist RDNA richtig stark.
https://www.computerbase.de/2021-03/amd-radeon-rdna2-rdna-gcn-ipc-cu-vergleich/#abschnitt_rdna_vs_rdna_2_in_wqhd

Die Effizienz wurde mit RDNA2 natürlich durch den cut im SI in die Höhe getrieben. Die 40CUs kann AMD nun mit 192bit füttern statt mit 256bit SI. Auch die Bandbreite ist von 448GB/s auf 384GB/s gesunken, was den Verbrauch natürlich senkt um Energiespielraum für mehr GPU-Takt zu haben.

Vergleich bezieht sich natürlich auf RX5700XT vs RX6700XT.

IPC-mäßig ist RDNA1 sogar stärker als RDNA2, aber nur für die begrenzte 7nm Kapazität einfach zu teuer, was ja eine Schwäche ist.

Der_Korken

2021-07-29, 15:30:46

Nein, es waren real +38-45% bessere Perf/W GTX 980 vs. 780 Ti:
https://cdn.mos.cms.futurecdn.net/2dGKAQLa3ohRcqejZJgo93.png

Maxwell hat aber zusätzlich die Performance pro Fläche um ca. 20% erhöht. GM204 war 33% größer, aber 50-60% schneller als GK104 bzw. knapp 30% kleiner als GK110 (der hat deutlich mehr DP-ALUs mitgeschleppt) bei leicht höherer Performance.

Man muss eigentlich immer beides (Perf/W und Perf/mm²) berücksichtigen, weil ich immer leicht Effizienz gewinnen kann, indem ich einen riesigen, niedrig getakteten Chip baue bzw. andersrum einen kleinen Chip schnell bekomme, indem ich die Effizienz komplett wegwerfe und übertakte.

basix

2021-07-29, 21:21:43

780 Ti auf 980 ist einfach der falsche Vergleich. 780 Ti vs. 980 Ti wäre geeigneter. Aber ich habe es etwas überschätzt, waren eher so 50-60% Effizienzsteigerung

Badesalz

2021-08-13, 17:28:21

Wenn das immer noch 6/7nm ist, dürfte CDNA3 in 5nm nicht zu lange auf sich warten lassen. Ende 2022? Ist nicht dort um den Dreh der Aufbau des nächsten HPC Supercomputers mit >2 ExaFlops?

Und wenn PPA extrem steigt im selben Node: Respekt. Zuletzt bei Maxwell gesehen.Der Aufbau vom Frontier ist jetzt ein Board (Node) mit 2 bisschen umgemoddeten Milans und 2x 4 MI200. Wovon es beide bereits real gibt und ausgeliefert/aufgebaut wird. Das macht mit Cray Shasta+Slingshot im Vollausbau direkt 1.5 Exaflops in FP64. Mit knapp unter 30MW aus der Stromleitung.

Und das funktioniert sogar direkt. :wink: Nicht so wie die Dramen die sich im LRZ täglich abspielen oder das - gelinde gesagt - bisherige Fiasko mit Aurora. Ob man für 2 Exaflops also gleich CDNA3 braucht?

Für mich zeichnet sich da auch langsam ein kleiner Paradigmenwechsel. OAK hat schon mal ein PR-Interview zu Frontier erzählt, mit in etwa diesem O-Ton: "Nun, was können wir also mit so einer schier unendlichen Rechenleistung machen?... (blah blah Erklärung)"
Jobs, die auf der kompletten (!) Maschine laufen gibt es eh nur paar Mal im Jahr. Lechzt es diese... "Community"... denn wirklich nach EINEN 5 Exaflops Superkomputer?
Klar wenn man im Jahr 3% der Rechenzeit bekommt, sind 3% von 5 Exaflops und 3% von 1.5 Exaflops nicht das gleiche, aber...

… wenn man mit der nächsten Generation 2 Exaflops mit knapp unter 20MW bekommen könnte, ist es da nicht besser paar mehr von solchen Kisten aufzustellen als die paar wenigen Giganten von 10 Exaflops?
Die Datensätze müssen erstmal dahin. Die Ergebnisse sind auch nicht unbedingt ein Bruchteil davon.
Es ist ja wie überall anders auch nicht so, daß z.B. OAK nur dafür rechnet was innerhalb des eigenen Zaunes stattfindet. Baut man dann also zwei 10 Exaflops Kisten oder lieber sinnvoll verstreute 5 Rechenzentren mit jeweils 2 Exaflops?

Wir werden sehen. Das Prestigerennen gibt es zwar weiterhin, aber ich denke ERSTMAL, daß sich das zukünftig bisschen ändern wird.

vinacis_vivids

2021-08-13, 17:42:21

780 Ti auf 980 ist einfach der falsche Vergleich. 780 Ti vs. 980 Ti wäre geeigneter. Aber ich habe es etwas überschätzt, waren eher so 50-60% Effizienzsteigerung

Falsch.

980Ti ist ~30% schneller als die 780Ti bei gleichem Verbrauch (250W). Also ist die Effizienz lediglich um ~30% gestiegen.

boxleitnerb

2021-08-13, 19:13:55

Falsch.

980Ti ist ~30% schneller als die 780Ti bei gleichem Verbrauch (250W). Also ist die Effizienz lediglich um ~30% gestiegen.

Falsch, 50% sind korrekt:
https://www.techpowerup.com/review/nvidia-geforce-gtx-980-ti/32.html

Platos

2021-08-13, 19:21:02

47.5% mehr Leistung beim Gaming pro Watt im FHD Perfomance Index. Quelle ist die jeweilige Launchanalyse der beiden Karten und der Perfomanceindex.

30% sind weit daneben.

Badesalz

2021-08-13, 19:57:12

30% sind weit daneben.
Immerhin 70% weniger als so ein Thema in diesem Thread ;)

amdfanuwe

2021-08-13, 19:59:25

Baut man dann also zwei 10 Exaflops Kisten oder lieber sinnvoll verstreute 5 Rechenzentren mit jeweils 2 Exaflops?

Nur so ein Gedanke: Wieviel Exaflops bringt Google Stadia insgesamt auf die Waage? Wenn da schon 10 TFlops pro Gamer bei Millionen von Gamern gleichzeitig angepeilt waren...

Aber sicherlich trainiert Google da ihre KI in den ungenutzten Zeiten darauf.

Platos

2021-08-13, 20:10:22

Immerhin 70% weniger als so ein Thema in diesem Thread ;)

Musste 3 mal lesen. Komma fehlt da glaube ich.

Badesalz

2021-08-13, 20:22:38

Ich denke darüber muss man nicht nachdenken. Stadia ist bekanntlich ein "monumentaler Flop" ;)

Platos

2021-08-13, 21:25:20

Ich denke darüber muss man nicht nachdenken. Stadia ist bekanntlich ein "monumentaler Flop" ;)

Zum Glück.

Leonidas

2021-08-14, 08:55:51

Immer noch keine belastbare Info, in welcher Fertigung Aldebaran nun kommt?

vinacis_vivids

2021-08-14, 09:38:48

Falsch, 50% sind korrekt:
https://www.techpowerup.com/review/nvidia-geforce-gtx-980-ti/32.html

https://www.techpowerup.com/gpu-specs/geforce-gtx-780-ti-6-gb.c3302

Die 980Ti ist kumuliert 28% schneller als die 780Ti.

Die besagten ~30% von mir sind belastbare Zahlen. Deine bzw. Eure zahlen sind veraltet und ihr solltet Sie selbst korrigieren.

In neueren Spielen und Tests 2021 dürfte der Abstand noch geringer sein, vllt. 15-20% noch.
Meine Aussage bezieht sich auf die 6GB 780Ti Version. Die 3GB 780Ti geht in vielen Spielen schon der VRAM aus.

basix

2021-08-14, 10:22:24

Erst sagst du, unsere Zahlen stimmen nicht, deine seien belastbar usw. und dann kommst du mit der Behauptung zu neueren Spielen. Natürlich ohne Beleg. Merkst du es?

Hier von CB, sogar extra Einstellungen damit der Speicher bei älteren GPUs nicht vollläuft: https://www.computerbase.de/2017-01/geforce-gtx-780-980-ti-1080-vergleich/2/

Aber nun BTT please

Badesalz

2021-08-14, 11:24:55

Immer noch keine belastbare Info, in welcher Fertigung Aldebaran nun kommt?Gute Frage. Alle schreiben von 5nm, alle sind aber recht vorsichtig mit der Wortwahl für diese... Behauptung :)

Das war der leiseste Launch in AMDs Geschichte oder? :confused:

@vinacis_vivids
Nervt hier überhaupt nicht. Mach einfach nur weiter :freak:

fondness

2021-08-14, 11:29:29

Der offizielle Launch kommt natürlich noch. :)

Badesalz

2021-08-14, 12:39:46

Wahrscheinlich erfahren wir diesjahr noch was sie bereits nach Australien und OAK ausliefern :usweet:
Bisschen seltsam diesmal :) Mit MI100 gab es nicht so viel classified Kram :D

Läuft H100 denn schon vom Band? Das hat sich schonmal leicht verzögert wegen irgendwelchen Folien von AMD :rolleyes:
Vielleicht will AMD bis zum offiziellen Launch bei NV noch warten ;)

AffenJack

2021-08-14, 13:53:16

Gute Frage. Alle schreiben von 5nm, alle sind aber recht vorsichtig mit der Wortwahl für diese... Behauptung :)

Das war der leiseste Launch in AMDs Geschichte oder? :confused:

Es war kein Launch. Man launcht erst Ende des Jahres:

https://www.planet3dnow.de/cms/wp-content/gallery/amd-investor-presentation-august-2021/AMD_Investor_Presentation_August_2021_26.png
https://www.planet3dnow.de/cms/63369-amd-investor-praesentation-august-2021/nggallery/page/2

Man dürfte wohl erste Exemplare für den Aufbau von Frontier ausgeliefert haben, damit da die ersten Nodes aufgebaut werden. Aber das sind dann eher Samples, als ein echter Launch.
Wird interessant ob man genug CDNA2 und CPUs liefern kann, um schon in der nächsten Top500 Liste aufzutauchen.

Badesalz

2021-08-14, 15:17:06

An sich wirst du wohl schon Recht haben.

OAK sagte aber IMHO und bereits, wenn sich jetzt nicht etwas unerwartetes zeigt, dann fahren sie am Ende dieses Jahres 1.5 Exaflops mit Frontier. Vollausbau also.
Und da damit einiges schon alleine von der Mechanik her aufzubauen ist, denke ich nicht, daß sie jetzt erst evaluieren. Das auch nur für die Leute die alles zusammenschrauben und zusammenstecken soviel Arbeit, das passiert nicht in wenigen Wochen.
Das wird AMD mit Cray schon davor machen.

Bei den Australiern mit ihren 750 Karten (Setonix) wird es wohl genauso sein.
Den Launch "für den Markt" und damit leider auch die genaueren Daten wird es aber wohl viel später geben. Offiziell =)

amdfanuwe

2021-08-14, 16:32:17

Gute Frage. Alle schreiben von 5nm, alle sind aber recht vorsichtig mit der Wortwahl für diese... Behauptung :)

Weil Apple schon 5nm einsetzt glauben alle, dass auch AMD auf 5nm geht.
Ich denke aber nicht, dass AMD denselben Prozess verwenden würde. Somit hat AMD ein Risiko den nötigen Prozess rechtzeitig fertig zu bekommen.
Ich bezweifle, dass AMD das Risiko eingegangen ist.
Man sieht ja auch, was AMD mit ZEN3 und RDNA2 noch aus den 7nm rausgeholt hat.
Der nächste Schritt wäre 6nm.
Ich tippe also eher mal auf 6nm für CDNA2 und Rembrandt im Januar.

Badesalz

2021-08-14, 21:58:49

Den bisherigen Infos nach ist das eigentlich unmöglich, daß die MI200 eher aus 2 (MCM) CDNA1++ GPUs besteht die in 7nm+ gefertig werden?
Die hängen ja schon am Zen3+ dran =)

Denn wozu soll AMD gleich alles wieder raushauen? Direkt 1.5 Exaflops bei 30MW und das eben in Zuverlässig, ist schon ein ziemlicher Paukenschlag für 2021/2022.

Und egal ob H100 jetzt wie Alientech aussehen wird oder nicht, AMD muss sich hier erstmal nicht mehr erst beweisen. Nicht in absoluten Zahlen, aber bei den Bewegungen in der Top500 hat AMD sich in einem Jahr mein ich mind. verdoppelt.

basix

2021-08-15, 10:11:53

6nm ist auch ein Verfügbarkeitsthema. Das beinhaltet Waferkapazität als auch Technologiereife. Auch mit MCM werden die Chips gross. Und wenn AMD die veranschlagten Leistungsdaten mit 6nm erreicht, why not?

Badesalz

2021-08-15, 11:02:39

Herstellungsprozesse wirken sich halt auf die Herstellungspreise aus... ;)

Bei der besonderen Verschwiegenheit diesmal kann das natürlich alles sein. Mir fällt es nur schwer es zu glauben, daß die PR-Heinis sich wenigstens eine "<7nm" Angabe entgehen lassen würden =)

amdfanuwe

2021-08-15, 13:02:20

Naja, letztes mal haben sie das "+" zur Kennzeichnung eines verbesserten Nodes genutzt und sind von allen angemacht worden weil TSMC einen N7+ im Programm hat.

mboeller

2021-08-18, 20:57:11

AMD Aldebaran Video von Locuza:

https://www.youtube.com/embed/x6wcCBDdiUI?autoplay=1&auto_play=true

fondness

2021-08-22, 09:37:24

Warum kann ich das erste Post nicht mehr editieren? Ziemlicher fail.

Badesalz

2021-08-22, 21:09:24

So falsch war das alles nicht ;) Oder was ist damit?

Das Video von Locuza... über MI200... Man muss sich schon ziemlich konzentrieren um die Infos über MI200 mitzubekommen...

Locuza

2021-08-23, 02:09:12

So falsch war das alles nicht ;) Oder was ist damit?

Das Video von Locuza... über MI200... Man muss sich schon ziemlich konzentrieren um die Infos über MI200 mitzubekommen...
Wenn du Zeit und Lust hast kannst du mir gerne ein genaueres Feedback hinterlassen.
Ein paar Dinge die ich allgemein zum Video und den Umständen sagen kann:
- Die Aufnahme war an den heißen Sommertagen und ich wollte es teilweise schon schnell über mich bringen, da man nicht einmal in Ruhe sitzen konnte, ohne zu schwitzen.
- Normalerweise schreibe ich noch eine Zusammenfassung auf Englisch und Deutsch auf Patreon, um eben schneller die Informationen zu überblicken und in Ruhe die Bilder/Informationen anzuschauen.
Zeitlich hat das aber nicht gepasst, da gerade soviel parallel abgeht, dass ich mich auf andere Dinge fokussiert habe, wie Intel's Architecture Day und gerade startet die Hot Chips 33, erneut vollgepackt mit Informationen.
Die Zusammenfassung kommt irgendwann später.
____

Es gibt aber eine kleine Zusammenfassung wie immer auf Twitter, kurz und knapp gehalten, aber meist völlig ausreichend, da nur die wichtigste Information reingepackt wird:
https://twitter.com/Locuza_/status/1427610228233752577

Ich fasse es vielleicht auch einfach mal auf Deutsch hier kurz zusammen.
Es gibt ein neueres Diagramm, welches auf den Grundriss von Arcturus/CDNA1 basiert und grob der Realität entsprechen sollte:
https://pbs.twimg.com/media/E8_lSPLXoAMGrKv?format=jpg&name=large

Arcturus/CDNA1 als die graphic (sieht ziemlich nah an einem echten die shot aus):
https://pbs.twimg.com/media/E8_lTJ7WYAA0CPO?format=jpg&name=large

Einer der Grundprobleme, um Multi-GPU-Lösungen zu realisieren ist die Verbindung zwischen den Chips, historisch und auch jetzt ist man noch weit entfernt, um einen Durchsatz zu erreichen, der ungefähr die selbe Bandbreite hat wie zum lokalen Speicher.
Was bei CPUs noch ganz gut funktioniert, ebenso in Bezug auf die Energieaufnahme, ist bei GPUs einfach eine Ebene schwerer zu realisieren.
Dazu gibt es aber auch ein interessantes Forschungspapier von Nvidia, welches eine MCM-GPU modelliert mit insgesamt 3TB/s Speicherbandbreite, wo die Links zwischen GPUs aber nur 768GB/s erreichen:
https://research.nvidia.com/publication/2017-06_MCM-GPU%3A-Multi-Chip-Module-GPUs

Durch drei Erweiterungen der MCM-GPU kommt man mit Einbußen von 10% davon, anstatt ~50% bei Speicherintensiven Anwendungen:
1.) Es wird eine neue Cache-Stufe eingeführt die Datenzugriffe auf andere Chiplets Cached und somit dann die Datenlokalität.
2.) Die Thread-Bündel bzw. Warps von einem Kernel werden in vier Gruppen unterteilt und jedes Chiplet bekommt eine Gruppe, anstatt die Warps über alle Chiplets zu verteilen, erneut führt das dazu, dass mehr Daten lokal gehalten werden.
3.) Es wird eine First-Touch-Policy eingeführt, wo die Speicherseiten, die von einem Chiplet zuerst angefragt werden, lokal in dessen DRAM-Partition gespeichert wird, erneut bessere Lokalität.

Insgesamt führen die Verbesserungen dazu, dass die nötige Inter-Chiplet-Kommunikation massiv reduziert wird und man nur ~10% an Performance verliert gegenüber einer monolithischen Lösung.

Die Frage ist natürlich wie AMD nun das Chipletkonzept für Aldebaran umsetzt.
Ich habe bei den Treiber keine Hinweise in Bezug auf neue Caches, Scheduling-Modes oder Ähnliches gefunden, um die Lokalität zu verbessern.
In diesem Bezug denke ich das Aldebaran vermutlich simpel ausfällt.
Im Gegensatz zum Nvidia Forschungspapier, was auf eine Package-Level-Lösung setzt, kann AMD dagegen auf eine Silicon-Interposer-Lösung setzen, was es ermöglicht massiv mehr Bandbreite pro Link zu erreichen und deutlich energieeffizienter.
Aldebaran könnte ungefähr so aussehen:
https://pbs.twimg.com/media/E8_qFGZWEAwYJnu?format=jpg&name=large

Es gibt aber ein paar Probleme.
Für 2021 gibt TSMC eine maximale Interposergröße von ~2500mm² an, dass heißt pro Chiplet könnte man maximal auf ungefähr 600mm² setzen.
Nimmt man AMDs Vorgänger Arcturus/CDNA1 zu Hand und misst die dargestellte Chipgröße auf Basis der HBM2-Größe, dann kommt man schon auf so 730-740mm², viel zu groß, vor allem hat Aldebaran mehr Features, was mehr Transistoren und Fläche benötigt.
https://twitter.com/Locuza_/status/1427618192453681159/photo/1

Entsprechend gab es paar Gedankenspiele mit 6nm, was dennoch zu groß wäre, selbst wenn man eine optimistische Reduktion von 15% veranschlagt würde das zu 620-630mm² führen:
https://twitter.com/Locuza_/status/1427618976570478593/photo/2

Aus der Perspektive erscheinen 5nm als einzige Option, was auch aus Konkurrenzsicht nicht schlecht wäre, da Intel mit Ponte Vecchio fett aufdreht und 5nm für die Compute Tiles verwendet.
Laut ein paar Internetstimmen verwendet Aldebaran aber nicht 5nm, auch nicht 6nm, sondern tatsächlich nach wie vor 7nm.
Aufgrund von von einem Einwurf von TDevilfish habe ich dann sinnvollerweise Vega20 mit AMDs Schaubild für Arcturus verglichen und das passt von der Größe kaum überein.
Die HBM-PHYs sind viel größer, was sie bei ~20% mehr Geschwindigkeit aber zumindest nicht in der Größenordnung tun sollten.
Auch Strukturen wie der shared I/K$ und LDS sind massiv größer.
Normalisiert man AMDs Schaubild bzw. den echten die shot, der etwas künstlerisch modifiziert wurde, auf die PHY-Größe von Vega20, kommt man zu realistischeren Maßstäben und einer Chipgröße von ~630mm² für Arcturus/CDNA1:
https://twitter.com/Locuza_/status/1427640862377381894/photo/1

Möglicherweise ist Arcturus noch kleiner, als das.
Also es erscheint dann nicht völlig unmöglich ein Aldebaran-Chiplet unter 600mm² zu packen.

Es gibt noch eine Folie die eine Umsetzung mit CoWoS-L zeigt, wo anstatt einem riesigen Silizium-Interposer, ein organischer Interposer verwendet wird und nur an den Stellen, wo es notwendig ist, eine lokale Siliziumbrücke verbaut wird.
Das Größenproblem ist aber das gleiche, maximal ~2500mm² hat TSMC ursprünglich für das Jahr 2021 vorgesehen, jetzt spricht TSMC von 2022/23.
Ich kann mir nicht vorstellen, dass Aldebaran keine Crosslinks über Silizium verwendet, entsprechend denke ich wird das so aussehen wie oben dargestellt von TSMC, CoWoS-S mit großen Interposer und zwei Chiplets verbunden darüber.
Das wird bei 7nm dann sportlich bei der Umsetzung.

____

Eine Übersicht für das Video und was die Treiber in diesem Bezug listen:
- 2x Chiplets
- Ein Chiplet befindet sich im Primärmodus und darf als einziges Chiplet Power-Telemetrie anzeigen und Power-Limits setzen.
Ich vermute die Kommunikation mit der CPU läuft auch nur über das Primärchiplet ab und die Multi-Chiplet-Natur von Aldebaran wird verschleiert.
- Die System-Management-Unit kümmert sich um die Taktraten, die Stromspannungen und thermische Kontrolle und weitere Aufgaben.
Bei Aldebaran hat sie die Versionsnummer 13.0.2, die höchste die es bisher gibt.
Die Rembrandt APU verwendet 13.0.1, Cezanne z.B. 10.0.2 und CDNA1 und RDN1&2 haben die 11.x-Versionsreihe verwendet.
- Es gibt 8x HBM2e Stacks, mit jeweils 16GB bzw. 64GB pro Chiplet bzw. 128GB insgesamt.
- 14 CUs pro Shader-Array teilen sich den L2$, also jedes Chiplet hat 112 CUs aktiv bzw. es sind 224 insgesamt.
Physikalisch vorhanden sind aber vermutlich 128 CUs pro Chiplet bzw. 256 CUs insgesamt.
- Der L2$ wird mit der gleichen Größe wie bei Arcturus angegeben, gerade mal 8MiB pro Chiplet.
Das ist im Angesicht zum A100 von Nvidia mit 48MiB mickrig, noch lustiger wird es im Vergleich zu Ponte Vecchio, da hat ein Base-die 144MiB integriert...
- Die VCN-Engine trägt nun die Versionsnummer 2.6, Arcturus die Versionsnummer 2.5.
Die Engines wurden aber selber nicht verbessert, die interne Konnektivität ist jetzt schlicht anders und die Decoder hängen an einem anderen Multimedia-Hub, was der Hauptgrund für die neue Versionsnummer ist.
Es gibt also kein AV1 Decoding.

Das ist der flache Informationsgehalt für das Video, für das nächste wollte ich erwähnen das es jetzt einen gemeinsamen Adressraum zwischen CPU und GPU gibt, Cache Coherence, ein weiterer großer Punkt vom Projekt.
Und etwas mehr ins Detail bezüglich der CUs, Single-Rate FP64, Double-Packed FP32, Vergleiche zu A100, Ponte Vecchio, etc.
Das ist für die Enthusiasten hier im Forum wohl eher weniger mit neuen Informationen verbunden, sondern bekannte Kost.

Badesalz

2021-08-23, 08:16:57

Reedit:
(legal ;)) Alles gut.

amdfanuwe

2021-08-23, 13:03:45

auch nicht 6nm, sondern tatsächlich nach wie vor 6nm.
Meinst wohl 7nm.

Vielleicht verwendet AMD auch GUC.
https://www.guc-asic.com/en-global/news/pressDetail/glink
GLink's low area/power overhead for high throughput interconnect enables efficient multi-die InFO_oS and CoWoS solutions up to 2500mm2.

vinacis_vivids

2021-09-09, 18:53:51

Aldebaran MI200 wird vermutlich ein MCM-Monster mit 220CUs (2x110), angelegt sind physisch max. 2x128 = 256CUs.

https://videocardz.com/newz/amd-instinct-mi200-with-mcm-aldebaran-gpu-might-feature-110-compute-units

gfx90a_110

Die 110 entspricht der Zahl der aktiven CUs per Die. Im MCM 2xGPU Konfiguration ergibt das 220CUs und somit 14080SP.

220CUs @ 1,5Ghz -> ~ 42,2 Tflop/s fp32 (salvage)
256CUs @ 1,5Ghz -> ~ 49,1 Tflop/s fp32 (full)

basix

2021-10-11, 13:29:04

AMD Announces Ambitious Goal to Increase Energy Efficiency of Processors Running AI Training and High Performance Computing Applications 30x by 2025
https://ir.amd.com/news-events/press-releases/detail/1019/amd-announces-ambitious-goal-to-increase-energy-efficiency
https://news.mynavi.jp/article/20210929-1985760/

MI200 being deployed
https://www.hpcwire.com/2021/09/29/us-closes-in-on-exascale-frontier-installation-is-underway/

Alles aus dem B3D Thread: https://forum.beyond3d.com/threads/amd-cdna-discussion-thread.62128/page-8
In den verlinkten Seiten hat es auch BLockdiagramme zum Node (4x MI200 + EPYC). Sehr interessantes Zeugs.

Edit:
1.5 ExaFlops / >9000 Nodes = 166 TFlops / Node --> ~42 TFlops / MI200. Aber geil, >9000 haha :D

Edit 2:
4.6 PetaBytes HBM2e --> 4'600'000 GBytes / 128 GBytes = 36'000 MI200 --> ~42 TFlops / MI200

CPU muss auch noch berücksichtigt werden. Evtl. wird es eher so 40 TFlops / MI200

basix

2021-10-13, 08:42:24

Ich habe mir noch kurz überlegt, wie AMD ML/AI Workloads um 30x bis 2025 beschleunigen kann. Ich nehme hierbei an, dass CDNA2 die Ausgangslage dafür war.

Basis = CDNA2
Aus meiner Sicht, gibt es da folgende Möglichkeiten:
- 2x = Verdopplung der Matrix-Cores / CU (siehe A100)
- 2x = Sparsity Feature = Verdopplung Durchsatz (siehe A100)
- 1.5...2X = Grosser Infinity Cache, laut Papers 1.5...2x Performance-Steigerung bei ML-Workloads
- 5nm, 3nm und bei Glück noch 2nm

2*2*2 = 8x

Das bedeutet, noch ca. 4x Performance fehlt. Bei drei Full-Node Sprüngen zwischen 7nm und 2nm scheint mir das machbar. CDNA2 soll ja noch in 7nm kommen.

Basis = CDNA1
Auf der gezeigten Folie startet AMDs Trajectory 2020. Das wäre eher CDNA1

Stellschrauben
- 2x = CDNA2
- 2x = Verdopplung der Matrix-Cores / CU
- 2x = Sparsity Feature = Verdopplung Durchsatz
- 1.5...2X = Grosser Infinity Cache
- 5nm, 3nm und bei Glück noch 2nm

2*2*2*2 = 16x

Das bedeutet, dass nur ca. 2x Performance fehlen würde. Das wäre bei 3nm im Bereich des Möglichen.

amdfanuwe

2021-10-13, 09:42:36

wie AMD ML/AI Workloads um 30x bis 2025 beschleunigen kann.
Meinem Verständnis nach ging es um die Effizienz, entspricht nicht unbedingt einer Beschleunigung.
Allein ein spezialisierter ML/AI Chip, der nicht den ganzen unnötigen Kram aktueller GPUs mit rumschleppt, dürfte da schon einiges bringen.
Dazu noch Optimierung der Hardware auf die verwendeten Algorithmen und nicht wie aktuell Anpassung der Software an die bestehende Hardware.
Kann mir auch vorstellen, dass FPGA Technik an einigen Stellen effizient beschleunigend wirken kann.

basix

2021-10-13, 12:51:17

Stimmt, Effizienz ist das Ziel. Im HPC Kontext würde ich aber Effizienz = Performance gleichsetzen.

Linmoum

2021-10-23, 19:53:05

Ein paar Häppchen von ExecuFix:

47.9
1.7GHz boost clock, like you said: very high
383 FP16/BF16
They're not called MI200
"They're" is intentional... Yes, there's more than one SKU
https://twitter.com/ExecuFix/status/1451881860020244485

Ich bin mal auf die TBP gespannt bei dem überraschend hohen Takt. Würde mich wundern, wenn sie das noch - wie bisher - in 300W gepresst bekommen.

Piefkee

2021-10-23, 20:45:43

Ein paar Häppchen von ExecuFix:

https://twitter.com/ExecuFix/status/1451881860020244485

Ich bin mal auf die TBP gespannt bei dem überraschend hohen Takt. Würde mich wundern, wenn sie das noch - wie bisher - in 300W gepresst bekommen.

Und hier der Rest

Enough teasing. MI200 has two variants: MI250 and MI250X

MI250X
110 CUs, 1.7GHz boost
128GB HBM2e
500W TDP, 7nm
MCM

basix

2021-10-25, 10:41:58

MI250X wird ziemlich potent.

MI250 dann mit nur 300W als PCIe Karte?

Ausblick: Bei CDNA3 würde ich mir folgende Updates vorstellen...
- 4x Chip MCM
- V-Cache / Cache-Chiplets / MCDs (siehe N31/32)
- INT8/4 Beschleunigung

Piefkee

2021-11-08, 15:18:16

https://pbs.twimg.com/media/FDrVSgCXsAIdR3N?format=jpg&name=4096x4096

- Dual chiplet design
- 8x HBM
https://twitter.com/ExecuFix/status/1457711975925002241

mboeller

2021-11-08, 15:47:53

Locuza:

https://mobile.twitter.com/Locuza_/status/1457596601657176064

https://t.co/l48XqGoWky?amp=1

Linmoum

2021-11-08, 16:18:51

https://abload.de/img/mcm1ajyt.png

basix

2021-11-08, 16:36:43

Sieht High-Level beim Chip und den Geometrien auf dem Chip fast exakt wie MI100 aus. Ausser dass hier HBM2e zum Einsatz kommt. Man könnte sogar fast meinen, es sei der gleiche Chip... :uponder:

fondness

2021-11-08, 17:02:14

Geht gleich los:
https://www.amd.com/en/events/data-center

Vorstellung Aldebaran plus Milan-X.

fondness

2021-11-08, 17:11:17

Soviel zum Thema der Cache bringt nur was bei Spielen. "Up to 50% Performace Uplift".

Savay

2021-11-08, 17:15:54

Soviel zum Thema der Cache bringt nur was bei Spielen. "Up to 50% Performace Uplift".

Die pauschale Aussage war mir schon immer suspekt.
Ist halt nen bissl hit or miss. (pun indended) ;D

Entweder es bringt ordentlich was...oder fast nichts. Abhängig vom Workload.

fondness

2021-11-08, 17:22:23

Aldebaran also in 6nm genau wie von mir spekuliert. :)

mksn7

2021-11-08, 17:24:58

Spiele haben halt oft gerne verpointerte Datenstrukturen (=latenzempfindlich), und viele verschieden große data sets in der richtigen Größenordnung. Größere caches erhöhen dadurch fast immer die hit rate ein bisschen, weil sich hitrate vs cache capacity einigermaßen kontinuierlich verläuft. Bei anderen Applikationen hat man da oft viel deutlichere Stufen drin, gerade wenn die data sets gestreamed werden, also alles nacheinander einmal angefasst wird.

Neurosphere

2021-11-08, 17:36:11

Schon krass was AMD da mit den neuen MI liefert. Ich bin gespannt wie Nvidia da mit ihrem MCM Design gegen anstinken wollen/werden.

mksn7

2021-11-08, 17:40:49

Wenn Locuzas Info über die caches von Aldeberan stimmen, dann sind die im Vergleich zu A100 popelig klein, was es schwieriger macht die Leistung auch in echt abzurufen.

fondness

2021-11-08, 17:41:22

Die AMD Aktie geht gerade to the moon.

Nightspider

2021-11-08, 17:41:47

Aldebaran also in 6nm genau wie von mir spekuliert. :)

Ging nicht jeder von N6 aus?

AffenJack

2021-11-08, 17:55:35

Die Leistung ist schon top von den Zahlen her, auch wenn mksn7 Recht hat, dass es interessant wird, wie einfach es ist die Leistung auf den Boden zu bringen.

Anandtech hat weitere Spezifikationen, die den Leistungssrpung von Mi100 besser erklären:
https://www.anandtech.com/show/17054/amd-announces-instinct-mi200-accelerator-family-cdna2-exacale-servers

Man hat auch den Verbrauch von 300W auf 560W fast verdoppelt. Der Verbrauch pro Transistor ist also mehr oder weniger durch N6 und und die höhere TDP gleich geblieben. Aber man hat natürlich viel mehr TFlops/Transistor bei FP64 durch Fullspeed FP64.
Irgendwie lustig, dass AMD in HPC die kleineren Caches und mehr GFlops hat, während es im Consumerbereich genau andersrum ist im Vergleich zu Nvidia.

Unicous

2021-11-08, 18:09:48

AMD/TSMC hat die EMIB weiterentwickelt und zwischen Substrat und Die gesetzt:

https://www.hardwareluxx.de/images/cdn01/D7D92644B5A14A379B95F9F78C6842D8/img/A355942319E248B499A6BAB340E6F84D/AMD-Accelerated-Datacenter2021-Briefing-023_A355942319E248B499A6BAB340E6F84D.jpg

Das ist meiner Meinung nach eine wichtige Innovation, die etwas stiefmütterlich behandelt wird. Intel braucht bei EMIB eine ins Substrat eingebrachte Bridge, was u.a. die Kosten erhöht.

Eines der Patente dazu, die Underfox herausgesucht hatte vor einem Jahr:

https://twitter.com/Underfox3/status/1291265908535709697

AffenJack

2021-11-08, 18:15:23

Was mir bei Anandtech aufgefallen ist:

This also means that, especially given the die-to-die coherency, AMD is quoting the full throughput of both GCDs for the performance of their MI200 accelerators. This is technically accurate in as much as the accelerators can, on paper, hit the quoted figures. But it still comes with caveats, as each MI200 accelerator is presented as two GPUs, and even as fast as 4 IF links are, moving data between GPUs is still much slower than within a single, monolithic GPU

Also wenn ich das richtig verstehe und Anandtech kein Müll schreibt, dann verhält sich Aldebaran immernoch nur wie eine Dual-GPU auf einem MCM und könnte als Dual-GPU erkannt werden? Erst mit RDNA3 dürften dann Chiplets kommen, die sich wie eine Single-GPU verhalten.

Troyan

2021-11-08, 18:16:48

Ist das im HPC-Markt so relevant? Imo ist es sogar besser, da viel lokaler entwickelt werden kann.

AffenJack

2021-11-08, 18:24:33

Gute Frage, ich weiß es nicht. Vielleicht ist es sogar besser, denn die GCDs sind mit 400gb/s verbunden bei MI200. Nvidia kann mit dem Nvswitch mehrere GPUs mit 300Gb/s verbinden in einem ganzen Rack. Im Verhältnis sieht die GCD zu GCD Bandbreite da also schon ziemlich gering aus, vor allem wenn man die deutlich höhere Rohleistung in Betracht zieht. Sieht mir extrem Workloadabhängig aus das ganze.

Nightspider

2021-11-08, 18:25:22

War ja abzusehen das Aldebaran sich noch nicht wie eine monolithische GPU verhält.

Und das es im HPC Markt nicht so schlimm ist, sehen wir hier ja auch die erste Variante von MultiChip GPUs.

Troyan

2021-11-08, 18:41:32

basix

2021-11-08, 20:43:04

Locuza:

https://mobile.twitter.com/Locuza_/status/1457596601657176064

https://t.co/l48XqGoWky?amp=1

https://abload.de/img/mcm1ajyt.png

Auf dem einen Shot sind 128 CUs zu sehen. Im Whitepaper sind es klar 112 CUs (wie auch von Locuza spekuliert): https://www.amd.com/system/files/documents/amd-cdna2-white-paper.pdf

Was den nun :confused:

Edit:
OK auf allem offiziellen Material findet man 112 CUs. Beim von Linmoum geteilten Bild scheint man einfach MI100 eingefärbt zu haben.

Unicous

2021-11-08, 20:49:52

Auflösung: Es sind 128 von denen 16 abgeschaltet sind.

basix

2021-11-08, 21:01:39

Falsch ;)
https://www.amd.com/system/files/documents/amd-cdna2-white-paper.pdf
The AMD CDNA 2 architecture incorporates 112 physical compute units per GCD, divided into four arrays; the initial products include 108 (for AMD Instinct™ MI250) or 110 (for AMD Instinct™ MI250X) active CUs per GCD

Edit: Es sind 8*14 CU Shader Arrays und nicht 8*16. Locuza hatte also recht.

Unicous

2021-11-08, 21:26:27

Falsch ;)
:rolleyes:

https://twitter.com/Locuza_/status/1457719714323521548

basix

2021-11-08, 21:33:27

Das widerspricht sich aber. "Physical" ist für mich eigentlich eindeutig.

Edit:
Folge auch dem Twitter Thread weiter nach unten, letzte Aussage von Locuza tendiert wieder zurück nach 14 CUs ;) Wenn ich jetzt wem glauben schenken müsste: AMD hat hier mehr Gewicht als Kepler_L2 ;)

Aber ja, ein Die Shot von FritzchensFritz würde das Rätsel lösen :D

Unicous

2021-11-08, 21:53:33

Mach das mit AMD aus, der Patch ist eindeutig (natürlich kann es auch ein Typo oder Platzhaltereintrag sein, aber den Eintrag gibt es ja schon eine Weile)und die 128 bzw. 256 CUs schwirren schon eine Weile umher. Es werden CUs abgeschaltet. Das ist schon mal ein Fakt. Wenn AMD sagt es sind "physisch" xx CUs dann kann das auch einfach bedeuten, dass nur xx CUs in jedem Fall nutzbar wären und AMD keinen Sinn sieht alle bzw. noch mehr CUs freizuschalten. Wenn diese fused off sind, dann kann man auch sagen dass sie physisch nicht mehr vorhanden sind bzw. "totes" Silizium.

Mehr CUs abzuschalten macht nicht nur wegen Yield Sinn. Auch Leistungsaufnahme und Kühlung können dadurch verbessert werden. Der Die an sich ist schon mal riesig, es ist also mehr als im Bereich des Möglichen.

edit: Weil Locuza dir nach dem Mund spricht bist du natürlich seiner Narrative verfangen, logisch. Kepler hat afaik in der Vergangenheit einige Dinge zu CDNA geleaked von daher finde ich es interessant, dass du ihm hier sofort die "Expertise" absprichst, sie aber Locuza zubilligst. AMD kann am Ende viel sagen, das ist PR. Es gab schon unzählige Fälle wo mehr Features auf einem Die vorhanden waren, als offiziell kommuniziert. Auch Whitepaper sind nicht immer zu 100% akkurat, insbesondere da das Whitepaper von konkreten Produkten spricht, btw..

edit:

Du misprepräsentierst übrigens was Locuza bei Twitter sagt:

I know, I just mentioned that AMD is not too concerned about real representation, because that's not the only displayed difference.
The image you show uses the Arcturus die graphic and draws 14 CUs on top of it, covering the 16 CU array below.
But iirc AMD confirmed that only..

...14 CUs are physically present, but AMD does not show a real die shot of Aldebaran.
Let's believe them (or not...).
https://twitter.com/Locuza_/status/1457778658706276352

Er geht zwar von 14 CUs aus, sicher ist er sich aber auch nicht.

basix

2021-11-08, 22:09:52

Ich spreche Kepler_L2 keine Expertise ab, er hat ja oft recht akkurate Infos. Nur, dass offizielle Informationen typischerweise stärker gewichtet werden sollten als Leaker-Aussagen. Dass 128/256 schon lange vermutet werden, liegt aufgrund MI100 auf der Hand. Ich hatte bis zum Video von Locuza und den heute von AMD veröffentlichten Videos gar nie an eine 114 CU Variante gedacht, sondern bin immer (wie alle hier) von 128 CUs ausgegangen, wovon entsprechend einige deaktiviert werden.

Und ich spreche Locuza nicht Expertise zu und dem anderen nicht, nur dass er mit seiner Vermutung recht zu haben scheint ;)

Warten wir mal ab. Anandtech wird vermutlich bei AMD nachhaken.

Locuza

2021-11-08, 23:52:19

Aldebarahttps://www.amd.com/system/files/documents/amd-cdna2-white-paper.pdfn also in 6nm genau wie von mir spekuliert. :)
Ging nicht jeder von N6 aus?
AMD hat auf der Roadmap nur "Advanced Node" geschrieben.
In der Vergangenheit haben sie auch bei Vega und Zen3 7nm"+" geschrieben, also irgendetwas besseres, wobei es am Ende effektiv die gleiche Node war oder minimal mit kleinen Verbesserungen.
Entsprechend war die Tür ganz schön offen mit AMDs Beschreibung.
Da sie nicht explizit 5nm erwähnt haben wie bei Zen4, konnte man davon ausgehen, dass es zumindest das nicht sein wird.
Also verbessertes 7nm oder 6nm hatte man sich dann vorstellen können.
Laut TDevilfish und recht kürzlich ExecutableFix, würde CDNA2 aber nicht 6nm verwenden, sondern 7nm.
Zumindest ExecutableFix hatte einen guten Trackrecord und er hat auch die Specs nahezu korrekt geleakt.
Davor wussten wir nicht, dass die Produkte MI250(X) heißen werden und mit 1.7 GHz rennen.
Die 7nm-Info war aber falsch:
https://twitter.com/ExecuFix/status/1451979331362754563

Wenn Locuzas Info über die caches von Aldeberan stimmen, dann sind die im Vergleich zu A100 popelig klein, was es schwieriger macht die Leistung auch in echt abzurufen.
Da kann man stark davon ausgehen, denn ansonsten hätte AMD im Whitepaper diesbezüglich ein Upgrade erwähnt.
Die L2$-Größe von 8MB per Chip bestätigt das Unternehmen:
" The AMD CDNA 2 family uses a 16-way set-associative design with 32 slices with a total capacity of 8MB (per GCD)."
https://www.amd.com/system/files/documents/amd-cdna2-white-paper.pdf

AMD/TSMC hat die EMIB weiterentwickelt und zwischen Substrat und Die gesetzt:
[...]
Das ist meiner Meinung nach eine wichtige Innovation, die etwas stiefmütterlich behandelt wird. Intel braucht bei EMIB eine ins Substrat eingebrachte Bridge, was u.a. die Kosten erhöht.
[...]
Das war für mich persönlich eine der coolen Überraschungen.
Zu Beginn dachte ich das vielleicht CoWoS-L verwendet werden könnte, aber der Termin von Ende 2021 wurde auf 2022 verschoben, dennoch verwendet man eine ähnliche Methodik ohne Silizium-Interposer.

Was mir bei Anandtech aufgefallen ist:

Also wenn ich das richtig verstehe und Anandtech kein Müll schreibt, dann verhält sich Aldebaran immernoch nur wie eine Dual-GPU auf einem MCM und könnte als Dual-GPU erkannt werden? Erst mit RDNA3 dürften dann Chiplets kommen, die sich wie eine Single-GPU verhalten.
So würde ich es annehmen.
Persönlich habe ich gehofft das AMD über einen Silizium-Interposer oder eine Silicon-Bridge die Cross-Chip-Verbindung umsetzt, wie sie es eben Intel bei Ponte Vecchio tut, aber es geht klassisch über das Package mit 400GB/s.
Da wird man sicherlich für die starke NUMA-Eigenschaft optimieren müssen.

Sieht High-Level beim Chip und den Geometrien auf dem Chip fast exakt wie MI100 aus. Ausser dass hier HBM2e zum Einsatz kommt. Man könnte sogar fast meinen, es sei der gleiche Chip... :uponder:
[...]
edit: Weil Locuza dir nach dem Mund spricht bist du natürlich seiner Narrative verfangen, logisch. Kepler hat afaik in der Vergangenheit einige Dinge zu CDNA geleaked von daher finde ich es interessant, dass du ihm hier sofort die "Expertise" absprichst, sie aber Locuza zubilligst. AMD kann am Ende viel sagen, das ist PR. Es gab schon unzählige Fälle wo mehr Features auf einem Die vorhanden waren, als offiziell kommuniziert. Auch Whitepaper sind nicht immer zu 100% akkurat, insbesondere da das Whitepaper von konkreten Produkten spricht, btw..
[...]
Er geht zwar von 14 CUs aus, sicher ist er sich aber auch nicht.
[...]
Warten wir mal ab. Anandtech wird vermutlich bei AMD nachhaken.
Als ExecutableFix das Bild geteilt hat, wollte ich das schnell abchecken bevor der Live-Stream beginnt.
Es war dann direkt auffällig das es wie die Arcturus Die-Graphic aussieht, aber auch nicht völlig überrascht, da man stark davon ausgehen kann das AMD den Grundriss wiederverwendet.
Aber wenn man die Grafiken übereinander legt dann ist sofort klar, dass es die alte Arcturus die-graphic ist, schlicht nur anders gefärbt und präsentiert.

Ich bin anfangs auch von 16 CUs ausgegangen wegen Arcturus und L2_Keplers Behauptung in diesem Punkt, wobei 16 deaktivierte CUs dann schon viel sind, außer die yield is miserabel, deaktiviert soweit ich weiß kein Hersteller so massiv seine Produkte, außer für bestimmte Marktsegmente, wir reden hier aber über die Top-SKU.
15 CUs sind hässlich umzusetzen, denn man bräuchte eine I$/K$-Instanz mehr, 14 CUs sind ganz rund, dann sind nur 2 deaktivierte CUs aber sportlich, wenn es keine weiteren SKUs gibt.
Es gibt aber die MI250 welche nur 104 von 112 CUs verwendet, dass passt dann sehr gut ins Bild.
Ich glaube AMDs Aussage, dass es physikalisch nur 14 CUs bzw. 112 CUs pro Chip gibt.
Ebenso kann man sich aber natürlich nicht eine gewisse Paranoia verkneifen, die Hersteller verwenden Marketingmaterial wie sie lustig sind und erst neulich hat die AVX512-Geschichte bei Alder Lake wohl für einiges Stirnrunzeln gesorgt, nachdem explizit gesagt wurde die Einheiten sind fused-off und dann plötzlich funktioniert es doch.

basix

2021-11-09, 00:04:46

Noch was zu EFB und was es sein könnte (von bondrewd aus B3D): https://www.3dincites.com/2020/07/iftle-456-spil-fan-out-embedded-bridge-foeb-technology/

Scheint gegenüber CoWoS einige Vorteile zu bieten.

Unicous

2021-11-09, 01:17:10

Was meinst du mit was es sein könnte?:confused:

bondrewd fragt sich nur ob die Implementierung in MI200 mit TSMC oder ASE/SPIL entwickelt wurde bzw. produziert wird.

TSMC nennt es LSI
https://images.anandtech.com/doci/16031/Advanced%20Packaging%20Technology%20Leadership.mkv_snapshot_11.38_%5B2020.08.25_ 14.14.11%5D.jpg
https://www.anandtech.com/show/16031/tsmcs-version-of-emib-lsi-3dfabric

aber es ist essentiell das Gleiche, ein Silizium Interconnect der zwischen Substrat und Die(s) sitzt.

https://3uzly11fn22f2ax25l6snwb1-wpengine.netdna-ssl.com/wp-content/uploads/fig-1-7.jpg

basix

2021-11-09, 07:42:49

Ehm, genau darum gings ja, dass es mit höchster Wahrscheinlichkeit das gleiche ist. Einfach mit etwas mehr Infos als bei der InFo-LSI Präsentation.

EFB ist nicht etwas neues sondern eher ein Markenname von AMD. InFo-LSI anscheinend ebenfalls.

konkretor

2021-11-09, 08:05:51

Was mir bei Anandtech aufgefallen ist:

Also wenn ich das richtig verstehe und Anandtech kein Müll schreibt, dann verhält sich Aldebaran immernoch nur wie eine Dual-GPU auf einem MCM und könnte als Dual-GPU erkannt werden? Erst mit RDNA3 dürften dann Chiplets kommen, die sich wie eine Single-GPU verhalten.

Danke die Info, die hab ich schon gesucht, im HPC Bereich nicht so dramatisch.
Mal sehen bis wann MCM wirklich als Single GPU angezeigt wird.

Unicous

2021-11-09, 08:23:28

@basix

Natürlich ist es ein Marketingname. LSI zum Beispiel ist ein Schrottname weil er nicht einmal den Versuch unternimmt erahnen zu lassen was dahinter steckt. (Local Si Interconnect). "Fan-out Embedded Bridge" lässt da schon mehr durchblicken und eine "Elevated Fan-out Bridge" formt so halbwegs ein Bild.

Im Endeffekt ist der "Marketingname" aber scheiß egal. AMD hat daran mitgearbeitet bzw. die explizite Implementierung in einem Produkt vorangetrieben. Das ist eine herstellerübergreifende Entwicklung ich verstehe nicht, warum das so schwer zu verstehen ist.:rolleyes:

Das Gleiche ist geschehen bei HBM oder den Chiplets. AMD wie auch die Fabs haben Grundlagenforschung betrieben. Das ist eine Kollaboration. Dein "EFB ist nicht etwas neues" Seitenhieb ist vollkommen unangebracht. Es war von vornherein klar, dass es "nichts Neues" sein kann, denn AMD hat keine Fabs und ist daher auch nicht in der Lage neue Verfahrensprozesse aus dem Hut zu zaubern.:rolleyes:

Das Patent hat AMD übrigens Ende 2018 eingereicht und 1 1/2 Jahre später wurde es veröffentlicht:

https://www.freepatentsonline.com/20200185367.pdf

Worauf willst du also hinaus? Dass AMD was von der Stange genommen hat und es jetzt als das eigene Produkt deklariert?:rolleyes:
Damit stößt du den unzähligen Ingenieuren an den Kopf die jahrelang an dieser Lösung gearbeitet haben. Und wie bei so vielen Erfindungen gibt es nicht nur den einen klugen Kopf der Heureka ausruft, sondern unzählige die auf der ganzen Welt an neuen Lösungen tüfteln. Genauso wie Apple mit TSMC zusammenarbeitet und Ansprüche an den Prozess stellt, ist das bei AMD Nvidia und Co. natürlich auch der Fall. Nvidia hält auch unzählige Verfahrenspatente. (Und wie bei so vielen Patenten gilt auch hier, nicht wer die Idee zuerst hatte ist der Gewinner sondern derjenige, der zuerst das Patentamt informiert, außerdem gibt es unzählige redundante Patente, deswegen ist es auch so lächerlich wenn große Unternehmen deswegen vor Gericht ziehen). Die Grundlagenforschung findet überall und zeitgleich statt und ist nicht lokal auf die einzelnen Fabs und ihre Forschungslabore beschränkt. Testament dafür ist, das man nicht sicher ist, ob Mi200 bei ASE zusammengebastelt wird oder direkt bei TSMC.

basix

2021-11-09, 09:19:28

Du legst mir ein bisschen zu viele Sachen in den Mund ;) Nirgends habe ich was dazu geschrieben, dass AMD nicht an der Co-Entwicklung beteiligt war. Und wer weiss, evtl. hat EFB noch was drin, was LSI nicht hat. Die Verfahren sind aber sehr ähnlich, deswegen kann man gewisse technische und kostenmässige Vorteile übertragen. Nur um das ging es mir: Sachliche Aspekte rund um die Technologie, welche interessant sind, die man nun aus verschiedenen Quellen zusammentragen kann.

Nun bitte BTT, bei Bedarf können wir das auch per PN ausdiskutieren

Unicous

2021-11-09, 10:03:09

Es ist genau das Gleiche.:confused: Nochmals, worauf willst du hinaus? Deine Posts ergeben keinen Sinn.

Ob FOEB oder LSI. Die Namen sind Schall und Rauch, die Herangehensweise ist so ähnlich, dass man gar nicht sagen kann welche Firma hier Assembly und Packaging macht. Hier Korinthen zu kacken ist völlig fehl am Platz. Ich verstehe auch nicht warum du BTT schreibst, wenn du selbst diese eher nebensächliche "Info" eingebracht hast. :uponder:

EFB zeigt, dass AMD/TSMC weiterhin die Zügel in der Hand halten, auch was neue Packaging-Technologien anbelangt. Mit Foveros haben ja einige schon die Intel-Ära eingeläutet, ich bin mir aber ziemlich sicher, dass AMD noch so einige Überraschungen in petto hat. Cache-Stacking ist auch nur ein weiter Baustein. Micro bumps, TSVs, Interposer waren es davor. Intel spricht gerne und oft von tollen neuen Entwicklungen, zu Massenprodukten hat es in jüngerer Vergangenheit nicht gereicht bzw. wurden diese teuren Experimente nach kurzer Zeit wieder eingestellt (siehe Kaby Lake G und Lakefield). Irgendwas mit EMIB und Foveros soll dann erst wieder 2022 kommen und ich habe das Gefühl, dass man hier too late and too expensive sein wird außerhalb des angekündigten Aurora Upgrades, für das man schon drauf zahlen muss.

Gerüchteweise wird "MI300" eine APU und das kann nur bedeuten, dass man hier all die Technologien die gestern vorgestellt wurden in ein neues Produkt gießt und ein Gesamtpaket schnürt. Auch hier ist wieder Kollaboration gefragt zwischen AMD und Fabs und A&P.

edit: Foveros Omni, Intels Version der gleichen Philosophie soll erst 2023 bereit für Produkte sein.

fondness

2021-11-09, 10:09:33

So würde ich es annehmen.
Persönlich habe ich gehofft das AMD über einen Silizium-Interposer oder eine Silicon-Bridge die Cross-Chip-Verbindung umsetzt, wie sie es eben Intel bei Ponte Vecchio tut, aber es geht klassisch über das Package mit 400GB/s.
Da wird man sicherlich für die starke NUMA-Eigenschaft optimieren müssen.

Wenn ich mir ansehe, welchen unfassbaren Aufwand Intel mit Ponte Vecchio betreiben muss, um unterm Strich auch nicht schneller wie Aldebaran zu sein, dann hat AMD denke ich einen guten Weg gewählt. Vor allem: Wann kommt das Ding jetzt eigentlich genau?

Unicous

2021-11-09, 10:23:41

Ja, so sehe ich das auch. PV scheint ein teures Unterfangen zu werden und ich kann mir momentan nicht vorstellen, dass man hier signifikante design wins ergattern kann, wenn die Konkurrenz ein augenscheinlich deutlich ausgewogeneres Produkt anbietet. Die einzige Hürde die ich sehe sind die riesigen Dies seitens AMD, aber ich wette die werden durch das günstigere und einfachere Packaging wieder aufgewogen.

mksn7

2021-11-09, 12:05:07

Die Zahl "110 CU/Die" kenn ich schon relativ lange. Wenn es physikalisch mehr wären, hätte man sich nicht so früh festgelegt wieviele man genau abschaltet.

Für HPC ist es einfacher das Richtige zu tun, wenn sich die Karte als zwei devices meldet. Sonst müsste man für die optimale performance wie bei den CPUs NUMA beachten (pinning, first touch allocation,...), und das ist in den GPU APIs von heute gar nicht vorgesehen. Wenn man stattdessen die Karte als mGPU programmiert, hat man für NUMA automatisch alles richtig gemacht.

Edit: 110 macht ja gar keinen Sinn. Ist ja nicht durch 4 teilbar, und im whitepaper steht ja auch 112.

AffenJack

2021-11-09, 17:36:12

PV scheint ein teures Unterfangen zu werden und ich kann mir momentan nicht vorstellen, dass man hier signifikante design wins ergattern kann, wenn die Konkurrenz ein augenscheinlich deutlich ausgewogeneres Produkt anbietet.

Ausgewogeneres Produkt? Also das dürfte ganz klar PV werden, wenn auch zu einem extrem teuren Preis. CDNA2 geht in Richtung der chinesischen Supercomputer mit extrem hohen Gflopzahlen, die man aber sehr schwer auslasten kann. Macht eher den Eindruck, dass man einfach die höchsten Zahlen wollte, um Exascale draufschreiben zu können. Heißt nicht, dass MI200 nicht trotzdem beeindruckend ist. Aber in Sachen Ausgewogenheit sollte PV mit seinen Caches etc. deutlich vorraus sein. PV dürfte viel leichter auszulasten sein und auch für viel mehr Anwendungen geeignet sein.

Unicous

2021-11-09, 18:22:49

Hier ging es allein um ökonomische Faktoren im Vergleich zum Packaging-Verfahren keine Ahnung warum du dich bemüßigt fühlst meine Worte zu verdrehen und daraus eine Aussage zu Performance-Metriken zu machen wenn PV nicht einmal veröffentlicht wurde.:rolleyes:

Außerdem ist dieses Mimimi von wegen AMD bruteforced Performance während Nvidia und Intel "eleganter" die Leistung abrufen solch eine abgehalfterte Argumentation.:rolleyes:
Offensichtlich ist das eine you win some you lose some Architektur die nicht alle Märkte bedienen kann. CDNA ist keine radikal neu entwickelte Architektur. Und dennoch ist es ein bemerkenswertes Produkt, weil es zeigt, dass AMD eine Vision hat und diese auch verfolgen kann und nicht nur herumdümpelt wie die Jahre zuvor.

fondness

2021-11-09, 18:29:58

Ausgewogeneres Produkt? Also das dürfte ganz klar PV werden, wenn auch zu einem extrem teuren Preis. CDNA2 geht in Richtung der chinesischen Supercomputer mit extrem hohen Gflopzahlen, die man aber sehr schwer auslasten kann. Macht eher den Eindruck, dass man einfach die höchsten Zahlen wollte, um Exascale draufschreiben zu können. Heißt nicht, dass MI200 nicht trotzdem beeindruckend ist. Aber in Sachen Ausgewogenheit sollte PV mit seinen Caches etc. deutlich vorraus sein. PV dürfte viel leichter auszulasten sein und auch für viel mehr Anwendungen geeignet sein.

Die Leistung von supercomputern wird in der Praxis gemessen und nicht theoretische Zahlen verglichen. Von daher macht das Argument wenig Sinn. Zumal die Kunden von AMD, immerhin die höchsten Stellen der USA wohl sicher wenig Interesse daran haben einen papiertiger zu kaufen.

mboeller

2021-11-09, 19:21:22

https://mobile.twitter.com/Locuza_/status/1458132215221702662

So, how did it turn out after AMD's official reveal?
There were some big surprises for me:

- Matrix FP64 is as fast as Matrix FP32, I assumed half-rate.
So you do get ~96 TFLOPs there.

- The chips appear much larger than I expected, instead of ~600mm² about 720-740mm².

96TFlops!

Locuza

2021-11-10, 01:06:55

[...]
Ob FOEB oder LSI. Die Namen sind Schall und Rauch, die Herangehensweise ist so ähnlich, dass man gar nicht sagen kann welche Firma hier Assembly und Packaging macht. Hier Korinthen zu kacken ist völlig fehl am Platz. Ich verstehe auch nicht warum du BTT schreibst, wenn du selbst diese eher nebensächliche "Info" eingebracht hast. :uponder:

EFB zeigt, dass AMD/TSMC weiterhin die Zügel in der Hand halten, auch was neue Packaging-Technologien anbelangt.[...]
Du hattest ein Bild auf der vorherigen Seite gezeigt, es sieht sehr stark nach FOEB von ASE/SPIL aus:
https://www.3dincites.com/2020/07/iftle-456-spil-fan-out-embedded-bridge-foeb-technology/

Laut David Schor waren die auch für das Packaging von Vega zuständig.
https://twitter.com/david_schor/status/1458081551460225031

Was aber mehr wiegt ist die Beschreibung.
Bei FOEB wird zuerst ein organischer Interposer mit Kupferleitungen und einer Silicon-Bridge hergestellt, vergossen, geschliffen und mit Microbumps versehen.
Anschließend kommen die compute chips und HBM drauf und dann wird das Ganze noch einmal vergossen.
Das ist dann ein Chip-Last-Prozess.

InFO-L wird als Chip-First von TSMC beschrieben:
https://images.anandtech.com/doci/16031/Advanced%20Packaging%20Technology%20Leadership.mkv_snapshot_02.28_%5B2020.08.25_ 14.13.18%5D.jpg

AMDs Zeichnungen zeigen Mold1 und Mold2:
https://pics.computerbase.de/1/0/1/1/9/7-b1bf61181f4a280d/17-1080.e4a1bd70.jpg

Das sollte dann zum Chip-Last-Verfahren bei FOEB passen.

Wenn ich mir ansehe, welchen unfassbaren Aufwand Intel mit Ponte Vecchio betreiben muss, um unterm Strich auch nicht schneller wie Aldebaran zu sein, dann hat AMD denke ich einen guten Weg gewählt. Vor allem: Wann kommt das Ding jetzt eigentlich genau?
Im November 2020 ging man noch von H1 2022 aus:
“We haven’t modified from that, which was sort of a window of the end of 2021 to the first half of 2022 timeframe,” said McVeigh. “I think that’s still the window that we’re describing for that work. We’ve still got work to do. Obviously, that’s more than a year from now, but we’re pretty pleased with some of the modifications we did based on the changes back in in the July timeframe. So I won’t give any more public information at this stage on it, but we’re happy where that’s proceeding.”
https://insidehpc.com/2020/11/at-sc20-a-bridge-to-ponte-vecchio-intel-provides-aurora-updates-as-argonne-developers-use-substitute-intel-xe-hp-gpus/

Sapphire Rapids Produktion soll in Q2 hochgefahren werden, wenn Intel das die Entwicklungspipeline gut gemanaged hat, könnte H1 2022 noch passen.
Ansonsten kommt es später und es stellt sich die Frage wie fern oder nah CDNA3 und Amperes Nachfolger sind.

[...]
Außerdem ist dieses Mimimi von wegen AMD bruteforced Performance während Nvidia und Intel "eleganter" die Leistung abrufen solch eine abgehalfterte Argumentation.:rolleyes:
Offensichtlich ist das eine you win some you lose some Architektur die nicht alle Märkte bedienen kann. CDNA ist keine radikal neu entwickelte Architektur. Und dennoch ist es ein bemerkenswertes Produkt, weil es zeigt, dass AMD eine Vision hat und diese auch verfolgen kann und nicht nur herumdümpelt wie die Jahre zuvor.
Die Leistung von supercomputern wird in der Praxis gemessen und nicht theoretische Zahlen verglichen. Von daher macht das Argument wenig Sinn. Zumal die Kunden von AMD, immerhin die höchsten Stellen der USA wohl sicher wenig Interesse daran haben einen papiertiger zu kaufen.
Es ist natürlich bei allen ein Trade-Off zwischen vielen Faktoren.
PVC ist ein Monster in vielen Bereichen, verwendet aber auch viel Bleeding-Edge-Zeug, wo man sich fragen kann, ob sich ökonomisch so gut ausfällt wie bei simpleren Konkurrenzprodukten.
Bei AMD ist aber auch offensichtlich, dass CDNA2 bei mehreren Gebieten seine Probleme haben sollte.
Es hat ein sehr dürres Cache-Subsystem und eine starke NUMA-Charakteristik.

Natürlich zählen in der Realität, bzw. für die Unternehmen, nur die Erträge durch die Business-Deals.
AMD hat Frontier gewonnen und auch schon El Capitan, was finanziell sicherlich nicht wirklich hilft, aber wie bei den Konsolen bei der Verbreitung der Hardware und vor allem der Softwareoptimierung für das ganze Ökosystem helfen sollte.

Aber wie die Zukunft aussieht kann man schwer sagen.

Unicous

2021-11-10, 02:19:47

basix

2021-11-10, 10:43:56

Es ist natürlich bei allen ein Trade-Off zwischen vielen Faktoren.
PVC ist ein Monster in vielen Bereichen, verwendet aber auch viel Bleeding-Edge-Zeug, wo man sich fragen kann, ob sich ökonomisch so gut ausfällt wie bei simpleren Konkurrenzprodukten.
Bei AMD ist aber auch offensichtlich, dass CDNA2 bei mehreren Gebieten seine Probleme haben sollte.
Es hat ein sehr dürres Cache-Subsystem und eine starke NUMA-Charakteristik.

Natürlich zählen in der Realität, bzw. für die Unternehmen, nur die Erträge durch die Business-Deals.
AMD hat Frontier gewonnen und auch schon El Capitan, was finanziell sicherlich nicht wirklich hilft, aber wie bei den Konsolen bei der Verbreitung der Hardware und vor allem der Softwareoptimierung für das ganze Ökosystem helfen sollte.

Anscheinend soll CDNA3 eher früh als spät kommen. In 5nm macht das Sinn, das ist um die Ecke und wird einen guten Boost bringen bezüglich Density und Energieeffizienz. Wenn ich tippen sollte, was AMD mit CDNA3 macht:

Gleiches Konstrukt aus 2x GCD und 8x HBM2e
Mehr CUs (obviously)
Vergrösserte Caches (=Flops auf die Strasse bringen)
3D Infinity Cache (bandwidth amplification, latency reduction; sehr gross, evtl. sehen wir hier die 8-hi Stacks, jeweils mittig zwischen zwei HBM-Interfaces direkt bei den Speichercontrollern und somit 2x 512MByte pro GCD; Cache liegt unterhalb der GCDs wie die EFBs zum HBM)
Aufgebohrte Matrix Cores (verglichen mit CDNA2 2x FP32/CU sowie INT8/4 Beschleunigung)
Schnellere Off-Chip Links wären ebenfalls nicht schlecht (2x Bandbreite, PAM-4 Signaling?). Evtl. wäre hier aber Nvidias Ansatz schlussendlich besser: Zentraler IF-Link Switch. Momentan verwendet AMD 6x Links zwischen den GPUs, was total 600 GByte/s entspricht. Nvidia hat hier mit A100 und NVLink pro Chip nicht mehr, sind ebenfalls 600 GByte/s. Mit einem Switch 5-Port Switch (4x GPUs, 1x CPU) wäre das wohl eine gute Lösung bezüglich NUMA und Peak-Bandwidth zwischen einzelne GPUs.
Falls es dann noch drin liegt bezüglich Power Draw: Mehr Takt

Was ich bei (sehr üppigen) IF$ als grossen Vorteil ansehe: Neben dem Caching für normale Speicherbandbreite (lokaler HBM) kann man damit auch das NUMA Verhalten innerhalb des Nodes stark glätten.

Caching von HBM wie auch IF-Link Datentransfers
HBM Speicherbandbreite muss mit IF$ nur moderat erhöht werden. IF-Link Bandbreite stärker erhöhen, und die entsprechenden Bandbreiten nähern sich an (was NUMA zusätzlich reduziert)

Wenn man so will, könnte man mit CDNA3 oder evtl. erst CDNA4 den HPC-Node bestehend aus 1x CPU und 4x GPU mehr oder minder als "riesen APU" ansehen. Infinity Cache wäre dazu der Key, da man mit Pre-Fetching und Caching das NUMA-Verhalten eben stark glätten kann.

Piefkee

2021-11-10, 10:54:33

Anscheinend soll CDNA3 eher früh als spät kommen. In 5nm macht das Sinn, das ist um die Ecke und wird einen guten Boost bringen bezüglich Density und Energieeffizienz. Wenn ich tippen sollte, was AMD mit CDNA3 macht:

Gleiches Konstrukt aus 2x GCD und 8x HBM2e
Mehr CUs (obviously)
Vergrösserte Caches (=Flops auf die Strasse bringen)
3D Infinity Cache (bandwidth amplification, latency reduction; sehr gross, evtl. sehen wir hier die 8-hi Stacks, jeweils mittig zwischen zwei HBM-Interfaces direkt bei den Speichercontrollern und somit 2x 512MByte pro GCD; Cache liegt unterhalb der GCDs wie die EFBs zum HBM)
Aufgebohrte Matrix Cores (verglichen mit CDNA2 2x FP32/CU sowie INT8/4 Beschleunigung)
Schnellere Off-Chip Links wären ebenfalls nicht schlecht (2x Bandbreite, PAM-4 Signaling?). Evtl. wäre hier aber Nvidias Ansatz schlussendlich besser: Zentraler IF-Link Switch. Momentan verwendet AMD 6x Links zwischen den GPUs, was total 600 GByte/s entspricht. Nvidia hat hier mit A100 und NVLink pro Chip nicht mehr, sind ebenfalls 600 GByte/s. Mit einem Switch 5-Port Switch (4x GPUs, 1x CPU) wäre das wohl eine gute Lösung bezüglich NUMA und Peak-Bandwidth zwischen einzelne GPUs.
Falls es dann noch drin liegt bezüglich Power Draw: Mehr Takt

Was ich bei (sehr üppigen) IF$ als grossen Vorteil ansehe: Neben dem Caching für normale Speicherbandbreite (lokaler HBM) kann man damit auch das NUMA Verhalten innerhalb des Nodes stark glätten.

Caching von HBM wie auch IF-Link Datentransfers
HBM Speicherbandbreite muss mit IF$ nur moderat erhöht werden. IF-Link Bandbreite stärker erhöhen, und die entsprechenden Bandbreiten nähern sich an (was NUMA zusätzlich reduziert)

Wenn man so will, könnte man mit CDNA3 oder evtl. erst CDNA4 den HPC-Node bestehend aus 1x CPU und 4x GPU mehr oder minder als "riesen APU" ansehen. Infinity Cache wäre dazu der Key, da man mit Pre-Fetching und Caching das NUMA-Verhalten eben stark glätten kann.

CDNA3 wird sicherlich die neue TSMC CoWos5 nutzen damit kannst du anstatt 2 nun 3 chips verbinden.
Damit hast du dann 3 Chips und 12x HBM2e

Felixxz2

2021-11-16, 02:20:30

Wieso kommt die Mi200 eig mit so wenig L2$? Selbst A100 hat 5x so viel, bei deutlich geringerer Rechenleistung. Ist AMDs Cache System anders aufgebaut, mehr Register oder L1? Oder einfach ein Trade Off für mehr Raw Power, für eben eher spezielle Anwendungsfälle?

basix

2021-11-16, 09:03:34

Das ist ein Design-Tradeoff. Mit grösseren Caches ist es typischerweise einfacher, die maximale Leistung auf den Boden zu bringen. Dafür kostet es Platz und Energie. Da AMDs Kunden bei MI200 vor allem HPC/Supercomputer betreiben, kann dort ein höherer Optimierungsgrad auf Seiten Software erwartet werden. Das verringert das Problem etwas.

AMD hat von Seiten Caches bei MI200 schon noch einige Features hinzugefügt, welche das Problem reduzieren sollten (weiss nicht mehr, ob das im Whitepater von CDNA2 steht). Aber man kann sich ziemlich sicher sein, dass die Grösse der Caches bei CDNA3 steigen wird. Grössere L1/L2 Caches sind da ein Thema. Infinity Cache als LLC ein anderes.

Siehe auch Intels Ponte Vecchio, der hat extrem viel Cache verbaut. Viel mehr als auch Ampere.

Felixxz2

2021-11-19, 17:55:10

Interessant, ja grad gelesen bei CB, wo es nochmal mehr Details gab. Anscheinend wurde u.a. die L2 Bandbreite auf über 7 TB/s verdoppelt.
Trotrzdem natürlich die Frage wieso man nicht schon diese Gen mehr Cache verbaut hat.

basix

2021-11-22, 11:07:04

Interessant, ja grad gelesen bei CB, wo es nochmal mehr Details gab. Anscheinend wurde u.a. die L2 Bandbreite auf über 7 TB/s verdoppelt.

Nicht nur das. Im LDS sowie L2$ wurden FP64-Atomics für min/max etc. hinzugefügt. Wusste gar nicht, dass dies in den Caches gemacht wird. Macht aber eigentlich sehr viel Sinn, um die Datenwege möglichst kurz zu halten.

Trotrzdem natürlich die Frage wieso man nicht schon diese Gen mehr Cache verbaut hat.
Wie gesagt: Ein Design Tradeoff. AMD wollte/musste dieses Jahr noch liefern. Da ist der Sprung zwischen CDNA1 und CDNA2 mit HBM2e, Elevated Fanout-Bridge, Full-Rate FP64, Matrix-FP64 und 2x Bfloat16-Ops/Cycle sowie Speicherkohärenz zur CPU schon ein ziemlich grosser Sprung. Und in 6nm sind bei den Target-Applikationen anscheinend mehr Flops mehr Wert als mehr Cache.

CDNA3 soll anscheinend ja schon gegen Ende 2022/Anfang 2023 aufschlagen. Da in 5nm, sollten grössere Caches und Infinity Cache dann drin liegen ;) Bei CDNA3 erhoffe ich mir dann auch, dass die zwei GCDs als eine GPU auftreten (siehe RDNA3), wobei die GCDs dann mit IF$-Chiplets verbunden und 3D-Stacked sind. Das sollte schon einen schönen Boost geben. Zudem erhoffe ich mir, dass AMD so etwas wie einen NV-Link Switch einführt, welcher innerhalb des 4-GPU Nodes alle GPUs via Crossbar verbindet. Das ergäbe einen deutlichen Bandbreitenboost, ohne das man mehr IF-Link PHYs benötigen würde. Die beiden GCDs haben total 8x Links. Diese auf den IF-Link-Switch geführt und auf PCIe 5.0+ umgestellt (z.B. 150 GByte/s anstatt 100 GByte/s pro Link), und man erhält ~1200 GB/s anstatt ~400 GB/s zu den anderen GPUs. Beim Switch kann man noch zusätzliche Ports für den zweiten 4-GPU-Node vorsehen, dann hat man einen 8-GPU Node in einem 1U-Blade (wenn Wassergekühlt). Etwa so wie in der Grafik unten würde ich mir das vorstellen. Den IF-Link Switch kann man dann auch für CDNA4 wiederverwerten (Design Re-Use, Upgrade Pfad für Kunden).

Infinity Cache auf den GPUs als auch optional auf dem IF-Link-Switch wäre ein grosser Vorteil. Locuza hat bereits vor einiger Zeit dazu was verlinkt, was Nvidia in einem Paper dazu ausgearbeitet hat: https://research.nvidia.com/publication/2017-06_MCM-GPU:-Multi-Chip-Module-GPUs
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12770475#post12770475
Mit dem IF-Cache kann man off-chip Traffic buffern, was bei 512-1024 MByte pro GPU wohl ziemlich gut machbar wäre. Im Nvidia Paper haben sie 16 MByte pro Chiplet verwendet. Auf dem IF-Link Switch könnte man das auch, um z.B. Traffic vom anderen 4-GPU Node oder aus dem Netzwerk zu buffern. Das sehe ich aber eher als optional an. Auf den GPUs selbst macht es sicher mehr Sinn.

Locuza

2021-12-06, 18:31:07

ASE hat schon bei Fiji mitgearbeitet. AMD arbeitet mit ihnen spätestens seit sie ihre A&P Fabs verkauft haben, bzw. Ati hat mit ihnen natürlich schon vorher zusammengearbeitet, fällt mir gerade ein.

Und nochmals, es ist scheiß egal, ob TSMC, ASE oder wer auch immer das Packaging übernimmt. Ich verstehe nicht warum ihr euch darauf so versteift.:confused:
Die zugrunde liegende Technologie erreicht am Ende das Gleiche.
[...]
Mir ging es allgemein nur darum die Frage zu beleuchten, wer für das Packaging (mit)verantwortlich ist.
Keine Versteifung meinerseits. :wink:

[...]
Wenn ich tippen sollte, was AMD mit CDNA3 macht:
[LIST]
Gleiches Konstrukt aus 2x GCD und 8x HBM2e

[...]
Schnellere Off-Chip Links wären ebenfalls nicht schlecht (2x Bandbreite, PAM-4 Signaling?). Evtl. wäre hier aber Nvidias Ansatz schlussendlich besser: Zentraler IF-Link Switch. Momentan verwendet AMD 6x Links zwischen den GPUs, was total 600 GByte/s entspricht. Nvidia hat hier mit A100 und NVLink pro Chip nicht mehr, sind ebenfalls 600 GByte/s. Mit einem Switch 5-Port Switch (4x GPUs, 1x CPU) wäre das wohl eine gute Lösung bezüglich NUMA und Peak-Bandwidth zwischen einzelne GPUs.

https://videocardz.com/newz/amd-instinct-mi300-gpu-to-feature-4-graphics-chiplets

Ich weiß nicht, ob das erneut von AMDs Linux-Treibern kommt, aber 4x GCDs werden für MI300 aktuell formuliert.
Es scheint auch so, dass Intel in der Zukunft mit 4x Chips aufbäumen wird, gegenüber 2x beim aktuellen Ponte-Vecchio-Model.

___

Falls ich das richtig sehe, dann fällt die Kommunikation bei Nvidia ja wesentlich besser aus.
Bei der MI250X gibt es 4x Links zwischen den GCDs auf einem Package, womit man bidirektional auf 400GB/s kommt.
Für die Verbindung zu anderen GDCs werden entweder 2x Links oder gar nur 1x Link verwendet.
Insgesamt kommt man dann auf 700 bzw. 600GB/s zwischen GCDs, aber praktisch ist das ganz anders aufgeteilt.
Dank NVSwitch hat man bei Nvidia aber eine vollständig vernetzte Crossbar, wo bis zu 16 GPUs untereinander mit 600GB/s kommunizieren können, während die Direktkommunikation bei AMD 400, 200 oder gar nur 100GB/s zwischen GCDs ermöglicht.

Falls CDNA3 mit 4x Chips pro Package kommt, werden diese vermutlich über eine Silizium-Verbindung verfügen, was diese Runde noch nicht geklappt hat.
Das sollte die Situation innerhalb des Packages dann schon wesentlich verbessern.
Off-Chip wird sich AMD sicherlich auch mehr anstrengen.

davidzo

2021-12-07, 14:56:06

Siehe auch Intels Ponte Vecchio, der hat extrem viel Cache verbaut. Viel mehr als auch Ampere.

Intel gibt aber auch zu dass ihr erster Wurf, also PV eher imbalanced ist in Bezug auf Rohleistung vs Speichersystem. Raja gibt in dem Talk mit Patrick kennedy von STH ganz offen zu dass Intel dort AMD und Nvidia in bezug auf Math Density hinterherhinkt. AMD liegt bei DP vorne und Nvidia bei Matrix-Operationen.

One of the big ones and the first on that list is “Architecture” with a 16x improvement. That 16x involves adopting similar math execution to what some others in the market are doing.
https://www.servethehome.com/rajas-chip-notes-lay-out-intels-path-to-zettascale/

Und:
His position is that Intel would focus on not just DP execution that may get Intel to the Zettaflop era, but also AI math operations, and perhaps most importantly ensuring that memory bandwidth is plentiful and well-utilized.

Dadrin steckt aber sicher auch ein bisschen Marketing für PV ("most importantly memory bandwidth"...), da Raja als VP natürlich keinen Osborne Effekt anstoßen darf. Und genau dieses "mehr DP als Nvidia" und "mehr Matrix als AMD" ist ja auch schon die bisherige Balance von PV.
Es kann schon sein dass Intel einfach beim Speichersystem schon eine Architekturstufe weiter ist, für die Alus aber weiterhin die von XE abgeleitete µArch herhalten musste welche nicht die optimale compute Density erreicht die man sich für die Zukunft wünscht.

Den authentischere Teil seiner Aussage abseits von marketing für PV ist also "16x improvement (...) by adopting similar math execution to what some others in the market are doing". Die wollen also mehr Density bei den Alus, bzw. sehen dass sie dort gegenüber AMD zurückliegen bzw. bei den matrixengines gegenüber Nvidia.

Falls ich das richtig sehe, dann fällt die Kommunikation bei Nvidia ja wesentlich besser aus.
Bei der MI250X gibt es 4x Links zwischen den GCDs auf einem Package, womit man bidirektional auf 400GB/s kommt.
Für die Verbindung zu anderen GDCs werden entweder 2x Links oder gar nur 1x Link verwendet.
Insgesamt kommt man dann auf 700 bzw. 600GB/s zwischen GCDs, aber praktisch ist das ganz anders aufgeteilt.
Dank NVSwitch hat man bei Nvidia aber eine vollständig vernetzte Crossbar, wo bis zu 16 GPUs untereinander mit 600GB/s kommunizieren können, während die Direktkommunikation bei AMD 400, 200 oder gar nur 100GB/s zwischen GCDs ermöglicht.

Das kann man so nicht direkt vergleichen.
- ja, Nvlinks sind flexibler und Peak ist die von nvidia gebotene Bandbeite zwischen zwei GPUs theoretisch höher. Aber genau in jenem 16GPU Szenario ist das nicht ganz praxisrelevant.
- Du kannst nicht die aggregierte Bandbreite bei Nvidia mit der Einzelbandbreite eines IFlinks vergleichen. Wenn dann musst du auch die aggregierte Bandbreite aller IFlinks anrechnen und das sind ebenfalls 600gb/s, also Gleichstand.
- Wenn du dir die Topologie von NVswitch anguckst, sind das sechs einzelne switches mit jeweils 2x lanes pro GPU. Wenn das Cluster gleichmäßig ausgelastet ist, kann auf eine einzelne NachbarGPU also nur mit 2x Links zugegriffen werden, die anderen 10 Nvlinks sind mit anderen GPUs verbunden.
https://images.anandtech.com/doci/15801/NVSwitch_575px.png
- Die volle Bandbreite von 600gb/s steht also nur zur Verfügung wenn lediglich eine einzelne GPU ausgelastet ist und auf den Speicherpool von allen anderen GPUs zugreift, weil diese ihre NVlink Verbindung gerade nicht anders auslasten.
- Man kann sich das so vorstellen als wenn der Switch eine Backplane von 600gb/s hat und eine pro port Bandbreite von 600gb/s. Wenn das ganze System ausgelastet ist kommt also insgesamt nicht mehr als 600gb/s durch, also 50gb/s pro GPU wenn gleichverteilt. Das ist genau so viel wie mit PCIe4.0 X16, also nichts besonderes.
- Die 600gb/s sind also ein idealszenario, was bei guter Auslastung nicht eintritt, ganz wie bei AMDs Lösung auch.
- Theoretisch kannst du bei AMD auch über mehrere Hops bzw. GPUs im Kreis gehen und damit alle IFlinks einer GPU mit allen einer anderen verbinden und somit die totale Bandbreite addieren. Die Frage ist ob das energetisch und für die praxis Sinn macht.
- Nicht ohne Grund sieht man in der Praxis nur A100 Cluster mit maximal 8 GPUs, wie Nvidias eigener DGX-A100. Allerdings verwenden viele Hersteller wohl auch einfach weniger NVswitch Chips anstatt die freigewordenen Links dann untereinander zu einer Backplane zu verbinden.

Klar der NVswitch ist sehr flexibel und hat den Vorteil von mehr möglichen GPUs im Cluster, aber ist das nur ein Vorteil?
- Für viele Workloads ist die CPU zu GPU Bandbreite wichtiger, weil die benötigten Daten im RAM liegen und nicht auf einer anderen GPU. Nvswitch bindet die CPUs auch nur mit 300gb/s pro CPU an (600gb/s total), was aufgeteilt auf 16 GPUs nur noch 50gb/s sind. Bei IFlinks kann man immerhin entscheiden je nach Systemkonfiguration deutlich mehr cpu to GPU Bandbreite zu verwenden.
- NVswitch added nicht unerheblich zu den Speicherlatenzen.
- Vom Power-budget her ist es viel teurer über NVswitch auf den Speicher einer GPU im Cluster zuzugreifen als auf den eigenen und immer noch etwas teurer als auf den einer benachbarten GPU.
- Aldebaran hat 128gb, A100 in der standardversion nur 40GB, optional 80gb. Der Bedarf an externer Bandbreite wird bei Mi250x also geringer sein als bei A100.

Locuza

2021-12-13, 15:27:56

3DCenter braucht ein Forenupdate.
Ich würde mir bessere Bildupload-Funktionen wünschen, Zitatbenachrichtigungen und ein Like-Button, denn dein Beitrag davidzo war großartig, danke dafür. :)

basix

2021-12-13, 16:08:33

- Wenn du dir die Topologie von NVswitch anguckst, sind das sechs einzelne switches mit jeweils 2x lanes pro GPU. Wenn das Cluster gleichmäßig ausgelastet ist, kann auf eine einzelne NachbarGPU also nur mit 2x Links zugegriffen werden, die anderen 10 Nvlinks sind mit anderen GPUs verbunden.
https://images.anandtech.com/doci/15801/NVSwitch_575px.png
- Die volle Bandbreite von 600gb/s steht also nur zur Verfügung wenn lediglich eine einzelne GPU ausgelastet ist und auf den Speicherpool von allen anderen GPUs zugreift, weil diese ihre NVlink Verbindung gerade nicht anders auslasten.
- Man kann sich das so vorstellen als wenn der Switch eine Backplane von 600gb/s hat und eine pro port Bandbreite von 600gb/s. Wenn das ganze System ausgelastet ist kommt also insgesamt nicht mehr als 600gb/s durch, also 50gb/s pro GPU wenn gleichverteilt. Das ist genau so viel wie mit PCIe4.0 X16, also nichts besonderes.
- Die 600gb/s sind also ein idealszenario, was bei guter Auslastung nicht eintritt, ganz wie bei AMDs Lösung auch.

Ich hätte das anders eingeschätzt, da ja 6-12 NVSwitches pro Cluster verbaut werden:
- NVLink Switches beinhalten eine Crossbar
- Wenn man jede GPU zu jedem Crossbar mit 1-2 Links anhängt, hat man 6-12 Links von der GPU zu jeder anderen GPU
- Je nachdem, wie viele Ports der NVSwitch hat, gilt das auch zwischen den zwei 8-GPU-Blöcken
- Bei Ampere gibt es entweder eine neue Version (anhand des NVSwitch Schaubildes von Ampere, 28-32 NVLink Ports, wäre mir aber neu dass es den gibt) oder man hat die bestehende Version genommen (18 Ports)

32 Ports:
- Innerhalb der einen Seite des Clusters (GPUs 1-4 und 9-12) hat man 12 Links und somit 600 GByte/s bidirektional --> 2 Hops
- Auf die andere Seite hat man 6*16=96 Lanes, somit pro GPU im Schnitt 96/8*50GB/s = 600 GByte/s --> 3 Hops

28 Ports:
- Innerhalb der einen Seite des Clusters (GPUs 1-4 und 9-12) hat man 12 Links und somit 600 GByte/s bidirektional --> 2 Hops
- Auf die andere Seite hat man 6*12=72 Lanes, somit pro GPU im Schnitt 72/8*50GB/s = 450 GByte/s --> 3 Hops

18 Ports:
- Innerhalb der einen Seite des Clusters (GPUs 1-4 und 9-12) hat man 6-12 Links und somit 300-600 GByte/s bidirektional (1-2 Lanes pro GPU/NVSwitch) --> 2 Hops
- Auf die andere Seite hat man 6*2=12 oder 6*8 = 48 Lanes, somit pro GPU im Schnitt 75 oder 300 GByte/s --> 3 Hops
- 16 Ports des NVSwitches werden hier für GPUs verwendet. Insgesamt 96 Ports = 4.8 TByte/s bidirektional
- 6*2 Ports = 12 Ports = 600 GByte/s wären noch für die CPU frei

Ich tippe darauf, dass es immer noch 18 Ports sind. Und hier kann man nun den Kompromiss machen:
- 300 GB/s zwischen allen GPUs --> 16 GPUs (4.8 TByte/s / 16 = 300GB/s)
- 600 GB/s zwischen allen GPUs --> 8 GPUs (4.8 TByte/s / 8 = 600GB/s)

Anscheinend ist die zweite Lösung aus einigen Gründen sinnvoller:
- Bandbreite
- Latenz
- Aufbau der GPU-Cluster (es passt in ein einzelnes 4U-Rack)

NVSwitch hat den Vorteil, dass man auf Seiten GPU weniger Ports für "NUMA" Speicherzugriff sowie gleichzeitig hoher Bandbreite benötigt. Nachteil ist der gestiegene Energiebedarf sowie die gestiegene Latenz. Mich würde es nicht überraschen, wenn AMD in Zukunft ebenfalls mit sowas ähnlichem kommen würde. Das noch garniert mit Infinity-Cache (auf der GPU und allenfalls auch auf dem IF-Link-Switch), um die Latenz zu verstecken.

Edit:
Ich weiß nicht, ob das erneut von AMDs Linux-Treibern kommt, aber 4x GCDs werden für MI300 aktuell formuliert.
Es scheint auch so, dass Intel in der Zukunft mit 4x Chips aufbäumen wird, gegenüber 2x beim aktuellen Ponte-Vecchio-Model.
4 GCDs geht auch. Ist komplexer aber geht auch. Würde dann auch zulassen, dass man die IF-Links irgendwo zentral unterbringt oder gar 3D-Stacked. Da wären total dann sogar weniger IF-Links für die selbe Bandbreite nötig. Geht man von IF-Link (100GByte/s) und PCIe 5.0 (128 GByte/s) aus, könnte IF-Linl-Gen2 allenfalls mit 150 GByte/s daherkommen. Bei 8x Links ergäbe das bereits 1.2 TByte/s (bidirektional) zu einem zentralen IF-Link-Switch. Hier an den Switch noch die CPU sowie die NICs anschliessen und man hat die gwünschte flachere Speicherhierarchie. Ob man da nun den Cluster noch grösser machen will: Könnte man auf verschiedene Varianten, je nach Grösse des IF-Link-Switches.

AffenJack

2021-12-13, 17:51:53

3DCenter braucht ein Forenupdate.
Ich würde mir bessere Bildupload-Funktionen wünschen, Zitatbenachrichtigungen und ein Like-Button, denn dein Beitrag davidzo war großartig, danke dafür. :)

Ich verstehe das eher wie basix und du in deinem ersten Post. Bei Nvlink hat jede GPU die volle Bandbreite:

https://abload.de/img/nvswitch2n3j0y.png
https://www.nvidia.com/de-de/data-center/nvlink/

Die aggregierte Bandbreite des Nvswitch ist nicht etwa 600Gb/s, wie von Davidzo beschrieben, sondern 9,6 TB/s.

Bei einem 16 GPU System sieht so ein Switch für mich deutlich angenehmer aus, als AMDs Lösung:
https://abload.de/img/cdna2lbjvi.png

Worst Case von GCD 6 zu GCD14 über 5 Hops ist eher unoptimal.

basix

2022-02-23, 13:22:00

Im Beyond3D Forum gibt es neue Gerüchte zu MI300
- 4 GCDs (z.B. 32 CUs pro GCD? Somit 1x Compute Engine + 1x HBM)
- SH5 Sockel
- HBM, vermutlich 4 Stück
- CPU CCDs
- Optional: Infinity Cache

Im Endeffekt wäre das eine Mega-APU. Ähnlich wie Sapphire Rapids mit HBM-Boost. Aufgrund der GCDs aber mit massiv mehr Vektor / Matrix Rechenleistung. Hier würde ich mich aber fragen, wie viel Watt man einem SH5-Sockel zumuten darf. Wird das eine 500W APU?

vinacis_vivids

2022-03-19, 10:27:56

https://www.amd.com/de/products/server-accelerators/instinct-mi250x
https://www.techpowerup.com/gpu-specs/radeon-instinct-mi250x.c3837

AMD Radeon Instinct MI250X

TSMC 6nm
58,2 Mrd. Tr.
220 Rechenkerne
14080 SP :eek:
int8: 383 TOPs
fp16: 383 Tflop/s (8:1)
fp32: 47,87 Tflop/s
fp32 Matrix: 95,7 Tflop/s
fp64: 47,87 Tflop/s (1:1)
fp64 Matrix: 95,7 Tflop/s

128GB HBM2e
8192bit SI
3277 GB/s Bandbreite
1600Mhz MEM-CLK

1700Mhz GPU-CLK
TDP 500W - 560W peak

Die Size: ???

https://abload.de/img/1002-defaultfnjjh.jpg
https://abload.de/img/3837-frontrwkds.jpg

Geiles Teil :eek::tongue::D

Das Ding ist ein MCM mit zwei größeren CDNA "Dies"

Damit bewegt sich AMD Richtung Weltspitze im Bereich HPC und KI.

Linmoum

2022-03-19, 10:31:40

Das ist alles schon seit November bekannt und damals bereits offiziell von AMD vorgestellt worden. :confused:

vinacis_vivids

2022-03-19, 10:53:09

Hier mal ein Vergleich zur Konkurrenz mit dem A100 :eek:
Quasi vaporisiert. AMD`s Rechenleistung ist einfach krank.

https://abload.de/img/mi250xleistungw9j5m.png

Hier der Graphics Compute Die:

https://abload.de/img/mi250xgcdgraphicscomp63k57.png

Hier die erweiterte Compute Units:

https://abload.de/img/cdna2executionunitsnlk6g.png

Die Infinity Fabric der 3. Generation erlaubt eine direkte CPU-GPU Speichenzugriff und Kohärenz, was einzigartig ist.

Skysnake

2022-03-19, 15:30:54

Ne ist nicht einzigartig. Power8 mit NVLink plus ne Kepler kann das auch. Die Frage ist nur wie die Granularität ist. Bei IBM+NVIDIA ist es eine Page was halt ziemlich viel ist und es damit nicht sonderlich performant macht. Trotzdem ist es teils performanter als ohne Kohärenz. Vor allem ist es aber deutlich angenehmer zu programmieren. Insbesondere halt wenn man weiß, das es fast nie passiert.

Bei AMD muss man erst noch schauen was die Granularität ist. Also Pages oder Cachelines.

Bei Pages ist es nichts neues und bei Cachelines muss mann erst schauen wie die Performance im realen Betrieb ist.

vinacis_vivids

2022-03-19, 17:47:33

Ich empfehle dir dich mal zu informieren und die white-papers zu lesen
https://www.amd.com/system/files/documents/amd-cdna2-white-paper.pdf
https://www.amd.com/de/graphics/server-accelerators-benchmarks

Skysnake

2022-03-19, 18:57:43

Selbst gelesen? Ich habe das Gefühl nein, aber du kannst mir den Passus bezüglich der Granularität bestimmt zitieren. Ich habe es nicht gefunden...

Oder meinst du den Bullshit von wegen Novel? Das ist doch der klassische Herstellerbullshit. Bei x86 ist es neu, das war es dann aber auch, sofern sie eben nicht die Granularität von Cachelines haben für die Kohärenz. Darüber lassen sie sich aber eben nicht aus...

Skysnake

2022-03-22, 10:00:36

Kommt da noch was? oder war das einfach einmal in die Runde gekackt?

mksn7

2022-03-22, 12:14:31

Hat sich jemand mal die ISA Dokumentation von Februar angeschaut?

https://developer.amd.com/wp-content/resources/CDNA2_Shader_ISA_4February2022.pdf

Hat sich da was geändert im Vergleich zu dem was sie im November veröffentlicht haben?

Interessant finde ich das "Feature Changes in MI200 Devices" Abschnitt:

• Supports DPP for 64-bit data types
• Float64 memory atomic operations: ACC, MIN, MAX
• Merged Architectural and Accumulation VGPRs into one unified pool of VGPRs
• Allow memory operations to return data directly to accumulation VGPRs
• Remove GDS operations (retain GWS operations)
• Merged compute shader thread indices into a single VGPR
• Remove support for "SRC2" DS instruction

Ich kenn mich nicht gut genug mit CDNA aus um die Signifikanz einschätzen zu können, aber interessant finde ich die "Merge Architectural and Accumulation VGPRs". Es hieß ja mal dass es jetzt mehr Register gibt, und das ist vermutlich der Grund dafür. Bei code der für MI100 kompiliert wird, wird bei Registerknappheit in diese Accumulation Register gespilled. Das ist jetzt wohl nicht mehr nötig, sondern die können direkt genutzt werden.

vinacis_vivids

2022-03-22, 12:31:00

S.14/15
"3.6.1. Out-of-Range behavior
This section defines the behavior when a source or destination GPR or memory address is
outside the legal range for a wavefront.
Out-of-range can occur through GPR-indexing or bad programming. It is illegal to index from
one register type into another (for example: SGPRs into trap registers or inline constants). It is
also illegal to index within inline constants."

Das ist schon geil. Hier wird schlechter/fehlerhafter Programmcode hardwaremäßig aussortiert.

@Skysnake

? Es kommt drauf an in welcher Präzision du die Ergebnisse haben willst.
Mit double precision fp64 ist einiges an Granularität möglich und bisher numerisch auch der höchste Standard was Hardware in vorhersagbarer Lebenszeit leisten kann.
128bit Gleitkommazahlen dauern noch einige Jahre.

Nvidia hat natürlich zuviel gemogelt mit den Tensorzeugs und im HPC versucht viele Unternehmer mit dem proprietären Zeug auszunehmen und zu ungenaue Ergebnisse geliefert.

AMD MI250 leitet schon eine neue Ära ein.

Sich mit dir zu unterhalten ist wie einer der seit 30 Jahren paar BASIC-Schleifen verstanden hat und nun bei Assembler-Feinarbeit mitdiskutieren will. :freak:

Nakai

2022-03-22, 12:39:47

mksn7

2022-03-22, 13:00:04

Den GDS gibt es wohl noch. Heißt aber jetzt (oder vorher auch schon?) GWS für Global Wave Sync. Aber nicht mehr in der Rolle als globales scratchpad verwendbar.

Nakai

2022-03-22, 13:21:06

Den GDS gibt es wohl noch. Heißt aber jetzt (oder vorher auch schon?) GWS für Global Wave Sync. Aber nicht mehr in der Rolle als globales scratchpad verwendbar.

Ja macht Sinn, dafür wurde er generell nie richtig verwendet.

mksn7

2022-03-22, 14:04:23

S.14/15
"3.6.1. Out-of-Range behavior
This section defines the behavior when a source or destination GPR or memory address is
outside the legal range for a wavefront.
Out-of-range can occur through GPR-indexing or bad programming. It is illegal to index from
one register type into another (for example: SGPRs into trap registers or inline constants). It is
also illegal to index within inline constants."

Das ist schon geil. Hier wird schlechter/fehlerhafter Programmcode hardwaremäßig aussortiert.

Das hat gar nichts mit fehlerhaftem Programmcode zu tun. Nur ein fehlerhafter compiler kann ungültige Registerzugriffe erzeugen.

Sich mit dir zu unterhalten ist wie einer der seit 30 Jahren paar BASIC-Schleifen verstanden hat und nun bei Assembler-Feinarbeit mitdiskutieren will. :freak:

Puh, halt mal die Füße still. Von dir hört man nie etwas außer dass du wilde Dinge in vage Marketingstatements reinfantastierst.

Skysnake

2022-03-22, 20:16:04

@Skysnake

? Es kommt drauf an in welcher Präzision du die Ergebnisse haben willst.
Mit double precision fp64 ist einiges an Granularität möglich und bisher numerisch auch der höchste Standard was Hardware in vorhersagbarer Lebenszeit leisten kann.
128bit Gleitkommazahlen dauern noch einige Jahre.

Thema???? Es ging um die Granularität der Cache Kohärenz nicht mehr und nicht weniger...

Und was ist das bitte für ein Quatsch mit FP64 <-> FP128??? Dir ist wohl nicht bekannt, das es seit Jahrzehnten HW gibt die FP128 nativ kann/konnte. Das würde nur in den meisten Chips gestrichen weil es fast niemand benutzt und es eben auch LIBs gibt die dir FP128 auf FP64 HW ermöglichen. Ist zwar deutlich langsamer als nativ, aber weil die commodity HW so extrem viel Leistungsfähiger geworden ist hat es sich einfach nicht mehr gelohnt FP128 weiter nativ k die Chips zu machen
Wobei Power9 das eventuell sogar noch kann genau wie fixedPoint Arithmetik.

Du hast da komplett falsche Vorstellungen....

Nvidia hat natürlich zuviel gemogelt mit den Tensorzeugs und im HPC versucht viele Unternehmer mit dem proprietären Zeug auszunehmen und zu ungenaue Ergebnisse geliefert.

AMD MI250 leitet schon eine neue Ära ein.

NVIDIA hat nicht "gemogelt" sie haben nur einen fetten Haufen auf die Besürfnisse der Leute gesetzt die FP64 oder auch FP32 Leistung wollen. Das war die Devise Friss oder stirb. Die hatten und haben ganz klar AI/ML im Fokus und der Rest muss schauen was er mit der gebotenen HW macht. Die Leute werden einfach gezwungen das Zeug zu benutzen weil NVIDIA eben die Leute damit zuscheißt.

AMD hat das jetzt wieder etwas geändert, daher sind die auch in einigen der großen Kisten mit ihren GPUs. Aber NVIDIA macht jetzt auch wieder etwas mehr FP64, aber nur so viel wie sie müssen. Der Fokus liegt weiter auf AI/ML.

vinacis_vivids

2022-04-04, 21:42:43

Die Nachfrage nach hoher single precision fp32 und double-precision fp64 Leistung ist schon lange da gewesen, weil man mit dem AI-Zeug was Nvidia anbietet, einfach nichts anfangen kann.

Der NV-Marketing AI Zeug ist in diesen Fällen völlig unbrauchbar, weil zuviel Datenmüll erzeugt wird und die Berechnung zu teuer ist, zu lange braucht und die Ergebnisse auch zu ungenau sind. Wozu Geld weiter reinschleudern wenn nichts gescheites rauskommt?
Dazu hat Nvidia versucht fp32 Rechenoperationen für fp64 zu verkaufen.
Das zu Nvidia.

Es gibt eben eine Reihe von Anwendungen, die eine hohe Präzision an Rechenleistung braucht Genome Sequency ~ Sequenierung des Genoms (von Menschen, Tieren, Pflanzen)
Galaxy Simulation ~ Simulation der Milchstraße, der Galaxy bspw.
Laser (Licht) Simulation ~ Partikelsimulation mit hoher Energie und Geschwindigkeit.

All das verlangt nach nach schneller und präziser Rechenleistung, deren Ergebnisse danach auch brauchbar sind. Mit dem NV Marketing-Monopol hat sich das über Monate und Jahre verzögert, was nach technischer Machbarkeit jetzt mit CDNA-Hardware bereits in wenigen Wochen möglich ist.

Außerdem ist AMD weitgehend open-source und auch preislich für viele machbar während sich Nvidia preislich nach oben hin abgeschottet hat und nach wie vor geschlossen in einer black-box arbeitet.

Mit CDNA2 wurde jetzt auch eine erweiterte Matrizen-Multiplikation mit fp64 = doppelter Genauigkeit in der Hardware eingebaut. Erst dieser Aufwand in der Hardware erlaubt überhaupt beispielsweise eine Drehmatrix im Universum halbwegs genau darzustellen zu können.

"AMD CDNATM 2 Matrix Core Technology The AMD CDNA™ 2 architecture Matrix Core technology has also been enhanced, with an emphasis on high-performance computing. The AMD CDNA 2 Matrix Core technology now supports double-precision data, which is critical for many scientific computing applications. Matrix-matrix multiplication is one of the important primitives that can be leveraged in HPC kernels. Its accelerated implementation can speed up execution of HPC applications, including the important High Performance Linpack (HPL). Performing matrix multiplication using general FMA64 instructions is less efficient, spending substantial energy on register file accesses for each operand. Ultimately, this energy use limits the maximum performance that is possible within a given TDP. AMD CNDA 2 introduces a set of matrix multiplication instructions specifically for FP64 precision with a simplified microarchitecture. New instructions realize block-based matrix multiplication for the fixed matrix blocks sizes of 16x16x4 and 4x4x4 (MxNxK) and are wave-wide operations where input and output matrix block data are distributed over a wavefront’s lanes. The whole input is read from registers once and reused several times during calculation for a substantial reduction in power. The FP64 matrix multiply instructions can deliver two times the throughput compared to using FP64 vector instructions, while also helping improve power efficiency. The net result is a corresponding 4X improvement in FP64 TFLOP/s compared to the MI100. These instructions can be used in AMD-provided libraries to accelerate linear algebra calculations and are expected to demonstrate maximal FP64 throughput for MI200. As Table 1 above illustrates, this quadruples the computational throughput for FP64 compared to the previous generation. Additionally, the AMD CDNA 2 Matrix Core technology has improved the bfloat16 performance so that it delivers equivalent throughput to FP16. "

Mit den 16x16x4 Matrix und 4x4x4 Matrix deckt CDNA 2 mit fp64 schon eine gute Menge an Möglichkeiten ab.

https://developer.amd.com/wp-content/resources/CDNA2_Shader_ISA_4February2022.pdf
S. 3 Im ISA für Instinct MI200:
Added Matrix Arithmetic Instructions
V_MFMA_F64_{16x16x4f64, 4x4x4f64 }

Das sind echte fp64 Matrizenmultiplikation , während sowas Tensor Cores von Nvidia lange Zeit kein echtes fp64 können. Gut das hat sich jetzt mit Hopper uArch geändert.

Vor allem die die fp64 Matrizenmultiplikation bei CDNA2 schon geil: 256 Flops/Clock/CU -> 256 x 1,7Ghz x 220 = 95,7 Tflop/s

Das das mit der relativ preiswerten 6nm Fertigung von zwei zusammengeschlateten günstigen GCDs :-)

https://abload.de/img/mi250xgcd2xyhjqk.png

Mit dieser GCD-Technik kann AMD jederzeit die Konkurrenz kontern, indem AMD auch mal 4xGCD "zusammenschweißt". Das ist ein absoluter Quantensprung in der GPU Technologie.

mksn7

2022-04-05, 09:39:35

Schön dass du so begeistert bist. Die hohe FP64 Leistung von den MI200's ist tatsächlich beeindruckend.

Ich versteh manchmal nur nicht ganz warum du immer gleich alles in so bombastischen, übertriebenen Statements formulierst. Arbeitest du im Marketing von AMD?

Glaub einfach immer nur die Hälfte von dem was in den Marketingfolien steht! Das gilt für alle Firmen.

vinacis_vivids

2022-04-06, 00:28:05

Du weißt schon wie die Preise sich bewegen?

Nvidia Tesla V100 32GB - 8.000€
7,0 Tflop/s fp64
900 GB/s Bandbreite

AMD`s Radeon Instinct MI100 32GB - 5.000€
11,5 Tflop/s fp64
1229 GB/s Bandbreite

Das schlechte an dieser Wirtschaft ist auch noch, dass nahezu überall sich der falsche Ruf sich durchgesetzt hat, dass Nvidia besser sei. Das ist in der high-tech Branche leider sehr weit verbreitet, dass schlechtere Produkte Aufgrund von Marketing durchsetzen statt durch echte Technik.

Hast du noch einen dummen Entscheider an obere Stelle rumsitzen, der über das Budged entscheidet und ständig Nvidia kauft, ist deine Firma prinzipiell am Arsch. Die Projekte werden teuer und qualitativ womöglich schlechter und langsamer wegen solchen Entscheidungen.

amdfanuwe

2022-04-06, 02:27:13

Das ist in der high-tech Branche leider sehr weit verbreitet, dass schlechtere Produkte Aufgrund von Marketing durchsetzen statt durch echte Technik.

Da spielt die Technik keine Rolle. Probleme löst man mit dem, was man kennt, mit der Software, die man beherrscht. Da spielen ein paar Tausend €uro keine Rolle zu dem was die Ingenieure an Zeit kosten das unbekannte System ans laufen zu bekommen.
Deshalb ja auch AMDs Bemühungen auch CUDA Code zu verarbeiten.

Geilste Technik ist nun mal nicht immer die optimale Lösung für eine Firma.

mksn7

2022-04-06, 11:21:08

Genau. Wenn ich als Rechenzentrum hardware kaufen möchte, die meinen Nutzern tatsächlich was bringt, dann muss ich NVIDIA GPUs kaufen.

Die Rohleistungen sind ja schön und gut, aber aus zwei Gründen übertragen die sich oft nicht in wissenschaftliche Produktivität:

1. Architektur. Und da muss man leider sagen dass NVIDIA's Architekturen überlegen sind. Da muss man nur den rießigen, schnellen und schnellen (2x mal schnell, weil geringe Latenz und viel Bandbreite) L1 cache nennen. Da kommt bei NVIDIA einfach viel leichter was von der Rohleistung rum.

2. Software. Die ganze software ist halt CUDA kompatibel. Das liegt einfach daran, dass NVIDIA mit CUDA die letzten 10 Jahre eine absolut stabile GPU computing Platform geboten hat. Wenn man sich dagegen anschaut wieviele verschiedene, halbgare Dinge AMD in den letzten 10 Jahren gedreht hat? Zeitweise war die einzige vernünftig benutzbare OpenCL platform von ... NVIDIA.

Das gleiche Argument (was bringt meinen Nutzern am Meisten) hätte man vor fünf Jahren gemacht um zu begründen dass ein CPU System gekauft wird, und keine GPUs.

Die Leute hätten schon gerne einen Konkurrenten zu NVIDIA. Bei AMD tut sich auch soviel wie noch nie aktuell, aber unsere admins fluchen trotzdem wenn ich was wegen ROCM von ihnen will... Mein Professor hat neulich mal gesagt dass er echt Lust hätte einen Port eines großen Softwarepakets, das viele unser Nutzer verweden, zu finanzieren, einfach weil er den NVIDIA sales Menschen so arrogant fand.

Edit: wegen euch hab ich jetzt den Vormittag damit verbracht meine Speicherdatentransferratenbenchmark wieder auf HIP zu portieren. MI100: 1042 GB/s, V100: 810 GB/s, A100: 1378 GB/s.

Dino-Fossil

2022-04-06, 12:00:09

Ja, bei uns steht bald die größere Anschaffung von Softwarelizenzen und einer Workstation an. Die Lizenzen kosten bedeutend mehr als die Workstation, egal ob wir da nVidia oder AMD verbauen.

Persönlich würde ich gerne AMD nehmen, aber die Software arbeitet nunmal mit CUDA. CUDA ist dermaßen verbreitet bei professionellen Lösungen im wissenschafltichen Bereich (jedenfalls in meiner Sparte), dass man um nVidia praktisch nicht herumkommt. Eine der Softwarelösungen kann auch OpenCL nutzen, gibt aber klar an, dass CUDA trotzdem schneller ist.

Ist schade, aber nunmal Fakt. Software sells Hardware.
AMD müsste wohl massiv in einen CUDA-ähnlichen Ansatz investieren, um hier an nVidia heran zu kommen.
Das mag in anderen Sparten natürlich anders aussehen.

dildo4u

2022-04-28, 10:22:00

Infos zum Aufbau von MI300.

https://videocardz.com/newz/amd-instinct-mi300-gpus-rumored-to-feature-3d-die-stacking-up-to-eight-compute-dies-support-for-hbm3-and-pcie-gen5

Pirx

2022-04-28, 11:54:08

HOT

2022-04-28, 14:30:54

Ach guck mal an, komplexe N6-Chiplets als Basis mit Speichercontrollern und Cache. Darauf gestapelt N5-GCDs. MMn könnte RDNA3 ähnlich aussehen, nur eben mit Commandprozessor und größeren GCDs.

basix

2022-04-29, 14:13:59

Infos zum Aufbau von MI300.

https://videocardz.com/newz/amd-instinct-mi300-gpus-rumored-to-feature-3d-die-stacking-up-to-eight-compute-dies-support-for-hbm3-and-pcie-gen5

MLID beschreibt noch, dass die Compute-Chiplets gegen was anderes austauschbar sind. Mir kommen spontan FPGAs in den Sinn. Gab doch von Lisa Su die Aussage, dass man recht früh bereits ein erstes Ergebnis des AMD + Xilinx Mergers sehen wird?!

So ein kleines schönes 110mm2 FPGA Chiplet und man kann sich Custom Accelerators zusammenbasteln: Der Mix CDNA3 / FPGA Chiplets kann vom Kunden auf seine Anwendungsfälle zugeschnitten werden. 4x CDNA + 4x FPGA gerne? Oder sollens doch lieber 6x CDNA und 2x FPGA werden? ;)

Ach guck mal an, komplexe N6-Chiplets als Basis mit Speichercontrollern und Cache. Darauf gestapelt N5-GCDs. MMn könnte RDNA3 ähnlich aussehen, nur eben mit Commandprozessor und größeren GCDs.
Prinzipiell ja. Die Frage ist, ob es die Kosten zulassen. Interposer ist halt teurer als andere Lösungen.

Edit:
Ein zweiter Gedanke ist, dass man die Base Chiplets (+Interposer) ohne Compute Die auch als Infinity Fabric Switch verwenden könnte? Den NVLink Switch von Nvidia sehe ich als grossen Vorteil an, wenn man grössere Systeme bauen will, welche gut skalieren sollen,

Heute hat eine MI250X total 600GB/s IF-Fabric Bandbreite bei total 1600 GB/s IF-Fabric Tranceivern auf beiden Die (total 16 Ports).
+ MI300 Base Die: Total 2-4x IF-Fabric Tranceiver. 4x Base Die ergeben dann 8-16x IF-Fabric Ports.
+ Zusatzchiplet, welches via HBM-PHY angebunden wird. Auf diesem Zusatzchiplet sind dann die Infinity Fabric PHY des Switches untergebracht. Beispiel: 8*6.4GT/s HBM Interface = 6.55 TByte/s, welche durch den Switch passen würden. 4x 16 IF-Ports (4x MI300) = 6.4 TByte/s
+ Die Base Die haben dann immer noch 8-16x IF-Fabric Ports frei, welche nativ in den Base Die untergebracht sind --> Verbindung zu CPU & Networking Interfaces via Infinity Fabric und/oder PCIe
+ 64 IF-Fabric Ports würden für das anschliessen von 4x MI300 mit der vollen Bandbreite reichen --> Siehe HPC-Konfigurationen mit 4x MI250
+ 64 IF-Fabric Ports lassen natürlich auch 8x/16x/32x/64x MI300 zu, dann halt mit jeweils weniger Ports pro MI300 (oder man verwendet 2x IF-Fabric Switches in parallel für 8x MI300 mit voller Bandbreite oder um nochmals doppelt so viele MI300 zu verbinden)
+ Selbe Interposer + Base Die für die IF-Fabric Switches verwendbar. Einfach ohne das drauf-stacken der Compute Die --> Economy of Scale, Design Re-Use
+ Infinity Fabric Switch hätte zusätzlich noch viel Cache onboard. Damit liesse sich sicher was sinnvolles anstellen. Shared Data Pool & Caching für was auch immer.
+ Wenn man extrem auf die Kacke hauen will: Man stacked noch ein paar FPGA/Networking-Chiplets auf die Base Die des IF-Fabric Switches. Die "DPU" und anderes Networking Zeugs ist gleich integriert
+ Man kann neben 64x Port IF-Fabric Switches auch kleinere Konfigurationen mit 16x oder 32x Ports bauen.
- Viel Silizium, aber geil :D

Edit 2:
In etwa so stelle ich mir das vor. Ob Si-Interposer oder EFB spielt vom Grundkonzept her nicht so eine Rolle. Ohne Interposer ist es aber vermutlich einfacher, verschiedene SKUs mit 1, 2, 4 Base Die zu kreieren. Dafür sind Datentransfers zwischen den diagonal angeordneten Die etwas suboptimal.

basix

2022-05-30, 10:02:37

AMD knackt die 1.0 ExaFLOPS:
https://www.computerbase.de/2022-05/frontier-supercomputer-hpe-amd-system-ist-das-erste-westliche-exascale-system/

- 3x Top 10 Plätze in der Top500 Liste
- 1. bis 4. Platz in der Green500 Liste

Edit:
Top500 / Green500
https://www.top500.org/news/ornls-frontier-first-to-break-the-exaflop-ceiling/
https://www.top500.org/lists/top500/2022/06/
https://www.top500.org/lists/green500/2022/06/

Edit 2:
Frontier auch mit #1 im HPL-AI Benchmark, 6.88 ExaFLOPs. Das ist relativ zu Fugaku (ARM) und Nvidia A100 gesehen etwa in der Mitte (FP64 Rmax vs. HPL-AI). AI-Performance scheint also auch recht gut zu sein (Energieffizienz ca. 1.35x höher als Nivdia Selene mit A100)
https://www.hardwareluxx.de/index.php/news/allgemein/wirtschaft/58800-nun-aber-die-exascale-huerde-wurde-von-frontier-geknackt.html
https://www.hpl-ai.org/doc/results

Wo Frontier etwas zurückfällt ist HPCG. Dort erreicht man nur ca. 50% der Effizienz (HPCG vs. Rmax) verglichen zu Fugaku und den Nvidia Beschleunigern. HPCG wird afaik als realistisch eingeschätzt, was die reale Anwendungsperformance sein wird. HPL ist da relativ synthetisch.
Die ~50% kann man anhand LUMI aufskalieren, welcher auch auf MI250X setzt. Was man aber unterstreichen muss: Perf/W in HPCG sind gleich gut oder sogar etwas besser wie bei Nvidias Selene mit A100!
Auch wenn man also in realen Anwendungen noch nicht die Recheneffizienz von der Konkurrenz erreicht, bei der Energieffizienz hat man zu A100 aufgeschlossen. mMn ein starkes Stück.
https://top500.org/lists/hpcg/2022/06/

Alles in allem:
Beeindruckende Leistung von AMD, in allen Belangen. Nvidia wird mit H100 das Spiel wieder drehen und vermutlich in allen Performance- und Effizienz-Kategorien wieder die Führung übernehmen. Das allerdings mit TSMC 4N vs. N6.