News Ryzen 9 9950X3D & 9900X3D: AMD erklärt, wieso es weiterhin nur ein X3D-Chiplet gibt

[stefan92x]

wäre nicht auch ein 10kerner mit 3D Cache möglich Also wo alle 10 kerne den Cache haben.

Halt auch nur als Dual-CCD-Lösung und hätte damit die gleichen Probleme und Produktionskosten wie der 16-Kerner, wäre aber natürlich deutlich schwächer.

 

[Sunjy Kamikaze]

jo klar. Wenn schon 10 oder 12 Kerne mit einem CCD als Cache. Dafür verzichte ich gern auf die Kerne ohne zusätzlich.

 

[qiller]

Ich hätte auch echt gern beim aufrüsten zumindest ein paar wenige Kerne mehr die voll am Cache hängen. 10 oder 12 wären schon sexy. 16 müssten es nicht zwingend sein.

Reine Kostenfrage. Klar würde das auch jetzt schon gehen. Man hätte dann halt nicht 2 kostengünstigere 8-Kern CCDs, sondern halt 1 größeren 16-Kern CCD (oder auch 12-Kern CCD). Das Problem ist halt, dieser eine große 16-Kern CCD ist mehr als doppelt so teuer, als die 2 kleinen 8-Kern CCDs. Das ist ja der Grund, warum AMD überhaupt auf das Chiplet-Prinzip setzt. Also die Performance ist es jedenfalls nicht. Ohne den lahmen Infinity Fabric würde die Performanceskalierung über 8-Kerne hinaus nämlich schon ganz anders aussehen.

Irgendwann wird das auch kommen, also Single CCDs mit 12 o. 16 Kernen. Bei den komprimierten ZenC-CCDs ist das ja jetzt schon der Fall. Die können halt nur nicht hoch takten, weil dann die Leistungsdichte einfach zu hoch wäre und die ein Loch ins Silizium brennen würden. Aber bei den nicht komprimierten Zen-Desktop-Kernen wird das auch kommen. Gibt ja schon Spekulationen, dass bei Zen 6 mit 12-Kern CCDs geliebäugelt wird. Dann hätte man bei einer X3D-Variante gleich 12-Kerne, die auf einen großen und schnell angebundenen L3-Cache zugreifen können. Das wär schon nice.

 

[CDLABSRadonP...]

Man kann das noch weiter nachvollziehen und feststellen, dass der Vorteil daraus entsteht, dass die Daten schneller (= mit niedrigerer Latenz) geladen werden können als beim Schritt zur nächsten Stufe der Speicherhierarchie, also dem System-RAM. D.h. das ganze ist streng genommen kein Speicherplatzproblem, sondern ein Speicherlatenzproblem. Und diese Sichtweise hilft vielleicht auch noch einmal, um zu verstehen, dass es mit dem Weg über IF und I/O-Die zum Cache des zweiten CCDs nicht gelöst wird. Eben weil die Latenz hier signifikant schlechter ausfällt als zu alloziertem Speicher im "eigenen" X3D-Chiplet.

