News AMD Instinct MI455X vorgestellt: Mit 320 Mrd. Transistoren, CDNA5 & HBM4 gegen Nvidia Rubin

DevPandi schrieb:
Zu den Gerüchten äußere ich mich mal später zu RDNA.
Ich hoffe dass AMD endlich was zur Architektur von GFX13x in AMDGPUUsage.rst hinterlegt. Das wird ein deutlicher Fingerzeig geben wie AMD tatsächlich weitermacht.

Wirklich spannend wird sein wie das AMD Marketing mit den WGP und CUs weitermacht.

So wie ich es verstehe haben die Compiler bei GFX125x gar keinen Zugriff mehr auf das was bisher CU hieß. GFX120X hat keinen CU wavefront execution mode mehr. AMD nennt das was vorher die CU war in GFX125x auch nicht mehr CU sondern nur noch SIMD32pair.



Bei den Gerüchten gibt es sehr viele Behauptungen und keine Belege. Auch bei Venice waren einige Dinge die als Gewissheit verbreitet wurde falsch. Und ohne die "Dokumente" zu kennen auf denen die Leaks basieren, kann man nicht einschätzen wie fundiert das ganze ist.
 
  • Gefällt mir
Reaktionen: SweetOhm
Ein MI455A (inkl. CPU-Kernen wie beim MI300A) wär schick, und ein paar GB mehr noch, dann läuft direkt GLM drauf...
 
  • Gefällt mir
Reaktionen: K0r4nd
k0ntr schrieb:
für gamer kommt dann cloud gaming, da amd und nvidia die beste hardware inhouse hat :)
Klar um dann am schluss opfer der Enshittification zu werden. Wir wissen doch wie es läuft: Erst abhängig machen, dann Melken.
Streaming war mal der Heilige Gral gegen Piraterie und schau was sie innerhalb von 15 Jahren daraus gemacht haben. Dutzende Dienste, Serie beginnt bei Plattform X, und geht bei Plattform Y weiter (hallo The Expanse), alles teilt sich auf, wird Fragmentierter, bekommt wieder werbung, permanente Erhöhungen...

Naja es ist ein Freier markt, sollen sie frei pleite gehen. Aber jeder der dabei mit macht sollte sich darauf einstellen dass es am schluss teurer wird oder generischer, in dem man mit jedem Produkt ein breiteres Publikum ansprechen will bis man keinen mehr anspricht.
Wer versucht Kunst und Kultur unter Marktwirtschaftlichen Gesichtspunkten zu Skalieren wie ein Gegenstand zerstört sie im regelfall.
Ich hab das damals fast nicht ertragen als man PC-Spiele auf die Konsole gebracht hat, alles war kleiner, eingeschränkter und unfreier. Egal ob Halo 1 (Ursprünglich PC spiel, das hat man auch gemerkt), Crysis, Unreal turnament, Battlefield, Crysis, Supreme Commander, alles wurde erstmal schlechter bzw hat sein Potential nicht ausschöpfen können weil alles in den winzigen Ram der PS3/Xbox360 passen musste. Das hat einige games gekillt weil man eine zielgruppe angesprochen hat die gar nicht angesprochen werden wollte, die ressourcen sind draufgegangen, man hat falsche kompromisse gemacht und an der Kernzielgruppe vorbei entwickelt.

Kein Streaming und kein Gamepass und am besten keine gelockten Stores wie auf der Playstation/Xbox oder bei Ninendo. Wenn das weiter Schule macht stehen wir hier in 20 Jahren und fragen uns warum alles nur schlechter und teurer wird so wie jetzt gegenüber von vor 25 jahren.

Gebt das Geld denjenigen die uns Gamer Respektieren und tatsächlich für uns arbeiten und nicht für Investoren.
 
  • Gefällt mir
Reaktionen: SweetOhm und Flutefox
ETI1120 schrieb:
Ich habe Dir nicht widersprochen
Ich weiß, du warst nicht gemeint. Es gab aber immer wieder - und ich will Namen nicht nennen - die steif und fest behauptet haben, dass ja GCN wieder kommt. Und bei PCGH trifft das nicht nur User, sondern etwas bekanntere Gesichter. Auch quasi bis quasi heute nacht. Nun ist mit GFX12.5 quasi die Bestätigung da, was UDNA sein wird => RDNA.

