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

MoD23 schrieb:
Ich wüsste nicht warum das kein erfolgreiches Produkt werden sollte. Das Beste aus 2 Welten. 🤷
Ich glaube auch nicht, dass das merhf achangesprochene Scheduling solch ein Problem darstellt. Spiele, die nicht sauber als solche erkannt werden und Windows daher die Kernlast frei/falsch priorisiert, sind vermutlich zumeist eines älteren Baujahres und bedarfen daher sowieso keiner neuesten X3D-CPU.

Was gab es da vor Kurzem für einen Ausreißer? Da wurde hier auch berichtet. Ich gehe aber mal davon aus, dass insbesondere für neuere Spiele entsprechend zügig Patches kommen und zugleich muss man sich stets die Frage stellen, ob man in einem Spiel wie Indiana Jones oder Black Myth Wukong auch tatsächlich auf Biegen und Brechen 200+ FPS braucht, oder ob es nicht auch 60 oder 120 FPS tun.
 
Cr4y schrieb:
Ist die recht rudimentäre Packaging-Technik bei den Ryzens überhaupt ein Engpass?
Ziemlich sicher, ansonsten gäbe es bereits eine gute Versorgung mit Granite-Ridge-X und Raphael-X hätte nicht so drastisch zurückgeschraubt werden müssen.
Es gab auch einige Analysen von Dritten in letzter Zeit --- die immer gleichen wurden die Tage in Kommentaren auf Reddit gespammed, jetzt finde ich sie nicht mehr. So ist das --- ist da, wenn man es nicht braucht und weg wenn doch.
 
Was soll es denn bringen, ein Produkt rauszubringen, was dann garantiert deutlich teurer wird, als der "normale" 9950X3D aber dann vielleicht im Mittel nur 2% Performance-Zuwachs erhält und dabei in diversen Spielen dann doch wieder langsamer ist, als ein 9800X3D? Latenzpoblematik bleibt, so oder so. Nur wenn man Anwendungen weiterhin auf einem CCD zwingt, kann man vom zweiten 3D-Cache wirklich profitieren, aber dann eben auch nur in Anwendungen, die auch unter dem 9800X3D gut performen. Und in wievielen Situationen hat man als Endanwender eines Consumerprodukts die Notwendigkeit von zwei parallelen Multicore-Anwendungen, die gut mit Cache skalieren? Und wie oft weist ein Anwender dann die Kerne manuell zu?

Dafür müsste man ein komplettes Produkt auflegen, dieses in einer gewissen Stückzahl produzieren, damit überhaupt realistische Preise rauskomme, welche dann doch wieder im Regal liegen bleiben weil die Tests der Magazine sehr ernüchternd ausfallen und dann die Leute darüber herziehen, dass man eine CPU bringt, die am Ende doch nicht wirklich was bringt.
Dazu gibt es dann weniger der herkömmlichen X3D-CPUs und der Ausschuss dürfte auch größer ausfallen, dass beide CCDs dann akkurat mit dem Cache verbunden sind, was auch eingepreist werden muss. Unter 1000€ kann man dann eh knicken eher deutlich mehr, weil kleinere Stückzahlen und weniger andere X3D.

Man kann es eben nie allen recht machen, entweder bringt man einen doppelten X3D und die Leute beschweren sich über den viel zu hohen Preis bei kaum Leistungsgewinn im Schnitt (nicht zu vergessen, dass man gerade zur Anfang kaum mit der Produktion der X3D hinterher kommt) Oder man bringt ihn nicht und die Leute beschweren sich eben, dass die den nocht bringen.
 
  • Gefällt mir
Reaktionen: Ja_Ge und stefan92x
Könnte man nicht, mit 200Mhz höherem Takt, die Latenzen wieder ausgleichen? Ein FX3D würde mir schon gefallen....:smokin:
 
@Joshua2go Nein. Die Core-to-Core-Latenzen vervierfachen sich in etwa beim Sprung von einem CCD zum anderen (verglichen zur Latenz innerhalb eines CCD). 5% mehr Takt gleichen 300% mehr Latenz nicht aus.
 
ruthi91 schrieb:
Und was spräche gegen einen "9990X3D" mit zwei X3D Chiplets für einen gewissen Aufpreis?
Die Frage beantwortet sich eventuell selbst.