Es ist eigentlich immer eine Kombination: Wie "lange" (im Sinne von: Für wie viel Speicherplatz) kann die niedrige Latenz gehalten werden? Also wenn man so einen typischen Vergleich von chipsandcheese nimmt...
https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https://substack-post-media.s3.amazonaws.com/public/images/3b4caff5-271e-4ada-bc37-7f1854e07c92_1124x545.png
(aus dem Artikel https://chipsandcheese.com/p/amds-9800x3d-2nd-generation-v-cache)
...dann ist die Frage, ob das Integral bis zu einer bestimmten Speichermenge noch signifikant geringer oder bereits höher oder gleich ist. Was dort schön zu erkennen ist, sind die paar Taktzyklen zusätzlicher Latenz durch den V-Cache, dafür gewinnt er danach aber halt massiv, nur damit es sich später wieder angleicht. Also: Kapazität und Latenz sind wirklich sehr eng miteinander verschränkt --- und Effizienz kommt ja zu allem Überfluss auch noch hinzu...

 

[incurable]

jo klar. Wenn schon 10 oder 12 Kerne mit einem CCD als Cache.

AMD hat keine Prozessorplättchen mit 10 oder 12 Kernen.

Ergänzung (14. Januar 2025)

"--Bitte die Zitierregeln beachten--"

Wieder so ein Fall, in dem die "Zitierregeln" völlig sinnentstellend wirken, weil nicht erkennbar ist, auf welchen Teil von @Vitche s langem Beitrag @CDLABSRadonP... geantwortet hat.

 

[ghecko]

wäre nicht auch ein 10kerner mit 3D Cache möglich Also wo alle 10 kerne den Cache haben.

Die Compute-Chiplets bei Zen5 liegen ohnehin nahe beieinander und der 3D-Cache ist darunter. Es wäre möglich gewesen einen einzigen, doppelt so großen Cache-DIE für beide zu verwenden. Somit hätte jeder Kern vollen Zugriff auf jeden Teil des 3D-Caches gehabt, ohne über den IOD kommunizieren zu müssen.
Der Cache-DIE wäre aber zweifellos teuer geworden.

AMD hat keine Prozessorplättchen mit 10 oder 12 Kernen.

Aber mit 16 (Zen5C) Kernen. Und ich bin was da betrifft nicht aktuell, aber sollte die Anzahl der Kerne pro CCD
nicht mit Zen6 sowieso steigen?

 

[Araska]

Die Compute-Chiplets bei Zen5 liegen ohnehin nahe beieinander und der 3D-Cahce ist darunter. Es wäre möglich gewesen, einen einzigen, doppelt so großen Cache-DIE für beide zu verwenden. Somit hätte jeder Kern vollen Zugriff auf jeden Teil des 3D-Caches gehabt, ohne über den IOD kommunizieren zu müssen.

Geht das mit den Chipgrößen noch, oder wäre da schon wieder ein wenig Bonuslatenz hinzugekommen?

 

[ghecko]

oder wäre da schon wieder ein wenig Bonuslatenz hinzugekommen?

Da der Weg weiter ist, ist natürlich mit Bonuslatenz zu rechnen. Aber nichts im Vergleich zu der Kommunikation zu einem anderen CCD über den IOD. Geht ja direkt durchs Silizium.

 

[stefan92x]

Geht das mit den Chipgrößen noch, oder wäre da schon wieder ein wenig Bonuslatenz hinzugekommen?

Nicht nur ein wenig, sondern eine ganze Menge. Dieser L3 würde keinen Spaß mehr machen. Denn es ist zwar richtig, dass die CCD nebeneinander liegen, aber der eigentliche Cache liegt nur in der Mitte des CCD - also weit voneinander entfernt. Wenn man das komplett überbrücken und als einen Cache ansprechen würde, müsste man alleine aufgrund der Distanzen im Chiplet mit der dreifachen L3-Latenz reichen (ganz grob als Größenordnung, vielleicht auch nur die doppelte)

Aber mit 16 (Zen5C) Kernen.

Die aber auch deshalb so kompakt sind, weil sie z.B. keine TSVs besitzen, die man fürs Stacking bräuchte. All diese extras wurden aus dem Design entfernt, um das Chiplet kleiner machen zu können.

Und ich bin was da betrifft nicht aktuell, aber sollte die Anzahl der Kerne pro CCD
nicht mit Zen6 sowieso steigen?

Definitiv. Die Gerüchteküche scheint sich nicht ganz einig zu sein, auf welche Größe das hinausläuft, aber mehr wird es sicher geben. Wird ja auch mal Zeit, seit Zen 2 hat sich da ja nichts mehr getan.

 

[incurable]

Die Compute-Chiplets bei Zen5 liegen ohnehin nahe beieinander und der 3D-Cache ist darunter. Es wäre möglich gewesen einen einzigen, doppelt so großen Cache-DIE für beide zu verwenden. Somit hätte jeder Kern vollen Zugriff auf jeden Teil des 3D-Caches gehabt, ohne über den IOD kommunizieren zu müssen.

Wie soll das logisch funktionieren?

Der L3 ist in Zen 5 soweit ich mich erinnere ein reiner Opferspeicher, nimmt also nur die aus den niedrigeren Zwischenspeichern fallenden Inhalte auf, und die Prozessorplättchen können nur über die Nordbrücke miteinander kommunizieren.

MIt mal eben alles in ein (wie auch immer) vergemeinschaftetes Speichergatter werfen ist es bei weitem nicht getan.

Ergänzung (14. Januar 2025)

Zen6

Zwischen "Zen" und die Versionsnummer gehört ein Leerzeichen.

 

[Araska]

Zwischen "Zen" und die Versionsnummer gehört ein Leerzeichen.

...aber auch nur bei den Versionsnummern. Das '+' kommt direkt an die Bezeichnung.

 

[CDLABSRadonP...]

"--Bitte die Zitierregeln beachten--"

Wieder so ein Fall, in dem die "Zitierregeln" völlig sinnentstellend wirken, weil nicht erkennbar ist, auf welchen Teil von @Vitche s langem Beitrag @CDLABSRadonP... geantwortet hat.

Danke für die Erwähnung. Ohne sie hätte ich nicht gewusst, dass mein Beitrag editiert wurde. In diesem Beitrag wurden übrigens die Zitationsregeln eingehalten, ich habe also extra nur den Teil zitiert, auf den sich mein Beitrag bezog. Ich tagge mal auch @Zensai, damit sich das Problem angeschaut werden kann. Mir ist ziemlich unverständlich, wie eine Befolgung zu einem Edit führen kann --- höchstens durch irgendeinem Kontrollalgorithmus, der im Hintergrund absurd durchdreht.
Entsprechend ist mein Beitrag nun auch lesbar wiederhergestellt und ich freue mich auf eine Reaktion von dir @incurable und @Vitche auf den Beitrag.
Der ganze Metaebenen-Kram kann gerne nach Lösung des Problems auch gerne wieder aus meinem Kommentar raus.

 

[Zensai]

Das wurde versehentlich falsch moderiert. Haben das Intern geklärt, war schon okay wie da von dir zitiert wurde. ;-)