Und aus UDNA leiten sie ab jetzt CDNA und RDNA ab. Wichtige Eigenschaften, die in beiden Bereichen wichtig sind, werden ab jetzt als UDNA entwickelt und mit Ableitungen - zum Beispiel in dem man Datentypen beschneidet und Co - kann man dann RDNA und CDNA dann daraus destilieren.
ETI1120 schrieb:
Der Witz ist, je mehr ich von der ganzen Geschichte verstanden habe, desto offensichtlicher wurde, dass Deine Argumente richtig waren
Ich hab mir halt auch mal die Änderungen am LLVM als auch Mesa3D angesehen, dann auch das, was da mit dem VOPD und Co kamen. @MichaG hat mir sogar mal absichtlich eine Nachricht geschickt, ich bin dann rein in das LLVM-Repository, hab mir da die Punkte angesehen und festgestellt: Eigentlich hat das keinen Wert darüber zu berichten, weil es einfach primär für die Entwickler von Mesa3D und eben ROCm wichtig ist, daraus jedoch eine Prognose zur Leistung aufzubauen - wie die Leaker als auch andere Seiten machten - dafür war es viel zu dünn! Änderungen an dem Dual-Vector-Operations sind spannend, wenn man sich mal mit Treiberbau befassen will, darüber hinaus ist es allerdings schwere Kost, bei der man bei Leistungsanalysen für Games und KI nur verlieren kann.
ETI1120 schrieb:
Das ist das Problem mit der Gerüchteküche, viele Leute verbreiten mit Inbrunst Dinge, die sie im Grunde nicht verstehen.
Das ist mit das größte Problem dabei, viele Leaker bekommen am Ende des Tages irgendwelche eckdaten zugeschanzt, können diese aber oft nur bedingt richtig einordnen. Aber gerade bei AMD ist es relativ die Gerüchte auch zu prüfen und mit gewissen wirklich vorhanden "Leaks" sogar zu verbinden:

https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/amd?ref_type=heads
https://github.com/ROCm/llvm-project/tree/amd-staging/llvm/test/MC/AMDGPU

Und man kann hieraus sogar schon ableiten, dass gfx13 als nöchste Version ebenso ein deutlich größeres Registerfile haben wird, als ohnehin schon.
ETI1120 schrieb:
IMO kommt ein Faktor hinzu. ROCm. AMD hat ROCm mit einer sehr dünnen Personaldecke hochgezogen und ROCm war sehr an die Hardware gebunden.
Klar, war das damals auch eine Personal frage. Zu mal RDNA ja weiterhin Wave64 verarbeiten konnte. ;)
ETI1120 schrieb:
Dasselbe gilt auch für die Zusammenarbeit von AMD mit Meta, AMD mit OpenAI
Japp, Triton zu nennen.
ETI1120 schrieb:
Auch bei der Architektur Entscheidungen getroffen die näher zu NVIDIA gehen.
Ja, wobei man hier sagen muss, dass AMD aktuell hier sogar eine echt geschickte Schiene fährt: Nvidia gibt vor, AMD zieht nach und verbessert dann an den Punkten, bei denen Nvidia auf "stur" stellt und quasi den Entwicklern sagt: Ne, wir machen das so, lebt damit. Entsprechend geht AMD bei den Kooperationen mit quasi jeder Firma als "Juniorpartner" rein und sagt: Sagt uns, was ihr von uns in der Hardware wollt, welche Kanten sollen wir schleifen.