Schauen wir Mal ob es stimmt dass Threadripper auch Varianten mit X3D hat.
 
lynx007 schrieb:
Aber mit Mathe und Buchhaltung haben es so manche in der Consumer-World einfach nicht. Es lohnt sich halt nicht.
das Problem ist eher wieder dieses Thema der Threads und Cores, ein Ungleichgewicht auf der CPU und irgend eine fancy Logik in Windows / Linux muss es wieder ausbaden
 
Krautmaster schrieb:
und irgend eine fancy Logik in Windows / Linux muss es wieder ausbaden
Das ist auch das, was mich am meisten an dieser Lösung für X3D-Dual-CCD-CPUs stört, vor allem unter Windows das mit der Gamebar zu koppeln. Also was dümmeres ist AMD wohl nicht eingefallen. Bin froh, wenn ich so ein Scheiß abschalten kann. Dann kommt AMD daher und findet es eine tolle Idee, die Corezuweisung daran zu koppeln. Und dann funktioniert das nichtmal 100%ig. Sieht man ja schön an den Gaming-Benchmarks, wo das X3D-Single-CCD Pendent das Tomodell schlägt.

Mit ner manuellen Core-Zuweisung o. Process Lasso biste dann jedenfalls besser bedient. Btw, gibts (gab?) da ja auch bei Intel hin- und wieder Probleme, wo dann Gamecode auf E-Cores läuft. Ehrlich gesagt, bin ich kein Freund von ungleichen CPU-Aufbauten, solang die Lösungen so aussehen, wie sie es aktuell tun.
 
  • Gefällt mir
Reaktionen: lynx007 und schwimmcoder
Convert schrieb:
Auf die paar Mhz mehr des Non-X3D-CCDs in Single Threaded Anwendungen könnte man getrost verzichten.
Du schließt von dir auf alle Kunden? Mehr als schwierig.
Grade auf Computerbase, wo alle möglichen Leute mit übertakter-RAM etc. basteln, behauptest du, der Taktgewinn wäre egal. 🙃
 
Also ziemlich genau die Begründung, die hier bei jeder Forderung nach 2xX3D auch immer wieder genannt wurde.

Bringt für >95% der Anwender wenig bis nichts. Kostet mehr Geld und bringt letztendlich nur schlechte Presse, weil man Erwartungen weckt (X3D ist ja gut, also muss 2xX3D ja besser sein), die unerfüllbar sind.
Ergänzung ()

Sharky99 schrieb:
Es geht hier nicht vorranging darum ob man nur 10% mehr Performance bekommen würde, sondern dass man die Fälle vermeiden würde wo die Spiele/Apps auf den Kernen liegen die keinen L3 Cache haben. Die Performance ist dann unterirdisch
Du hast das Problem nicht begriffen. Die Performance ist unterirdisch, wenn Inter CCD Latenzen ins Spiel kommen. Das passiert vollkommen unabhängig davon, ob es den extra Cache nun auf beiden CCDs gibt oder nicht.
 
  • Gefällt mir
Reaktionen: baizer, mibbio, incurable und 2 andere
Vlt. kriegt AMD/TSMC das ja irgendwann so hin, dass 128MB SRAM quasi als On-Platine/Package-"Fundament" für 2 Chiplets herhält. Sprich man hat da ein Sandwich aus Platine, dann 128MB 3DV-Cache SRAM und darüber die beiden Chiplets. Wär natürlich 2-CCD (bzw. Threadripper/Epyc) exklusiv, also für Single-CCD unsinnig. Die Latenzen zu so einem L4 Cache wären vlt minimal größer, aber dafür ist das shared Cache über alle Kerne und halt immer noch sehr dicht an den Kernen dran.

Edit: Im grunde sowas ähnliches wie Intels Foveros. Verstehe auch nicht, warum Intel nicht schon längst mit so einer Technik mal einen cachestarken Gaming-Prozessor gebracht hat.
 
