News Ryzen 9 7950X3D² mit doppeltem 3D V-Cache als Vorschau auf den Ryzen 9 9950X3D?

[PCGH-Redaktion]

Jetzt ist Ihre Meinung gefragt zu Ryzen 9 7950X3D² mit doppeltem 3D V-Cache als Vorschau auf den Ryzen 9 9950X3D?

Ein ganz besonderes Engineering Sample ("ES") eines AMD Ryzen 9 7950X3D ist jetzt aufgetaucht, welches insbesondere durch seinen von 64 MiB auf 128 MiB verdoppelten 3D V-Cache, der sich auf beide Chiplets verteilt, von sich reden macht.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: Ryzen 9 7950X3D² mit doppeltem 3D V-Cache als Vorschau auf den Ryzen 9 9950X3D?

 

[Schori]

Dass es so ein ES gibt sollte nicht überraschen.
Warum die so nciht gekommen sind wird seine Gründe haben.

Ich stelle es mir schwierig vor da beide Cache Teile ja durch den interconnect getrennt sind und hier Daten im Fall der Fälle doppelt vorhanden oder von einem CCD zum anderen übertragen werden müssen.

 

[m4ntic0r]

Nach allen Begründungen zum 7950x3d kann ein zukünftiger Prozessor eigentlich nicht mit doppelt Cache kommen. Nicht bei zwei Chiplets. Wenn es ein 16er Chiplet gibt hat sich das eh erledigt.

Auch wenn das einige gerne sehen würden, kann das AMD als Firma nicht bringen, weils ihnen und den Gamern nichts bringen würde.

Die einzige Begründung könnten irgendwelche "KI" Workloads sein, da gibts nicht viele aber doch einige wo auch der Cache anspringt und Sinn macht.

 

[Mazrim_Taim]

mmm
Bin dann mal gespannt ob, wann und wie teuer ein Ryzen 9 9950X3D² wird

 

[rum]

Interessant wäre, ob man bei 2x8 Kernen + V-Cache oder 1x16 Kernen + V-Cache nicht einfach SMT grundsätzlich weglassen, und ob man dadurch vielleicht nicht noch n Tick mehr Performance rausholen könnte. Mehr als 8 Kerne werden aktuell ja immer noch nicht flächendeckend ausgereizt.

 

[XD-User]

Sollte der Interconnect mit Zen 6 wirklich überarbeitet werden und auch ggf. der IO DIE in größerem Maße was die Schwierigkeiten bzw. Probleme zwischen den DIEs löst oder stark abschwächt, dann könnte ein potentieller 16 Kerner mit 128MB X3D Cache als quasi Ryzen 9 "11990" X3D neben einem 11950 X3D (Sollte die 10er Reihe als Zwischensprung wieder Mobil bzw APUs vorbehalten bleiben) sicherlich ein sehr interessantes Produkt und eventuell als Abschluss der Plattform AM5 gut ankommen. Alles Spekulation und Träume, aber man darf ja gerne mal abdriften ins, was wäre wenn.

 

[Korben06]

Ich stelle es mir schwierig vor da beide Cache Teile ja durch den interconnect getrennt sind und hier Daten im Fall der Fälle doppelt vorhanden oder von einem CCD zum anderen übertragen werden müssen.

Aber beim X3D ist der zusätzliche Cache ja auch vom anderen Chiplet getrennt. Warum sollte das nicht genauso auch auf dem anderen Chiplet funktionieren?

 

[sophocles]

Dass es so ein ES gibt sollte nicht überraschen.
Warum die so nciht gekommen sind wird seine Gründe haben.

Ich stelle es mir schwierig vor da beide Cache Teile ja durch den interconnect getrennt sind und hier Daten im Fall der Fälle doppelt vorhanden oder von einem CCD zum anderen übertragen werden müssen.

Das ist genau der Punkt.

