News AMD Aldebaran: Profi-Grafikkarten bekommen zwei GPU-Dies und 224 CUs

[Colindo]

Am Anfang werden es den Gerüchten nach und der Machbarkeit halber vermutlich nur 2 chiplets + I/O sein.

Ein Detail ist nicht ganz richtig: Der "Primary Die" enthält bereits die I/O-Sachen. Also mit dem "Secondary Die" nur ein weiterer, fertig ist die Laube.

 

[Matthias B. V.]

Ein Detail ist nicht ganz richtig: Der "Primary Die" enthält bereits die I/O-Sachen. Also mit dem "Secondary Die" nur ein weiterer, fertig ist die Laube.

Mein Fehler. Interessant wäre ob man den "Primary Die" auch ohne Secondary betreiben kann. Somit hätte man auch alle Karten in der Hand diesen nur als monolithisches Design auszuliefern falls was schief geht oder man es so in kleinere und / oder Mobile Karten packen will.

 

[predator7]

Quasi optimal für VR. Für jedes Auge eine gpu. Hoffentlich kommt es in den consumer Bereich bei allen gpu herstellern.

 

[Haffke]

Ich vermute Mal das beide Teile mit i.o sind und es aber nur bei einem aktiviert wird. Ansonsten müsste man ja zwei unterschiedliche DIE. was wiederum zu mehr kosten führen würde.

 

[CoffeeJunkie]

Nächste Nvidia Pro Generation heißt dann Todesstern

Ich warte dann auf AMD X-Wing.

 

[lnnz]

Quasi optimal für VR. Für jedes Auge eine gpu. Hoffentlich kommt es in den consumer Bereich bei allen gpu herstellern.

Es wird sicherlich bei allen GPU-Herstellern im high-end Desktop darauf hinauslaufen. Ist eher die Frage, ob high end VR eine ausreichend große Nische wird, damit sich für die Hersteller der Software- und Treibersupport für eine VR-spezifische Lösung lohnt. Selbst NVidia hat ja kaum mehr als einen halbherzigen Versuch gewagt, multi-GPU für VR vernünftig umzusetzen.

 

[fox40phil]

Wie stehts denn um Einsteiger bis Mittelklasse GPUs für Consumer bei AMD?!
Wir haben die 2. H von 2021... RDNA2 ist seit über einem halben Jahr auf dem Markt - wenn auch nur sporatisch... im Highend Bereich.

 

[C4rp3di3m]

Schön, aber lieber wäre mir eine bezahlbare consumer Grafikkarte mit HBM zum fairen Preis.

mfg

 

[Colindo]

Interessant wäre ob man den "Primary Die" auch ohne Secondary betreiben kann.

Ist sehr wahrscheinlich. Kniffliger ist eher der Punkt von @Haffke , ob es zwei gleiche Chips werden oder einer tatsächlich kleiner gefertigt wird.

 

[ZeroStrat]

Ein Detail ist nicht ganz richtig: Der "Primary Die" enthält bereits die I/O-Sachen. Also mit dem "Secondary Die" nur ein weiterer, fertig ist die Laube.

Hast du ne Quelle zufällig parat? Man munkelt ja, dass einen I/O-Chip geben soll.

 

[Colindo]

Hast du ne Quelle zufällig parat? Man munkelt ja, dass einen I/O-Chip geben soll.

Die beste Quelle von allen: Mich selbst.

So beschreibt der Hersteller, dass alle Chiplets Recheneinheiten à la CUs beinhalten werden, allerdings ein Chiplet als „Primary Chiplet“ die Kommunikation mit der CPU übernimmt. Dadurch wird der CPU weiterhin vorgegaukelt, mit einer monolithischen GPU zu arbeiten, wodurch die Notwendigkeit von Anpassungen an Anwendungen durch die Entwickler vermieden wird.

Ausschließen kann man natürlich nicht, dass es einen I/O-Die gibt, die bekannten Patente gehen aber in die andere Richtung.

 

[Haffke]

OK also darf man gespannt sein. Ich denke Mal das wir in eine ähnliche Richtung bei den Desktop GPUs sehen werden. Ich hätte nur halt erwartet daß das ganze quasi wie bei CPUs gemacht wird. Also I.O + chiplets und skalierbar dann soweit wie das PCB reicht.

 

[Teralios]

Wenn, dann wäre das für AMD und TSMC in relativ ferner Zukunft. An den Siliziumträgern arbeitet Intel schließlich schon seit vielen Jahren.

Nö, nicht ferne Zukunft. AMD hat vor kurzem ihr "Huckepack"-Cache für Zen3 vorgestellt, was man hier quasi auch verwenden könnte, nur dass man auf einen Cache-IO-Baustein dann die Chiplets mit de CU aufsetzt.

Mein Fehler. Interessant wäre ob man den "Primary Die" auch ohne Secondary betreiben kann. Somit hätte man auch alle Karten in der Hand diesen nur als monolithisches Design auszuliefern falls was schief geht oder man es so in kleinere und / oder Mobile Karten packen will.

Beim Patent, was @Colindo sehr gut analyisiert hat, sind alles gleichwertige Dies, nur das der Primary-Die die Kommunikation mit dem System übernimmt.