Und ja, Nvidia reagiert aktuell darauf, aber alleine das OpenAI und quasi alle großen KI-Firmen angefangen haben eigene Frameworks zu schrieben, um sich von den Herstellern zu lösen und freier zu agieren. Allerdings ist auch das eine Sache, die ich bereits seit 3 - 4 Jahren in dem Beriech beobachte und auch geschrieben hatte.
ETI1120 schrieb:
Alle aktuellen Grafikkarten laufen unter ROCm. Alle aktuelle APUs laufen unter ROCm.
AMD hat ROCm massiv aufgewertet und arbeitet hier an allen Ecken daran. ROCm ist quasi das "Herz" der g
ETI1120 schrieb:
AMD nennt das was vorher die CU war in GFX125x auch nicht mehr CU sondern nur noch SIMD32pair.
Was an der Stelle auch logisch ist. Viele Aufgaben, die vorher ja pro CU "separat" bei GCN erledigt wurden, sind bereits mit RDNA in die WGP verlagert worden, während gleichzeitig bestimmte Aspekte dafür in der CU "ausgebaut" wurden, weil der Platz dafür vorhanden war.

AMD hat ja bei RDNA die CU auf zwei Wave-Fronten reduziert, sie haben die Wave-Verwaltung der CU heraus gelöst und als WGP-Schicht drüber gesetzt. Die Wave-Verwaltung der CU war auf 4 Wave-Fronten ausgelegt, also musste man diese quasi nicht wirklich "anpassen" und konnte den Platz der zweiten Wave-Verwaltung für andere Sachen nutzen.

Es ist schon teilweise erstaunlich, wie genial AMDs GPU und CPU Architekten sind und was die für Kniffe finden.
 
  • Gefällt mir
Reaktionen: SweetOhm, peru3232, MichaG und 2 andere
DevPandi schrieb:
Und aus UDNA leiten sie ab jetzt CDNA und RDNA ab.
Alles andere ergibt auf Dauer auch keinen Sinn, die Überschneidungen bei den Anwendungen sind viel zu groß um in der Architektur grundsätzlich andere Wege zu rechtfertigen.
DevPandi schrieb:
Ich hab mir halt auch mal die Änderungen am LLVM als auch Mesa3D angesehen, dann auch das, was da mit dem VOPD und Co kamen. @MichaG hat mir sogar mal absichtlich eine Nachricht geschickt, ich bin dann rein in das LLVM-Repository, hab mir da die Punkte angesehen und festgestellt: Eigentlich hat das keinen Wert darüber zu berichten, weil es einfach primär für die Entwickler von Mesa3D und eben ROCm wichtig ist, daraus jedoch eine Prognose zur Leistung aufzubauen
Man hat doch gesehen, dass die erste Phase von DualIssue bei Games einen relativ überschaubaren Einfluss hatte. Ohne Simulator und Code den man durch den Simulator jagt kann niemand abschätzen was tatsächlich bei Games rauskommt.

DevPandi schrieb:
- wie die Leaker als auch andere Seiten machten - dafür war es viel zu dünn! Änderungen an dem Dual-Vector-Operations sind spannend, wenn man sich mal mit Treiberbau befassen will, darüber hinaus ist es allerdings schwere Kost, bei der man bei Leistungsanalysen für Games und KI nur verlieren kann.
Ganz ehrlich, nach dem was DualIssue bei RDNA3 für Games gebracht hat, wie kann man davon ausgehen kann, dass eine Verdoppelung der Performance drin ist. Diese ganze Artikel waren in meinen Augen die Demonstration der Inkompetenz.
DevPandi schrieb:
Das ist mit das größte Problem dabei, viele Leaker bekommen am Ende des Tages irgendwelche eckdaten zugeschanzt, können diese aber oft nur bedingt richtig einordnen.
Das habe ich gemeint.

Und für uns nicht eingeweihten bleibt nur zu raten wo die eigentlichen Leaks aufhören und wo die Schlussfolgerungen anfangen. Und die Schlussfolgerungen gehen, wenn die Information falsch eingeordnet werden massiv daneben. Siehe Van Gogh.

Süß finde ich unter anderem die Diskussion im Annadtech forum zu Zen 6. Da reitet einer aus der Silicon Gang auf den 15 % Steigerung von Fmax, die TSMC für N2X genant hat, herum. Und verwendet jetzt um seine 6,5 GHz Fantasien rechtzufertigen ständig Fmax, in Bezug auf die maximale Frequenz der CPU.