Erstens hat AMD zur Veröffentlichung der 7900/7950X3D selbst erklärt, dass sie auch mit vCache auf beiden Chiplets experimentiert haben. Das ist ja auch nur logisch, warum sollten sie das nicht ausprobieren. Es entspricht dem normalen Lauf der Dinge, dass solche Engineering Samples irgendwann irgendwo auftauchen. Ehrlich gesagt hätte ich sogar schon früher damit gerechnet.

Genauso hat AMD damals lang und breit erklärt, warum sie sich für das asymmetrische Design entschieden haben - weil es für den Desktopeinsatz schlicht besser ist.

Wie @PCGH_Sven es schön ausdrückt, stirbt seit der Veröffentlichung von Zen4X3D die "Hoffnung" von PC-Gamern nicht aus, dass es irgendwann mal Dual-CCD Ryzen mit vCache auf beiden CCDs geben könnte. Das ist vor allem ein Beleg dafür, dass viele einfach nicht verstehen, wie so eine CPU funktioniert und worin der Vorteil des vCache besteht.

Ich für meinen Teil würde mir mit Zen5 eher einen (rein hypothetischen!) Ryzen 9 9960X3D wünschen, bestehend aus einem 8-Kern Zen5 CCD mit vCache und einem 16-Kern Zen5c CCD mit normalem 32MB shared L3. Das wäre wirklich fast schon eine eierlegende Wollmilchsau. 24c/48t, brutale Energieeffizienz bei hoher Threadlast, keine Schedulingprobleme für's Gaming - herrlich. Wenn Sie dann doch noch den IOD überarbeiten und die XDNA2 NPU reinpacken... unrealistisch, ich weiß, aber man wird noch träumen dürfen. 😁

 

[Aeshma-Deva]

Wenn man dann kein extra Programm benötigt, welches ein ccd deaktiviert um bei Spielen keine Performance zu verlieren wäre das nett.

 

[PCGH_Sven]

Ich für meinen Teil würde mir mit Zen5 eher einen (rein hypothetischen!) Ryzen 9 9960X3D wünschen, bestehend aus einem 8-Kern Zen5 CCD mit vCache und einem 16-Kern Zen5c CCD mit normalem 32MB shared L3.

Du setzt bei den Träumereien ja noch einmal einen drauf.

Würde ich aber auch so nehmen. ^^

 

[sophocles]

Aber beim X3D ist der zusätzliche Cache ja auch vom anderen Chiplet getrennt. Warum sollte das nicht genauso auch auf dem anderen Chiplet funktionieren?

Aus genau dem Grund, den Du nennst: Bei allen Dual-CCD Ryzen sind die Caches eines CCDs für die Kerne des anderen CCDs nur über das Fabric zugänglich.

Der Vorteil eines (möglichst großen) Caches besteht vor allem in zwei Punkten: Möglichst viele Daten nah bei den Kernen vorzuhalten, damit diese nicht erst vom RAM angefordert werden müssen, sorgt dafür, dass die Daten schneller verfügbar sind und dass der Transfer weniger Energie verbraucht.

Müssen die Daten erst über das Fabric und den IOD von einem CCD zum anderen geschoben werden (was grundsätzlich geht und natürlich auch so stattfindet), schenkt man einen guten Teil dieser Vorteile her. Natürlich ist der Zugriff noch schneller und energieeffizienter als der Rückgriff auf den RAM, aber um Welten langsamer und ineffizienter als der Verbleib innerhalb eines CCDs (bzw. um genau zu sein in diesen Fall CCX).

Als Beispiel mag gerne der Schritt von Zen2 zu Zen3 dienen: Zen 2 organisierte seine 8 Kerne innerhalb eines CCD (Core Chiplet Die) nochmals in jeweils 2 CCX (Core Complex) à 4 Kerne mit 16MB L3 Cache. Zen 3 vereinheitlichte die CCX zu 8 Kernen mit 32MB L3. Auf dem Papier hatten beide Generationen 8 Kerne mit 32MB L3 pro CCD - aber allein der Unterschied in den Zugriffszeiten machte Zen3 bekanntermaßen deutlich schneller als Zen2. Und das war nur der Zugriff innerhalb eines CCD. Geht man jetzt von einem Chiplet zum Anderen über das Fabric, wird es nochmals langsamer. Deshalb macht es einfach keinen großen Sinn, beide CCDs mit vCache auszustatten, dafür dann aber auch bei beiden fMax und tMax zu opfern. Denn nicht vergessen: Das vCache Chiplet opfert bis zu 800Mhz Takt. AMD weiß schon, was sie da machen.

