AMD Ryzen 9 9950X3D Gesichtet: Über 5,6 GHz Boost-Takt und 128 MB L3-Cache im CPU-Z Leak

Das (mögliche ) Problem bei den Ryzens mit mehr als 8 Kernen, also 2 CCDs - 1 CCD mit X3D, einer ohne - ist, daß man gerade Windoof manchmal mit der Nase darauf stoßen muß, ein Programm (Spiel) auf dem CCD mit X3D laufen zu lassen, und nicht auf einem der Kerne auf dem CCD ohne X3D. Bei den 8 und 6 Kernern gibt's ja nur 1 CCD, so daß Programme und OS bei dem 7800X3D, 9800 X3D usw erst gar keine Wahl haben, und immer Kern(e) auf dem CCD mit X3D benutzen müssen. Was man ja gerade in Spielen will. Wenn zB ein 9950 (16 Kerne in 2 CCDs) X3D unter jedem der zwei CCDs hätte, wär es dagegen egal, wo das OS ein Programm ausführen will.

Völliger Spekulatius meinerseits: So einen 2x X3D Zen5 16 Kerner wird AMD uU für HEDT und Workstations zurückhalten , also als entry level Threadripper (mit TR Preisen😜). Sind eben nicht nur Spiele, die durch extra Cache deutlich schneller und effizienter laufen können.

OT: bin gespannt, ob und wie Intel sowas ähnliches wie X3D in Panther Lake bringen wird. Intel ist hier im Zugzwang, und muss sich was einfallen lassen.

Antwort 2 Likes

Die Aussage "Zusammen mit dem L2-Cache ergibt sich ein Cache-Gesamtvolumen von 144 MB" halte ich für etwas irreführend,
die beiden Caches L2 und L3 sind ja nicht additiv, sondern funktional gestapelt, erst L3, dann L2.
Außerdem ist L2 doch je Core - d.h. L2-Cache-Änderungen müssen an die anderen Cores signalisiert werden, das ist kein großer, zusammenhängender Cache.

Übrigens: die 2 x Cache-Dies würden vermutlich nur was bringen, wenn sie miteinander verbunden wären. Und das dürfte mit dem derzeitigen Chiplet-Design wohl eher nicht möglich sein. Somit kann ein Core des einen Chiplets nicht auf bereits im L3 befindliche Daten des anderen Chiplets zugreifen, sprich: die Daten müssten je nach Thread und Programm in beiden L3 Caches, also doppelt vorgehalten werden und damit auch oft doppelt aus dem RAM geladen werden.

Bei den Server-CPUs greifen dann ohnehin andere Mittel, die fahren auch nicht mit Windows 10, sondern mit Server-Betriebssystemen, die andere Scheduler haben. Manche Server sind ja NUMA, d.h. verschiedene Prozessoren greifen auf unterschiedlichen RAM zu, das dazu passende Scheduling bzw. Thread-Verteilung auf die jeweils zusammenpassenden Cores muss das Betriebsystem können. Bei Servern geht es um Anwendungen, Filesysteme und Datenbanken, die wohl eher ein anderes Thread-Verhalten als Feld/Wald/Wiesen-Games haben.

Antwort Gefällt mir

Was soll mir das sagen ?

Die Infinity Fabric verbindet die CCDs mit dem IOD, nicht aber die Caches untereinander.
Sonst könnten bereits jetzt beide CCDs auf die gemeinsamen 96+32 MB L3 zugreifen.

Aus der von dir oben verlinkten Webseite entnehme ich:
If this causes a block to be evicted from L1, the evicted block is then placed into L2. This is the only way L2 gets populated.

Auf Ryzen L2-L3 bezogen: in den L3 eines CCD geht nur rein, was aus dem L2 eines Cores dieses CCDs rausfliegt.
Also nix mit "hintenrum über die Fabric in den L3 des anderen CCDs".

Ich bin nicht mal sicher, ob überhaupt die anderen Cores desselben CCDs auf L2->L3 overflow Daten
eines anderen Cores zugreifen dürfen, finde dazu aber nur nicht-AMD-spezifische Aussagen.

Die IF Taktrate liegt übrigens weit unterhalb den Cache-Taktraten, hier zwei Links:
Der Takt des Infinity Fabric liegt üblicherweise zwischen 1.600 und 1.800 MHz.
FCLK is typically far lower than L3 and core clocks.

Im zweiten Link kann man auch sehen, dass die CCDs nicht direkt miteinander verbunden sind,
sondern die CCDs jeweils nur mit der Fabric und..
Wenn die Cores der CCDs über dieses Konstrukt ihre Daten miteinander teilen wollten,
müssten diese ja zweimal übertragen werden (CCDx-Fabric-CCDy), das führt zu Latenzen.

So eine Inter-CCD Cache-Direktverbindung führt zu deftigem Overhead/Komplexität - und die Wege,
auch wenn es sich nur um Milli- oder Mikrometer handelt, sind auch zu berücksichtigen (Latenz).

