Colindo schrieb:
1.) IIRC war es in den 90s und um die Jahrtausendwende noch ein wenig wie der wilde Westen.
Zwar gab es einen FP32-Standard von der IEEE, bevor aber jede HW konform war hat es gedauert.
Es gab auch viele Eigenwege was FP16 und FP24 anging.
Soweit ich weiß hat aber spätere FP16-HW (was noch nicht IEEE konform war), alle definierten Regeln von FP32 befolgt, aber eben nur 5 Bits für den Exponenten und 10 Bits für die Mantisse verwendet.
Irgendwann wurde es als Standard von der IEEE aufgenommen.
Dank Nvidias gewaltiger Marktmacht können die auch schon fast Quasi-Standards setzen, solange sich nicht die Konkurrenz und andere Akteure dagegen stellen.
Da Intel auch schon TF32 umsetzt, für Ponte Vecchio, kann man schon davon ausgehen, dass der Zug schon fährt und wenn man konkurrieren möchte, spielt man da lieber mit.
2.) Du hast das später im Edit erwähnt mit dem Video, laut Treiber sind es 16KiB für den L1D$ und 32 Bank-Groups werden für den Local Data Share genannt, wie bei allen anderen chips davor auch, also höchstwahrscheinlich 64KB.
AMD hätte sicherlich ein Upgrade hier erwähnt, hätten Sie eins vollzogen.
Größere Caches wären allgemein schon wichtig, selbst bei Spielen wäre es scheinbar sehr willkommen.
Bei RDNA3 würde ich auch stark davon ausgehen, dass AMD das ändert.
3.) Die offenen Treiber verraten schon sehr viele technische Details.
Über die Jahre konnte man Arcturus (CDNA1) und Aldebaran (CDNA2) schon relativ gut nachzeichnen.
Auch bei RDNA1 gab es viele juicy details vorab, wenn man das technische Verständnis besitzt und sich Zeit nimmt das durchzulesen.
Ich bin bei weitem kein Experte, entsprechend verstehe ich nicht alle Details und einige Sachen waren falsch interpretiert, dennoch selbst als Semi-Laie kann man schon weit kommen.
Wenn AMD die Compiler und Treiber-Patches für CDNA3 einreicht, geht das gleiche Spiel von vorne los.
Zu Beginn werden häufig nur vereinzelte Dinge beschrieben, was mit der Zeit aber immer mehr wird.
Wenn man Glück hat werden sogar relativ früh Konfigurationsdetails geteilt, bei Arcturus war früh klar das es 8 Shader Engines und 16 CUs gibt = 128 CUs.
Bei Aldebaran gab es eine Treiberstelle, die 16 CUs ausgewiesen hat, aber das hat sich nicht als richtig herausgestellt.
Ziemlich spät kam die Treiberinfo, dass eine SKU 110 CUs aufweist.
Volker schrieb:
Schicke Analyse hier.
Ich hab auch die Kommentare auf Twitter verfolgt, der Chef des aktuell weltweit stärksten Supercomputers nennt die hohen FLOPs von MI200 deshalb ja "merly a stunt" und gerade FP64 sei für HPC weitgehend unwichtig, denn das Teil könnte hier und da echt verhungern wenn es echte Analysen machen soll.
Na warten wir mal ab, der erste Exascale-Rechner in den USA ist ja zweifelsfrei viel PR-Stunt, mal sehen was die Kiste dann wirklich leistet.
Man kann wohl stark davon ausgehen, dass ohne optimierte Routinen die Leistungsabfälle sehr deutlich sein werden in mehreren Applikationen.
Aber soweit ich es vernommen habe, würde man nicht mit einem Exascale-System werben, wenn zumindest im LINPACK nicht konstant über 1 Exaflop mit FP64 erreicht wird.
Eine völlige Luftpumpe wird es dann gewiss auch nicht sein.
Ich denke aber allgemein wird es noch dauern, bis AMD für den breiten Markt attraktiv sein wird.
Frontier ist einer der ersten und wichtigen Schritte in der Richtung.
AMDs Softwarestack muss noch deutlich reifen und die HW kann noch einige Upgrades vertragen.
Das Unternehmen hat die letzten Jahre aber gute Schritte nach vorne gemacht, nach Hawaii im Jahr 2014 hatte man Jahrelang nichts, bis Vega20/MI50 nur minimale Erfolge verbuchen konnte und MI100 auch nur sehr selten anzutreffen war.
Jetzt hat baut man das erste westliche Exascale-System auf und hat auch einen weiteren Deal mit El Capitan gewonnen.
![[wege]mini](https://pics.computerbase.de/forum/avatars/m/778/778975.jpg?1575883542){kind=avatar}