Und noch eines als Nachsatz: Natürlich weiß AMD von den Nachteilen des Infinity Fabric. Ryzen und Epyc sind seit Zen2 nicht so aufgebaut, wie sie es sind, weil AMD (und TSMC) es nicht besser können, sondern weil es immens billiger ist als bessere Alternativen und trotzdem reicht, um besser zu sein als die Konkurrenz. RDNA3 nutzt nicht umsonst nicht Infinity Fabric sondern ein Fan-out Konzept namens Infinity Link für die Verbindung vom GCD zu den MCDs, die Bandbreite, der Energieverbrauch und die Latenz des Infinity Fabric wäre hier viel zu schlecht. Erst für Zen6 wird im Moment erwartet, dass AMD den Interconnect ändern wird.

Edit: Falsche Übersetzung von CCD korrigiert.

 

[Alderson-RApID]

"HXL alias @9550pro hat über den Kurznachrichtendienst X - vormals X "

Hieß der "Laden" vormals nicht anders ?

 

[TausendWatt]

Freu mich drauf, das wird meine Ablöse für die Base Line Krücke...

 

[empy]

Ich stelle es mir schwierig vor da beide Cache Teile ja durch den interconnect getrennt sind und hier Daten im Fall der Fälle doppelt vorhanden oder von einem CCD zum anderen übertragen werden müssen.

Das ist ja sowieso so, weil auch CCDs ohne X3D-Cache einen L3-Cache haben. Aber dadurch, dass auch mehr Cache im anderen CCD verfügbar ist, müssen Kerne auf diesem CCD seltener nach außerhalb vom CCD und die Kerne von dem anderen CCD zumindest seltener nach außerhalb der CPU kommunizieren. Das ist isoliert betrachtet also auf jeden Fall ein Vorteil.

Interessant wäre, ob man bei 2x8 Kernen + V-Cache oder 1x16 Kernen + V-Cache nicht einfach SMT grundsätzlich weglassen, und ob man dadurch vielleicht nicht noch n Tick mehr Performance rausholen könnte.

Naja, man kann es ja deaktivieren, wenn man sich davon Vorteile verspricht. Extra Hardware dafür zu entwickeln lohnt sich ziemlich sicher nicht, weil SMT nicht sonderlich viel Chipfläche einnimmt.

 

[The_Invisible84]

Das ist genau der Punkt.

Erstens hat AMD zur Veröffentlichung der 7900/7950X3D selbst erklärt, dass sie auch mit vCache auf beiden Chiplets experimentiert haben. Das ist ja auch nur logisch, warum sollten sie das nicht ausprobieren. Es entspricht dem normalen Lauf der Dinge, dass solche Engineering Samples irgendwann irgendwo auftauchen. Ehrlich gesagt hätte ich sogar schon früher damit gerechnet.

Genauso hat AMD damals lang und breit erklärt, warum sie sich für das asymmetrische Design entschieden haben - weil es für den Desktopeinsatz schlicht besser ist.

Wie @PCGH_Sven es schön ausdrückt, stirbt seit der Veröffentlichung von Zen4X3D die "Hoffnung" von PC-Gamern nicht aus, dass es irgendwann mal Dual-CCD Ryzen mit vCache auf beiden CCDs geben könnte. Das ist vor allem ein Beleg dafür, dass viele einfach nicht verstehen, wie so eine CPU funktioniert und worin der Vorteil des vCache besteht.