Bei der Angabe von Fmax durch TSMC hatte ich von Anfang an einen Verdacht, der neulich jemand bei Semiwiki bestätigt hat. Fmax bezieht sich auf die maximal Taktfrequenz der Transistoren. Aber die maximale Frequenz der Transistoren hat nicht so viel damit zu tun welche Frequenz man bei einer CPU erreichen kann.

DevPandi schrieb:
Aber gerade bei AMD ist es relativ die Gerüchte auch zu prüfen und mit gewissen wirklich vorhanden "Leaks" sogar zu verbinden:

https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/amd?ref_type=heads
https://github.com/ROCm/llvm-project/tree/amd-staging/llvm/test/MC/AMDGPU

Und man kann hieraus sogar schon ableiten, dass gfx13 als nöchste Version ebenso ein deutlich größeres Registerfile haben wird, als ohnehin schon.
Ich kenne mich im Code nicht aus und kann da nur begrenzt Schlüsse ziehen. Ich muss mich auf Textvergleiche und High Level Views beschränken. Auch fehlt mir das Verständnis für die GPU Architektur. Aber auch mit High Level View und Erkenntnisse die man aus Textvergleichen zieht, kann man erkennen ob jemand Ahnung hat oder nur herumlabert.

BTW. langsam bekomme ich das Gefühl dass die gfx1310 die MI500 ist. Wenn MI500 tatsächlich gfx1350 wäre, sollte gfx1350 so langsam Mal in LLVM aufgetauchen, ...
DevPandi schrieb:
Ja, wobei man hier sagen muss, dass AMD aktuell hier sogar eine echt geschickte Schiene fährt: Nvidia gibt vor, AMD zieht nach und verbessert dann an den Punkten, bei denen Nvidia auf "stur" stellt und quasi den Entwicklern sagt: Ne, wir machen das so, lebt damit. Entsprechend geht AMD bei den Kooperationen mit quasi jeder Firma als "Juniorpartner" rein und sagt: Sagt uns, was ihr von uns in der Hardware wollt, welche Kanten sollen wir schleifen.
Das hat zwei Seiten. Das Gute am von Nvidia abgehängt worden zu sein war, Nvidia folgen zu können.
Das Problem ist einerseits wer folgt kann nicht wiederholen und wenn man im Detail andere Entscheidungen trifft, folgt man nicht wirklich.
DevPandi schrieb:
Und ja, Nvidia reagiert aktuell darauf, aber alleine das OpenAI und quasi alle großen KI-Firmen angefangen haben eigene Frameworks zu schrieben, um sich von den Herstellern zu lösen und freier zu agieren. Allerdings ist auch das eine Sache, die ich bereits seit 3 - 4 Jahren in dem Beriech beobachte und auch geschrieben hatte.
NVIDIA hat keine andere Wahl als unangefochten der schnellste zu sein. Jeder in der Szene versucht sich von NVIDIA unabhängig zu machen. Und das geht eben nur wenn man das eigene Know How nicht an das Design von NVIDIA ankettet. Der erste Schritt dazu sind Frameworks die über CUDA agieren.
DevPandi schrieb:
AMD hat ROCm massiv aufgewertet und arbeitet hier an allen Ecken daran. ROCm ist quasi das "Herz" der g
Es war son sehr frustrierend wie langsam der Fortschritt außerhalb der Supercomputer war.

Aber das was Vamsi Boppana gestern gezeigt hat, passt wieder zu der Vision die Victor Peng auf dem FAD 2022 präsentiert hat.

Seit Anush Elangovan ROCm übernommen hat, geht es wieder voran. Es wurde an allen gleichzeitig Schrauben gedreht, Erweitern der Hardwareunterstützung, Buildsystem, SPIR-V ...
DevPandi schrieb:
Es ist schon teilweise erstaunlich, wie genial AMDs GPU und CPU Architekten sind und was die für Kniffe finden.
Das wirst Du immer finden wenn Du ein funktionierendes Stück Technik anschaust. das macht die Technik an sich so interessant, ...
 
  • Gefällt mir