Die machen ja schon bei der Signalisierung zwischen den CCDs Probleme, hier : Absatz "Kern-Latenzen",
dafür gab's schon einen AGESA Update, da reden wir aber über Prozessor-Signalisierung,
nicht über Cache-to-Cache-Verbindung, wo es um echte Datenmengen ginge.

Aber mal ehrlich, was soll das Bohei um die "möche-ich-haben" doppelten L3-Caches eigentlich ?
Ein Profi, der wirklich Anwendungen fährt, wird doch nicht etwa Spiele auf seine Workstation laden ?
Dann sollte das Finanzamt (und/oder eine eventuelle Geschäftsführung ;-) das aber nicht mitbekommen.

Und ein Gamer, der ab und an ein paar Videos erstellt ?
Sooo langsam sind die ?600X3D/?800X3D nu ja auch wieder nicht.

Antwort Gefällt mir

Alles addieren = Marketing. Dazu ist die Funktion der Caches m.E. zu komplex.
Mir selbst war es nur wichtig, die Funktion der Caches besser zu verstehen.

Schleierhaft ist mir allerdings, wie "3rd Party Tools" herausfinden sollen, wie die Hardware strukturiert ist.
Und was ist mit "alle Cache Level sind Unified" gemeint ? Dass alle - auch über Chiplets hinweg - verbunden sind ?
Das würde allen Dokumentationen widersprechen, wir reden nicht nur über Anandtech.
Die Diskussion ist aber ohnehin nicht zielführend - egal, wie der Cache ausgelegt ist,
entscheidend ist, was hinten rauskommt. Also abwarten und Tee trinken.

Der Leak selbst bringt im Grunde nix Neues: wenn man die seitherigen Prozessoren
7950X3D, 9700X, 9800X3D im Zusammenhang betrachtet, kann man sich die Struktur gut herleiten,
einen zweiten 3D-Cache wird es wohl nicht geben, dafür mehr Takt und OC für den 3D-Cache-CCX.
Vielleicht will AMD da zu den Server-Prozessoren (z.B. Genoa-X: je CCD 96 MB L3) differenzieren.

Jedenfalls falls der L3 als Overflow nur je Core-L2 verwendet würde und auch nur dieser jeweilige Core
die Daten wieder aus L3 in seinen L2 zurückbrächte, dann würde ein zweiter Cache-Die Sinn machen.
In dem Fall würde eine Verbindung der beiden L3-Caches auch keinen Sinn machen.
Aber das kann AMD wohl am Besten beurteilen.

Antwort Gefällt mir

Hab bei dem Sauwetter heute mal länger recherchiert, es gibt allerdings keine belastbaren Aussagen und viel Widersprüchliches.
Könnte auch mit dem Zen-Unterschied Server (Genoa/Epyc) vs. Desktop (Ryzen) zu tun haben.

Jedenfalls hat wohl AMD vor einigen Jahren ein Patent für ein Directory-based Cachemanagement eingereicht.
Anscheinend fahren die zwischen den Prozessoren keinen echten Snoop, sondern ein Directory je Node (Chiplet ?).
Die Cachedaten werden schon zwischen den Nodes/Cores ausgetauscht, ich nehm auch an, dass es für I/O-DMA ein Snooping gibt
(die Cores müssen ja erkennen, ob ein DMA-Controller den Speicher geändert hat).

Wenn das zitierte Patent wirklich in den Zen-CPUs implementiert wurde, tauschen die Nodes untereinander (L3) Cache-Inhalte aus.
Das Patent bringt lt. AMD Optimierungen bzgl. der Node-Kommunikation, indem wohl nach meinem Verständnis
der Owner einer Cache-Line (bin dabei über MOESI gestolpert) immer "hart" wechselt
(um die Bilder im o.g. Patent zu verstehen, muss man im PDF die Seite 9 rechts lesen).

Jedenfalls ist die Sache an sich recht geheimnisvoll und ich bin froh,
dass meine Ryzens auch ohne mein Zutun fröhlich und ohne Murren und Knurren arbeiten.

Antwort 1 Like

Das sind die Links zwischen CCD und IO-Die. Was hat das mit Cache zu tun ?

Bei CXL geht es nach meinem Verständnis um das Erweitern des RAM mit anderen Medien (SSD), siehe hier und hier und hier

Das hatte ich nicht gewusst. Wie der Austausch von Cache-Daten zwischen den Nodes und Cores bei AMD abläuft, geht aus deren Patentdokumenten vor , dieses Prinzip wurde wohl in der Zen-Architektur implementiert.

Das bedeutet aber nicht, dass ein Core direkt auf den Cache eines anderen Dies zugreifen kann, vielmehr bekommt er die Daten über die Links (Latenz !). Ein Direktzugriff eines Core auf den L3 eines anderen Core würde auch dem von dir genannten non-inclusive widersprechen.

Schade, dass du so denkst, sonst hätte ich dir noch folgende Lektüre empfohlen: Kap. 3, 6, 7 (aus 2022, behandelt zwar Zen 3 EPYC Server Prozessoren, ich nehm aber an, das Prinzip wird auch in Zen 4/5 verwendet, da finde ich nirgends, dass sich da etwas signifikant geändert hätte).

Antwort Gefällt mir