Wenn AMD Geld sparen will - Masken entwerfen ist "teuer" - dann werden alles vollwertige DIEs, die aber anhand der Kette entscheiden ob sie Prime/Controller und Secondary/Worker.

Hast du ne Quelle zufällig parat? Man munkelt ja, dass einen I/O-Chip geben soll.

Man munkelt da vieles, weil es einige Konzepte gibt, die man hier nutzen könnte. Da wir hier aber von den MIs sprechen, ist die Koordinierung zum "glück" etwas einfacher und es ist auch nicht so zeitkritisch, dass man die Daten auch langsamer verschicken kann. Hier kommts am Ende auf die gesamte Rechenleistung an.

Ausschließen kann man natürlich nicht, dass es einen I/O-Die gibt, die bekannten Patente gehen aber in die andere Richtung.

Also, ich sag es ganz ehrlich: Bei GPUs glaube ich nicht, dass es ein "reiner" I/O-Chip werden würde, wenn man es umsetzt, da ja die Arbeit zwischen den einzelnen Tiles/Chiplets koordiniert werden müsste. Mit dem Infinity-Cache und den 3D-Stacking könnte ich mir aber vorstellen, dass man einen entsprechenden Cachebaustein und IO als Controller umsetzt und sich die Chiplets ihre Aufgaben direkt aus de Infinity Cache holen.

Ich hätte nur halt erwartet daß das ganze quasi wie bei CPUs gemacht wird. Also I.O + chiplets und skalierbar dann soweit wie das PCB reicht.

Ein reiner I/O würde bei GPUs nicht reichen, da die GPUs viele ALUs haben, diese aber explizit gefüttert werden wollen und daher ein Sheduler auch die Aufgaben zuweisen muss. Zumindest diese Controlllogik muss mit in de I/O wandern, damit die Aufgaben koordiniert werden.

 

[dustydelta]

Bei "Aldebaran" musste ich sofort an Dr. Axel Stoll denken.

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Genau für diesen Beitrag bin ich hier

 

[ZeroStrat]

Man munkelt da vieles, weil es einige Konzepte gibt, die man hier nutzen könnte. Da wir hier aber von den MIs sprechen, ist die Koordinierung zum "glück" etwas einfacher und es ist auch nicht so zeitkritisch, dass man die Daten auch langsamer verschicken kann. Hier kommts am Ende auf die gesamte Rechenleistung an.

Ich denke, dass man die Bandbreite über genügend Lanes in den Griff bekommen würde für einen performanten Gaming Chip, aber die Latenzen? Kann ich mir nicht so recht vorstellen.

 

[Teralios]

Ich denke, dass man die Bandbreite über genügend Lanes in den Griff bekommen würde für einen performanten Gaming Chip, aber die Latenzen? Kann ich mir nicht so recht vorstellen.

Ich meinte mit Langsamer im dem Fall auch "zeitlich" langsamer, nicht von der Bandbreite her.

 

[ZeroStrat]

Ich sehe auch nicht, wie das mit Caches gelöst werden soll das Latenzproblem. Vielleicht kann man einen speziellen RT Die integrieren. Ich könnte mir vorstellen, dass das nicht so latenzkritisch ist. Oder man verwendet einen Interposer, um die Chips zu verbinden. Aber das könnte teuer werden.

 

[Colindo]

Mit dem Infinity-Cache und den 3D-Stacking könnte ich mir aber vorstellen, dass man einen entsprechenden Cachebaustein und IO als Controller umsetzt und sich die Chiplets ihre Aufgaben direkt aus de Infinity Cache holen.

Die Patente erhielten ja noch die "Bridge", wo im späteren Patent dann der L3-Cache mit drauf war. Diese Bridge könnte auch der I/O-Chip sein, von dem @ZeroStrat gehört hat.

Ich sehe auch nicht, wie das mit Caches gelöst werden soll das Latenzproblem.

Soweit ich weiß, haben GPUs gar kein Latenzproblem. Solange die Daten gleichmäßig fließen, ist die Latenz sehr viel weniger kritisch als bei CPUs. Also Hauptsache, alle Interconnects haben viel Bandbreite.

 

[Teralios]

Soweit ich weiß, haben GPUs gar kein Latenzproblem.

Jaein, beim Echtzeit-Rendern ist das heute etwas anders bei manchen Sachen, weil die Daten ja im Cachen sein müssen für andere.

Im HPC-Bereich ist es unkritisch, da müssen Daten eher rein als raus.

 

[Colindo]

@Teralios Aber zum Beispiel in dem Paper zum Thema Raytracing, das ich mal durchgegangen bin, wurde das ebenso gesagt. Spielegrafik ist prinzipiell deutlich vorhersagbarer als die CPU-Berechnungen dafür. Das heißt ja nicht, dass es nicht Berechnungen gibt, die eine geringe Latenz benötigen. Beim Paper über Shared Cache von AMD wurden eine ganze Reihe von Programmen gezeigt (aus GPGPU), die geringe Latenzen benötigen. Aber soweit ich weiß sind Spiele tatsächlich eher genügsamer.