Reaktionen: SweetOhm und Duffy Duck
ETI1120 schrieb:
Bei der Angabe von Fmax durch TSMC hatte ich von Anfang an einen Verdacht, der neulich jemand bei Semiwiki bestätigt hat. Fmax bezieht sich auf die maximal Taktfrequenz der Transistoren. Aber die maximale Frequenz der Transistoren hat nicht so viel damit zu tun welche Frequenz man bei einer CPU erreichen kann.
Ach, dieses Thema ... an der Stelle wird es doch erst richtig "Komplex". Wenn TSMC angibt, dass man den Takt um 15 % steigern kann, dann ist das immer auf den Referezen-Chip, der 1:1 geshrinkt wird bezogen. Dieser kann bei gleicher Leistungsaufnahme 15 % mehr leisten, oder bei gleicher Leistung, 30 % weniger Energie benötigen.

Am Ende gibt es hier aber viel mehr Faktoren, die die reale Leistungssteigerung am Ende bestimmen und viel mehr Stellschrauben, die hier entscheiden, was geht. Leckströme, Signalintegrität und so weiter.
 
  • Gefällt mir
Reaktionen: SweetOhm und Duffy Duck
DevPandi schrieb:
Ach, dieses Thema ... an der Stelle wird es doch erst richtig "Komplex".
Ne das ist noch Mal eine andere Fassette. So wie ich es verstehe geht es bei Fmax um die maximale Frequenz die die Transistoren erreichen können. Die liegt weit höher als der Takt der CPUs.
DevPandi schrieb:
Wenn TSMC angibt, dass man den Takt um 15 % steigern kann, dann ist das immer auf den Referezen-Chip, der 1:1 geshrinkt wird bezogen. Dieser kann bei gleicher Leistungsaufnahme 15 % mehr leisten, oder bei gleicher Leistung, 30 % weniger Energie benötigen.
Ja auf diese Werte beziehen sich auch sehr viele. Aber auch hier werden regelmäßig Kleinigkeiten übersehen:
  • Die Referenzchips sind Arm Cores
  • Bei hoher Spannung ist der Zugewinn an Frequenz kleiner als bei niedriger Spannung
  • Bei niedriger Spannung ist das Absenken der Power kleiner als bei hoher Spannung
  • Die Kurven von TSMC zeigen üblicherweise den Verlauf bis 0,9 V
DevPandi schrieb:
Am Ende gibt es hier aber viel mehr Faktoren, die die reale Leistungssteigerung am Ende bestimmen und viel mehr Stellschrauben, die hier entscheiden, was geht. Leckströme, Signalintegrität und so weiter.
Weshalb AMD wohl bei Zen 5 verzichtet hat die Frequenz zu pushen obwohl N4P laut den Zahlen von TSMC 11 % mehr Performance bot.

Hohe Frequenzen zu erreichen bedeutet sehr viel Fläche zu investieren und die Power zu erhöhen. Und dann stellt sich die Frage, wann diese hohen Frequenzen überhaupt erreicht werden können. Die Power die man investiert hat kommt einem dann auch noch bei Multi Core Anwendungen in die Quere.

Und wenn man mehr Cores auf einen Die packt und diese auch belastet ziehen die auch noch Power.
 
  • Gefällt mir
Reaktionen: SweetOhm
Wundert mich jetzt auch ein bischen.... Dachte da kommt jetzt wirklich sowas wie UDNA. Aber vermutlich wieder verworfen. Weil die Marktanteile von NV haben sie nicht, der Kuchen ist schon gebacken und verteilt.
Die Mode, wer , welche Lösung, das rennen macht, scheint sich ja auch alle paar Monate zu verändern. Mal gehört die zukunft TPUs... , dann wieder GPUs, dann spricht wieder keiner davon.... Viele sahen ja die auspaltung zwischen RDNA und CDNA als fehler an. Vielleicht ist er das strategisch einer gewesen, aber auch nicht mehr umkehrbar... weil halt der Kuchen ja schon verteilt ist.
Ähnlich wie bie ALID oder LIDL die jetzt kotzen, weil sie vor 10 Jahre den Schritt zum "Wohlfühl" supermarkt gegegangen sind.... aber dort nicht mehr herauskommen.