@qiller Ja auf so eine Lösung hatte ich auch schon mal gehofft/spekuliert.
Im Prinzip würden man so einen L4 Cache dann "einfach" an den I/O Die packen und alle CCDs darauf zugreifen lassen. Allerdings sind die Latenzen mehr als nur minimal höher und man löst das Inter CCD Latenzen Problem damit nicht komplett.
Also Games die tatsächlich mehr Kerne sinnvoll verwenden können, als ein CCD hergibt, würden profitieren.... alle anderen wären aber im Vergleich zur aktuellen X3D Lösung im Nachteil.
 
Wur werden wohl auf Zen 6 warten müssen. Wenn CCD mit 16 Kernen kommen, entfällt ja diese Grenze bei 8 Kernen.
 
KurzGedacht schrieb:
Im Prinzip würden man so einen L4 Cache dann "einfach" an den I/O Die packen und alle CCDs darauf zugreifen lassen. Allerdings sind die Latenzen mehr als nur minimal höher
Ne, nicht unterm IO-Die. Das macht auch gar keinen Sinn, da dann ja wieder ein längerer Weg über den Infinity Fabric gegangen werden muss. Da sind höhere Latenzen noch das kleinere Problem. Ich meinte schon direkt unter den CCDs, eingebettet in/auf die Platine und mit den Durchkontaktierungen zu den CCDs, damit die Wege kurz bleiben, die Datenraten hoch und die Latenzen niedrig.
KurzGedacht schrieb:
Also Games die tatsächlich mehr Kerne sinnvoll verwenden können, als ein CCD hergibt, würden profitieren.... alle anderen wären aber im Vergleich zur aktuellen X3D Lösung im Nachteil.
Ja das kommt dann halt auf die Höhe der Zusatzlatenz an. Wie gesagt, ein bisschen mehr könnte so eine Konstruktion schon erfordern. Aber ich könnte mir naiv vorstellen, dass es nicht mehr als 10-20% wären. Und dafür haben dann alle Kerne Zugriff auf den L4-Cache.

Aber ja, die etwas höhere Latenz würde aktuell bei den meisten Spielen die Performance (gegenüber den aktuellen X3D-CPUs) etwas mildern. Und bei Spielen, die mit mehr als 8 Kernen was anfangen können, führt das auch noch nicht zwangsläufig zu einer Performancesteigerung, wenn Berechnungen Abhängigkeiten bedingen und wieder Inter-CCD Kommunikation stattfinden muss.

Um das Problem zu beheben, müssten die CCD selber nochmal mit einem Hochgeschwindigkeits-Bus verbunden sein (könnte man theoretisch auch 3D stacken). Dann wirds wahrscheinlich richtig teuer. Und der ursächliche Grund des Chiplet-Designs war ja eigentlich eine Abwägung aus Chipgröße, Performance, Flexibilität und vor allem Herstellungskosten. Den Vorteil der Wirtschaftlichkeit wieder durch teures/kompliziertes Packaging zunichte zu machen, ist halt auch quatsch. Dann könnte man auch gleich einen monolithischen XXL-16-Kern-256MB Cache-Monster-Chip bauen^^.

Edit: Wobei als Halo-Enthusiasten-CPU, die vlt. 1.5k kostet. Ich weiß nur nicht, ob sich das wirklich lohnen würde. Anscheinend werden ja Halo-Produkte durchaus gekauft (siehe Nvidia RTX xx90-Karten). Man hat halt auf jeden Fall erstmal Mehrkosten, weils ein anderer Chip ist und die Yieldrate wird durch die Größe schlecht sein. So ein großer Chip wär auf jeden Fall risikoreicher.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: KurzGedacht
qiller schrieb:
nicht unterm IO-Die. Das macht auch gar keinen Sinn, da dann ja wieder ein längerer Weg über den Infinity Fabric gegangen werden muss. Da sind höhere Latenzen noch das kleinere Problem. Ich meinte schon direkt unter den CCDs, eingebettet in/auf die Platine und mit den Durchkontaktierungen zu den CCDs, damit die Wege kurz bleiben, die Datenraten hoch und die Latenzen niedrig.
Das ist jetzt etwas sehr weit außerhalb meines Fachgebietes und damit nicht viel mehr als Spekulation, aber ich glaube, dass es sehr schwierig ist einen CCD übergreifenden Cache zu bauen, der nicht am I/O Die (o.ä.) hängt.
Schlicht, weil irgendetwas ja die Verwaltung organisieren muss. Woher weiß CCD1 was CCD2 an irgendeine Stelle geschrieben hat, wie verhindert man, dass zwei CCDs sich die Daten gegenseitig überschreiben usw....
Der Overhead, um diese Informationen zwischen allen CCDs auszutauschen wäre gigantisch und macht einen solchen Cache letztendlich sinnlos.
 