Ich für meinen Teil würde mir mit Zen5 eher einen (rein hypothetischen!) Ryzen 9 9960X3D wünschen, bestehend aus einem 8-Kern Zen5 CCD mit vCache und einem 16-Kern Zen5c CCD mit normalem 32MB shared L3. Das wäre wirklich fast schon eine eierlegende Wollmilchsau. 24c/48t, brutale Energieeffizienz bei hoher Threadlast, keine Schedulingprobleme für's Gaming - herrlich. Wenn Sie dann doch noch den IOD überarbeiten und die XDNA2 NPU reinpacken... unrealistisch, ich weiß, aber man wird noch träumen dürfen. 😁

Keine scheduling Probleme? Wo laufen dann die Anwendungen drauf und wo bei mischlast?

Die sollen einfach einen nativen 16core mit 3dcache raushauen, wäre Instant buy auch für 1k Eur

 

[wurstkuchen]

Multi CCD Design Ryzen scheinen abzustinken beim Gaming wegen Latenz und Interconnect Problemen. Wenn bräuchte man ein monolites design mit 12-16 Kernen wo dann ein dicker 3d Cache drauf sitzt.

 

[LastManStanding]

"HXL alias @9550pro hat über den Kurznachrichtendienst X - vormals X "

Hieß der "Laden" vormals nicht anders ?

Diese Fehler passieren wenn man ständig Schreibt "vormals Twitter"... Man müsste meinen die Leser seien bescheuert!.
Wenn ich durch Heirat o.ä heute Schmit hieße schreibe ich doch auch nicht auf jedes Dokument Schmit-"Vormals Müller"

 

[PCGH_Raff]

"HXL alias @9550pro hat über den Kurznachrichtendienst X - vormals X "
Hieß der "Laden" vormals nicht anders ?

Gefixt.

MfG
Raff

 

[m4ntic0r]

Eingebundener Inhalt

Imgur

imgur.com/gallery/54d8cdF

An dieser Stelle findest du externe Inhalte von Imgur. Zum Schutz deiner persönlichen Daten werden externe Einbindungen erst angezeigt, wenn du dies durch Klick auf "Alle externen Inhalte laden" bestätigst: Alle externen Inhalte laden Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit werden personenbezogene Daten an Drittplattformen übermittelt.
Für mehr Informationen besuche die Datenschutz-Seite.

 

[sophocles]

Keine scheduling Probleme? Wo laufen dann die Anwendungen drauf und wo bei mischlast?

Die sollen einfach einen nativen 16core mit 3dcache raushauen, wäre Instant buy auch für 1k Eur

Der Windows Scheduler kann bei den CPUs durchaus unterscheiden, welche Kerne schneller und welche langsamer laufen. Das ist Standard. Priorisierte Threads werden wann immer es möglich ist den besten Kernen zugewiesen.

Daraus entsteht auch das Schedulingproblem des R9-7950X3D bei der Zuweisung von Game-Threads, denn die besten Kerne des non-Cache CCDs takten ja problemlos bis 5,8 GHz, die des vCache-CCDs nur bis max. 5,25 GHz. Standardmäßig priorisiert Windows also immer das non-vCache CCD. Im Alltagsbetrieb, im Workstationbetrieb und sowieso ganz allgemein ist das ja auch gut so und man möchte das, weil von Spezialfällen abgesehen profitieren die meisten Anwendungen eben ab einem gewissen Punkt mehr von Takt als von Cache. Games möchte man aber zumeist lieber auf dem vCache-CCD, weil die 96MB L3 Cache den Geschwindigkeitsnachteil der Kerne mehr als nur ausgleichen. Deshalb der Umweg über den angepassten Chipsatztreiber und die X-Box Game Bar, um dem Scheduler einen Fingerzeig zu geben, dass er von seinem Standardverhalten abweichen soll. Natürlich mit dem bekannten Problemen.

Die Probleme hätte der hypothetische 8 Kerne vCache + 16 c-Kerne Prozessor von vornherein gar nicht erst - weil dann die Standardkerne mit oder ohne vCache ohnehin höher takten als die c-Kerne. Damit landen die ersten 16 Threads eines Spiels schon ohne Eingriff automatisch auf dem vCache CCD.