Jetzt also CDNA doch nicht tot... und auch kein UDNA... was auch immer das für Consumers, insbesondere LocalWeight bedeuten soll... ALso war das um UDNA einfach wieder so ne Fakenews, bzw misinterpretierte FLipchart die geleaked wurde? Oder kommt diese schritt ganz sicher, nur nicht ganz zu schnell?
 
lynx007 schrieb:
Wundert mich jetzt auch ein bischen.... Dachte da kommt jetzt wirklich sowas wie UDNA.
UDNA ist schon da. RDNa 4 ist gfx12 und CDNA 5 ist gfx125x. Die anderen CDNA sind gfx9, wie Vega.

Und ein Blick in LLVM zeigt, CDNA 5 ist viel näher an RDNA 4 als an CDNA 4.
lynx007 schrieb:
Viele sahen ja die auspaltung zwischen RDNA und CDNA als fehler an. Vielleicht ist er das strategisch einer gewesen, aber auch nicht mehr umkehrbar... weil halt der Kuchen ja schon verteilt ist.
Die Aufspaltung hat es AMD ermöglicht in HPC Fuss zu fassen ohne die "Gaming" GPUs zu vernachlässigen.
lynx007 schrieb:
Ähnlich wie bie ALID oder LIDL die jetzt kotzen, weil sie vor 10 Jahre den Schritt zum "Wohlfühl" supermarkt gegegangen sind.... aber dort nicht mehr herauskommen.

Jetzt also CDNA doch nicht tot...
CDNA ist ein Label. RDNA ist ein Label. Bei sind eingeführt. AMD hat beschlossen sie beizubehalten und darauf verzichtet statt dessen das Label UDNA einzufügen.

Denn man wird nach wie vor die witzlose Frage, ob man mit den Datacenter Karten Crysis spielen kann mit nein beantworten.

lynx007 schrieb:
und auch kein UDNA...
CDNA5 ist sehr viel mehr RDNA als CDNA. Und genau das soll UDNA sein die neue gemeinsame Architektur. Aber AMD wird trotzdem RDNA und CDNA als Labels beibehalten, weil nie angedacht war Raytracing Units in die Data Center GPUs einzubauen. D. h. RDNA und CDNA unterscheiden sich in einigen IP-Blöcken, verwenden aber dieselbe Grundlegende Shaderarchitektur.

Das wird spätestens dann offensichtlich, sobald auch die Gaming GPUs unter dem Label gfx13 auftauchen. Wie gesagt beim bisher einzigen Eintrag unter gfx13, der gfx1310, bin ich mir ziemlich sicher, dass das die MI500 ist.

lynx007 schrieb:
ALso war das um UDNA einfach wieder so ne Fakenews, bzw misinterpretierte FLipchart die geleaked wurde?
Jack Huynh selbst hat in einem Interview mit Toms Hardware den Namen UDNA ins Spiel gebracht als er erklärt hat, dass AMD RDNA und CDNA wieder zusammenführen wird. Er hat auch sehr ausführlich und deutlich erklärt warum das Zusammenführen notwendig ist.

Und wie @DevPandi viel besser als ich erklären kann, hat AMD nicht CDNA und RDNA weiterzusammengeführt, sondern hat RDNA als neue Basis gewählt.
lynx007 schrieb:
Oder kommt diese schritt ganz sicher, nur nicht ganz zu schnell?
Es ist wie gesagt schon da.

Und darüber hinaus wurde die Organisation der Caches massiv verändert.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: stefan92x und DevPandi
lynx007 schrieb:
ALso war das um UDNA einfach wieder so ne Fakenews, bzw misinterpretierte FLipchart die geleaked wurde?
Stand heute würde ich "UDNA" eher so verstehen, dass es eine "Unified Roadmap" für CDNA/RDNA gibt. Ob es sich wirklich so entwickeln wird, muss man mal abwarten, aber ich sehe hier so ein bisschen ein "Tick-Tock"-Modell auf uns zukommen:
RDNA4 ist die Basis
CDNA5 ist eine Modernisierung des RDNA4-Compute-Teils (Tick)
RDNA5 wird CDNA5 mit "drumherum modernisiert" (Tock)