Das mit der höheren Latenz durch weitere Distanz im Die etc. wäre doch auch durch gute Programmierung lösbar?! Wenn das Konstrukt dadrüber (Firmware? OS? Treiber?!) es steuern würde, dass nicht die weiteste Distanz/Latenz genutzt würde?

Also ja theoretisch ist es scheinbar möglich und vermutlich auch lösbar... nur eben teuer und bringt wohl (noch) nicht so viel mehr Leistung. Schade, aber wir gucken mal was die Zukunft bringt!
Vllt müssen auch langsam mal wieder die Entwickler (& Co) ran und besser optimieren...
 
fox40phil schrieb:
Das mit der höheren Latenz durch weitere Distanz im Die etc. wäre doch auch durch gute Programmierung lösbar?!
Genau das ist es, was Tools wie Process Lasso machen und was mit der XBox Game Bar erreicht werden soll.
 
  • Gefällt mir
Reaktionen: fox40phil
fox40phil schrieb:
Vllt müssen auch langsam mal wieder die Entwickler (& Co) ran und besser optimieren...
Naja, das ist ja schon seit etlichen Jahren ein Problem. Aber BlingBling-Animationen und unnötige Redisigns sind ja wichtiger.

Müsste man glatt mal nen Test machen. MS Word starten, Text schreiben, speichern:
  • einmal unter Windows XP mit Word XP
  • einmal unter Windows 11 mit MS Word 365
  • Anzahl der CPU-Cycles im ProcessExplorer zählen lassen
...aber ich bin OT :x.
 
  • Gefällt mir
Reaktionen: fox40phil
Nagilum99 schrieb:
Du schließt von dir auf alle Kunden? Mehr als schwierig.
AMD hat aktuell so eine starke Dominanz mit den X3D-CPUS, so dass die sich das letzte Quaentchen single Thread-Takt bei den X3D-Modellen sparen können und wären immer noch beliebter als Intel. Das sieht man ja auch am 8-Kern X3D-Modell, der auch nicht den höchsten Single-Core-Takt hat. Aber mit dem von mir vorgeschlagenen Schritt könnte man vielleicht mehr Ryzen 9 X3D verkaufen, weil dann alle, die nicht kontrollieren wollen, ob das X3D-Chiplet wirklich arbeitet oder nicht beruhigt zugreifen können. Die aktuelle Strategie mit dem bevorzugen vom Non-X3D-Chiplet, weil der etwas mehr Takt hat, hat eine 10:1 Verkaufsverteilung zu gunsten vom Ryzen 7 X3D, bzw, zu ungunsten von Ryzen 9 X3D. Und der Ryzen 7 X3D hat eben nicht mehr Takt, wird aber trotzdem gekauft, weil der eben Sorgenfrei ist.

https://www.tomshardware.com/pc-com...-product-is-causing-ryzen-9-9800x3d-shortages

Zitat: "McAfee also said new 99x0X3D products won't help spread the demand, as customers choose the 8-core X3D parts 10-to-1 over the higher core count X3D models."

Abgesehen davon, könnte man die Wahl auch dem Kunden per Bios-Einstellung überlassen. Das habe ich ja auch schon geschrieben.

Convert schrieb:
Man hätte übrigens das ja auch als Zusatzfeature im Bios anbieten können, wenn man es schon nicht als Grundeinstellung anbieten will. Das man dort einfach einstellt "X3D-CCD immer priorisieren" und dann meldet die CPU dem Betriebssystem immer, dass das X3D-CCD die schnellsten Kerne hat, auch wenn das andere CCD eigentlich schneller takten kann.
 
Zuletzt bearbeitet:
wäre nicht auch ein 10kerner mit 3D Cache möglich Also wo alle 10 kerne den Cache haben.

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.
 
Zurück
Oben