Da wir nicht editieren, kommt auch kein Kram raus. ich lass das jetzt hier inkl meinem Kommentar. Wir werdens überleben =)

 

[Sunjy Kamikaze]

Wie läuft das den mit dem 16 kerner beim zocken. Muss man dem Game über ein tool sagen auf welchen Kernen es zu laufen hat oder macht Windows das zuverlässig? Geht das überhaupt oder ist das ein glücksspiel?

 

[PS828]

@Sunjy Kamikaze ich kenne das vom Vorgänger Zen4 dass die Zuordnung automatisch und zuverlässig funktioniert. Das war selbst zu release schon so und wurde hier auf CB sogar getestet

 

[Sunjy Kamikaze]

Ich habe neben dem Game halt noch viel anderes laufen. Dutzende Tabs mehrere Streams und Tools die ich zur Arbeit benötige.

Wichtig wäre mir das ich Safe sagen kann 8 Kerne fürs Game 8 kerne für den rest und so das Optimum aus beiden welten habe. Wenn er beim zocken aber langsamer als der 9800X3D wäre würde mich das schon ärgern.

 

[incurable]

ich kenne das vom Vorgänger Zen4 dass die Zuordnung automatisch und zuverlässig funktioniert

(1) Zen 4, mit Leerzeichen.

(2) Bei Zen 4 wurden Mehrplättchenprozessoren ohne zusätzlichen Zwischenspeicher nicht gesondert behandelt. AMD-Motto: Wird schon irgendwie laufen.

(3) Seit Zen 5 fallen Mehrplättchenprozssoren unabhängig vom Vorhandensein zusätzlichen Zwischenspeichers in die Kategorie Sonderbehandlung, also mit Spieleleiste, Neuinstallation und abgschalteten Kernen beim Spielen.

 

[Sunjy Kamikaze]

Ok versteh ich nix von. Bedeutet das es bei Zen 5 dann so laufen sollte?

Kann man den z.B einem Game direkt Kerne zuweisen so das auch wirklich nur diese 8 kerne sich nur um das Game kümmern und der rest den rest macht?

 

[incurable]

Ok versteh ich nix von. Bedeutet das es bei Zen 5 dann so laufen sollte?

Nein, bei Zen 5 muss man bei allen Mehrplättchenprozessoren speziell vorgehen und Zusatzprogramme installieren:

https://www.computerbase.de/artikel...te_windows_und_softwareprobleme_neu_aufgelegt

 

[Martyn]

Wie läuft das den mit dem 16 kerner beim zocken. Muss man dem Game über ein tool sagen auf welchen Kernen es zu laufen hat oder macht Windows das zuverlässig? Geht das überhaupt oder ist das ein glücksspiel?

Im Regelfall macht Windows das schon zuverlässig.

Aber bei den 12- und 16-Core 3D Cache wo nur 3D Cache auf einem Chiplet ist schwören manche Leute drauf im EFI/BIOS das Chiplet ohne 3D Cache zu deaktivieren, damit nicht doch machmal einzelne Tasks von Cores ohne 3D abgearbeitet werden.

Da soll dan manchmal die fps ein bisschen höher werden und die Lows weniger.

Für Casual Gamer ist es aber eigentlich nicht notwendig. Weil die meisten Leute sehen ja zwischen vielleicht 165-180 fps oder 175-195 fps geh keinen Unterschied, oder ob sie 1,3% Lows oder nur 0,8% Lows haben.