So klare RDNA-Roadmaps habe ich jetzt nicht gesehen, um das zu belegen, aber es spricht für mich viel dafür, dass CDNA dann jeweils die führende Architektur ist, die als RDNA dann um Grafik-Features erweitert wird.
 
stefan92x schrieb:
Stand heute würde ich "UDNA" eher so verstehen, dass es eine "Unified Roadmap" für CDNA/RDNA gibt.
Roadmap beschreibt einen Aspekt IP den anderen.

Was Jack Huynh mit UDNA ausdrücken wollte war, dass CDNA und RDNA auf dieselbe Roadmap der Shader IP zugreifen.


stefan92x schrieb:
Ob es sich wirklich so entwickeln wird, muss man mal abwarten, aber ich sehe hier so ein bisschen ein "Tick-Tock"-Modell auf uns zukommen:
RDNA4 ist die Basis
CDNA5 ist eine Modernisierung des RDNA4-Compute-Teils (Tick)
RDNA5 wird CDNA5 mit "drumherum modernisiert" (Tock)
IMO ist dieses Bild falsch.

AMD wird die Shader IP kontinuierlich weiter entwickeln. Die einzelnen GPU Generationen sind Branches von dieser Hauptentwicklungslinie (Roadmap). Wenn man es so will sind die GPU Generationen die Release Branches.

Und die Shader Architektur ist nur einer von vielen IP Blöcke die jeweils in einer eigenen Roadmap weiter entwickelt werden.

AMD hat nun die alte Entwicklungslinie mit GFX9 stillgelegt und verwendet die Shader Architektur von RDNA als gemeinsame Basis für RDNA und CDNA.

CDNA 5 und RDNA5 verwenden die nächste Version der Roadmap.

stefan92x schrieb:
So klare RDNA-Roadmaps habe ich jetzt nicht gesehen, um das zu belegen, aber es spricht für mich viel dafür, dass CDNA dann jeweils die führende Architektur ist, die als RDNA dann um Grafik-Features erweitert wird.
Alleine schon das CDNA5 gfx125x ist sollte klarmachen dass RDNA die Basis ist. Auch in den Sourcen von LLVM ist klar zu erkennen dass CDNA 5 die Linie von RDNA weiterführt.

In Wahrheit ist CDNA5 noch radikaler als alle RDNA Varianten weil CDNA5 den Übergang von der CU zum WGP abschließt.
 
Gleichzeitig bringt CDNA5 eine radikale Überarbeitung der Cache Hierarchie die sich so wie ich es verstehe sich deutlich der Architektur von Nvidia annähert. Das deutlichste Zeichen ist das Verschwinden des Infinity Caches und das deutliche Vergrößern des L2 Caches.

Es wird interessant sein zu sehen wie groß der L2 Cache der einzelnen Implementierungen von RDNA5 wird. Bei CDNA5 hat AMD den L2 Cache auf andere Dies ausgelagert. Das ermöglicht es einerseits den L2 Cache deutlich zu vergrößern und machte andererseits Platz frei andere Caches zu vergrößern.
 
Der L3-Cache/Invinity Cache hatte den Vorteil, dass er die ganzen Chips auf so einem Package vereinigt hat. Der Chip aus einem FCD hätte auf den L3-Cache und damit die Ergebnisse aus dem anderen FCD zugreifen können. Der L2-Cache ist jetzt aber auf ein FCD beschränkt. Das Einzige was die beiden FCDs verbindet, ist damit nur noch der Fabric. Der Fabric muss also aus dem L2 des einen FCD die Egebnisse in das L2 des ersten FCDs laden, wenn das erste FCD mit den Ergebnissen des zweiten FCD weiter arbeiten soll.

1785148802766.png
 
Der Brummer gefällt schon.
Aber zuerst kommt ins Homelab die MI350P wenn AMD endlich mal damit rausrücken tut.
 
Sapphire Forum
Zurück
Oben