Zen 6 (Morpheus-Kerne, 2/3 nm, H2/2025)

[aufkrawall]

Untergräbt Open Source nicht gewisse Sicherheitsaspekte?

Nicht open-source direkt. Es hat sich bislang nur niemand die Mühe gemacht, für etwa den Linux-Kernel etwas wie Patchguard + Treiber-Signatur-Erzwingung zu implementieren. Damit sollte Linux prinzipiell nicht "knackbarer" sein als Windows für Content Protection, Anti-Cheat etc.

Bei Firmware sehe ich da sowieso keine Einschränkung. Gibt eh ständig Lücken auch im closed Zeug.

[Zossel]

Untergräbt Open Source nicht gewisse Sicherheitsaspekte?

Bin da nicht vom Fach und bitte um Erleuchtung.

Was sind denn alles die Vorteile?

https://www.google.com/search?q=kryptochef+vollbitverschl%C3%BCsselung

[Zossel]

Nicht open-source direkt. Es hat sich bislang nur niemand die Mühe gemacht, für etwa den Linux-Kernel etwas wie Patchguard + Treiber-Signatur-Erzwingung zu implementieren.

Ach, wie haben es den die FTDI-Treiber geschafft die vorsätzlich Hardware zerstören einen Stempel von MS zu bekommen?
Und wie schaffen es die ganzen Root-Kits von den Spieleherstellern regelmäßig einen Stempel von MS zu bekommen?

[aufkrawall]

Lass doch mal dieses peinliche absichtliche Missverstehen, um irgendeine Gelegenheit für Windows-Bashing zu erzeugen...

[Zossel]

Lass doch mal dieses peinliche absichtliche Missverstehen, um irgendeine Gelegenheit für Windows-Bashing zu erzeugen...

Das ist kein Missverstehen, sondern ich zeige exemplarisch die Unwirksamkeit der von dir propagierten Maßnahmen auf.

Warum werden die Root-Kits der Spielehersteller nicht gegen eine eigene CA signiert die man sich in seinen Rechner installieren kann um damit den Rechner dann auch in einen offiziellen untrusted Mode zu versetzen?
Kryptografie ist nur toll wenn man die richtig nutzt, und genau das tut MS eben nicht.

[aufkrawall]

Sieht die Content-Industrie aber anders, also Pech gehabt für Linux-Nutzer.

[Zossel]

Sieht die Content-Industrie aber anders, also Pech gehabt für Linux-Nutzer.

Hat die Content-Industire auch was anderes als Feuerwasser und Glasperlen im Angebot?

[ChaosTM]

Was die "durchschnittlichen Leute" halt so wollen.
With lootboxes & hookers..

[basix]

Ich hatte gerade eine etwas wilde Idee für Zen 6:
Könnte man den Core statisch partitionieren und daraus 2x Cores machen? Zen 5 legt dafür irgendwie die Basis.
- Dual-Scheduler
- Dual-Port uOp-Cache
- Vergrösserter L1D
- Deutlich mehr Execution Units
- "Volles" AVX512
- Deutlich grösseres FP-Register-File
- Mehr Unified Scheduler (was eine Partitionierung effektiver macht)

Zen 6 könnte mit ein paar Anpassungen dort weiter gehen:
- 48kB L1I
- 9k Entry uOp-Cache
- 1.5 MByte L2-Cache
- Integer Register-File auf z.B. 384 Entry erhöhen
- Reorder Buffer auf 576...640 Entry erhöhen

Damit hätte man beim Cache (L1I, uOp, L1D, L2) genau 75% von Zen 4. Bei den Core-Strukturen (Reorder-Buffer & Scheduler, ALUs) wäre es in einer ähnlichen Grössenordnung. Vielleicht kriegt man damit knapp Zen 4 IPC oder zumindest Performance hin (inkl. Takt).

Das wäre eigentlich ziemlich cool. Der Kunde könnte dann wählen, ob er "kleine" Cores will oder stärkere grössere Cores. Zen 6 + SMT hätte vermutlich die gleiche Performance wie "virtuell verdoppelte Cores" die auf Zen 4 Niveau laufen. Allerdings mit dem Nachteil verschiedener Sicherheitsbedenken und -risiken bei shared Caches und Ressourcen. Ausserdem wird das Noisy Neighbour Problem mit einer statischen Partitionierung eliminiert.

Für AMD hätte es den Vorteil, dass man mit dem selben Core-Design "Big" und "Little" Cores anbieten könnte, um hier gegen Intels E-Cores besser aufgestellt zu sein.

[fondness]

Du meinst defacto den beast Lake Jim Keller Ansatz? Könnte natürlich sein, dass Keller diese Idee damals auch bei AMD eingepflanzt hat.

[basix]

Jein, ist eher der umgekehrte Ansatz ;)

Rentable Units haben anhand er Gerüchte ja mehr das Ziel, ST Performance deutlich zu steigern. Bei Zen 6 würde es nicht primär darum gehen, sondern dass man die SMT-Threads statisch und ohne Thread-to-Thread Übersprechen isolieren kann. Das ist eher ein "CMT done right" als Rentable Units. Oder evtl. auch ein "Little Cores done right", da man nicht verschiedene Core Designs fahren muss und vermutlich auch die Core & Cache Ressourcen insgesamt effizienter nutzen kann.

[fondness]

https://i.postimg.cc/ydQZvf3z/image.png (https://postimg.cc/VrtvNWF7)

https://patentscope.wipo.int/search/en/detail.jsf?docId=US439561554&_cid=P22-M1X716-54757-6

[Nightspider]

Da sind auch paar schöne Bilder dabei mit Stacking und Backside Power Delivery (kommt mit TSMC N2P ab Ende 2026)

[Gipsel]

https://i.postimg.cc/ydQZvf3z/image.png (https://postimg.cc/VrtvNWF7)

https://patentscope.wipo.int/search/en/detail.jsf?docId=US439561554&_cid=P22-M1X716-54757-6
Face-to-face Montage gestackter Dies mit geteilten (shared, nicht divided) Metal-Stacks. Hat nur mittelbar mit dem Thema zu tun, aber es gibt halt Entwicklungen auf dem Gebiet.

[robbitop]

Wenn man damit die Intra CCX Latenzen senken kann, könnte man ggf. auch den L3 zwischen den CCDs teilen? Ggf. auch mit einer IGP?

[MSABK]

Meint ihr AMD geht auf 3NM wie Arrow Lake? Weil ich denke 2NM wird wahrscheinlich von Apple gekapert.

[robbitop]

Ich würde vermuten N3E dann 2026.

[BavarianRealist]

Meint ihr AMD geht auf 3NM wie Arrow Lake? Weil ich denke 2NM wird wahrscheinlich von Apple gekapert.

Vor allem für Notebook braucht AMD alsbald einen Nachfolger für Strix-Point; und da sehe ich noch wenig Chancen, dass Zen6 in N3 Anfang 2026 verfügbar wäre...

Aktuell scheint die Definition dieses Nachfolgers noch völlig unbekannt zu sein, sodass womöglich sogar AMD erst spät entschieden haben könnte, was hier kommt.

Womöglich bringt AMD doch einen nach N3P geschrinkten Zen5, weil Zen6 noch zu weit hin sein könnte und Zen5-N3P ein schnelles günstiges Upgrade vor allem für Server bieten könnte und man Zen5 in N3 für einen schnellen Nachfolger für Strix-Point - der dann auch RDNA4 enthielte - gut brauchen könnte, zumal Zen5c ja schon in N3 verfübar ist.

[stinki]

Die werden Medusa Point (oder wie auch immer er heißen mag) in N3P für 2026 bestimmt schon in der Entwicklung haben.
Mobile Zen5 gab es ja auch vor Desktop und Server Zen5. Warum sollten Mobile Zen6 und Desktop Zen6 nicht auch wieder parallel kommen.
N2 wird wahrscheinlich nur das 32c Zen6 Server Die in 2026.

Den einzigen Refresh den AMD momentan vorbereitet ist Bald Eagle Point als Strix Point Refresh und der ist sehr wahrscheinlich noch N4P.

[reaperrr]

Ich würde vermuten N3E dann 2026.
Eher N3P, der sollte bis dahin so weit sein.
Bzw. N2 für die Server-Zen6c-Chiplets.

Vor allem für Notebook braucht AMD alsbald einen Nachfolger für Strix-Point; und da sehe ich noch wenig Chancen, dass Zen6 in N3 Anfang 2026 verfügbar wäre...
Naja, was heißt "alsbald"... Panther Lake kommt erst Ende 2025, und Mitte 2026 für den Zen6 Strix-Nachfolger halte ich für möglich.

Das halbe Jahr kann man dann auch mit nem Mini-Refresh + Preissenkungen überbrücken.


Womöglich bringt AMD doch einen nach N3P geschrinkten Zen5, weil Zen6 noch zu weit hin sein könnte und Zen5-N3P ein schnelles günstiges Upgrade vor allem für Server bieten könnte
Unnötig, Intel ist im Serverbereich noch immer ziemlich weit hinten und so schnell würde ich für die gerade erst vorgestellten 6000er Xeons keine massiv besseren Nachfolger erwarten.

Für Desktop ebenfalls unnötig, man ist ja durch die ARL-Schwäche auch hier mit Zen5(X3D) gut aufgestellt.

Und dass man nur für den Zeitraum zwischen Panther Lake und Zen6 mal eben StrixP auf N3P shrinkt, sehe ich noch nicht.
Die Zen5-Kerne von Strix sind nicht identisch mit den Zen5c-Kernen der Server-Parts, man müsste quasi 2 weitere Kern-Varianten von N4 auf N3 portieren. Ziemlich viel Aufwand für ne Übergangs-Lösung.

Fazit: Ich rechne maximal mit nem leichten Refresh, ne neue Top-SKU mit 100 MHz mehr Turbo und Preissenkung für die anderen Modelle.
Wenn überhaupt...

[HOT]

Dass es ein weiteres 3nm CCD für Zen5 geben wird halte ich auch für sehr unwahrscheinlich. MMn wird es noch ein refresh von Strix-Point geben genannt Eagle Point weiterhin in N4P und Sonoma Valey in SF4X, damit dürfte dann Zen5 für AMD komplett abgehakt sein. Aber ich würde auch eher N2 sagen für Medusa, denn Su sagte bei irgendner Veranstaltung, dass Gate All Around ein großer Fortschritt für AMD sei.

https://cdn.mos.cms.futurecdn.net/jH85rnriCAdcgRsoKhyQME.jpg


Hier steht GAA schon bei 3nm, ich nehme an, dass man gerne MI350 in SF3P fertigen möchte bei Samsung. Mal sehen, ob das aufgeht. Oder diese Chips sind zu groß und es sind doch Medusa-CCDs für Mobil-CPUs oder sowas. Mit Zen6 endet mMn die Zeit der Einzel-APUs, alles was in der gen kommt ist CCD+IOD auch für Mobil.

Denkbar wäre z.B.
- 4+4c CCD Ende 2025 in SF3P
- 8+8c CCD Mitte 2026 in N2
- 32c CCD Mitte 2026 in N2

- MI350 -> N3P oder SF3P
- RDNA5-GCDs -> N3P oder SF3P

IODs und Base-Dies werden mMn alle N4c oder SF4X sein.

https://www.tomshardware.com/tech-industry/amd-to-use-samsungs-3nm-tech-as-it-looks-to-dual-source-future-chips-report

[Nightspider]

Samsung scheint so weit hinten zu sein bei Yields und Effizienz das es mich wundern würde, wenn in nächster Zeit überhaupt jemand wichtige Produkte bei Samsung fertigen lässt.

[Altehardware]

ja nvidia

[davidzo]

Ist nicht unbedingt schlecht. Wenn sie den Stromverbrauch der E-Kerne in den Griff bekommen dann passt das. :) Die E-Kerne sind bei Intel das eigentliche Problem grad. Sie fressen viel zu viel Strom für die Leistung, die sie bringen.
Das ist wohl nur im Desktop so weil man unsinnige Taktraten braucht um das Fehlen von SMT auszugleichen wodurch die CPUs sonst langsamer als der Vorgänger wären.

In Sierra forest takten die E-Cores mit 2,2Ghz und nem Turbo von 3,2Ghz bei weniger als 2,5Watt pro Core.
Das sind wohlgemerkt noch die alten Crestmont Coes. Da fehlen also +32% Integer IPC und die verdoppelte FPU (+68% bei LL).
Laut Computerbase ist der Verbrauch der Skymont E-Cores zwar um 9% gestiegen, das würde ich aber eher auf die angehobenen Taktraten zurückführen. Der Baseclock ist +800mhz höher (3,2 statt 2,4Ghz) und der Turbotakt um 200mhz (4,6 statt 4,4Ghz).
Wahrscheinlich verbrauchen die Skymont E-Cores trotz dass sie wesentlich größer sind bei gleichem Takt auch ca. gleichviel wie Crestmont.

Der performancegewinn von +32% Int und +68% FP ist damit quasi kostenlos. Das ist ein sehr ordentlicher IPC Gewinn und dürfte Skymont auf eine vergleichbare Effizienz und Leistung wie Zen4C hieven.

Als Cheese and Chips das Power scaling von Crestmont analysiert hat lag der sweetspot bei ca. 2Ghz bei 2,5Watt und damit ca. auf Zen2 Leistung und Effizienz.

Also während das angesichts der teuren N3 Fertigung nicht gerade berauschend ist, ist das schon eine solide Architektur mit konkurrenzfähiger Effizienz.


Hier steht GAA schon bei 3nm, ich nehme an, dass man gerne MI350 in SF3P fertigen möchte bei Samsung.

Ganz bestimmt nicht. Die AI Beschleuniger sind bis auf weiteres alle auf advanced Packaging bei TSMC angewiesen um mehrere DIEs und den HBM anzubinden. Samsung wäre da ein großer Rückschritt der AMD um Jahre hinter Nvidia zurückwerfen würde.
Dass die RDNA4 Bigchips gecancelt wurden ist ja ein klares Zeichen dass man die gebuchten Kapazitäten für3nm und advanced Packaging eben für die Mi-Chips nutzen will.

Ich würde mich freuen wenn Sonoma wirklich noch kommt. Das wäre zwar reichlich spät für eine Zen4c basierte APU, aber das würde zu Valve passen. Dazu würde sogar ein älterer Node wie 4LPX passen. Schon Aerith nutze erstmal freigewordene 7nm Kapazitäten während AMD schon auf 6nm und 5nm geschwenkt ist. SF3 ist als GAA Prozess eine viel zu riskante und teure Technik für einen Konsolenchip. Valve orientiert sich lieber an Nintendo was die Hardwareentwicklung angeht und nimmt das was bei AMD in der Entwicklung ohnehin abfällt und eine Fertigung die Opportun ist. Das ist imo auch eine veritable Strategie, denn wie man sieht ist VG trotz veralteter Kernarchitektur ein sehr effizienter Chip für die TDP. Das Power management war sehr ausgereift und die Chipkosten niedrig genug dass man lieber beim RAM in die vollen gehen konnte. Solchen Kompromisse sind gut.

[MSABK]

Jetzt nach dem 9800x3d habe ich das Gefühl Zen6 wird richtig abgehen.

[Der_Korken]

Die alte Folie von MLID hat für Zen 6 "nur" 10%+ IPC genannt, während sie mit 10-15% für Zen 5 relativ akkurat war (abseits von AVX512-Kirschen). Ich weiß nicht, ob sie nach Zen 4 nochmal so einen Stunt beim Takt hinbekommen. Die Taktraten von Lion Cove sehen mir jetzt nicht so danach aus, als würden wir bei Zen 6 ad große Sprünge erwarten können in 3nm. Wenn außerdem die Gerüchte stimmen, dass Desktop und Mobile als Plattform vereinigt werden sollen, würde ich noch weniger mit hohen Peak-Taktraten planen, da die mobilen Chips da zuletzt (aus Effizienzgründen) immer ein gutes Stück hinterherhinkten. Die bisherigen 5,7Ghz wären da fast schon ein "Zen-4-artiger" Sprung. Für Low-Power-Fans könnte es dagegen sehr nice werden.

[amdfanuwe]

Jetzt nach dem 9800x3d habe ich das Gefühl Zen6 wird richtig abgehen.
Erst mal abwarten, was da für Desktop bei rausspringt.

[reaperrr]

Die Taktraten von Lion Cove sehen mir jetzt nicht so danach aus, als würden wir bei Zen 6 ad große Sprünge erwarten können in 3nm.
Zen4-artiges vielleicht nicht ganz, nein.

Aber 3nm ist nicht 3nm.

Was Intel verwendet ist N3B. Das ist im Grunde nur ne bis zur Nutzbarkeit weiterentwickelte Variante des ersten N3-Prozesses, der so schlecht war, dass selbst Apple lieber erstmal N4 genommen hat.

Schon für N3E sind von TSMC bezüglich Perf/Effizienz etwas höhere Werte als für den Original-N3 genannt worden, halt auf Kosten etwas größerer Fläche (etwas weniger dichte Logik und Verzicht auf die kleineren SRAM-Zellen von N3B, dafür aber wohl bessere Ausbeute und eben Leistung/Effizienz).

N3P packt bei Perf/Effizienz nochmal ca. 5% auf N3E drauf.
Damit sollte der elektrische Vorteil von N3P ggü. N4P nicht weit von dem Vorteil weg sein, den N5P ggü. N7P hatte.

Außerdem: Intel ist von einem eigenen, stärker auf hohe Spannungen und Taktraten optimierten Prozess auf einen TSMC-Prozess gewechselt, der in erster Linie für Apple entwickelt wurde.
Dementsprechend dürfte (und danach sieht die Effizienzkurve von ARL auch aus) der Prozess mehr auf Taktraten unter 5 Ghz optimiert sein, nicht so stark auf Intels Bedürfnisse wie Intel 7.

Wenn außerdem die Gerüchte stimmen, dass Desktop und Mobile als Plattform vereinigt werden sollen, würde ich noch weniger mit hohen Peak-Taktraten planen, da die mobilen Chips da zuletzt (aus Effizienzgründen) immer ein gutes Stück hinterherhinkten.
Ich denke eher, dass man dann halt für beides Chiplets nimmt, die Kerne beherbergen, bei denen z.B. FullRate-AVX512 wieder rausgenommen wurde, um Fläche und Verbrauch zu reduzieren, wie jetzt bei den Strix-Kernen.

Die "normalen", nicht kompakten Consumer-Kerne werden jetzt nicht plötzlich weniger auf Takt optimiert sein als bei Zen5, zumal Takt immer noch eine der einfacheren Stellschrauben für Leistungszuwächse ist, gerade ST.

Die "P"-Kerne von Strix würden mit Desktop-TDPs und entsprechend hoch eingestellten maximalem Turbo auch auf ähnliche Taktraten wie bei 9700X & Co. kommen. Bloß mobile macht man's nicht, weil der Perf-Gewinn viel zu gering für die dafür nötigen Spannungs-Erhöhungen wäre.

[iamthebear]

Was bei N3 und N2 auch immer mehr zum Thema wird ist dass die Waferkosten mit jeder Generation ca. 50% steigen aber die Verbesserungen der Packdichte immer geringer werden:

N5 hat noch 1.7x für Logic und 1.3x für SRAM gebracht. Solange man den IO Die ausgelagert hat und nicht einen reinen Cache Die fabriziert hat war es also noch günstiger.
N3 hat 1.6x Density für Logic und nichts mehr für SRAM. Da werden Compute Dies maximal den Preis halten wenn nicht sogar teurer.
N2 soll nur mehr 1.15x für Logic und glaube um die 1.1x für SRAM bringen also so wie von N7 auf N6. Damit werden die dies teurer. Man hat also bei gleichen Kosten weniger Transistorbudget zur Verfügung und muss Performancesteigerungen über den Takt holen und aif Margen verzichten oder dem Endkunden drauf schlagen. Bei Datacenter klappt das vielleicht noch bei besserer Energieeffizienz. Bei Client und besonders GPU wird das schwierig.

[davidzo]

Die alte Folie von MLID hat für Zen 6 "nur" 10%+ IPC genannt, während sie mit 10-15% für Zen 5 relativ akkurat war (abseits von AVX512-Kirschen). Ich weiß nicht, ob sie nach Zen 4 nochmal so einen Stunt beim Takt hinbekommen. Die Taktraten von Lion Cove sehen mir jetzt nicht so danach aus, als würden wir bei Zen 6 ad große Sprünge erwarten können in 3nm. Wenn außerdem die Gerüchte stimmen, dass Desktop und Mobile als Plattform vereinigt werden sollen, würde ich noch weniger mit hohen Peak-Taktraten planen, da die mobilen Chips da zuletzt (aus Effizienzgründen) immer ein gutes Stück hinterherhinkten. Die bisherigen 5,7Ghz wären da fast schon ein "Zen-4-artiger" Sprung. Für Low-Power-Fans könnte es dagegen sehr nice werden.

All diese Aussagen zu Zen5 und Zen6 sind ja von Leuten wie Mike Clark, also CPU Architekten gemacht worden. Die beschäftigen sich eher mit High level design und höchstens noch bis HDL/verilog, lange bevor die physische Planung beginnt, mit der sie dann eher wenig zutun haben.
Fortschritte bei der Fertigung, packaging etc. sind nicht so deren Ding. Das ist quasi wie Back end of Line oder packaging für eine Chipfabrik - nichtmal in derselben Fab.

Mike Clark hat mehrfach zu Zen2 und Zen3 gesagt dass er von Zen3 viel mehr erwartet weil es ein groundup redesign wäre. Nun war zen3 zwar ein großer Schritt, aber für den Consumer nicht so relevant wie der Schritt von Zen1 auf Zen2.
- Zen2 hat erstmals die 8-Kern Chiplet + IO-DIE Architektur gebracht.
- Zen2 kam erstmals in einer überlegenen Fertigung gegenüber Intel
- Zen2 hat die Effizienz massiv gesteigert.
- Zen2 hatte eine doppelt so breite FPU, was AMD von leicht unterlegen in FP workloads zu überlegen gegenüber Intel katapultiert hat. Zen3 hat im wesentlichen dieselbe FPU.
- Zen2 hat den höheren IPC gewinn: 22% auf Zen1 bzw 16% auf Zen+. Zen3 hat gegenüber Zen2 nur 11% IPC Zuwachs (alle Werte von CB).
Demgegenüber hat Zen3 höchstens X3D als größte Neuerung vorzuweisen, was aber mit Clark weniger zutun hatte und auch erst 2 Jahre später gelauncht wurde als Zen3 schon in der Ablöse stand.

Trotzdem ist in Mike clarks Augen Zen3 die wichtigere Architektur, der größere Wurf. Einfach weil die da ein großes refactoring vorgenommen hatten dass ihnen dann auch für Zen4 und 5 die Grundlage geschaffen hat.
Dasselbe gilt für Zen4, welcher von den Ingenieuren nicht besonders gepriesen wurde, aber durch die enormen Taktgewinne nachträglich eine der besten neuen Architekturlaunches der jüngeren Jahre war. Zen5 wäre das große Redesign, da würde man drauf hinarbeiten, nicht Zen4.

Gerade wenn man weniger von Zen5 redesignt sehe ich sehr gute Chancen für größere IPC gewinne bei Zen6. Gerade wenn eine neue Fertigung ansteht ist die Chance für größere Taktgewinne am größten.
Zen5 ist eine starke Verbreiterung des Designs gewesen und die geringen IPC Gewinne bedeuten ja geradezu dass es da noch jede Menge ungehobenes Potential gibt und noch ein paar Handbremsen gelöst werden können.

Wenn AMD dazu auch noch das IFOP angeht und durch etwas moderneres wie 2.5D oder gar 3D ersetzt, dann muss man von mir aus überhaupt nichts an den Kernen machen und es wird trotzdem eine gute Generation für Spieler.

Stellt euch vor das 16Kern CCD ist zwar nicht größer als bisher, aber enthält eben keinen L3 Cache, nur die Kerne, die etwas mehr privaten L2 haben. Der Cache steckt stattdessen im io DIE das in 4/5nm gefertigt wird und auch viel sparsamer ist als bisher. Das io DIE hat genau die Größe von 2x CCDs nebeneinander, welche huckepack per 3d packaging darauf montiert werden. Damit würde man die Latenz zwischen CCD und IO-DIE deutlich reduzieren können, der Energieverbrauch der IFOP Verbindung würde wegfallen. Wenn der memorycontroller viel näher an den Cores liegt per advanced packaging hätte das auch die Chance auf deutlich bessere Speicherlatenzen, was sich direkt in höherer IPC in Games niederschlägt.



Was Intel verwendet ist N3B. Intel ist von einem eigenen, stärker auf hohe Spannungen und Taktraten optimierten Prozess auf einen TSMC-Prozess gewechselt, der in erster Linie für Apple entwickelt wurde.
Dementsprechend dürfte (und danach sieht die Effizienzkurve von ARL auch aus) der Prozess mehr auf Taktraten unter 5 Ghz optimiert sein, nicht so stark auf Intels Bedürfnisse wie Intel 7.

Intel musste N3B nehmen, da der Entwicklungszyklus so lange war dass N3E einfach noch nicht zur Verfügung stand. Es ist nicht dass Apple die N3B Produktionsstraßen einfach verlassen hat und neue, andere Produktionsanlagen für N3E benutzt. Die Scanner sind dieselben und TSMC könnte die LnL und ARL Produktionsstraßen mit nur minimalen Anpassungen auch für N3E nutzen, nur hat Intel eben noch mit dem N3B PDK designt weil sie für N3E zu früh angefangen haben.

Man darf nicht vergessen dass Intels Entwicklungsstrategie bisher anders aussah, nämlich durch jede Menge frühe Testchips geprägt, die bei der inhouse foundry halt kostenlos waren. So einen Entwicklungsprozess kippt man nicht eben. Wenn man also früh anfängt extern Chips zu bestellen muss man das PDK nehmen was dann zur Verfügung steht und nicht jenes welches zum Chip Launch Zeitfenster passt. Intel ist halt auch nur eine Behörde.

[fondness]

Zen6 angeblich weiter im AM5 Sockel
https://wccftech.com/amd-zen-6-ryzen-medusa-desktop-cpus-am5-compatible-late-2026-early-2027-launch/

[dargo]

Ist es schon bestätigt, dass Zen6 endlich mit mehr als 8 Cores in einem Chiplet kommt? Diese max. 8 Cores je Chiplet werden langsam langweilig. :cool:

[fondness]

Bestätigen wird AMD wohl gar nichts vor dem Launch. Aber alle Gerüchte sagen das ja.

[amdfanuwe]

Stellt euch vor das 16Kern CCD ist zwar nicht größer als bisher, aber enthält eben keinen L3 Cache, nur die Kerne, die etwas mehr privaten L2 haben. Der Cache steckt stattdessen im io DIE das in 4/5nm gefertigt wird und auch viel sparsamer ist als bisher. Das io DIE hat genau die Größe von 2x CCDs nebeneinander, welche huckepack per 3d packaging darauf montiert werden.
Also einen 32 Core Prozessor mit Cache im IO.
Wieviel Cache soll da im IO sein?
Wieviel wird der IO durch den Cache größer?
Wie sehen dann die X3D Varianten mit viel Cache aus?
Bei welchem Takt rennen denn die 32 Cores im Desktop bei gegebener TDP?
Bringen die dann überhaupt noch mehr MT Leistung als z.B. ein 24 Core Prozessor?
Wieviel kostet das Stacking, auch wenn der Yield mittlerweile >90% für X3D sein soll, verursacht es höhere Kosten.
Wie sollen die Chiplets im Server verwendet werden? 12 CCD auf dem IO mit Cache? OK, könnte dann wie MI300 aufgebaut sein mit 4 gekoppelten IO.

Im Desktop seh ich solch einen Chip nicht. Eher schon als APU mit einem 16 Core Chiplet und einem GPU Chiplet, Cache im IO Die. So eine Art Strix Halo Nachfolger. Könnte auch im Desktop bei bis dahin schnellerem RAM eine gute Figur für FHD Gaming machen.

[memory_stick]

26Q4/27Q1: ist nur mir so oder wäre das deutlich später als erwartet? Wäre ja auch 6Q nach Zen5, was mind. 1Y länger als zen4->zen5 wäre..

[amdfanuwe]

ZEN2 7. Juli 2019
ZEN3 5. November 2020 +16 Monate
ZEN4 27. September 2022 +22 Monate
ZEN5 15. August 2024 +23 Monate ( geplant Juli, wären +22 Monate gewesen)
ZEN6 +22 Monate -> Mai 26 ???

Q4/26 erscheint mir da auch ziemlich spät.

[HOT]

Lt. MLID-Quellen soll es ein teilweises Neudesign gegeben haben, was die Sache verzögert. Ich rechne auch mit Q4 26.

[Badesalz]

Ich rechne sogar mit kleinen Verzögerungen. Klar läuft das parallel, aber diesmal muss man die CCDs mit einem redisgn des IOD verheiraten. Was übrigens auch real neue Chipsätze bringt.

Das ist imho schon eine größere Baustelle als bisher.

[Altehardware]

Das redesign kommt erst mit zen7
zen6 ist lediglich ein shrink auf n3 und einen neuen i/o Die auf n4 node
zen7 wird einiges ändern insbesondere cowos apu.
mehr kerne bringe nix als gamer Takt ist hier der Schlüssel mehr cache hilft bei den Latenzproblemen beim ram
zen5 hat schon viel geändert da wird amd das nicht in ner neuen Aufguss auf nenn neuen node ändern.

[Zossel]

Das redesign kommt erst mit zen7
zen6 ist lediglich ein shrink auf n3 und einen neuen i/o Die auf n4 node
zen7 wird einiges ändern insbesondere cowos apu.
mehr kerne bringe nix als gamer Takt ist hier der Schlüssel mehr cache hilft bei den Latenzproblemen beim ram
zen5 hat schon viel geändert da wird amd das nicht in ner neuen Aufguss auf nenn neuen node ändern.

Was du so alles meinst zu wissen.

[The_Invisible]

Ist es schon bestätigt, dass Zen6 endlich mit mehr als 8 Cores in einem Chiplet kommt? Diese max. 8 Cores je Chiplet werden langsam langweilig. :cool:

Ja schön wärs. 16C, verbesserte IPC, 6Ghz Boost und 128Mb Cache und man hätte die "Endgame" CPU... Aber gut, das sagt man immer :D

[Platos]

Bestätigen wird AMD wohl gar nichts vor dem Launch. Aber alle Gerüchte sagen das ja.

Es geht aber immer nur um Zen6 und nicht zwingend um Desktop-CPUs. Es soll CCDs mit 8, 16 und 32 Cores geben. Es kann also gut sein, dass 32 Cores pro CCD für Epyc kommen, 16 für Threadripper und weiterhin 8 pro CCD für Desktop.

Oder aber sie gehen den weg, dass sie weiterhin nur 16 Kerne am Desktop anbieten, diese aber mit 2 verschiedenen CCDs machen. Also nicht mehr den 16- und 12-Kerner mit 2 8Kern CCDs, sondern 16- und 12-Kerner mit dem 16 Kern CCD und alles ab dem 8-Kerner abwärts mit dem 8-Kern CCD. Das 32-er CCD bleibt dann exklusiv für Epic und vlt. noch Threadripper.

Ich hoffe zwar auch auf mehr Kerne fürs gleiche Geld, aber nur weils mehr Kerne gibt für ganz Zen6, heisst das noch lange nicht, dass es auch bei Desktop-CPUs so sein wird.

[Badesalz]

An den Threads im Desktop wird sich bis mind. Zen7 imho garantiert nichts ändern. Eher knipsen sie SMT aus und es gibt 16c/16t.

@altehardware
ähh... Nein :rolleyes:

[iamthebear]

Ist es schon bestätigt, dass Zen6 endlich mit mehr als 8 Cores in einem Chiplet kommt? Diese max. 8 Cores je Chiplet werden langsam langweilig. :cool:

Aktuelle Gerüchtelage ist:
Zen6c: 32 Kerne (unklar ob 1 oder 2 CCX pro CCD)
Zen6 Datacenter: 16 Kerne (vermutlixh 1 CCX)
Zen6 Desktop: 8 Kerne

Also sorry. Solange Intel nichts liefert gibt es 8 Kerne forever.

[rentex]

Hm, früher war es andersrum...

[MSABK]

Ich denke die nächsten KonsolenGen wird uns zeigen ob es bei 8 Kernen bliebt oder nicht.

[basix]

Aktuelle Gerüchtelage ist:
Zen6c: 32 Kerne (unklar ob 1 oder 2 CCX pro CCD)
Zen6 Datacenter: 16 Kerne (vermutlich 1 CCX)
Zen6 Desktop: 8 Kerne

32C sollte ebenfalls 1 CCX sein, zumindest laut Gerüchten.

Cool wäre ja, wenn das 16C CCD ebenfalls bei Desktop aufschlägt. Also egal ob 8 oder 16 Kerne, man bekommt immer ein Single CCD. Hätte den Vorteil, dass sich 12C/16C in z.B. Spielen von den 8C absetzen können, da man den doppelten L3$ bekommen würde.

Also sorry. Solange Intel nichts liefert gibt es 8 Kerne forever.
Es ist schon erstaunlich, wie lange es nun 8C bei Zen gibt. Und bereits seit Zen 2 gibt es 12/16C CPUs aber die sind bisher nur Nische geblieben.

Ich habe so irgendwie das Bauchgefühl, dass bei Zen 6 (wenn single 16C CCD) mehr Leute zu 12/16C greifen werden und falls 3D-Stacking dazu kommt (L3$ komplett wird aus dem CCD gelöst und in ein Base Die verfrachtet) werden 8C irgendwann mal einfach zu klein sein, um gut kühlbar zu sein. 100W auf 50mm2 ist wohl so das Limit, wo man noch einigermassen kühlen kann. Und ich sehe nicht, wie 8C 50mm2 ausfüllen sollen. Ein Apple M4 Core ist <3mm2 in N3E und wir reden hier von einem N2P oder so Core für Zen 7.

Ich denke die nächsten KonsolenGen wird uns zeigen ob es bei 8 Kernen bliebt oder nicht.
Dürfte schon mehr werden. 12C oder 16C. Davon werden aber viele wohl Zen 6c sein, z.B. 4 höher taktende Kerne und 8 etwas langsamere "c" Cores

[Savay]

Also sorry. Solange Intel nichts liefert gibt es 8 Kerne forever.

Intel liefert doch schon lange mehr Kerne!
24 statt 16.
Und auch sonst hat mittlerweile jedes Gegenstück von Intel mehr Kerne als der jeweilige AMD.

Der Grund warum wir hier etwas stagnieren dürfte eher etwas anderer sein und nennt sich wohl eher "Consumer Software"...

[iamthebear]

Es ist schon erstaunlich, wie lange es nun 8C bei Zen gibt. Und bereits seit Zen 2 gibt es 12/16C CPUs aber die sind bisher nur Nische geblieben.

Zen2 war noch ein Quad Core CCX. Ab Zen3 gab es 8 Kerne. Ob man die 2 CCX nun auf 1 oder 2 CCDs verteilt ist performancetechnisch egal da die Kommunikation sowieso über den IOD läuft. Das sieht man gut bei den C2C Latenzen des 3950X.

Ich habe so irgendwie das Bauchgefühl, dass bei Zen 6 (wenn single 16C CCD) mehr Leute zu 12/16C greifen werden und falls 3D-Stacking dazu kommt (L3$ komplett wird aus dem CCD gelöst und in ein Base Die verfrachtet) werden 8C irgendwann mal einfach zu klein sein, um gut kühlbar zu sein. 100W auf 50mm2 ist wohl so das Limit, wo man noch einigermassen kühlen kann. Und ich sehe nicht, wie 8C 50mm2 ausfüllen sollen. Ein Apple M4 Core ist <3mm2 in N3E und wir reden hier von einem N2P oder so Core für Zen 7.

Den L3 in den IOD zu verfrachten würde die L3 Latenzen massiv ansteigen lassen und man bräuchte einen wesentlich schnelleren Interconnect als die aktuellen IF Links. Und das Problem der C2C Latenzen zwischen 2 CCDs löst man damit auch nicht.
Was die Kühlung angeht: Ich denke nicht, dass die CCDs dabei deutlich kleiner werden. Man wird eher den Zen5 Weg gehen dass man den gewonnenen Platz durch den kompajteren L3 nutzt um mehr Transistoren in die Kerne zu investieren.
Oder im Fall eines 16 Kern CCDs: Den Scheduler einfach erstmal nur jeden 2. Kern nutzen. Und wenn wirklich Volllast auf allen 16 Kernen anliegt dann muss man den Takt eben minimal senken.

Was man bei Zen6 in N3 überlegen könnte:
16 Kern CCX mit 32MB L3 im Base Die
128MB im darunter liegenden N6 Cache Die.

Was hier lediglich eine Challenge sein könnte ist dass AMD die C2C Latenzen auf dem aktuell sehr niedrigen Niveau halten kann ohne dass die Verlustleistung durch die Decke geht. Das Problem hat Intel immer noch nicht gelöst: 8 Ring Stops sind OK, 10 gehen auch noch, 12 sind schon kritisch und alles darüber nicht mehr sinnvoll.

Dürfte schon mehr werden. 12C oder 16C. Davon werden aber viele wohl Zen 6c sein, z.B. 4 höher taktende Kerne und 8 etwas langsamere "c" Cores[/QUOTE]

Intel liefert doch schon lange mehr Kerne!
24 statt 16.
Und auch sonst hat mittlerweile jedes Gegenstück von Intel mehr Kerne als der jeweilige AMD.

Der Grund warum wir hier etwas stagnieren dürfte eher etwas anderer sein und nennt sich wohl eher "Consumer Software"...

Aber bisher waren das alles sehr langsame E Cores die niemand so richtig nutzen wollte und ARL ist unbrauchbar für Gaming.

[basix]

Was man bei Zen6 in N3 überlegen könnte:
16 Kern CCX mit 32MB L3 im Base Die
128MB im darunter liegenden N6 Cache Die.
Genau sowas meine ich ja (allerdings erst bei Zen 7, Zen 6 erwarte ich noch als monolithische 8C / 16C Die ohne Stacking):
- 16C = Single CCX, sonst haben wir nicht viel Vorteile davon
- 64MByte L3$ Cache wird gestacked, wie jetzt der V-Cache unter die Cores -> Cache kommt nicht ins IOD
- Im Falle von V-Cache wäre es dann ein 3er Stack (Base Die mit "IFOP" und L3$ und Deep Trench Capacitors für Power Supply Decoupling // V-Cache Die // Top Die mit Cores)

Ich glaube aber nicht, dass man Zen 6 & 6c im selben CCD / CCX mischt. Die CCD-Chiplets sind primär für Server konzipiert. Bei Mobile SoCs sieht es etwas anders aus. Und bei Desktop würde man nur noch 1x Chiplet verbauen. Bei 8C das 8C Chiplet und bei 16C das 16C Chiplet.

[iamthebear]

Um ehrlich zu sein: Die c Kerne überzeugen mich bei AMD überhaupt nicht.

1.55x mehr Density bei 1.35x niedrigerem Takt gibt (bei perfekter MT Skalierung) lediglich 1.15x Performance/mm².

Zum Vergleich: Skymont bringt 3x Density im Vergleich zu Lion Cove and hat bei Performance/Kern auch nicht weoiter zurück. Das sind >2x Performance/mm².

[Achill]

Um ehrlich zu sein: Die c Kerne überzeugen mich bei AMD überhaupt nicht.

1.55x mehr Density bei 1.35x niedrigerem Takt gibt (bei perfekter MT Skalierung) lediglich 1.15x Performance/mm².

Zum Vergleich: Skymont bringt 3x Density im Vergleich zu Lion Cove and hat bei Performance/Kern auch nicht weoiter zurück. Das sind >2x Performance/mm².

Keine Ahnung was das für eine Rechnung sein soll? Sieht eher so aus als ob irgend etwas miteinander Multipliziert wird um eine höhere Zahl für Intel CPUs zu erreichen ... im Zen6 Speku Thread.

[Der_Korken]

Um ehrlich zu sein: Die c Kerne überzeugen mich bei AMD überhaupt nicht.

1.55x mehr Density bei 1.35x niedrigerem Takt gibt (bei perfekter MT Skalierung) lediglich 1.15x Performance/mm².

Zum Vergleich: Skymont bringt 3x Density im Vergleich zu Lion Cove and hat bei Performance/Kern auch nicht weoiter zurück. Das sind >2x Performance/mm².

Wenn man einen super ineffizienten Kern hat wie Intel, ist es natürlich leicht da große Verbesserungen gegenüber zu erzielen. Da kann AMD aber nichts für.

[davidzo]

Um ehrlich zu sein: Die c Kerne überzeugen mich bei AMD überhaupt nicht.

1.55x mehr Density bei 1.35x niedrigerem Takt gibt (bei perfekter MT Skalierung) lediglich 1.15x Performance/mm².

Zum Vergleich: Skymont bringt 3x Density im Vergleich zu Lion Cove and hat bei Performance/Kern auch nicht weiter zurück. Das sind >2x Performance/mm².

Bisschen schlechter Vergleich, weil das nichts über die absolute Größe aussagt.
Das kann genauso gut bedeuten dass Lion Cove einfach eine beschissene PPA hat verglichen zu Zen5.

Hier mal ein paar Fakten zur PPA:
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=90127&stc=1&d=1731167253

Fertigungsnormalisiert ist Zen5C ca. 1/3 größer als Skymont (TurinDense 2,94mm2, Arrowlake 1,92mm2), liefert aber +20% mehr Floatingpoint IPC und +30% mehr MT IPC dank SMT. Taktraten und Verbrauch sind anscheinend vergleichbar.

Mit den Mont Cores hat Intel zwar gleichgezogen bei der PPA mit AMD Dense, aber eben auf einem allgemein niedrigeren Leistungsniveau als Zen5. Und wie wir wissen steig die Leistung nicht Linear mit mehr Transistoren, sondern logarithmisch. Intel hat also noch viel zutun.


Btw, Skymont zeigt erst wie beschissen Lion Cove bei der PPA wirklich ist. Trotz N3B ist Lioncove 5.6mm2 groß in ARL. Raptorcove in Intel 10nm war 7mm2 groß, mehr als 2x M1 Kerne in 5nm oder 2x M4 kerne in N3E. Das ist entweder katastrophale Skalierung für zwei Fullnode Sprünge zu erheblich höheren Kosten oder Lion Cove schluckt einfach so massiv viel mehr Transistoren.

Zen5 ist mit 4.8mm2 zwar auch nicht gerade klein, gerade wenn man bedenkt das Apples Performance-Cores seit Jahren immer um die 3mm2 Kreisen, aber Zen5 kommt eben auch mit der verhältnismäßig günstigen N4P Fertigung aus.

Intels L3 Cache Design und Ringbus sind außerdem Trash. 36MB + Ringbus sind trotz N3B ca. doppelt so groß wie AMDs 32MB L3 + intra CCD Ringbus in N4P, trotz dass die AMD Lösung wesentlich bessere Latenzen bietet.

Btw, AMDs Cache density hat bei Zen5 einen großen Sprung gemacht und ist nun gar nicht so weit hinter Apple. Der 16MB shared P-Core L2 Cache vom A18pro ist 5.8mm groß in N3E. AMDs 16MB L3 in Strix sind 9.5mm2.

[latiose88]

also ich habe auch gelesen das der IO DIe bei Zen 6 so bleiben wird.Darum erwarte ich auch keine riesen Sprünge. Wobei ich mir echt wünsche würde,das es mehr Kerne werden.Ich denke mal das Zen 6 nur noch breiter sein wird als eh schon.Ob das dann was bringen wird,nicht bei jeder Anwendung.Nun ja mal sehen was so kommt.
Das mit den C CPU nutzt mir jedenfalls nix.Hat weniger L3 Cache und weniger Allcore Takt.Das mag meine Anwendung überhaupt nicht und fällt dann bei der Leistung zusammen.
Darauf kann ich echt verzichten.Ich brauche halt die Leistung.Also lieber was anderes als die C Kern CPUS in betracht ziehen.Die Aktuellen C Kerne,fallen hinter einem 8 Kerner zurück.Da nehme ich bevor ich die mit C kerne nehme,lieber 8 Vollwertige Kerne.

[Badesalz]

Der Grund warum wir hier etwas stagnieren dürfte eher etwas anderer sein und nennt sich wohl eher "Consumer Software"...Das kannst du 5x pro Seite schreiben, die sehen das nicht :ulol:

[Atma]

also ich habe auch gelesen das der IO DIe bei Zen 6 so bleiben wird.
Kann ich mir nicht vorstellen. Wie Zen 5 X3D eindrucksvoll gezeigt hat, limitiert der I/O Die schon jetzt vorne und hinten sobald kein extra Cache vorhanden ist.

[KarlKastor]

Das sieht man schon seit Zen3 x3d. Ist halt die Frage was wirtschaftlich am meisten Sinn macht.

[basix]

also ich habe auch gelesen das der IO DIe bei Zen 6 so bleiben wird.Darum erwarte ich auch keine riesen Sprünge.

Eine dritte CPU-Generation mit dem selben IOD würde die CPU zurückbinden. Gibt einige Dinge, die man updaten könnte. Benutzt würde das neue IOD mit Zen 6 und Zen 7.

Ich vermute, Zen 6 wird AM5+ einläuten:
- Neuer Chipsatz, evtl. in N6 oder etwas ähnlichem von Samsung (USB4, WiFi 7, 10GbE, PCIe 5.0 Uplink zur CPU)
- Neues IOD in N4C (stärkere iGPU, NPU, USB4, x32 Lanes PCIe 5.0, DP 2.1, 2.5D Anbindung des CCDs via "Infinity Fanout Links" mässiger Technologie)

[iamthebear]

Der Grund warum wir hier etwas stagnieren dürfte eher etwas anderer sein und nennt sich wohl eher "Consumer Software"...

Zum Teil ja. Wird werden kein Spiel sehen, das so läuft wie Cinebench aber teilweise ist es auch einfach ein Henne Ei Problem. Solange es nur 8 Kerne gibt wird sich auch niemand die Arbeit machen Auf > 8 Kerne zu optimieren bzw. ist niemand bereit Performance von 6 Core CPUs dafür zu opfern damit ein Spiel besser auf 16 Kernen läuft. Erst müssen 12-16 Kerne Mainstream werden bevor Spiele mitziehen.

Das kann genauso gut bedeuten dass Lion Cove einfach eine beschissene PPA hat verglichen zu Zen5.

Das mag sicher so sein, ändert aber nichts daran, dass es nicht viel Sinn macht diese im Desktop einzusetzen wenn sie in keinem Bereich deutliche Vorteile gegenüber dem P Core haben.

Fertigungsnormalisiert ist Zen5C ca. 1/3 größer als Skymont (TurinDense 2,94mm2, Arrowlake 1,92mm2), liefert aber +20% mehr Floatingpoint IPC und +30% mehr MT IPC dank SMT. Taktraten und Verbrauch sind anscheinend vergleichbar.

Skymont hat in ARL-H 4.5 GHz Boosttakt. Zen5c in Strix Point hat 3.3GHz. Das sind 36% Unterschied.

[davidzo]

Skymont hat in ARL-H 4.5 GHz Boosttakt. Zen5c in Strix Point hat 3.3GHz. Das sind 36% Unterschied.

Die 4,5Ghz sind in einer MobilCPU aber auch sehr theoretisch. In der Praxis takten beide in einem typischen Labtopchassis bei identischer 35-45Watt sustained TDP sehr ähnlich. E-Kerne sind bei ARL und Strix eh für MT workloads da, nicht für burst workloads, wozu also ein paar Millisekunden 4,5Ghz wenn man das nicht sustainen kann? Bei 4,5Ghz säuft Skymont viel zu viel, in einem Mobilsoc will man eigentlich dass die mit 2 bis 3Ghz laufen (2W pro Core sweetspot).

[Ramius]

[QUOTE=iamthebear;13647387]Zum Teil ja. Wird werden kein Spiel sehen, das so läuft wie Cinebench aber teilweise ist es auch einfach ein Henne Ei Problem. Solange es nur 8 Kerne gibt wird sich auch niemand die Arbeit machen Auf > 8 Kerne zu optimieren bzw. ist niemand bereit Performance von 6 Core CPUs dafür zu opfern damit ein Spiel besser auf 16 Kernen läuft. Erst müssen 12-16 Kerne Mainstream werden bevor Spiele mitziehen.

So ein Quark.
Eine Software sollte immer alle zur Verfügung stehenden Prozessoren einer CPU nutzen. Andernfalls ist diese schlecht programmiert und sollte den Programmierern um die Ohren gehauen werden.

[Badesalz]

@Ramius
:uup: :biggrin: :rolleyes:

Zum Teil ja. Wird werden kein Spiel sehen, das so läuft wie Cinebench aber teilweise ist es auch einfach ein Henne Ei Problem. Solange es nur 8 Kerne gibt wird sich auch niemand die Arbeit machen Auf > 8 Kerne zu optimieren bzw. ist niemand bereit Performance von 6 Core CPUs dafür zu opfern damit ein Spiel besser auf 16 Kernen läuft. Erst müssen 12-16 Kerne Mainstream werden bevor Spiele mitziehen.
Da es >16 Threads für Mainstream seit mind. 7 Jahren gibt weiß ich nicht wie ich das obige deuten soll.

Was hier über Bande postuliert wird ist wahrscheinlich, daß man die Preise in etwa halbiert und damit >16 Threads finanziell für den Mainstream erreichbar werden. Ist das richtig? Wie realistisch ist diese Idee?

Savay bleibt im Recht. Software verkauft Hardware. Crysis-Effekt. Nicht, es müssen erst genug Leute >16 Threads haben damit die Softwarebuden etws tun. Völlig blauäugig :freak:

Wo es geht, gehts. Selbst 1-Mann-Projekte können gut 32 Threads verwerten. Wo es ziemlich kompliziert wird lassen es auch Softwarekonzerne sein. Deswegen gibt es eben V-Cache für 16 Threads statt 4fach SMT.
Kommt damit klar.

Proof-of-concept für Obiges wird von AMD nächstes Jahr gestartet :up: Die mit 24 Threads werden wohl nicht langsamer beim Zocken als die mit 16 Threads. Eine Hemmschwelle weniger. Mal sehen wie die sich verbreiten... :rolleyes:

[basix]

Hier mal ein paar Fakten zur PPA:
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=90127&stc=1&d=1731167253

Fertigungsnormalisiert ist Zen5C ca. 1/3 größer als Skymont (TurinDense 2,94mm2, Arrowlake 1,92mm2), liefert aber +20% mehr Floatingpoint IPC und +30% mehr MT IPC dank SMT. Taktraten und Verbrauch sind anscheinend vergleichbar.
Skymont ist 1/3 kleiner oder Zen 5c ist 1.5x grösser würde stimmen ;)

Wenn die Grafik vom 16C Zen 5c Chiplet die Grössenverhältnisse richtig wiedergibt (nicht garantiert), dann sieh man zumindest einen kleinen Vorteil von N3E gegenüber von N4P. Der Core auf dem Server-Chiplet ist 5% kleiner doch kommt mit der kompletten FPU daher. Die FPU von Zen 5c bei Strix Point macht ca. 20% des Cores aus (inkl. L2) und 30% der Logikfläche (ohne L2). Das "normalisierte" Flächenverhältnis mit kompletter FPU wäre dann ca. 0.8x auf den ganzen Core gesehen oder ca. 0.7x auf den Core ohne L2$. N3E bringt 1.7x Logikdichte mit, was in Realität bei einem Chip nicht erreicht wird. Die ca. 1.4...1.5x höhere Dichte beim Core (0.7x Fläche) scheint mMn nicht schlecht zu passen.


Btw, AMDs Cache density hat bei Zen5 einen großen Sprung gemacht und ist nun gar nicht so weit hinter Apple. Der 16MB shared P-Core L2 Cache vom A18pro ist 5.8mm groß in N3E. AMDs 16MB L3 in Strix sind 9.5mm2.
Hmm, interessant dass Apples L2$ so kompakt ist. An den Cache Zellen kann es ja nicht liegen. Mit N3E wird die Cache-Logik zwischen den Zellen kompakter, aber das macht vielleicht 1.1...1.2x aus und nicht 1.6x. Und die ca. 5ns Latenz bei Apples L2 ist auch nicht von schlechten Eltern.

[Twodee]

Hmm, interessant dass Apples L2$ so kompakt ist. An den Cache Zellen kann es ja nicht liegen. Mit N3E wird die Cache-Logik zwischen den Zellen kompakter, aber das macht vielleicht 1.1...1.2x aus und nicht 1.6x. Und die ca. 5ns Latenz bei Apples L2 ist auch nicht von schlechten Eltern.
Doppelt so hoch - verglichen mit Zen4/5 - ist nicht von schlechten Eltern?

[dildo4u]

Keine Zen6 Laptops bis 2027?


https://wccftech.com/amd-mobile-cpu-gpu-2025-2026-update-ryzen-apu-refreshes-strix-halo-fire-range-krackan-radeon-rx-8000-series/

[Der_Korken]

Doppelt so hoch - verglichen mit Zen4/5 - ist nicht von schlechten Eltern?

Für die 16-fache Größe (und vierfache Zahl an Teilnehmern) durchaus ...

[basix]

Doppelt so hoch - verglichen mit Zen4/5 - ist nicht von schlechten Eltern?

16MByte anstatt 1MByte. Bei AMD ist das L3$ Niveau mit ~10ns Latenz. Zudem ist Apples L2-Cache bis 4MByte nochmals schneller als 5ns, so im Bereich 3...3.5ns rum.

[davidzo]

Skymont ist 1/3 kleiner oder Zen 5c ist 1.5x grösser würde stimmen ;)

Danke.


Wenn die Grafik vom 16C Zen 5c Chiplet die Grössenverhältnisse richtig wiedergibt (nicht garantiert),
Den habe ich nur anhand des package skaliert, nicht der DIEs. Die anderen Dies alle nach den bekannten Daten.1-3% Abweichung sind vielleicht möglich, aber ich denke das ist relativ genau.
Ich habe die Apple Chips in der gleichen Datei.


Hmm, interessant dass Apples L2$ so kompakt ist. An den Cache Zellen kann es ja nicht liegen. Mit N3E wird die Cache-Logik zwischen den Zellen kompakter, aber das macht vielleicht 1.1...1.2x aus und nicht 1.6x. Und die ca. 5ns Latenz bei Apples L2 ist auch nicht von schlechten Eltern.

Vielleicht nimmt Apple 6T und AMD 9T?
Btw, war das nicht so dass der Apple Cache auch wesentlich geringere Assoziativität hat?


Doppelt so hoch - verglichen mit Zen4/5 - ist nicht von schlechten Eltern?
Du kennst anscheinend die Apple Architektur nicht. Der L2 ist dort der L3.
Apples CPUs haben nur einen privaten Cache level, den zweiten hat man ausgelassen weil es einfach massiv viel L1 und OoO Ressourcen gibt. Die 16MB L2 sind ein shared quasi last level Cache, genau wie die 16MB L3 bei Strix Point. Last level stimmt nicht ganz weil es auch den SLC gibt, aber der ist eher für die GPU gedacht.
Btw, der A18pro hat doppelt soviel L2 pro Core wie Zen5 L3 pro Core hat. Für diese Größenordnung ist 5ns schon raketenschnell.

[Der_Korken]

Ein Vorteil von Apple dürfte erneut die größere Pagesize sein. Der L1TLB hat bei Zen 5 jetzt 96 Einträge, d.h. bei 4kB Pagesize können dort im best case 384kB physischer Speicherbereich abgedeckt werden. Das heißt aber, dass bei einem L2-Zugriff in der Mehrheit der Fälle der L2TLB durchlaufen werden muss, welcher mal eben 7 Zyklen kostet. Insgesamt sind es für den L2 dann 21 statt 14 Zyklen. Apple könnte mit der gleichen L1TLB-Größe 1,5MB abdecken, d.h. ein gleich großer L2 hätte in der Praxis eine deutlich geringere durchschnittliche Latenz.

Mit größeren Pagesizes von z.B. 64kB könnte man bei zukünftigen Cores deutlich Platz durch kleinere TLBs sparen und gleichzeitig die Latenz bei den so kritischen tiefen Levels verbessern. Bei den L1-Größen hängen Intel und AMD einfach schon ewig fest, weil sie mit größeren L1D entweder die Latenz (durch fehlendes VIPT) oder den Verbrauch (durch absurde Assoziativität) killen würden. Es würde mich nicht wundern, wenn das mittlerweile eine ziemlich üble Bremse ist, um die Intel und AMD seit Jahren drumrum bauen.

[stinki]

N3X und N2 sind laut TSMC H2/2025 verfügbar.
Auf die beiden Prozesse, denke ich, wird AMD bei Zen6 aufsetzen und die sind für AMD wahrscheinlich in Massen dann erst ein Jahr später verfügbar. Vielleicht kommen die Server CPUs etwas eher als die Desktop CPUs bei Zen6. Und die Zen6 APUs kommen dann zur CES 2027.
Nova Lake wird ja auch nicht vor Ende 26 erwartet.
Interessant wird wann Intel Clearwater Forest und Diamond Rapids in 18A liefern kann.
TSMC N2P und A16 sollen dann H2/2026 verfügbar sein. Damit wird dann wahrscheinlich Zen7 irgendwann Ende 27 / Anfang 28 kommen.

[reaperrr]

N3X und N2 sind laut TSMC H2/2025 verfügbar.
Auf die beiden Prozesse, denke ich, wird AMD bei Zen6 aufsetzen und die sind für AMD wahrscheinlich in Massen dann erst ein Jahr später verfügbar.
Ich weiß nicht, was immer alle mit diesen dämlichen X-Prozessen haben.

Nochmal zum Mitschreiben für alle, die es nicht verstehen oder wahrhaben wollen:

Die X-Varianten sind nicht "P+", sondern Prozess-Varianten, die nochmal ~5% Taktbarkeit draufpacken im Gegenzug dafür, dass die Leakage MASSIV hochgedrückt und die Effizienz aus dem Fenster geworfen wird.

Mit anderen Worten, ein Prozessor der in N3P max. 6 GHz schafft, schafft in N3X dann 6,3 aber mit doppeltem Verbrauch und enormer Hitzeentwicklung.

Die X-Prozesse sind explizit für bestimmte Nischenprodukte im HPC-Bereich, wo 100-200W mehr nicht so schlimm sind, weil die eh mit Wasser oder enorm starkem (+ lautem) Luftstrom gekühlt werden und es nur um Performance geht.
Diese Prozesse sind für normale Desktop-/Mobile-CPUs und -GPUs eher weniger geeignet, da auf üblichen Betriebspunkten heißer und weniger effizient als die P-Varianten.

Und nein, AMD wird auch nicht anfangen einen Chip für Mobile und Mainstream-Desktop in N3P, und dann noch eine extra Variante in N3X für die paar "Verbrauch egal, ich hab Wakü!"-Taktfetischisten zu produzieren.
Das sind dann 2 Masken und auch sonst extra Aufwand, und AMD ist GEIZIG, gerade wenn es um Nischenprodukte geht, die keine 5000-10000$ je Stück abwerfen.

Consumer-Zen6 wird N3P und das war's.

[stinki]

Das stimmt so nicht ganz.
N3X -7% Power bei gleichem Speed vs. N3P.
N3X 1,1x Density bei gleichem Speed vs. N3P.
N3X kann höher tackten als N3P (und säuft dann auch mehr) muss man aber nicht machen. Man kann auch einfach die Power und Density Vorteile mitnehmen.

Edit:
Zudem ist die nominelle Voltage des Prozesses 0,9V bei N3X und 1,0V bei N3P, also gleiche Transistorperformance bei niedriger Spannung (deshalb -7% Power bei gleichem Speed).
Und der Prozess ist für höhere Spannungen freigegeben, das braucht man wenn man 1 oder 2 Cores boosten will z.B. 1,2V für 5,xGHz.

Deshalb hat N3X sowohl bei Desktop als auch bei Mobile CPUs/APUs Vorteile gegenüber N3P.

[davidzo]

Woher sind die Zahlen @Stinki?

Ich kannte bisher nur das hier:
In April 2023, at its Technology Symposium, TSMC revealed some details about their N3P and N3X processes the company had introduced earlier: N3P will offer 5% higher speed or 5%–10% lower power and 1.04× higher "chip density" compared to N3E, while N3X will offer 5% speed gain at the cost of ~3.5× higher leakage and the same density compared to N3P.

[stinki]

Woher sind die Zahlen @Stinki?

https://www.anandtech.com/show/21408/tsmc-roadmap-at-a-glance-n3x-n2p-a16-2025-2026
Die sind aus einem AnandTech Artikel von Mai 24, Daten kommen wohl von TSMC.

Edit:
Und hier noch ein Link zu N4X von Mai 23
https://www.anandtech.com/show/18875/tsmc-details-n4x-extreme-performance-at-minimum-leakage
Da das Zen5 8-Core CCD bis 1,35V beim Boost auf 5,7+GHz bekommt, bin ich mir eigentlich ziemlich sicher, dass das in N4X produziert wird.

[davidzo]

George Cozma von Chips and Cheese: https://chipsandcheese.com/p/amds-9800x3d-2nd-generation-v-cache


I wonder what impact this will have on future AMD CPUs with regards to the packaging of their CPUs. Possibly in the future AMD will move all L3 cache into the base tile and just have the cores and L2 cache on top. Or mayhaps they will have more than 1 stacks on future CPUs.

Heißt future schon Zen6 oder erst Zen7/8?

Ich denke dann würde man diesem Ziel aber schon näher kommen:

- new packaging techniques (CCDs on IODs with silicon bridges?)
- new gen infinity fabric
- goal: "monolithic levels of latency"


L3 standardmäßig im Base tile, Kerne + L2 oben drauf und für die X3D CPUs einfach noch einen stack zwischen Cores und Base. Das wäre dann der "more than one stack".

[Nightspider]

Das spekulieren wir hier doch schon seit 2 Jahren oder? ^^

[amdfanuwe]

Heißt future schon
Zen6 oder erst Zen7/8?

Future heißt: Wenn AMD der Meinung ist die Technik mit guter Gewinnmarge in Massenproduktion bringen zu können.

In den Labors wird sicherlich schon an Multistacking, Back Side Power etc gearbeitet.

L3 standardmäßig im Base tile, Kerne + L2 oben drauf und für die X3D CPUs einfach noch einen stack zwischen Cores und Base. Das wäre dann der "more than one stack".
Standardmäßig wohl nicht, dürfte noch genügend Anwendungsfälle für einen günstigeren monolithischen Chip geben.
Letztendlich entscheiden die Produktionskosten oder andere Gründe, welches Design umgesetzt wird.
Man denke an HBM. Erwies sich als zu teuer für Gaming GPUs.

[Badesalz]

Heißt future schon Zen6 oder erst Zen7/8?Zen6 auf keinen Fall.

[w0mbat]

Zen6 auf keinen Fall.
Ich hatte auch nicht damit gerechnet, da schon mit Zen 5 der cache unter das CCD wandert.

[basix]

Zen 6 wird man vermute ich noch nicht auf 3D-Stacking setzen. Zumindest nicht beim 8C Die. Auch beim 16C Die sehe ich das nicht. Beim kolportierten 32C Die vielleicht schon, bis sogar gut möglich. N2 wird teuer sein und es wäre ein erster Testlauf vom 3D-Stacking (OK, 3. Testlauf nach CDNA3/CDNA4)

Bei Zen 7 sehe ich das dann viel eher. Doch dann vermute ich, wird es kein 8C CCD mehr geben. Aber allenfalls ein 8C+8C CCX aus Zen 6/6c. Ich war eigentlich der Meinung, dass das mischen der Core-Typen bei Server keinen Sinn macht. Un des deswegen das bei Client auch nicht geben wird. Aber ich habe mir den Zen 5 Die Shot nochmals angesehen und dort ist bei L2/L3 schon vieles drin, was bei Zen 4c neu dazu kam. Deswegen wurde das so kompakt bei Zen 5. Damit ist bereits viel der Flächeneinsparung mit dabei und scheint die Performance nicht zu beeinträchtigen. Ich vermute, dass Zen 5c nicht mehr so viel kleiner wird wie Zen 4c. Und bei N3E/N2 usw. kann man mit FinFlex und adaptiver Breite der FETs (Anzahl Finnen oder Kanalbreite bei GAA) viele der Zen 4c Flächengewinne umsetzen ohne gross Performance zu verlieren, wenn man sich die 2-1 / 2-2 / 3-2 Finnen-Konfigurationen von N3E anschaut. Deswegen denke ich, dass bei Zen 6 die 6c-Variante viel näher dran sein wird bei Fläche wie auch maximaler Taktrate. Und deswegen ein Mischen deutlich mehr Sinn macht.

Idee:
- Zen 7 16C Chiplet = 8+8C (8x "big", 8x "small")
- "Small" zu "Big" sind vielleicht noch 15% Unterschied in Fläche wie auch Maximaltakt (die Differenz HP zu Standard-Cells wird bei neueren Nodes immer kleiner, d.h. man HP Cells werden deutlich seltener benutzt werden)
- Das 16C Die wird dann für Client (Desktop & Mobile) sowie die xxF EPYC (high frequency Typen) verwendet
- Bei Standard-Server EPYC takten die "Big" & "Small" Cores dann einfach gleich hoch (low core count)
- Das 32C Die kommt nur mit "Small" Cores daher (oder wahlweise 2x 16C auf ein gemeinsames Base-Die gestacked) und bietet bei Server die selben Taktraten wie das 16C Die und auch 4MB L3$ pro Core

[latiose88]

Ja schon die 32c werden wohl schlechter sein als ein 24 Kern threadripper,aber bestimmt schneller als ein 16 Kerner. Wobei wenn der Faktor Cache und takt noch dazu kommt, wird das gewiss auch ein Unterschied aus machen. Außer man schafft es das die CPU Kerne weniger vom l3 cache abhängig sind, dann wäre ne Halbierung der l3 cache auch keine Auswirkung mehr. Mal sehen wie es in dem Punkt so aussehen wird. Der l3 cache kostet den meisten Platz einer CPU.

[Badesalz]

Ich hatte auch nicht damit gerechnet, da schon mit Zen 5 der cache unter das CCD wandert.So wie sie sickern ließen war das für mich eigentlich Anfang Sommer schon eher gesetzt (auch wenn da weiterhin Speku, sitz da ja nicht im Labor...).

Das ist jetzt so bisschen wie mit dem V-Cache unter JEDEM CCD. Radeonfreak rechnet weiterhin nicht damit :wink:

@basix
Zu 95% wird es keine Hybride geben. Zu 98% jedenfalls keine für Desktop. Zu 100% keine für Server.

edit:
Wobei die Gamingbenches vom 285k in einer 1P + 16E Konfig eigentlich ziemlich gut aussehen :crazy:

[HOT]

Die 32mb sind einfach glaube ich nicht groß genug, dass sich das lohnen würde, die komplett auszulagern. Für billige Produkte und Serverprodukte ist es immer noch sinnvoll, L3 mit auf dem Silizium zu haben.
Ich vermute eher, dass es keine 2 CCDs mehr geben wird, nur ein 8C und ein 16C CCD+IOD. Das hätte auch den Vorteil, dass der Hauptverbraucher wieder in die Mitte des Packages wandert.

[Badesalz]

@HOT
Ich weiß auch nicht wie die Leute da jedes Mal ersehen wollen, daß ein 8C diesmal nicht mehr kommt. Jedes Mal irgendwie witzig (man verzeiht...). So eine urklassische Forenblase.
Das sind 16 Threads. Und da ist auch nichts verwerfliches dabei, wenn man sich den 9800X3D anschaut.

Ich bin wirklich gespannt, da ja jetzt unterm jeden CDD V-Cache liegt, was die nun erwarten, wie der 16C in Games abgehen soll (da 8C demnach ja endlich weg soll).
Ich meine abgehen soll, wenn man einen CCD nicht ausknipst.

Was sich langsam abzeichnet ist, daß wir auf einen monolithischen 8C zusteuern und einen monolithischen 6C mit nur c-Kernen. (nein, nicht Zen6 :rolleyes:)

Der Erstgenannte wäre aus der Sicht auf Speed und Verbrauch nur logisch. Wirtschaftlich aber nicht mehr so "billig" für AMD, weil wohl eher nicht mehr von Epycs Gabentisch runtergefallen. KP grad wie man den Epyc dazu basteln sollte (also die komplette Architekturplattform), damit sich das doch irgendwie lohnen/verheiraten lassen kann.

[HPVD]

was erwartet ihr denn bei der Architektur was (zumindest bei einzelnen Anwendungen ggf im Server-Bereich) einen wirklich großen Geschwindigkeits-Sprung auslöst?

bei ZEN 5 ist es full AVX512

bei ZEN 6 könnte es Unterstützung von MRDIMM 12800 Mbps (oder etwas weniger) sein.

Beim Xeon bringt bereits MRDIMM 8800 vs DDR5 6400 in Bandbreiten-limitierten Anwendungen bis zu +33%
siehe https://www.phoronix.net/image.php?id=intel-xeon6-mrdimm-ddr5&image=mrdimm_8800_10
aus https://www.phoronix.com/review/intel-xeon6-mrdimm-ddr5/5

=> seht ihr noch so einen Single Point mit viel Einfluss bei ZEN 6?

[basix]

@basix
Zu 95% wird es keine Hybride geben. Zu 98% jedenfalls keine für Desktop. Zu 100% keine für Server.

Dachte ich zuerst auch, dass das keinen Sinn macht. Aber wenn ich anschaue, dass sich Zen 6 und 6c vermutlich deutlich annähern werden aufgrund das was wir bei Zen 5 sehen und was mit N3E / N2x auf uns zu kommt (ca. 10...15% Takt- und Flächenunterschied) und N3E / N2x sehr teuer sein werden:

Man verringert für Client und "Low-Core" EPYC die Die Size, wenn man mischt (Kosteneinsparung)
Chiplet Re-Use Client und Server (R&D Ressourcen) bleibt bestehen
Server wird einfach alle Cores auf den selben Boost-Takt forcieren (wird halt leicht gedrosselt gegenüber Client und auf "Small" Niveau reduziert), dürfte gegenüber heutigen EPYC keinen Taktnachteil bedeuten da eben nur 10-15% Unterschied was mit 5.0 vs. 5.7 GHz heute schon vorhanden ist (Server vs. Client). Man spart bei Server also Kosten, ohne Performance zu verlieren.
Bereits heute haben die 16C Desktop-SKUs ca. 5% Taktunterschied zwischen den zwei CCD. Wenn das auf ~10-15% anwächst wirst du das nicht merken. Und ist auch nur relevant für alles, was viel MT benötigt und 10% Leistungsunterschied wäre auch nur für "kritische" SW ausschlaggebend, wo der 9. Thread noch 90% der "Critical-Thread" Leistung benötigt (wo es vermutlich nicht viel SW gibt, die so eng gestaffelt sind). Hinsichtlich reinen MT-Workloads (wie Cinebench) ist ein Intel P+E Core Prozessor ja auch Top und das mit viel grösseren Unterschieden zwischen den Core-Typen.

Es gibt zudem Gerüchte, dass es keinen Zen 6c mehr geben wird. Da "Big" / "Small" vermutlich näher zusammenrücken (anhand meiner Analyse von Zen 5 Die Shot und N3E FinFlex), wäre das eine Erklärung dafür. Es gibt immer noch eine kompaktere Variante, aber die Unterschiede sind halt deutlich kleiner. Und durch eine Mischung der Core-Typen gäbe bei Produkten auch keine explizite Trennung in "c" und "non-c" mehr (deswegen evtl. das Gerücht?). Der "non-C" hat den grössten Teil des Weges zum "c" bereits hinter sich gebracht, weil man Cache-Grösse und Fin-Libraries bereits deutlich stärker auf Density optimiert hat. Bei Zen 5 ist das bei L3/L2-Cache definitiv bereits der Fall. Beim Rest des Cores noch nicht, dort käme nun N3E FinFlex ins Spiel.

Das wäre bei Zen 6 dann etwa so:
- 8C = "Big" Cores only
- 16C = 8C "Big" + 8C "Smaller, but still Big"
- 32C = 32C "Smaller, but still Big"

Ich weiß auch nicht wie die Leute da jedes Mal ersehen wollen, daß ein 8C diesmal nicht mehr kommt. Jedes Mal irgendwie witzig (man verzeiht...). So eine urklassische Forenblase.
Solange es monolithisch bleibt, wird es vermutlich 8C CCD geben. Also bei Zen 6 wird es mMn noch 8C geben. Aber ein 8C Die zu stacken, wenn man den L3$ und IO rauslöst (evtl. Zen 7)? Unwahrscheinlich. Die 8C bei Zen 4 sind 30mm2 gross (inkl. L2$). Bei Zen 5 40mm2. Mit N3E wird der Core mit hoher Wahrscheinlichkeit wieder einiges kleiner (Density, Kosten). Könnte ziemlich schwierig werden das zu kühlen, selbst bei 65W TDP / 89W PPT. Mit Backside Power Delivery wird die Kühlbarkeit nochmals schwieriger.

[Badesalz]

@basix
Punkte sind ok. Aus AMD Sicht... Die Industrie (RZ) will das aber einfach nicht. Das ist denen zu viel Chaos bei Einschätzungen der Leistung. Und auch ihrer Konstanz. Man kann sich in einer nur leicht größeren Umgebung nicht sicher sein wie das grad skalieren wird. Und wie das wieder bei der nächsten Gen skalieren könnte. Schon die Planer lehnen das ab. Mehrheitlich. Die Admins, größtenteils. Entweder nur die Kleinen oder nur die Großen please...

Oder warum meint ihr gibt es keine P+E Xeons? (oder hab ich die grad verpasst?) Intel hat ja ne ganze Weile rumgefragt wie es so damit wäre ;)

Es wird 110% Zen6c geben. Wenn das mal sozusagen verschmelzen sollte, dann kann es ggf. funktionieren, aber dann ist das nicht mehr nach außen Hybrid, das oben erwähnte "Chaos" bleibt aus und die Industrie hört dann auch auf deswegen zu mosern.

[basix]

Mein Punkt ist ja genau folgender: Für den Server-Kunden gibt es keinen Unterschied zwischen grösseren und kleineren Cores mehr (beim 16C Chiplet). Selber Takt, selbe IPC, gleich viel Cache. Nur für AMD ändert sich was, sie sparen Chipfläche. Der Hybrid wäre gegen aussen bei einer Server CPU gar nicht zu sehen. Bei Client wäre der (leichte) Unterschied zugunsten von Peak-ST-Performance dann ersichtlich. Die Hybrid-Unterschiede sind bei MT-Workloads aber nicht gross relevant, Intels P+E CPUs beweisen das und bei AMD wäre der Unterschied zudem deutlich kleiner.

Zen 6c wird es mMn nur in einer relevanten Form geben: Halbierter L3$ beim 32C Chiplet und allenfalls Mobile. Mit dem Core an sich hat das dann aber weniger zu tun. Takt bei Server-CPUs wäre immer noch der selbe wie bei den 8C/16C Chiplets.

[Badesalz]

@basix
Wenn es irgendwann soweit sein sollte. Wir reden ja beide vom gleichen. AKTUELL aber (und damit auch beim Zen6) wird das aber nicht so sein.

Zen 6c wird es mMn nur in einer relevanten Form geben:Es wird Epycs mit nur Zen6c geben. Das ist gesetzt. Das "Edge" Zeug geht brauchbar weg. Du bist grad irgendwo zwischen Zen7 und Zen8 hingerannt ;)

[basix]

Ich behaupte, bei Zen 6 wird es so sein ;) Zen 5 ist bereits der halbe Schritt dort hin. Wird interessant einen Die Shot des Zen 5c Chiplets zu analysieren. Der Core sollte deutlich geschrumpft sein aber L2/L3 fast nicht, anders als bei Zen 4c.

[Badesalz]

Wollen wir um den Einsatz wetten den ich von Radeonfreak wegen der Sache mit V-Cache unter jedem CCD bekomme? :smile:

edit:
Halbierter L3$ beim 32C ChipletWobei das stimmt ja auch. Falls es dir darum ging. Und falls wir keine 512 Threads sehen :ulol:

[basix]

Was war dort der Einsatz? :D Thema wäre gemischtes 16C Chiplet, 8C+8C ;)

[Badesalz]

Was war dort der Einsatz? :D Ich glaub nachdem ich obszöne Bilder abgelehnt habe ist sie noch am grübeln...
(ich mein der... Mod, hat da aber auch mal gefegt, musste dafür sogar in den Gulag :frown: Hätte ich das Angebot bloß angenommen) :uking:

Thema wäre gemischtes 16C Chiplet, 8C+8C ;)Läuft.

[basix]

Nur um zu präzisieren: 8C+8C als Single CCX ;)

Läuft.
:up:

[HOT]

Ja aber der 8C ist mit Sicherheit nicht 8 big sondern 4+4c. Das Ding ist ja quasi der neue "10600X" (wird auch 100er-Namen haben).

R5 10600X -> AI 560X -> 4+4c
R7 10700X -> AI 570X -> 6+6c
R9 10950X -> AI 580X -> 8+8c

Würde ich mal tippen, dass das dann so aussieht.

[basix]

Das wiederum denke ich nicht. mMn wird es dort 8+0c sein. Aber wir werden es sehen, wenn es soweit ist.

[HOT]

Das ergibt einfach keinen Sinn. Das Ding ist der Billgheimer für CPUs und APUs.

Hawk Point -> Kraken Point

[basix]

Kraken Point ist aber monolithisch. Langfristig macht es bei Zen 6 mehr Sinn, das 8C Chiplet zu nehmen und vier reduzierte Cores im SoC/IOD unterzubringen (siehe Lunar Lake, Strix Point mit reduzierter FPU oder wohl auch Strix Halo). Die Produktdifferenzierung/Kostenanpassung passiert über das SoC Die und dass das 8C CCD deutlich kleiner ist als das 16C CCD.
- Kraken Point Nachfolger = (8)+4c + mickriges SoC-Die + 64bit DDR
- Strix Point Nachfolger = (8+4c)+4c + mittleres SoC-Die + 128bit DDR
- Strix Halo Nachfolger = (8+8c)+4c + dickes SoC-Die + RDNA5-GPU-Chiplet + 256bit DDR

[HOT]

Nope, wird man nicht machen. Es wird für APUs 2 IODs geben mit verschieden großer integrierter Grafik und das mit den CCDs paaren. Alles Weitere hätte mMn einfach keine Vorteile.

[basix]

Du widersprichst dir da irgendwie selber ;) Wieso macht man Kraken Point dann überhaupt als 3. Lösung neben Strix Point/Halo? Für Kosteneinsparungen. Für Kraken Point Nachfolger: Kleinere NPU, halbiertes SI, kleinere GPU, reduzierte Video/USB/HDMI etc. Interfaces als das mittlere SoC Die würde ein drittes, kleinstes SoC/IOD ja rechtfertigen. Du wirst definitiv teurer kommen, wenn du nur 2x IOD machst und dafür das CCD auf 4+4c reduzierst (ausser dass man einen Chip weniger designen muss).

Du, vielleicht wird es 4+4c beim kleinsten CCD. Wäre unter dem Strich nicht so tragisch, wenn das nicht 8+0c sein sollte, ich schiele eh auf das grössere CCD :D

[HOT]

Kraken ist der Nachfolger von Phoenix/Hawk Point. Strix Point steht darüber. Das ist die erste echte high-End-Notenook-APU von AMD.

Übrigens hat Kraken die gleiche NPU wie Strix.

[basix]

Ich weiss, dass die gleiche NPU drin ist. Das heisst nicht, dass das in Zukunft so bleiben wird wenn die Dinger immer leistungsfähiger und grösser werden. In Kraken ist es eine 50 TOPS NPU geworden weil man den AI/CoPilot-Sticker wollte. Ich vermute dort wird man in Zukunft stärker und abhängig vom Produkt-Segment skalieren, ist schlussendlich auch ein Kostenfaktor. Und auch eine Produktdifferenenzierung im Portfolio. Momentan ist die NPU über alle Produkte faktisch gleichgeschaltet aber sehr unwahrscheinlich, dass das immer so bleiben wird.

[HOT]

In Zukunft ist die NPU ja nicht mehr im CCD. So wie es aussieht wird die AI 500-Serie ja dann doch etwas anders aussehen.
Nehmen wir mal an, dass es 3 IODs gibt in der Generation, eines für Desktop+mobil, rest mobil allein.

- IOD1 mit 4 RDNA5-CUs, 55 TOPs NPU 128Bit DDR5 (CU)DIMM, CAMM2, LPDDR5X
- IOD2 mit 16 RDNA5-CUs, 110 TOPs NPU, 128Bit LPDDR6
- IOD3 mit 40 RDNA5-CUs, 110-220 TOPs NPU, 256Bit LPDDR6

- CCD1 mit 8/(4+4c)
- CCD2 mit 8+8c
- CCD3 mit 32c

dann kann man die ja beliebig mit einem CCD kombinieren. Für billig-mobil und Desktop wäre dann IOD1 + CCD1 die richige Wahl, für high-End-Desktop dann IOD1+CCD2, für medium-Mobil dann IOD2 + CCD1, für high-End-mobil dann IOD2+CCD2, und als Grafik-Replacement dann IOD3 mit CCD2 oder für Profi-Mobil eben IOD3+CCD3+ >=128GB LPDDR6. Für absolut billig-Mobil hätte man außerdem nach wie vor Sonoma Valley, den Mendocino-Nachfolger.

[basix]

Ja in etwa so stelle ich mir das auch vor. Allerdings denke ich, dass man CCD1 mit 8+0c umsetzen wird (sind grob abgeschätzt nur ca. 3mm2 Unterschied bei der Die-Grösse ob 4+4c oder 8+0c). Aber mal schauen. Gehen würde es sicher, aber 4+4c ist primär für Desktop eine nicht optimale Lösung. Für Mobile und Server ist es nicht so wichtig.

Edit:
Aber noch hart, dass wir hier 6 verschiedene Die haben :D

[HOT]

Ok, hast gewonnen :D. Stimmt, wenn das so wenig ausmacht wird man das dann eher so machen ;).

Man hat im Laufe des Jahres so viele Dies. Außerdem wird man die IODs (bis auf Server) ja eh wieder 2 Generationen durchschleppen.

[basix]

Jein, frag mal die Erbsenzähler die nehmen die 3mm2 gerne mit ;) Vielleicht sind es dann auch 5mm2 oder man strippt beim CCD1 noch die FPU auf 50% zurück. In der Desktop-Bubble ist es dann halt nicht optimal, ist aber der kleinste Markt.

[HOT]

Als BWLer hätte ich schon 4+4c mit halbierter FPU (hätt ich eh mit gerechnet) und halbiertem IFOP geplant. Aber bei AMD setzen sich ja nicht immer die BWLer durch, was eher gut ist. Die Kernfrage, der Pferdefuß gewissermaßen, die ich mir dabei stelle bleibt, ob man die Packagingkapazitäten dafür dann hat, oder ob der 4+4c mit 4 CUs monolithisch sein muss.

[Badesalz]

Ja aber der 8C ist mit Sicherheit nicht 8 big sondern 4+4c. Das Ding ist ja quasi der neue "10600X" (wird auch 100er-Namen haben).
Da sagst du was. Ich hab mich auch schon gefragt, ob die das wirklich so beibehalten wollen :freak: Zen6 mit Intels uralten Namennomenklatur hätte ICH jedenfalls nicht gebracht :rolleyes: Ich glaub nicht :wink:

@basix
Du bist jetzt von einem hybriden auf ein asymetrisches Design gegangen. Auch das wird nicht passieren =) Nehm das mit auf die Wettliste ;)

[davidzo]

Das spekulieren wir hier doch schon seit 2 Jahren oder? ^^
Na klar, aber die Meinung von George Cozma dazu ist ein neuer Hinweis.

Zen6 auf keinen Fall.
Wie soll man sonst das Ziel "monolitische Latenz" und new gen infinity fabric erreichen?

Wenn man den L3 weiterhin auf dem CCD hat kme man wohl mit 2.5D aus.
Also Info-R oder LSI (AMD EFB) im Package. Nur für den Speichercontroller braucht man kein 3d stacking. Erst wenn man den L3 im Base-tile oder unified über zwei CCDs machen wollte wäre die Bandbreite die man mit 3d stacking bekommt notwendig.

Ich frage mich wirklich ob es nicht günstiger wäre den L3 in den BaseDie zu packen. Ein 16C CCD in N3P ohne L3 wäre sicher nicht größer als der derzeitige 8C CCD und der Cache ist in N4P auch billiger zu haben. Aber ja, es nützt nichts wenn die Chips billiger sind aber das 3DPackaging völlig ausgebucht ist.


Btw, AMD macht ja gerne mal Testballons mit low volume Produkten bevor man das auf die ganze Produktpalette ausrollt. Was ist denn mit Sarlak? Wenn man sich den mal anschaut sind die DIEs nicht wie bei einem normalen Flipchip verteilt auf dem Package sondern sitzen direkt mit den Kanten aneinander, ohne Platz dazwischen. Ist das vielleicht schon ein 2.5D package Testballon für Zen6?

Zen 6 wird man vermute ich noch nicht auf 3D-Stacking setzen. Zumindest nicht beim 8C Die.

Da würde es sowieso eher Sinn machen einen Monolitischen chip in N4P oder so zu machen imo.


Kraken Point ist aber monolithisch. Langfristig macht es bei Zen 6 mehr Sinn, das 8C Chiplet zu nehmen und vier reduzierte Cores im SoC/IOD unterzubringen (siehe Lunar Lake, Strix Point mit reduzierter FPU oder wohl auch Strix Halo). Die Produktdifferenzierung/Kostenanpassung passiert über das SoC Die und dass das 8C CCD deutlich kleiner ist als das 16C CCD.
- Kraken Point Nachfolger = (8)+4c + mickriges SoC-Die + 64bit DDR
- Strix Point Nachfolger = (8+4c)+4c + mittleres SoC-Die + 128bit DDR
- Strix Halo Nachfolger = (8+8c)+4c + dickes SoC-Die + RDNA5-GPU-Chiplet + 256bit DDR

Aus Produktdifferenzierungsgründen ja vielleicht. Aber vieles Andere spricht dagegen:
- Zen6C Cores sind für MT performance optimiert, nicht für LPE Aufgaben. Das sind keine LPE cores die wie bei Intel dazu dienen Hintergrundaufgaben zu übernehmen damit man die großen schlafen legen kann.
- Nur 4x Zen6C cores bringen wenig MT performancesteigerung. AMD hat bisher immer doppelt soviele c-Cores verbaut wie P-Cores.
- Die Performance wäre besser wenn die Zen6C cores auch auf den L3 cache pool im CCD zugreifen könnten. (siehe cache-bedingte performance defizit bei Intels LPE Cores)



Ich glaube auch nicht wirklich an das 8+8 und 16+16 Konzept. Das ist vielleicht für Consumer gut, aber ungeeignet für Epyc.

Sowohl das 16C standard DIE als auch das 32C DIE werden wieder für Epyc mitgenutzt. Und im Server will niemand heterogene Cores haben. Es ist völlig nutzlos wenn eine VM anders performt als die andere. Keiner will das komplexe Scheduling das zwei verschiedene Core-typen in einem System mit sich bringt. Wenn bestimmte workloads mehr per Core performance brauchen als die C-Cores bieten, dann stellt man sich lieber einen zweiten Server nur mit P-Cores hin aus dem der workload dann läuft. Auch Ampere, Nvidia und Intel haben keine Pläne für gemischte Cores im Serverumfeld.

Wenigstens das 32C DIE wird Zen6C only sein und vielleicht wiede rnur bei Epyc eingesetzt weren.

Das 16C DIE könnte wieder das einzige DIE sein das für 3D Vcache vorbereitet ist. Bei V-Cache SKUs C-Kerne zu verbauen macht keinen Sinn, da es hier um maximale per Thread performance geht.
Das 8C DIE braucht wohl keinen V-Cache und wird für Epyc auch nicht genutzt. Hier sehe ich die einzige Chance für eine gemischte Kern-Bestückung.

[Badesalz]

Wie soll man sonst das Ziel "monolitische Latenz" und new gen infinity fabric erreichen?Wir werden imho erstmal den halben Weg dahin sehen ;) Beim Rest bist du ja weitgehend bei mir =)

Die Themen sind wirklich spannend. Schon aus der groben technischen Sicht. Da die Techno es irgendwann nicht mehr her gab, ist man den sinnvollsten Weg gegangen Chiplets zu machen. Garniert nun teils mit V-Cache unter den CCDs.
(wobei imho non V-Cache wird imho nicht nur beim Konsument auf dem absteigenden Ast sein)

Das alles, obwohl es schon recht viele Nachteile gibt, aber die Vorteile in Gänze überwiegen doch eher klar. Intel sah halt nur die Nachteile und wollte es doch irgendwie hinzaubern was nicht hinzuzaubern war.

Jetzt, wo Intel das Licht aufging und der erste Versuch, gelinde gesagt, ziemlich dürftig war, ist die Techno (jedenfalls die von TSMC) nach grob 7 Jahren wieder soweit, daß man die Idee mit den Chiplets in Zen7/Zen8 wieder teils zurückdrehen wird.

Auf eine Weise schon irgendwie bekloppt oder? :rolleyes:

[Zossel]

Als BWLer hätte ich schon 4+4c mit halbierter FPU (hätt ich eh mit gerechnet) und halbiertem IFOP geplant. Aber bei AMD setzen sich ja nicht immer die BWLer durch, was eher gut ist. Die Kernfrage, der Pferdefuß gewissermaßen, die ich mir dabei stelle bleibt, ob man die Packagingkapazitäten dafür dann hat, oder ob der 4+4c mit 4 CUs monolithisch sein muss.

Als BWL'er sollte dir eigentlich klar sein das die Entscheidung eine eigene Maske für bestimmte Produkte aufzulegen sich im wesentlichen aus 2 Faktoren ergibt:

Erwarteter Yield und erwartete Stückzahl.
Lassen sich die gewünschten Produktmerkmale nur monolithisch erreichen. (Powerel)

[Zossel]

Wir werden imho erstmal den halben Weg dahin sehen ;) Vielleicht hört hier jemand was raus: https://www.youtube.com/watch?v=wYLxf0zNc2c

[davidzo]

Da die Techno es irgendwann nicht mehr her gab, ist man den sinnvollsten Weg gegangen Chiplets zu machen.

Ich glaube das war rein kostengetrieben. Technisch macht Chiplet ohne advanced Packaging eigentlich nur wenig Sinn.
Wer sich es leisten konnte (Apple) hat eben auch monolitische Chips in 7nm und 5nm aufgelegt obwohl es brandneu und teuer war.

Ich kann mich gut erinnern an das interne Folienset dass Krzanich Intel-weit herumgeschickt hat zum Zen2 launch.
Darin stand dass AMD eine "highend" Strategie verfolge, die man nicht erwartet hat. Man hat nicht damit gerechnet dass die 7nm Chiplets auch in den Consumer Markt kommen. Nach Zen dachte man eben es geht so weiter mit monolitischen DIEs die ein wenig größer als Intels sind und ein wenig mehr Kerne bieten.

Intel hatte sich davor schon ausgerechnet dass sich EUV absehbar nicht lohnen wird.
Was TSMCs extrem komplexen DUV Prozess mit Multipatterning angeht haben Intels Ingenieure Krzanich beruhigt, dass es quasi unmöglich ist dass das jemand anders als Apple für den Consumer Markt benutzt weil die Margen dazu zu schlecht sind im Vergleich zu 14/12nm.

Dass AMD dann trotzdem frühzeitig auf 7nm gewechselt ist hat Intel kalt erwischt.
So steht das jedenfalls in dem internen Memo, dass man sich jetzt mit 10nm ein bisschen beeilen muss und dass 14nm eben auch Vorteile hätte, bei Kosten, bei den erreichbaren Maximaltaktraten zum Beispiel oder bei dem Corecount (10900k) und dass doch überhaupt der Support und die Softwareunterstützung viel wichtiger seien.


BTW, Die Verschiebung der Zen6 mobile APUs mit stattdessen einem Strix refresh legt jedenfalls nicht nahe dass die neuen APUs fertigungstechnisch günstig sein werden. Strix hat einen mit 225mm2 sehr großen DIE. Im relativ aktuellen N4P verfahren dürfe der nicht billig sein. Wenn der Zen6basierte Ersatz eine Chiplet CPU wäre, dann könnte die neue APU günstiger ausfallen und AMD sich genötigt sehen diese schon in 2026 zu bringen. Da in 26 aber erstmal Strix refresh kommt, rechne ich mit einer Zen6 mobile APU erst in 27.

[mboeller]

ich spekulieren auch mal ins blaue hinein:

CCD besteht immer aus Base-Die + CPU-Die

CPU-Die: 3nm; 8C Zen6 mit etwas größerem L2-Cache (~50-60mm2)

Base-Die (auch ~50-60mm2): 5nm; 64MB L3-Cache + 64bit DDR6 Speicherinterface, bis 12800MT/sec + CCD-Bridge (um die L3-Cache von 2 CCD direkt miteinander verbinden zu können) + IOD-Bridge


IOD = 2 Versionen (N6)

1) Northbridge (wie früher)
2) Northbridge + 4x Zen6L (128bit FPU, 512KB L2) + 2WGP RDNA5 (Speicherzugriff über CCDs)

[Zossel]

Dass AMD dann trotzdem frühzeitig auf 7nm gewechselt ist hat Intel kalt erwischt.
So steht das jedenfalls in dem internen Memo, dass man sich jetzt mit 10nm ein bisschen beeilen muss und dass 14nm eben auch Vorteile hätte, bei Kosten, bei den erreichbaren Maximaltaktraten zum Beispiel oder bei dem Corecount (10900k) und dass doch überhaupt der Support und die Softwareunterstützung viel wichtiger seien.

TSMC hat mit seinen Verfahren zum Masken putzen einfach einen ordentlichen Schritt nach vorne gemacht. Da hat eher TSMC als AMD Intel kalt erwischt.

[BavarianRealist]

Wenn Zen6 nun so weit in die Zukunft "verschoben" wird, würde ich hierfür zwei Vermutungen aufstellen:

1) AMD hat aktuell die Prio voll auf MI355/400, d.h. man gibt alle Resourcen (Human und Fertigungskapazitäten) erstmal hier hin, sodass sich Client-Produkte verzögern

2) AMD könnte hier einen größeren Technolgie-Schritt in Rechung 3D-Chipaufbau planen, der nur Sinn macht, wenn alle Elemente diesen gleichzeitig machen: Zen6-, RDNA5/UDNA-Chiplets sowie diverse passende SoC-Base-Dice.

Nur noch Zen6/RDNA5-CPUs/CU und L2 fänden sich dann in den kleinen N2/N3-basierenden Chiplets. Und der komplette Rest, vor allem alle Controller und L3 und sonstiges I/O nur noch im Base-SoC, da diese Elemente schon lange nicht mehr shrinken. Dafür dürfte dann sogar weiterhin N6 reichen, später evtl. N4.

[amdfanuwe]

Ich denke mittlerweile, dass sie 16 Core (wegen Yield) Dense Chiplets ohne Cache produzieren und stacken 2 davon auf ein Base Cache Die.
Damit haben sie einen 32 Core Chip für Server 128 Core bis 256 Core.

Dazu einen schnellen 8Core inclusive 32MB Cache in N3X.
Für Desktop und Server bis 128 Core.

Da die Cache Dies relative groß werden, könnten da 128MB Cache drin sein.
Wenn sie es geschickt anfangen, könnte das Cache Die auch als X3D für die 8Core Verwendung finden.

Könnten dann auch 2 x 8 Core auf dem Cache Die gestacked werden und damit eine 16 Core CPU mit 32MB + 32MB + 128MB =192MB shared L3 erzeugt werden.
Ebenso denkbar 8Core + 16Core Chips auf Cache Die für 24 Core CPU.

Ebenso dürften GPU Chiplets entwickelt werden, die man dann auch in APUs verwendet.
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=90160&stc=1&d=1731354976

[basix]

Interessantes Konzept. Könnte man so machen.

Es gibt aber eine Lücke:
- Kein "normales" 16C Die. Macht 16C bei Client teuer und bei Server ist der Unterschied zwischen 8C und 32C (4x Unified L3$) sehr gross

Würde es nicht Sinn machen, ein 16C / 64MByte Die in N3P/X aufzulegen? Das würde für alle eher kleineren Server-SKUs sowie 16C Desktop und Mobile befeuern, welche keinen X3D verwenden.
Ausnahme: 16C ohne X3D wird bei Client wieder über 2x 8C Die gelöst. Das wäre aber schade.

[amdfanuwe]

BTW, Die Verschiebung der Zen6 mobile APUs mit stattdessen einem Strix refresh legt jedenfalls nicht nahe dass die neuen APUs fertigungstechnisch günstig sein werden. Strix hat einen mit 225mm2 sehr großen DIE. Im relativ aktuellen N4P verfahren dürfe der nicht billig sein. Wenn der Zen6basierte Ersatz eine Chiplet CPU wäre, dann könnte die neue APU günstiger ausfallen und AMD sich genötigt sehen diese schon in 2026 zu bringen. Da in 26 aber erstmal Strix refresh kommt, rechne ich mit einer Zen6 mobile APU erst in 27.
Welche Verschiebung?

ZEN6 wird erst Mitte/Ende 2026 erwartet. Normalerweise APUs dann zur nächsten CES, also Jan. 27.

Strix Point hat man m.M. nach vorgezogen wegen dem AI-PC Hype. Sonst wär das auch ein CES 25 Thema geworden.
Zur CES 26 ist ZEN6 noch nicht so weit, bleibt nur ein Refresh.

[basix]

Ich denke mittlerweile, dass sie 16 Core (wegen Yield) Dense Chiplets ohne Cache produzieren und stacken 2 davon auf ein Base Cache Die.
Damit haben sie einen 32 Core Chip für Server 128 Core bis 256 Core.

Ich habe mir erlaubt dein Bild ein wenig anzupassen:

Alle 3x Die (8C N3x, 16C Server, V-Cache) sind exakt gleich gross
Da exakt gleich gross, erlaubt das Mix & Match und Wafer-on-Wafer Stacking
Mix von N2/N3 Die könnte man machen, ist mMn aber unwahrscheinlich da dann kein WoW-Stacking mehr geht
Alle 3x Die kann man auf dem Wafer einzeln oder als Doppelpack rausschneiden, gibt dafür Verbindungen zwischen den Die (ähnlich wie es Cerebras bei deren Wafer Scale Engine macht)
Das hätte den sehr grossen Vorteil, dass man nur 3x relativ kleine Die designen müsste (R&D Aufwand, Validierung, Maskenset, etc.) und trotzdem nach oben skalieren könnte und aus 2x 8C ein quasi monolithisches 16C Die erhält. Oder bei N2 2x 16C = 32C
Nachteil ist der Overhead für die redundanten "IFOP". Die sollten bei Zen 6 aufgrund Advanced Packaging aber deutlich kleiner sein als bei Zen 4/5 und wäre nur bei den günstigeren N3x / N4C Chiplets ein Thema. Der Overhead sollte sich also in Grenzen halten.


Edit:
Falls das nun 50/50 Zen 6/6c Cores beim N3x Die sind: Würde vermutlich gehen.
- 8C taktet generell etwas niedriger als das Topmodell (etwa -5% Takt)
- Die 6c Cores werden beim 8C Modell etwas mehr gepusht als sonst (sind nur 8C, man hat TDP Headroom)
- Dann landen wir bei evtl. 5-10% Taktunterschied zwischen den zwei 4C Clustern. Ein 9700X hat auch 5% Taktunterschied zwischen 4T und 16T und wäre somit in einem ähnlichen Rahmen.

[amdfanuwe]

Es gibt aber eine Lücke:
- Kein "normales" 16C Die. Macht 16C bei Client teuer und bei Server ist der Unterschied zwischen 8C und 32C (4x Unified L3$) sehr gross

Verstehe nicht, was du meinst.
Hätten beide 4MB unified L3 pro Core.



Würde es nicht Sinn machen, ein 16C / 64MByte Die in N3P/X aufzulegen? Das würde für alle eher kleineren Server-SKUs sowie 16C Desktop und Mobile befeuern, welche keinen X3D verwenden.
Ausnahme: 16C ohne X3D wird bei Client wieder über 2x 8C Die gelöst. Das wäre aber schade.


Ein 16C / 64MB DIE non Dense wäre doppelt so groß wie der 8C / 32MB.
Ich sehe nicht, wo da die Stückzahlen dafür herkommen sollen.
Kleinere Server SKUs kann man wie bisher über mehrere 8C zusammenbauen. 8C bis 128C.

Alternativ könnte AMD auch noch ein 64MB Cache Die auflegen auf das die 16C Dense gestacked werden bzw. für eine 8C X3D Variante wie aktuell auch.
Mobil kann man die 16Core auf den I/O Stacken.

Andererseits denke ich, dass es auf mehr Kerne im Desktop hinausläuft.
8C X3D wirken dann doch etwas lächerlich für den Preisbereich.
12/16 Core X3D unified 192 MB Cache dürfte da schon andere Preise ermöglichen. Als 8C X3D wird dann der 9800X3D bei gesenktem Preis weiterleben.

Top Modell wird 24C, mehr dürfte wegen TDP nicht drin sein. Wen interessieren da noch 16C non X3D?
Wird ja sicherlich auch noch salvage SKU geben. Da wird ein 16C X3D letztendlich günstiger sein als ein 16C / 64 MB Monolith mit geringen Verkaufszahlen. Man müßte auch mal sehen, wie viele Anwendungen überhaupt in welchem Maße von einem solchem 16C Chip profitieren würden. Ich denke nicht, dass es wirklich viel bringt.

Man muss auch bedenken, wie sich das ganze Preisgefüge bei Desktop verschiebt.

[HOT]

Vielleicht wäre es auch sinnvoll, wenn das 8 Core CCD 4+4c wäre und das 16 Core alle Kerne groß mit weiterhin 32MB L3$ und nur auf dem CCD überhaupt mit X3D. für Mobil könnte man ja auch einfach 2 kleine CCDs nutzen, wenn man das will, gibt ja eh ein eigenes IOD dann. Dann könnte man wieder Server-CPUs mit big Cores oder c-Cores anbieten, so wie jetzt.

[iamthebear]

Vielleicht wäre es auch sinnvoll, wenn das 8 Core CCD 4+4c wäre und das 16 Core alle Kerne groß mit weiterhin 32MB L3$ und nur auf dem CCD überhaupt mit X3D. für Mobil könnte man ja auch einfach 2 kleine CCDs nutzen, wenn man das will, gibt ja eh ein eigenes IOD dann. Dann könnte man wieder Server-CPUs mit big Cores oder c-Cores anbieten, so wie jetzt.

c Kerne werden nur eingesetzt wenn entweder:
a) Ausschließlich MT Performance gefordert ist und man beliebig viele Threads hat ODER
b) Die TDP sehr niedrig ist da die c Kerne im unteren Bereich ca. die gleiche Oerformance abliefern

Im Desktopbetrieb ist beides nicht gegeben. Ob man bei insgesamt 200mm² Chipfläche 5-10mm² für 4 c Kerne spart ändert an den Kosten wenig. Will AMD mit den Kosten runter müssen sie beim IOD ansetzen was aber nur Sinn macht wenn da auch etwas Stückzahl dahinter ist, denn so margenträchtig ist der Markt der Bürorechner nicht da das hauptsächlich OEM PCs sind wo man deutliche Rabatte geben muss. Um 300$ verbaut dir kein OEM einen 9600X.

[davidzo]

Welche Verschiebung?

ZEN6 wird erst Mitte/Ende 2026 erwartet. Normalerweise APUs dann zur nächsten CES, also Jan. 27.

Strix Point hat man m.M. nach vorgezogen wegen dem AI-PC Hype. Sonst wär das auch ein CES 25 Thema geworden.
Zur CES 26 ist ZEN6 noch nicht so weit, bleibt nur ein Refresh.

Hast du mal auf den Threadtitel geguckt?

Und Strix war verspätet, ebenso wie Granite Ridge.

Es geht um diesen Refresh: https://wccftech.com/amd-mobile-cpu-gpu-2025-2026-update-ryzen-apu-refreshes-strix-halo-fire-range-krackan-radeon-rx-8000-series/

[basix]

Verstehe nicht, was du meinst.
Hätten beide 4MB unified L3 pro Core.

In der Gesamtmenge sind es 32MB vs. 128MB. Das meine ich mit grossem Unterschied. Gibt Applikationen wo auch die Gesamtmenge von Relevanz ist, nicht nur die per-Core Menge. Spiele sind ja nur ein Consumer-Beispiel wo man das gut sieht, das gibt es auch bei Server-Anwendungen (siehe V-Cache Server EPYCs).

Ein 16C / 64MB DIE non Dense wäre doppelt so groß wie der 8C / 32MB.
Ich sehe nicht, wo da die Stückzahlen dafür herkommen sollen.
Kleinere Server SKUs kann man wie bisher über mehrere 8C zusammenbauen. 8C bis 128C.

Highend bei Client (Desktop & Mobile) und die mittleren Core Count Server. Die Stückzahlen wären schon da. Man mus hier bedenken, dass N2 sehr teuer sein wird und auf 3D-Stacking zwingend angewiesen wäre. Das hätte man mit einem 16C Die entschärft.

[amdfanuwe]

In der Gesamtmenge sind es 32MB vs. 128MB. Das meine ich mit grossem Unterschied.

Ah so meinst du das. Sind bei einer 128 Core CPU aber immer noch 512MB vs 512MB.
Seh ich aber kein Problem drin. Man kann nicht alle Fälle optimal abdecken. Irgend wo hat man immer eine Quantisierung.
Übel wirds ja nur, wenn zu wenig Cache da ist.
Ob mein Gedanke zu 128MB Cache im Base Die überhaupt sinnvoll realisierbar ist, Latenz etc... davon hab ich keine Ahnung.


Highend bei Client (Desktop & Mobile) und die mittleren Core Count Server. Die Stückzahlen wären schon da. Man mus hier bedenken, dass N2 sehr teuer sein wird und auf 3D-Stacking zwingend angewiesen wäre. Das hätte man mit einem 16C Die entschärft.
Seh ich jetzt nicht so. Spielt ja nur eine Rolle bei 12/16 Core CPUs.
Ob dafür alleine Stückzahlen in einer Größenordnung erreicht werden, die ein Maskensatz liefern kann (~1+ Millionen Stück)?
------
ChatGPD spuckt mir aus, dass ein EUV Maskensatz alle 20 bis 50 Belichtungen gereinigt und das 100 bis 500 Reinigungsvorgänge möglich sind. Sind wir im Minimum bei 20 x 100 = 2000 Wafer. Bei ~700 75mm² pro Wafer sind das 2000 x 700 = 1,4 Millionen Chips Minimum bis 50 x 500 x 700 = 17,5 Millionen Chips.
Non EUV Masken halten länger.
Ist eine ziemliche Spanne. Hat da jemand bessere Zahlen?

[HOT]

Ich denke auch, dass das 16 Core CCD N2 ist und nur das 8 Core N3irgendwas.
Lisa war ja hin und weg von GAAFETs, scheint für AMD eh ein großes Ding zu sein.

[reaperrr]

Ich denke auch, dass das 16 Core CCD N2 ist und nur das 8 Core N3irgendwas.
Lisa war ja hin und weg von GAAFETs, scheint für AMD eh ein großes Ding zu sein.
Warum sollte man in N2 sowohl ein 16C-CCD als auch ein 32C-CCD machen?
N2 macht mehr Sinn fürs 32C-Zen6c-CCD, weil dort auch der Logik-Anteil höher ist (unter der Annahme, dass das 32c-CCD die gleiche L3-Menge wie das 16C-CCD haben wird).

Die Gerüchteküche sagt außerdem, dass sowohl AMD als auch Intel mit NVL/Zen6 endlich mehr Kerne für Desktop bringen, aber dass auch für Desktop-Chiplets der nochmal deutlich teurere und evtl. in der Kapazität eingeschränkte N2-Prozess verwendet wird, glaube ich noch nicht.
Und dass AMD über 2 CCDs je CPU hinausgeht auch nicht, außer sie überlegen sich wirklich was für CCD2CCD (gemeinsamer L3-Basischip?), aber dann stellt sich generell die Frage nach dem Sinn von größeren CCDs.

[w0mbat]

Da exakt gleich gross, erlaubt das Mix & Match und Wafer-on-Wafer Stacking

WoW hat den Nachteil, dass man vorher nicht die KGDs selected kann, man also ein Ü-Ei Verfahren hat. Bei kleinen dies mit hohem yield kann WoW günstiger sein, aber selbst bei ~70mm² ist CoW aktuell die bessere Wahl. Zen 5 X3D ist nach meinen Infos weiterhin CoW, obwohl cache die und CCD gleich groß sind und AMD sicher gute yields hat.

[amdfanuwe]

aber selbst bei ~70mm² ist CoW aktuell die bessere Wahl. Zen 5 X3D ist nach meinen Infos weiterhin CoW, obwohl cache die und CCD gleich groß sind und AMD sicher gute yields hat.
dachte ich auch. Schau mal hier rein: https://semianalysis.com/2024/02/09/hybrid-bonding-process-flow-advanced/

Mit den gleich großen Chips wird AMD sicherlich damit experimentieren und Erfahrungen sammeln, wie sie zukünftig am günstigsten produzieren können.

[davidzo]

Der Yield müsste eigentlich so gut sein dass das kaum eine Rolle spielt.

AMD hat derzeit keine einzige Zen5 CPU mit beschnittenem L3 Cache. So gut sind die Yields also dass es sich nicht lohnt eine 16MB SKU aufzulegen. Es gibt einfach nicht genug Ausschuss DIEs mit einem Fehler im Cache. Es würde mich wundern wenn der Yield nach Salvage deutlich schlechter als 99% wäre.

Von Zen4 gab es ebenfalls rund zwei Jahre lang keine einzige CPU mit beschnittenem L3 und erst seit Juni diesen Jahres gibt es einen obskuren Epyc 4124P mit 4C/8T und 16Mb L3 auf Raphael Basis. Zwei Jahre lang musste AMD sammeln um auf eine ausreichende Stückzahl zu kommen für eine obskure edgeserver/embedded SKU und selbst dann ist es unklar ob jeder 4124T überhaupt Defekte im L3 hat oder nur nach bedarf gebinnt wurde.

Und selbst wenn man ausversehen ein bad-DIE auf den X3D Cache setzt oder der X3D Die einen Fehler hat heißt das ja noch dass das total Ausschuss ist. Es gibt ja auch noch 7600x3d und co.

Ich kann mir eher vorstellen dass im wafer on wafer Verfahren vielleicht unterschiedliche Wärmeausdehnung der Wafer, Durchbiegung, etc. eben ein höherer Ausschuss entsteht als wenn man jeden DIE einzeln positionieren kann. Das wäre dann aber der Yield des WoW Verfahrens der schlechter ist und nicht der Yield der Einzel-DIEs.
EDIT: Der Link zu Semianalysis beschreibt aber genau das Gegenteil bei WoW, also höhere Genauigkeit, höherer yield. AMDs eigene Folie sieht den turnover point wo w2w ineffizienter als D2W wird erst bei 225mm2, nicht bei 70 und geringer.


Auch möglich wäre dass es bei WoW einfach derzeit nicht mit den Kapazitäten passt.

[amdfanuwe]

Der Yield müsste eigentlich so gut sein dass das kaum eine Rolle spielt.


Bei Cache hat man Redundanzzellen eingeplant.
Bei den CPU Chiplets kommt es darauf an, welche Prioritäten man setzt.
Wenn man nur die besten Chips mit hohen Frequenzen und niedrigem Verbrauch fürs stacking verwenden will, also die besten 10% eines Wafers, sieht die Kostenrechnung für WoW schon anders aus.

Letztendlich kommt es auf die Kosten des finalen Chips an über die gesamte Produktpalette gerechnet. Da sitzen genügend Leute bei den Herstellern mit gespitzten Bleistiften um das auszutüfteln.

[Badesalz]

Ich kann mir eher vorstellen dass im wafer on wafer Verfahren vielleicht unterschiedliche Wärmeausdehnung der Wafer, Durchbiegung, etc. eben ein höherer Ausschuss entsteht als wenn man jeden DIE einzeln positionieren kann.Das geht über das Grundmaterial (Menge->Dicke) selbst. Damit regelt man die Ausdehnungskoefizienten des Ganzen. Ja, das gegenseitige Einpedeln kostet. Bisschen Fläche und bisschen Kohle. Rechnet sich aber vollkommen gegenüber dem Theater was man sich ohne dessen ans Bein binden würde.

[basix]

Wenn man nur die besten Chips mit hohen Frequenzen und niedrigem Verbrauch fürs stacking verwenden will, also die besten 10% eines Wafers, sieht die Kostenrechnung für WoW schon anders aus.

Letztendlich kommt es auf die Kosten des finalen Chips an über die gesamte Produktpalette gerechnet. Da sitzen genügend Leute bei den Herstellern mit gespitzten Bleistiften um das auszutüfteln.

Wieso ist das ein Problem? Man bekommt ja immer noch die besten Die. Das Base Die mit Cache ist dort eh egal (ist günstig und hat faktisch 100% Yield) und wenn man ein zweites, benachbartes Chiplet für doppelte Cores braucht ist das halt etwas langsamer. Ist heute bei den 16C Modellen auch bereits so. Und die Wahrscheinlichkeit, dass schnelle CCD nahe beieinander liegen ist höher als kreuz und quer über den Wafer verteilt. Was man weniger gut kann ist CCD mit unterschiedlichen Charakteristika gezielt paaren (Vf-Curve, max. Takt, Effizienz). Da kann man dann halt nur eines der vier benachbarten Die verwenden. Man hat aber immer noch vier CCD für die Paarung zur Auswahl.

[amdfanuwe]

Reine Kostenfrage.

[basix]

Dein Link zeigt, dass man <200mm2 mit WoW immer günstiger fährt. Und wir reden hier von ca. 2x 60mm2.

[amdfanuwe]

Dein Link zeigt, dass man <200mm2 mit WoW immer günstiger fährt. Und wir reden hier von ca. 2x 60mm2.
Jup, wenn alle Chips verwendet werden können/sollen.

Aber rechne mal nach, wenn man nur an den 10% der besten Chips interessiert ist.
90% unnötig dem stacking unterzogen. Da könnte es billiger sein vorher zu selektieren und die 90% anderen billigen SKUs zuzuführen.

[w0mbat]

Dein Link zeigt, dass man <200mm2 mit WoW immer günstiger fährt. Und wir reden hier von ca. 2x 60mm2.
In der Theorie. In der Praxis kann das wieder anders aussehen. Aktuell bonded TSMC nur thinned wafer und nutzt eigentlich immer reconstituted wafers. Es wird einen Grund geben, wieso Zen 5 immer noch CoW ist.

[basix]

Jup, wenn alle Chips verwendet werden können/sollen.

Aber rechne mal nach, wenn man nur an den 10% der besten Chips interessiert ist.
90% unnötig dem stacking unterzogen. Da könnte es billiger sein vorher zu selektieren und die 90% anderen billigen SKUs zuzuführen.

Es gibt einen 7600X3D, 7800X3D, 7900X3D, 7950X3D. Das sieht für mich so ziemlich nach allen Chips aus.

Es wird einen Grund geben, wieso Zen 5 immer noch CoW ist.

Hier ein Foto der zwei Die: Gleich breit, aber anscheinend nicht gleich hoch. WoW fällt da also raus.
https://x.com/94G8LA/status/1854441170027626564

[mboeller]

Hier ein Foto der zwei Die: Gleich breit, aber anscheinend nicht gleich hoch. WoW fällt da also raus.
https://x.com/94G8LA/status/1854441170027626564

ich klau jetzt einfach mal einen Kommentar aus dem Thread:


Why do they need a 75mm² die for 64MB of cache when 7800X3D could do it with around 30mm²?


->> WTF soll das???

[davidzo]

ich klau jetzt einfach mal einen Kommentar aus dem Thread:

Why do they need a 75mm² die for 64MB of cache when 7800X3D could do it with around 30mm²?

->> WTF soll das???

Weil die Kosten eines Dies nicht nur mit der Fläche skalieren sondern auch mit dem Prozess. Chips sind halt nicht nur zweidimensional sondern können unterschiedlichen metal stack haben, was den Preis per Fläche gravierend verändert. Das hat nichts mit dem Node zutun, der Metal stack kann innerhalb dessen auch variiert werden.

Ein 75mm2 Chip mit halbierter Layeranzahl hat auch halbierte Durchlaufzeiten und Prozesskosten. Bis auf die Kosten des Rohwafers muss der Chip also trotz der größeren Fläche nicht teurer sein.

[Zossel]

Ein 75mm2 Chip mit halbierter Layeranzahl hat auch halbierte Durchlaufzeiten und Prozesskosten. Bis auf die Kosten des Rohwafers muss der Chip also trotz der größeren Fläche nicht teurer sein.

Nicht ganz, die oberen Layer sind ziemlich grobschlächtig.

[w0mbat]

ich klau jetzt einfach mal einen Kommentar aus dem Thread:



->> WTF soll das???
Ich denke es ist ein Test. Später sehen wir IOD+cache im base chip.

[davidzo]

Nicht ganz, die oberen Layer sind ziemlich grobschlächtig.

Ist die Frage ob man überhaupt die ganzen Interconnect Layer eines normalen Metal Stacks braucht, wenn die Cache Transistoren eigentlich nur mit dem Top Layer verbunden sind und die Anbindung des CCDs einfach mit großen Via-last-TSVs gelöst sind die direkt durch den ganzen Cache Stapel gehen. Die TSVs können dann sogar dasselbe Pinout im Flipchip haben wie bei non-X3D CPUs.

Ich kann mir vorstellen dass man sich einen Großteil der oberen/letzten Layer sparen kann bei einem reinen Cache-DIE. Wie dem auch Sei sollten gerade diese Prozesschritte die günstigsten sein und die mit den einfachsten Masken und der schnellsten Durchlaufzeit, weil hier ja nichtmal EUV gebraucht wird.

[Der_Korken]

War es nicht auch so, dass bei Zen 3/4 die Tags des 3D-Caches auch im Base-Die waren, damit der Cache übereinander passt und nicht über die Cores ragt? Mit dem untenliegenden 3D-Cache kann man jetzt alles nach unten verschieben. Macht den teuren Die kleiner und den billigen nutzt man besser aus.

[Zossel]

War es nicht auch so, dass bei Zen 3/4 die Tags des 3D-Caches auch im Base-Die waren, damit der Cache übereinander passt und nicht über die Cores ragt? Mit dem untenliegenden 3D-Cache kann man jetzt alles nach unten verschieben. Macht den teuren Die kleiner und den billigen nutzt man besser aus.

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13627485&postcount=1535

[Gipsel]

War es nicht auch so, dass bei Zen 3/4 die Tags des 3D-Caches auch im Base-Die waren, damit der Cache übereinander passt und nicht über die Cores ragt?Nein. Der VCache-Die enthält auch die Tags für die 64MB zusätzlichen VCache.

[basix]

ich klau jetzt einfach mal einen Kommentar aus dem Thread:

Why do they need a 75mm² die for 64MB of cache when 7800X3D could do it with around 30mm²?

->> WTF soll das???

1. Das CCD ist 70mm² gross
2. Das Cache-Die ist ein gutes Stück kleiner als das CCD, ca. 60mm²
3. Das alte V-Cache Die ist eher so 40mm² rum

Aus 2.5x werden nun plötzlich nur nur noch 1.5x ;)

Ausserdem sieht man, dass auf dem neuen V-Cache Die noch neues Zeugs drauf ist. z.B. bei den FPUs hat es keinen Cache. In der Mitte hat es Zeugs, das auch irgendwie anders aussieht als beim alten Die (keine Ahnung was das ist, sind das die Tags?). Und die Zellen sind ein wenig weiter auseinander mit einem Raster dazwischen, vermutlich für Power-Vias zum CCD hin. Sieht für mich also alles erklärbar aus. Ein reduzierte Density ist bei einem Cache unter dem CCD zu 100% zu erwarten gewesen. Weil man eben Power-Vias usw. benötigt. Und bei den FPUs hat man den Platz halt einfach frei gelassen. Entweder weil es dort so viele Power-Vias braucht (Power-Density) oder den Platz für die 64 MByte einfach nicht benötigt hat.

https://www.techpowerup.com/review/amd-ryzen-7-5800x3d/images/arch98.jpg

Edit:
Das V-Cache Die ist wirklich ziemlich exakt 60mm² gross und der Bereich mit dem Cache (ohne FPU-Bereich) ist ~48mm² gross.

[Zossel]

Weil man eben Power-Vias usw. benötigt. Und bei den FPUs hat man den Platz halt einfach frei gelassen. Entweder weil es dort so viele Power-Vias braucht (Power-Density) oder den Platz für die 64 MByte einfach nicht benötigt hat.

Gerade die FPUs können gut heizen, bzw. brauchen viel Strom und damit eine möglichst niedrige Impedanz der Stromversorgung.
Vektorunits schalten halt viele Transen gleichzeitig.

Wäre auch mal spannend zu testen ob die ganzen bzgl. Spannungen zerfummelten Spieler-CPUs noch sauber richtig harten Vektor-Code durchnudeln können.

[Bolek]

Ist eine potente 35W Stromspar-APU für nanoITX Systeme in Aussicht? Ende 2025 will ich ein neues System bauen.

[robbitop]

Ist eine potente 35W Stromspar-APU für nanoITX Systeme in Aussicht? Ende 2025 will ich ein neues System bauen.

IIRC ist 2025 nur ein Refresh von Strix auf der Gerüchte Roadmap.
Und dummerweise veröffentlich AMD die APUs auch nur stark verzögert auf AM5. Ggf. kommt ja Strix bis dahin raus. Aber das habe ich noch nicht mal in den Gerüchten gesehen.
Aber bereits heute ginge das mit Phoenix fpr AM5. Und die TDP kann man ja auch im BIOS senken und auch noch ein bisschen undervolten (CO -30)

[Bolek]

IIRC ist 2025 nur ein Refresh von Strix auf der Gerüchte Roadmap.
Und dummerweise veröffentlich AMD die APUs auch nur stark verzögert auf AM5. Ggf. kommt ja Strix bis dahin raus. Aber das habe ich noch nicht mal in den Gerüchten gesehen.
Aber bereits heute ginge das mit Phoenix fpr AM5. Und die TDP kann man ja auch im BIOS senken und auch noch ein bisschen undervolten (CO -30)

Dann lasse ich mich mal überraschen.

[w0mbat]

1. Das CCD ist 70mm² gross
2. Das Cache-Die ist ein gutes Stück kleiner als das CCD, ca. 60mm²

Wie kommst du auf 60mm²? Das eine Bild mit dem abgelösten X3D die?

[iamthebear]

1. Das CCD ist 70mm² gross
2. Das Cache-Die ist ein gutes Stück kleiner als das CCD, ca. 60mm²
3. Das alte V-Cache Die ist eher so 40mm² rum

Aus 2.5x werden nun plötzlich nur nur noch 1.5x ;)

1.) Afaik gibt es kein Dummy Silizium mehr. Wie soll da ein größerer Die auf den kleineren gestacked werden? Deshalb die Annahme, dass der Cache Die mindestens so groß sein muss wie der CCD. Ob nun 71mm² oder 75mm² ist Haarspalterei.

2.) 40mm² war die erste Generation bei Zen3. Mit Zen4 wurde das Cache Die deutlich kleiner. Die genaue Größe habe ich nicht mehr im Kopf aber ich glaube es waren um die 33mm²[/QUOTE]

Ich denke es ist ein Test. Später sehen wir IOD+cache im base chip.

Wie stellst du dir das mit dem IOD mit 2 CCDs vor? Ich sehe da folgende Varianten:

a) Es wird beim 2. CCD einfach ein 2. IOD verbaut (möglicherweise teildefekt) => Ist relativ teuer

b) Es gibt einen großen IOD auf den bis zu 2 CCDs gestacked werden können. Der Cache ist geshared muss aber dann zum L4 werden was die Latenzen deutlich erhöht

c) Es gibt gar kein Dual CCD mehr und stattdessen z.B. einen 8 und einen 16 Kern CCD => Zusätzliche Designkosten für einen relativ kleinen Markt auch wenn mich das am Meisten freuen würde

[amdfanuwe]

b) Es gibt einen großen IOD auf den bis zu 2 CCDs gestacked werden können. Der Cache ist geshared muss aber dann zum L4 werden was die Latenzen deutlich erhöht

Warum L4 und deutlich erhöhte Latenzen?
AMD hat schon einen 16Core CCX, also schon Erfahrung mit entsprechender Cache Anbindung.
Warum sollten sie nicht 2 8 Core CCDs so auf einen gemeinsamen Base Die mit L3 VCache setzen können und sich der Chip somit wie ein native 16 Core verhält?

[Badesalz]

Ich verliere hier stellenweise den Überblick wann die Spekus Richtung Zen6 gehen und wann sie Richtung Zen7 abdriften ;)

[Orko]

Diskussion Chipgrößen bei Zen5X3D und Chipstacking als Blaupause für Zen6 und folgende:


Afaik gibt es kein Dummy Silizium mehr. Wie soll da ein größerer Die auf den kleineren gestacked werden? Deshalb die Annahme, dass der Cache Die mindestens so groß sein muss wie der CCD. Ob nun 71mm² oder 75mm² ist Haarspalterei.


CoWoS aka Chip-on-Wafer-On-Substrat Technologie:
Zwingend ist dabei der obere Chip (etwas) kleiner als der untere Chip-noch-im-Waferverbund*

Frage:
Inwieweit ist denn bei Zen5X3D klar welcher Chip auf welchen Wafer gestapelt wird?

Option A)
CCD Wafer wird hergestellt und vereinzelt
Cache Wafer wird hergestellt
CCD Chips werden auf den Cache Wafer aufgebracht
Wafer wird vereinzelt
Die Chipstapel werden auf das Substrat aufgebracht: Substrat - Cache - CCD - Heatspreader
-> CCD Chip kleiner als Cache Chip

Option B)
Cache Wafer wird hergestellt und vereinzelt
CCD Wafer wird hergestellt
Cache Chips werden auf den CCD Wafer aufgebracht
Wafer wird vereinzelt
Die Chipstapel werden auf das Substrat aufgebracht: Substrat - Cache - CCD - Heatspreader
-> Cache Chip kleiner als CCD Chip


IMHO ist Option B für Zen 5X3D technologisch deutlich näher an Zen3XD bzw Zen4X3D.
Die TSVs sind nun halt im Cache Chip statt im CCD Chip
Die Stapelchips werden nun mit Cache-nach-unten statt Cache-nach-oben auf das Substrat aufgebracht.
Konsequenzen wären:
- der Cache Chip ist etwas kleiner als der CCD Chip
- aber nur etwas, damit kein thermomechanischer ggf problemetischer Chipüberstand des CCD Chips auftritt

----
Prozessabläufe stark vereinfacht dargestellt, ohne Waferthinning und Support-Wafer
* :
Beim Prozess des Aufbringens der Chips auf den Wafer.
Nach Vereinzelung des Wafers (Wegsägen der Scribe Lines) ist es theoretisch auch möglich dass dann beide Chips genau gleich gross sind

[w0mbat]

X3D nutzt nicht CoWoS sondern SoIC-X. Und afaik werden beide dies auf einen carrier wafer aufgebracht.

[iamthebear]

Warum L4 und deutlich erhöhte Latenzen?
AMD hat schon einen 16Core CCX, also schon Erfahrung mit entsprechender Cache Anbindung.
Warum sollten sie nicht 2 8 Core CCDs so auf einen gemeinsamen Base Die mit L3 VCache setzen können und sich der Chip somit wie ein native 16 Core verhält?

Also wir wollen:
a) L3 von CCD1 und L3 im Base Die sollen weiterhin geshared werden
b) Gleichzeitig soll der L3 des Base Die auch mit CCD2 geshared werden
c) Das bedeutet, dass auch die L3 von CCD1 und CCD2 geshared sein müssen.

Also ein CCX das sich über 2 CCDs erstreckt mit einer Latenz um die 10ns bis zum L3 des anderen CCD. Das halte ich für ziemlich unrealistisch.
Ja AMD hat bereits ein 16 Kern CCX entwickelt aber das war weiterhin ein CCD.

Diskussion Chipgrößen bei Zen5X3D und Chipstacking als Blaupause für Zen6 und folgende:

CoWoS aka Chip-on-Wafer-On-Substrat Technologie:
Zwingend ist dabei der obere Chip (etwas) kleiner als der untere Chip-noch-im-Waferverbund*

Frage:
Inwieweit ist denn bei Zen5X3D klar welcher Chip auf welchen Wafer gestapelt wird?

Ganz unabhängig davon welche Packaging Technologie bei Zen5X3D verwendet wird:
Der untere Die wird niemals deutlich kleiner sein als der obere ohne dass der Rest mit Dummy Silizium aufgefüllt wird (was beim 9800X3D nicht der Fall ist).
Da gäbe es einen Hohlraum zwischen oberem Die und dem Untergrund wodurch der obere Die ziemlich schnell abbrechen würde sobald da ein Kühler mit > 30kg Anpressdruck draufgeschraubt wird.

[Orko]

@w0mbat

Stimmt da hast du Recht, X3D Technologie ist SoIC, nicht CoWoS.
Ist hier etwas detaillierter beschrieben:
https://semianalysis.com/2024/02/09/hybrid-bonding-process-flow-advanced/

Aber für beide sehe ich nicht, dass der in der fertigen CPU unten liegende Chip zwingend grösser sein muss als der oben liegende Chip.

CoWoS:
Siehe oben. Der Chipstapel kann auch geflipped auf das Substrat aufgeracht werden.
Das ergibt dann: Substrat - kleinerer Chip - größerer Chip - Heatspreader

SoIC:
Beide Chips werden vereinzelt, dann auf Carrier Wafer aufgebracht, und dann hybrid-gebondet.
Die Größen der Chips sind primär unabhängig voneinander.
Der fertige Chipstapel wird dann auf das Substrat aufgebracht.
Auch hier kann der kleinere Chip unten liegen: Substrat - kleinerer Chip - größerer Chip - Heatspreader

Ich sehe also nicht, dass bei Zen5X3D der unten liegende Chip (Cache) größer als der oben liegende Chip (CCD) sein muss.
Also auch nicht für mögliche gestapelte Zen6 Designs.

[Orko]

Ganz unabhängig davon welche Packaging Technologie bei Zen5X3D verwendet wird:
Der untere Die wird niemals deutlich kleiner sein als der obere ohne dass der Rest mit Dummy Silizium aufgefüllt wird (was beim 9800X3D nicht der Fall ist).
Da gäbe es einen Hohlraum zwischen oberem Die und dem Untergrund wodurch der obere Die ziemlich schnell abbrechen würde sobald da ein Kühler mit > 30kg Anpressdruck draufgeschraubt wird.


Zen5X3D:

Da bin ich bei deiner Aussage:
Der Cache Chip ist wohl nicht deutlich kleiner als der CCD, aber halt auch nicht zwingend größer als dieser.
Ein geringer Chipüberstand des CCD würde ohnehin mit dem Underfill Material ausgefüllt.


Zen 6 und folgende:

Mit CoWoS oder SoIC ohne zusätzliches molding (oder Ähnliches):
Da bin ich bei dir: Nicht deutlich kleiner, aber auch nicht zwingend grösser.

Mit z.B. InFO oder anderen Technologien bei denen der Chipstapel eingemoldet wird,
und damit Hohlräume / Überstände ausgefüllt werden,
bevor er auf das Substrat kommt,
kann der untere Chip durchaus deutlich kleiner sein.

Mit einer geeigneten Kombination aus
a) zunächst SoIC hybrid bonding, in welcher genauen Ausgestaltungsform auch immer
b) CoWoS / InFOn / ...
denke ich kann jede gewünschte Chipstapel-Kombo umgesetzt werden.

[Gipsel]

Mit z.B. InFO oder anderen Technologien bei denen der Chipstapel eingemoldet wird,
und damit Hohlräume / Überstände ausgefüllt werden,
bevor er auf das Substrat kommt,
kann der untere Chip durchaus deutlich kleiner sein.

Mit einer geeigneten Kombination aus
a) zunächst SoIC hybrid bonding, in welcher genauen Ausgestaltungsform auch immer
b) CoWoS / InFOn / ...
denke ich kann jede gewünschte Chipstapel-Kombo umgesetzt werden.Ja, ich habe auch schon darauf hingewiesen, daß AMD bereits beim MI200/250 große Chips auf kleinen (den elevated fanout-bridges) gestapelt hat. Die unteren sind ja sehr dünn und werden durch den mold mit wenigen 10 Mikrometer hohen copper pillars kontaktiert.

https://s20.directupload.net/images/241123/58eoaw8m.png

[MR2]

AMD präsentiert revolutionäre “Chip-Stapelung”-Technologie zur Optimierung der Die-Nutzung

https://www.igorslab.de/amd-praesentiert-revolutionaere-chip-stapelung-technologie-zur-optimierung-der-die-nutzung/

[][immy]

AMD präsentiert revolutionäre “Chip-Stapelung”-Technologie zur Optimierung der Die-Nutzung

https://www.igorslab.de/amd-praesentiert-revolutionaere-chip-stapelung-technologie-zur-optimierung-der-die-nutzung/

Ich kann mir ehrlich gesagt nur schwer vorstellen, das doch das gut kühlen lässt. Aber ggfs sinnvoll bei einer Variante wo die langsameren chips (bzw die welche weniger Wärme produzieren) unten sind.

[amdfanuwe]

Habs mal etwas eingefärbt.
Im Schnitt FIG. 4 erkennt man deutlich, dass die kleinen Chips oben liegen, teilweise den großen Chip (Gelb 25) überlappend.
Das ganze zu einem Chip ( Orange 115) vergossen.

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=90324&stc=1&d=1732451291

[Badesalz]

1. Soll das mit Zen6 kommen? :|

2. Die Stelle wo das patentwürdig ist, weil eben ganz anders als Foveros, ist? Oder ist das sozusagen IN Die?

[amdfanuwe]

Müsste man das Patent mal komplett lesen können.

[HPVD]

Müsste man das Patent mal komplett lesen können.

hier findet man einiges verteilt über die verschiedenen Tabs:
https://worldwide.espacenet.com/patent/search/family/068238342/publication/EP3785297B1?q=EP3785297B1

[Orko]

Habs mal etwas eingefärbt.
Im Schnitt FIG. 4 erkennt man deutlich, dass die kleinen Chips oben liegen, teilweise den großen Chip (Gelb 25) überlappend.

Danke! Etwas Farbe macht das gleich viel leichter lesbar / erfassbar / interpretierbar / verständlicher.



Die Stelle wo das patentwürdig ist, weil eben ganz anders als Foveros, ist?

Die Frage der "Patentwürdigkeit" wird IMHO meist von Aussenstehenden überschätzt.

Es geht bei Patenten schon lange nicht mehr so wirklich um erfinderische Leistung, sondern um einen Industriezweig der mit geistigem Eigentum Geld verdient / umsetzt (Gebühren, Anwälte, Lizenzabkommen, Patent-Trolle) bzw Interessen verteidigt (Produktschutz).

Beispiel:
Firma A hat eine Idee X und patentiert diese.
Firma B liest das veröffentliche Patent, findet die Idee X interessant, und möchte diese ggf in einigen ihrer kommenden Produkte umsetzen.
Firma B kleistert mit Patenten der Form "X in Kombination mit Yn" das Themenfeld zu.
Firma B geht auf Firma A zu:
Hallo, ihr habt ca n Patente der Form "X + Yn", und wir haben nun auch ca n Patente der Form "X+Yn".
Keiner von uns kann ein Produkt auf den Markt bringen, ohne ein Patent des anderen zu verletzen.
Lasst uns doch deshalb unsere Patente gegenseitig lizensieren, und uns beide in Absprache gegen Dritte möglichst abschotten.
Das ist gut für uns beide.

Es ist im wesentlichen eine Art Monopoly-Spiel, wer welche interessanten Themenfelder wie schnell (vor möglichen Anderen) mit wie vielen Patenten zupflastern kann. Die strategische / produktpolitische Aussagekraft eines einzelnen Patents ist meist eher gering. Zumindest solange man kein Insiderwissen hat, was an dem Patent nun "wichtig" und was Blendwerk / Ablenkung / Ausschmückung, ... ist.

-----

1. Halbleiterchipvorrichtung, umfassend: ein rekonstruiertes Halbleiterchipgehäuse (115), einschließlich eines Interposers (125), der eine erste Seite und eine zweite und gegenüberliegenden Seite und einen Metallisierungsstapel (145) auf der ersten Seite, einen ersten Halbleiterchip (25) auf dem Metallisierungsstapel und mindestens teilweise umhüllt von einer dielektrischen Schicht (165) auf dem Metallisierungsstapel, mehrere Verbindungselemente (202), die zwischen dem ersten Halbleiterchip und dem Metallisierungsstapel positioniert sind und diese elektrisch verbinden, und mehrere Halbleiterchips (30, 35, 40, 45, 95, 100), die über dem ersten Halbleiterchip (25) positioniert sind und diesen mindestens teilweise seitlich überlappen, aufweist dadurch gekennzeichnet, dass die dielektrische Schicht (165) eine Öffnung (260) einschließt, die geeignet ist, um einen Abschnitt eines Wärmeverteilers (265) darin zu positionieren, um thermischen Kontakt mit dem ersten Halbleiterchip (25) herzustellen.

Eine klassische Kombinations-Erfindung:

Es wird ein Bauteil beschrieben das eine Kombination von Eigenschaften aufweist,
welche in dieser Kombination einfach bisher nicht patentiert worden sind,
um
a) Ein konkretes Bauteil mit diesen Merkmalen vor Wettbewerber (Nach)Bauten zu schützen
und/oder
b) Claims (Patent-Themenfelder) abzustecken bzw zuzupflastern, als Verhandlungsmasse für Lizenz-Abkommen.

Das ganze geht in möglichst beeindruckendem Patentanwalts-Deutsch formuliert als Patentanmeldung an die Patentstelle(n),
und dann wird deren Reaktion abgewartet:

Entweder es kommt durch, wird also als Patent akzeptiert.

Oder es gibt Entgegenhaltungen.
Diese geben genau an, warum das Patent in dieser Form nicht patentwürdig ist, also an welchen Stellen genau die "erfinderische Leistung" unzureichend ist.

Dann werden im so von der Patentstelle aufgezeigten Themenfeld solange optionale Ausführungsbeispiele in die Kernbeschreibung übertragen (Die Kombination an Eigenschaften die alle zugleich erfüllt sein müssen wird erhöht) bis die Patentstelle akzeptiert.

</OT>

[iamthebear]

Nur weil eine Firma etwas patentiert bedeutet nicht, dass das zwingend in der nächsten Generation haargenau so kommen muss.
Da wurde einfach etwas erforscht und patentiert. Ob das dann auch in irgendeiner Soarte einmal Sinn macht muss sich erst zeigen.

[amdfanuwe]

hier findet man einiges verteilt über die verschiedenen Tabs:
https://worldwide.espacenet.com/patent/search/family/068238342/publication/EP3785297B1?q=EP3785297B1
Danke, hatte danach gesucht aber nichts gefunden.

[stinki]

Laut MLID scheinbar 12Core CCD bei Zen6
https://www.youtube.com/watch?v=h5dDn8nzvAw
Wären dann 12Cores für Medusa Point, 12/24Cores für Medusa Ridge, 16x12Cores für Venice, und 8x32Cores für Venice dense.

[mironicus]

Zen 6 wird wirklich interessant. Jetzt auch mit einer NPU an Bord?

[Badesalz]

Zen 6 wird wirklich interessant.Wohl ja, aber für mich vor allem (erstmal) wegen all den neuen Geschichten um den I/O rum :wink:

[basix]

Hmm, interessante Idee mit den 12C pro CCD. Würde den momentanen MT-Nachteil gegen Intel deutlich reduzieren. Anstatt 8C & 6C SKUs gäbe es dann wohl 12/10/8C SKUs. Damit kommen aber gleich ein paar Fragen auf: Alles Big Cores? Gibt es noch ein separates 8C CCD? Gibt es ein 16C CCD neben dem 12C CCD (alles Big Cores)? L3$ pro Core bleibt bei 4MByte?

Desktop IOD würde dann vermutlich bei 2x CCD bleiben.

[Badesalz]

@basix
Also die Gerüchte um den V-Cache unter jedem CCD waren ja schlecht. Ok :tongue: Wo aber gab es überhaupt welche, daß es im Desktop nicht nur BigCores geben sollte?

Oder beziehen sich deine Fragen eher auf Laptops? Gabs da schon etwas selbst von MLID :ulol: zu hören?

[basix]

Ich würde z.B. erwarten, dass es für Server 32C & 16C Chiplets geben wird und da ist 12C mit All-Big-Cores ein wenig schräg drin. Mit 8+4C und Consumer only wäre das irgendwie "sinnvoller".

Eine andere Möglichkeit wäre 12C / 24C in 3nm und 32C in 2nm. Keine Ahnung, gibt viele Möglichkeiten ;) Vielleicht macht es AMD auch ganz krumm mit 12/20/32C CCDs :D

[stinki]

Das 12Core CCD sollen alles Big Cores sein. Sehr wahrscheinlich in N3.
Ein 16Core CCD bräuchte man nicht, wenn man Venice, wie heute Turin, mit 16CCDs a 12 big Cores baut. Damit käme man auf die für Venice spekulierten 192 big Cores.
Und für Venice dense gibt es das 32 dense Core CCD. Sehr wahrscheinlich in N2. Damit käme man auf die für Venice dense spekulierten 256 dense Cores (8x32Cores).
Das Medusa Point IOD soll 16CUs (RDNA4? für UDNA wahrscheinlich zu früh) und eine dicke NPU bekommen.
Für Medusa Ridge wird es ein anderes IOD, wahrscheinlich mit weniger CUs und für zwei CCDs, geben (mal schauen wie dick die NPU im Desktop IOD wird).
Ein 8Core CCD mit big Cores und ein 16Core CCD mit big Cores braucht man eigentlich nicht.
12 big Core CCD (N3) und 32 dense Core CCD (N2) reicht eigentlich für die gesamte Produktpalette.
Und Medusa Halo, mit vielen CUs im IOD, 256bit Memory-Bus und ein/zwei CCDs (12/24 Cores), kommt bestimmt auch.

Für mich sieht das alles extrem straight-forward aus von AMD als Weiterentwicklung der Produktpalette von Zen5 nach Zen6.

[Badesalz]

Ich würde z.B. erwarten, dass es für Server 32C & 16C Chiplets geben wird Dann passt du nicht gut auf. Die Serverguys haben zu intel von Anfang an gesagt:
- Nur P-Cores ist ja normal. Alles gut.
- Nur E-Cores könnte interessant sein. Lass mal sehen.
- P+E braucht ihr im Xeon aber nicht bringen. Das könnt ihr direkt behalten.

Und Intel hält sich daran ;) Ich kann mir also nicht vorstellen, daß AMD dazu shicegal sagt und doch sowas bringt. Für wen? Als Technologiestudie?

[basix]

Du hast meinen Post glaube ich nicht verstanden ;)

Ich gehe davon aus, dass bei den Server-Chiplets alle Cores gleich sind. Ob das 12/16/20/24/32 Cores pro Chiplet sind wäre egal. Aber falls es ein 16C-Server Chiplet gibt, dann wäre ein allfälliges 12C Chiplet wohl nicht einfach 12 "Big" Cores (zu nah dran an 16C), sondern dann eher 8+4C und zudem Consumer only. Falls es kein 16C Chiplet gibt (sondern z.B. 20C), dann wird das 12C Chiplet wohl nur "Big" Cores tragen.

Eine Ausnahme gäbe es beim P+E Mix für Server: Wenn der Taktunterschied so gering ist, dass es keine Rolle spielt. Schaffen die E-Cores ~80% des Taktes der grossen Cores (und bei gleichem Takt ähnlichen Verbrauch), dann schaffen die E-Cores die peak Taktraten von Server-CPUs. Und dann ist es gegen aussen egal, ob das nun P oder E Cores sind. Die Performance sowie das Featureset wären identisch. Das ist ganz anders als die Situation bei Intel. Ich hatte hier im Thread schon mal spekuliert, dass die E-Cores aufgrund N3E & FinFlex näher an die P-Cores ranrutschen könnten. Bei Server werden die Taktraten dann auf "E-Core" Niveau reduziert. Bei Desktop und xxF Server-CPUs macht man sich die Taktraten der grösseren Cores zunutze.

[Badesalz]

Consumer-only, meinte ich damit eigentlich auch. Denn man sieht nun endgültig was das für ein Chaos ist und wie wirsch die Leistung auf die Straße gebracht wird.

Die Blauen haben jetzt genug Antiwerbung dafür gemacht. Wenn man ALLES selbst bestimmt, wie Apple, mag das funktionieren. Sonst wohl eher nicht...

[HOT]

Laut MLID scheinbar 12Core CCD bei Zen6
https://www.youtube.com/watch?v=h5dDn8nzvAw
Wären dann 12Cores für Medusa Point, 12/24Cores für Medusa Ridge, 16x12Cores für Venice, und 8x32Cores für Venice dense.

Jop, man kann sich schon in etwa zuzsammenreimen, wie das letztendlich aussieht:

- xxx-Point -> Zen6-Monolith mit Grafik für den günstigen Markt nach Kraken Refresh
- Medusa Point -> UDNA1 IOD mit 16-20CUs + 1 12C CCD nach Eagle Point
- Medusa Halo -> UDNA1 IOD mit 40+CUs + 2 12C CCD nach Strix Halo
- Medusa Ridge -> RDNA3.5 IOD mit 2 WGP + 2 12C CCD nach Granite Ridge (Refresh?)

MMn wird Medusa Ridge ca. September/Oktober 2026 erscheinen, Point, Halo und der "neue kleine"-Notebooks zur CES 2027, Venice mMn erst Anfang 27.

Da Lisa so auf GAA-FETs steht, würde ich sagen, dass das CCD doch schon N2 ist (vielleicht mit günstigem Spinoff in SF2P?). Das soll ja sicherlich auch 2 Jahre vorhalten und Intel geht dann ja schon auf 18A-P mit Nova Lake. Das Mesuda Ridge-IOD ist mMn N4c und die Mobile-IODs sind genau wie UDNA1-GPUs mMn N3P.

[w0mbat]

SF2P? SP3 läuft so schlecht, dass es nur einen 18mm² Chip gibt, der auch noch ein schlechtes yield hat.

[HOT]

Ja vielleicht bekommt man es ja doch hin. Ist ja dann Ende 26 oder Anfang 27. Man muss sie ja nicht immer kommen sehen, warten wir es einfach mal ab, was passiert.
Ist ja nur ne wilde Speku sonst nichts.

[Zossel]

Ich würde z.B. erwarten, dass es für Server 32C & 16C Chiplets geben wird und da ist 12C mit All-Big-Cores ein wenig schräg drin.
Was ist daran "schräg"?

[iamthebear]

1.)
Also ich finde die Idee von 12 Kernen gar nicht so schlecht. Das ist denke ich ein guter Kompromiss. Das gibt eine gute Gaming CPU ab:
.) 12x Zen6 in 3nm auf einem ca. 80mm² CCD
.) 128MB Vache Die unterhalb (wie 9800X3D)

2.) Auch im Serverbereich sehe ich jetzt nicht unbedingt das Problem. Wenn wir uns die letzten Generationen ansehen:
Zen3: 8x8=64 Kerne

Zen4: 12x8=96 Kerne
Zen4c: 8x16=128 Kerne

Zen5: 16x8=128 Kerne
Zen5c: 12x16=192 Kerne

Der nächste Schritt wären dann:
Zen6: 16x12=192 Kerne ODER
Zen6c: 8x32=256 Kerne

Ob nun 16x12 oder 12x16 dürfte relativ egal sein.

3.) Was den Desktopbereich angeht hätte man folgende Möglichkeiten:
a) 1x12 Kerne + optional VCache: Entweder als Premium Gaming CPU oder als Midrang Alrounder
c) 1x10 oder 1x8 Kerne + optional VCache als Midrang Gaming CPU oder günstigere Einstiegs CPU
d) Für Low End Bürorechner 6 oder 8 Kerne Zen5: Für die will man sich den teureren IOD + Packaging sowieso nicht leisten.
e) 2x12 Kerne ohne VCache als Multimedia Topmodell gegen Intel Nova Lake (laut Gerüchten 16P+32E). Bei Bedarf auch noch 2x8 um die Lücke zu füllen.
f) Zusätzlich noch 2x12 Kerne mit einem VCache CCD für Gaming + Multimedia

[amdfanuwe]

Ja, 12C Chiplet hat seinen Reiz. Dürfte von der Größe und TDP her passen.
1.)

3.) Was den Desktopbereich angeht hätte man folgende Möglichkeiten:
a) 1x12 Kerne + optional VCache: Entweder als Premium Gaming CPU oder als Midrang Alrounder
c) 1x10 oder 1x8 Kerne + optional VCache als Midrang Gaming CPU oder günstigere Einstiegs CPU
d) Für Low End Bürorechner 6 oder 8 Kerne Zen5: Für die will man sich den teureren IOD + Packaging sowieso nicht leisten.
e) 2x12 Kerne ohne VCache als Multimedia Topmodell gegen Intel Nova Lake (laut Gerüchten 16P+32E). Bei Bedarf auch noch 2x8 um die Lücke zu füllen.
f) Zusätzlich noch 2x12 Kerne mit einem VCache CCD für Gaming + Multimedia
Seh ich nicht ganz so.
12C löst den bisherigen 8C ab.

12C X3d sollte der neu Gaming Champion werden.
12C und 10C entsprechend als x700X und x600X
Darunter, <=12C, APUs, also Strix Point und Krackan Point Nachfolger.
Dazu auslaufen der ZEN5 Modelle.

Könnte mir auch vorstellen, dass ZEN6 PCIe6.0 mitbringt. Sind natürlich nur mit neuen Boards dann auch nutzbar, wie es schon mit PCIe 4.0 damals war.
Obwohl, Xilinx bringt jetzt schon mit Versal Premium https://www.amd.com/en/products/adaptive-socs-and-fpgas/versal/gen2/premium-series.html?utm_source=x&utm_medium=social&utm_campaign=versal-premium-gen2&utm_content=infographic-anchor#infographic PCIe 6.0.
Vielleicht gibt es ja schon nächstes Jahr für ZEN5 Refresh ein überarbeitetet IO-Die mit PCIe 6.0 damit es dann mit ZEN6 rund läuft. Die Industrie braucht ja auch Boards, auf denen sie Versal Premium Beschleuniger unterbringen können.

Bei dem ganzen stellt sich die Frage, wo das noch hin führt:
Für Heim Office und Media reichen eigentlich 4C. Gaming ist mit 8CX3D gut bedient. Wer mehr Professionell mehr Cores braucht, nimmt Threadripper.
Bleibt für >12C Desktop eigentlich nur eine kleine Zielgruppe. Oder seh ich das falsch?

[Badesalz]

12C X3d sollte der neu Gaming Champion werden.Aber nicht der möglichst schnellste oder? Wenn man schon beim 8c SMT ausmacht und manches nochmal paar Prozent zulegt. Eine Realität die kollektiv nicht wahrgenommen werden will und wenn sie schon am Rande auftaucht, dann sind es halt die Konsolen schuld :wink:

Bei dem ganzen stellt sich die Frage, wo das noch hin führt:
Für Heim Office und Media reichen eigentlich 4C. Gaming ist mit 8CX3D gut bedient. Wer mehr Professionell mehr Cores braucht, nimmt Threadripper.Wenn die Software überhaupt so hoch skaliert muss es auch nicht gleich ein Threadripper sein. Da tun es auch schon die 12c und 16c.
-> Man sollte sowas auch in Threads und nicht in Cores rechnen :wink:
Da kommt man schoin mit einem 12c sehr weit. Nicht jeder der da was semipro oder gar pro mit zu tun hat, hat einen lohnenswerten Nutzen mit Plattformen die gleich das mehrfache kosten.

Die meisten tun es eben nicht. Die ganzen Dachbodennerds die sich von links nach rechts und dann zurück einen in die Tasche lügen tun immer so als wenn sie selbst und mind. die halbe Welt dadraußen ständig etwas mit Handbrake, 7-zip und PremierePro machen würde. Tut sie aber nicht. Und sie selbst meist auch eher selten bis ebenfalls nicht.

Bleibt für >=12C Desktop eigentlich nur eine kleine Zielgruppe. Oder seh ich das falsch?Bisschen. Habs korrigiert.

[basix]

12C "für die Massen" wäre schon langsam an der Reihe. Intel bietet schon länger eine höhere MT-Performance bei den kleineren Modellen und jetzt hat man auch bei Strix Point / Mobile bereits 12C. Es fühlt sich einfach richtig, den Core Count etwas zu erhöhen. 8C gibt es nun bereits seit Zen 1. 12C ist hier irgendwie das gesunde Mittelmass. 16C wäre vom Sprung her evtl. zu gross und die meisten können so viele Cores eh nicht nutzen.

Zum L3-Cache / V-Cache: Ich vermute man wird bei 4MB/Core bleiben. Dann wären es 48MByte auf dem Die und 96 + 48 = 144MByte mit V-Cache. Wird interessant, was das bei Spielen ausmachen würde :)

Was ist daran "schräg"?
12C Big & 16C Big im selben Portfolio wären schräg ;)

Aber vielleicht ist es so wie iamthebear hier (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13658587#post13658587) sagt: Bis zu 16*12C bei Epyc. Dann hätte man wieder nur 2x CCD: 12C Big & 32C Small. Dann passt das

[Skysnake]

@Badesalz

SMT ausschalten um mehr Leistung zu bekommen bedeutet nicht zwingend das man nicht mehr cores für mehr Leistung benutzen kann.

Durch SMT und zwei parallel laufende Threads/Prozesse wird z.b. der L1 und L2 geteilt. Das kann Leistungsprobleme verursachen die nicht mit mehr Kernen gegeben sind.

Zudem wenn du eh den Kern schon voll auslasten bedeutet ein zusätzlicher Thread nur noch zusätzlichen Overhead.

Im HPC macht man auch SMT in der Regel aus und das obwohl man auf hunderte, tausende, zehntausende oder noch mehr Kerne skaliert.

[Badesalz]

@basix
Für die Epycs ist das schon wichtig. Für den Desktop ist das ohne relevanten Belang.

Wird sich mit der Zeit verbreiten, wenns kommt, weil costa quasi entsprechend genauso und weil es halt keine 8c mehr gibt. Und sieht im TaskManager goiler aus.

Intel bietet schon länger eine höhere MT-Performance bei den kleineren ModellenVielleicht gehöre ich damit zu dieser "klaren Minderheit", aber MIR erscheint das schon seit einiger Zeit - nicht erst seit ArrowLake - schwierig vernünftig einzuschätzen welche reale Relevanz es hat was Intel vormacht.

Genauso schwierig wie die reale Relevanz dessen was Plebs-Reviewer diesbezüglich testen, wenn sie y-cruncher, Cinebench und Corona anwerfen, um dann von einer hochen oder niedrigen "Anwendungsleistung" zu sprechen.

@Skysnake
Ja. Ist ein Punkt. Man kann es aber auf dem Desktop des Plebs mit 8c und SMT und 16c ohne SMT schon ne ganze Weile an sich bequem vergleichen.

@all
Oder, könnte. Tat denn obiges schon jemand? Den Sinn ergeben halt nicht die Möglichkeiten/Fähigkeiten der Hardware, sondern der Software.

[basix]

Vielleicht gehöre ich damit zu dieser "klaren Minderheit", aber MIR erscheint das schon seit eingier Zeit - nicht erst seit ArrowLake - schwierig vernünftig einzuschätzen welche reale Relevanz es hat was Intel vormacht.

Für 08/15 Daily Stuff sind 8C genug und eine hohe ST-Performance ist in den meisten Fällen spürbarer als 8C -> 12C. Aber es gibt immer mehr Fälle, wo ich gerne eine schnellere CPU hätte. Das kann z.B. Shader Compilation bei einem Spiel sein. Ich arbeite zwischendurch mit Python-Skripts, welche auch parallele Tasks abarbeiten können. Daneben beschäftige ich mich ein wenig mit der UE5 und Cooking / Building von Projekten dauert mit dem 5800X3D einfach ziemlich lange. Wenn man keine solchen Use Cases hat, dann reichen 8C. Für mich sind 16C und der entsprechende Aufpreis aber auch etwas Overkill, da so hohe MT-Performance dann doch nicht so oft "gefordert" ist. Vielleicht hätte ich auf einen 5950X3D geupgraded, den gab es bei Zen 3 allerdings nie ;) (meine AM4 Historie ist 5600X -> 5950X -> 5800X3D)

Unter dem Strich: Für mich wären 12C X3D die "vernünftigste" Lösung. Als Single-CCD CPU. In vielen Fällen brauche ich nicht massig Cores aber es gibt Use Cases, wo ich gerne mehr MT-Performance hätte. Da bin ich vermutlich nicht der einzige und Dual-CCD CPUs kommen mit anderen Daily Usage Nachteilen daher (Stromverbrauch, Kühlung, Null Spiele-Skalierung). Wenn man 12C nicht braucht: Es wird 8/10C CPUs geben und die würden in Games von 48MByte L3$ ebenfalls profitieren ;)

[Badesalz]

@basix
In meine Posts ging es auch nicht um "sowas kann echt keine Sau gebrauchen"...

Vielleicht hätte ich auf einen 5950X3D geupgraded, den gab es bei Zen 3 allerdings nie (meine AM4 Historie ist 5600X -> 5950X -> 5800X3D)Dachte ich mir auch beim Lesen, warum du noch auf AM4 festsitzt :wink: aber irgendwie liest sich das immer wesentlich allgemeiner als es jetzt grad erschien.

[basix]

Dachte ich mir auch beim Lesen, warum du noch auf AM4 festsitzt :wink: aber irgendwie liest sich das immer wesentlich allgemeiner als es jetzt grad erschien.

Zen 4 war nice aber für +30% wechsle ich nicht die Plattform. Ausserdem hat AM5 ein paar Dinge, die mir nicht so ganz gefallen wollen. Zen 5 ist OK in 9800X3D Form aber die Plattform wurde nicht wirklich besser. Momentan plane ich für AM5+ und Zen 6. Das sollte von der CPU her wie auch Plattform ein schönes Upgrade geben (iGPU, NPU, lower idle power IOD & Chipset, all PCIe 5.0, USB4, WiFi 7). Da lohnt es sich dann auch für ein Upgrade ;)

[Zossel]

Im HPC macht man auch SMT in der Regel aus und das obwohl man auf hunderte, tausende, zehntausende oder noch mehr Kerne skaliert.

Die dort typischen "kurzen" und optimierten Schleifen schaffen es dort wahrscheinlich meistens die maximale Parallelität der FPU auch auszulasten.

BTW: Wer sich mal typischen HPC-Code anschauen möchte: https://gitlab.dkrz.de/icon/icon-model (Nichts für Flacherdler und Klimaleugner)

[BavarianRealist]

Wann soll Zen6 kommen?

Ich halte es für möglich, dass Zen6 nur noch in der X3D-Variante kommt, d.h. darauf optimiert ist, woraus AMD einen extremen Leistungssprung realisieren könnte. Schon deshalb könnte es nötig gewesen sein, dass das Die eine Größe um die 70mm² haben musste, weil evtl. das X3D-Chiplet die gleich Größe bei 96MB-L3 haben könnte. Das Zen6-Chiplet dürfte dann wohl eher nur noch 16MB-L3 oder sogar gar keinen mehr haben, weil L3 in 3nm/2nm reine Flächenverschwendung wäre, da er ja nicht mehr schrumpft. Für das X3D-Chiplet dürfte der 6nm-Prozess weiterhin ausreichen, zudem dürfte ein reines Sram-Chiplet mit weniger Layers auskommen als ein CPU-Die, sodass das L3-Chiplet nur einen Bruchteil kosten dürfte.

[basix]

Unwahrscheinlich, dass es keinen non-X3D CPUs geben wird. Nicht alle Spielen auf ihren Kisten oder die Performance ohne X3D ist bereits gut genug.

Der L3$ ist bei Zen 5 sehr klein geworden (~15mm2). Da die Hälfte wegschneiden bringt doch fast nichts mehr. Bei Zen 6 wären 48 MByte wohl ~20mm2 gross und helfen in vielen Workloads (Gaming, Server). Hier 10mm2 einzusparen und dafür öfters X3D zu verwenden wird unter dem Strich wohl einiges teurer sein.

Die kolportierten 75mm2 für das 12C Chiplet stimmen ziemlich gut mit meinem Erwartungswert überein für 12C + 48MB L3$ in N3E

[Skysnake]

@basix global Interpreter lock sagt dir was oder? Python kann nicht echt parallel laufen. Wenn dann irgendwelche Libs externen binaries die man called oder NumPy, was am Ende aber auch Libs sind.

Ok ok in der aller neuesten Version haben Sie sich dem wohl angenommen aber das muss ich mal noch evaluieren.

@Zossel

Das ist unpräzise formuliert. Die Schleifen sind normal sehr lange, bzw Sie sollten hunderte+ von Iterationen haben, ansonsten bekommst du nur schlechte Performance raus. Kurze looks von ner Hand voll Ierationen entrollt man am Besten händisch. Der Loop Overhead ist sonst nicht vernachlässigbar. Gerade wenn man multiple Codepfade vom Intelcompiler hat.

Wenn du aber meinst wieviel Code innerhalb einer Schleife steht dann stimmt das auch nur teilweise. Ja recht viele Anwendungen haben überschaubare Schleifen, aber es gibt auch solche mit hundert+ Zeilen Code.

[basix]

@basix global Interpreter lock sagt dir was oder? Python kann nicht echt parallel laufen. Wenn dann irgendwelche Libs externen binaries die man called oder NumPy, was am Ende aber auch Libs sind.

Ok ok in der aller neuesten Version haben Sie sich dem wohl angenommen aber das muss ich mal noch evaluieren.

Doch, doch, das geht schon. Zumindest als "Enduser Erfahrung" bei meinem Anwendungszweck ;)

Ich mache meistens einen Process.Pool() womit man mehrere Python-Prozesse/Instanzen spawned und das sind dann schon mehr oder minder unabhängige Worker-Threads. Prinzipiell sind es mehrere Python-Instanzen die parallel laufen, nichts paralleles innerhalb der einer einzelnen Python-Instanz. Auf denen mache ich dann das Heavy Lifting / Signal Processing (z.B. Algorithmen-Parameter Permutationen für Optimierungsprozesse). Gibt bei Python einen relativ grossen Overhead für den Thread-Spawn aber das kann man mit etwas Erfahrung leichtgewichtig halten (möglichst wenig Daten rumkopieren, Prozesse beibehalten und nicht immer neu spawnen) und 500ms Overhead für Process-Spawning sind bei 10sec Berechnungszeit auf 8 Threads (~60sec auf 1x Thread) dann auch nicht so tragisch.

In meiner Erfahrung und meiner Rechenlast ist Parallel Computing aber eh nur der letzte Hebel. Hatte mal ein organisch gewachsenes Simulationsskript was irgendwann mal 10min dauerte um durchzulaufen (im Rückblick halt auch maximal schlecht programmiert). Code Optimierungen haben es dann auf knapp 3sec runtergebracht, also ein 200x Speedup für den selben Task :D Das parallele abarbeiten von Tasks war etwa die Hälfte davon, ca. 1.5sec. Die zusätzlichen 6x Speedup durch 8x Threads lassen dann nur komplexere Simulationen, grössere Datensets und Permutationsbereiche zu, ohne dass die Rechnerzeit explodiert.

[HOT]

Unwahrscheinlich, dass es keinen non-X3D CPUs geben wird. Nicht alle Spielen auf ihren Kisten oder die Performance ohne X3D ist bereits gut genug.

Der L3$ ist bei Zen 5 sehr klein geworden (~15mm2). Da die Hälfte wegschneiden bringt doch fast nichts mehr. Bei Zen 6 wären 48 MByte wohl ~20mm2 gross und helfen in vielen Workloads (Gaming, Server). Hier 10mm2 einzusparen und dafür öfters X3D zu verwenden wird unter dem Strich wohl einiges teurer sein.

Die kolportierten 75mm2 für das 12C Chiplet stimmen ziemlich gut mit meinem Erwartungswert überein für 12C + 48MB L3$ in N3E

N3E hat er definitiv nicht, wenn dann N3P. Ich glaub das aber auch nicht, das CCD wird schon N2 sein.

[Skysnake]

@basix ich will dich ja jetzt nicht schockieren, aber laut google ist auch der Thread Pool durch den GIL betroffen. Es hilft also nur wenn man IO intensive Aufgaben hat die nicht im GIL hängen.

Ich befürchte du hat da überhaupt kein "heavy lifting" und könntest das bei ner Implementierung in C wahrscheinlich auf einem oder zwei cores in nem Bruchteil der Zeit erledigen.

Sorry Bro.

[Zossel]

@basix ich will dich ja jetzt nicht schockieren, aber laut google ist auch der Thread Pool durch den GIL betroffen. Es hilft also nur wenn man IO intensive Aufgaben hat die nicht im GIL hängen.

Ich befürchte du hat da überhaupt kein "heavy lifting" und könntest das bei ner Implementierung in C wahrscheinlich auf einem oder zwei cores in nem Bruchteil der Zeit erledigen.

Sorry Bro.
Hüstel:
multiprocessing is a package that supports spawning processes using an API similar to the threading module. The multiprocessing package offers both local and remote concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of threads. Due to this, the multiprocessing module allows the programmer to fully leverage multiple processors on a given machine. It runs on both POSIX and Windows.
https://docs.python.org/3/library/multiprocessing.html

Solange man nicht viele Daten hin und her kopiert kann man durchaus mit mehreren Prozessen arbeiten. Es ist aber auch bezeichnend Threads und Prozesse so bunt gemischt zu bezeichnen.
Das zitierte Intro zu dieser Klasse ist aber auch schon selten dämlich formuliert.

@basix: Ein fork(2) geht ziemlich schnell, Windows ist da, weil ohne fork(2), konzeptionell im Nachteil. Wenn du also ein richtiges OS nutzt solltest du die Datenvorbereitung an den tiefer liegenden Mechanismus von fork(2) anpassen bevor du die Prozesse forkst. Die Tochterprozesse kopieren die Daten erst wenn die Page beschrieben wird. Das hängt aber alles an den konkreten Aufgabenstellungen und Implementierungen.

[basix]

@basix ich will dich ja jetzt nicht schockieren, aber laut google ist auch der Thread Pool durch den GIL betroffen. Es hilft also nur wenn man IO intensive Aufgaben hat die nicht im GIL hängen.

Ich befürchte du hat da überhaupt kein "heavy lifting" und könntest das bei ner Implementierung in C wahrscheinlich auf einem oder zwei cores in nem Bruchteil der Zeit erledigen.

Ich bezweifle nicht, dass es in C deutlich schneller ginge. Das stelle ich nicht in Frage. Du stellst dir evtl. was anderes unter Heavy Lifting vor aber bei mir ist es das, das die längste Ausführungszeit braucht und auch sonst am meisten macht (eben alles durchrechnen, der Rest ist nur Skript Setup und Auswertung / Grafiken). Der Code ist nichtmal gross vektorisiert, da es eine serielle Signal Processing Chain durchrechnet, wo jeweils eine handvoll neue Messwerte reinkommen und der Algo ein Update macht. Klar gibt es da noch "Heavier Lifting" mit mehr Arithmetik-Throughput ;)

Und nein, die Prozesse sind nicht IO limitiert (ausser du rechnest hier den DRAM auch zu IO). Meine Prozesse sind zudem völlig unabhängig, ich brauche keinen Sync zwischen den Prozessen ausser am Schluss, wenn alles fertig gerechnet hat. Ich habe parallele Instanzen vom selben Algo mit verschiedener Parametrierung und die Input Datensätze sind ebenfalls nicht voneinander abhängig und in einer Vielzahl vorhanden. Viel einfacher etwas zu parallelisieren geht es nicht. Und dennoch nennt sich sowas parallelisiert ;)

[Badesalz]

Meine Prozesse sind zudem völlig unabhängig, ich brauche keinen Sync zwischen den Prozessen ausser am Schluss, wenn alles fertig gerechnet hat.Perfekt. Das hab ich mir schon die ganze Zeit gedacht :up:

Kann man in solchen Fällen eigentlich von MT-Leistung sprechen? :usweet:

[Skysnake]

Embarrassing parallel um genau zu sein. Aus der Beschreibung von dem Konstrukt ging jetzt aber nicht hervor, dass das auch geht. Ich würde bei Python immer sehr sehr sehr vorsichtig sein ob da wirklich etwas echt parallel geht.

Aber gut in dem Fall geht es dann vielleicht am Ende.

Und ob du RAM limitiert bist ist die Frage. Wenn dann wahrscheinlich durch die Latenz aber nicht durch den Durchsatz. Aber sein drum.

Es ging ja nur um die Grundsätzliche Aussage dass das Thema komplexer ist als man denkt

@Badesalz ja kann man. Siehe oben;)

Der deutsche Begriff ist Trivialparallel.

Ist ne ziemlich große Klasse an Problemen die da rein fällt. Zum Beispiel auch die MonteCarlo Simulationen.

[iamthebear]

Natürlich sind das MT Workloads. Diese Anwendung ist von ihrer grundsätzlichen Art schon paralleler Natur und wird deutlich besser mit mehreren Kernen skalieren als ein serieller Workload wie Spiele, der durch viel Aufwand teilparallelisiert werden kann.

Bestes Beispiel ist hier auch der klassische Datacenter Bereich. Ein Webserver, der 1000 verschiedene Clients gleichzeitig bedient skaliert wunderbar und das sind die Kunden, die auch gerne auf 256 Zen6c Kerne setzen auch wenn die ST Performance dann mieserabel ist.

Die Frage ist nur: Wie oft nutzt der Durchschnittsuser solche Anwendungen. Wenn ich an den normalen beruflichen und privaten Alltag denke und wie lange ich auf etwas warte ist das:
.) Windows updaten, Software installieren => ST oder vielleicht 2-3 Threads parallel
.) Dateien öffnen => ST
.) Software compilieren => In meinem Fall ST (bei den Mainstream Programmiersprachen aber MT)
.) Zeugs durch die Gegend kopieren wo der Virenscanner bremst => ST
.) Spiele => 6-8 Threads aber selten mehr und alles auf einem CCD, braucht primär L3/RAM
.) Gelegentlich ein paar Archive mit WinRAR erstellen => Skaliert bis ca. 8 Kerne, darüber ist es RAM Bandbreitenlimitiert. Ist aber selten dass ich große Archive habe wo ich wirklich lange warte

Aber wenn ich eine CPU kaufe gebe ich gerne etwas mehr für zusätzlichen Headroom aus. Das hat sich sowohl damals bei meinem 2600K (4C/8T) und 9900K (8C/16T) bewährt.
Abgesehen davon helfen mehr Kerne auch gut beim Shader compilieren.
Ein 7950X3D ist allerdings ziemlich uninteressant, da das 2. CCD in der Praxis für mich nie sinnvoll nutzbar sein wird und ich auf die Frickelei mit der Gamebar keine Lust habe.

[Nightspider]

Unwahrscheinlich, dass es keinen non-X3D CPUs geben wird. Nicht alle Spielen auf ihren Kisten oder die Performance ohne X3D ist bereits gut genug.

Der L3$ ist bei Zen 5 sehr klein geworden (~15mm2). Da die Hälfte wegschneiden bringt doch fast nichts mehr. Bei Zen 6 wären 48 MByte wohl ~20mm2 gross und helfen in vielen Workloads (Gaming, Server). Hier 10mm2 einzusparen und dafür öfters X3D zu verwenden wird unter dem Strich wohl einiges teurer sein.

Die kolportierten 75mm2 für das 12C Chiplet stimmen ziemlich gut mit meinem Erwartungswert überein für 12C + 48MB L3$ in N3E

AMD könnte doch auch auf 3MB L3 pro Core gehen und somit 36MB auf einem 12C Chiplets unterbringen.
N3 ist arschteuer und bei den APUs kam man bisher sogar mit 2MB pro Core klar.

Somit hätte ein 12C Chiplet immerhin 12,5% mehr L3 als die bisherigen 8C Chiplets. Für die meisten Anwendungen könnte es eventuell auch reichen und für die Kunden mit großem Bedarf an Cache wird es halt einfach die neuen V-Cache Varianten geben.

Immerhin soll das Chiplet nur 75mm² groß werden und es sollen 50% mehr Cores verbaut werden, obwohl nur rund 75% des Chips mit dem besseren Fertigungsprozss skalieren wird. Denn die Cache Zellen werden ja nicht mehr kleiner.

12C + 36MB Cache auf 75mm² klingt für mich irgendwie realistischer.

Es ist einfach effizienter den Cache aus dem teuren Compute Chiplet herauszuholen, welcher im teuren Fertigungsverfahren produziert wird.
Vielleicht gibts bei Zen6 auch erstmals 2 V-Cache layer.

[Badesalz]

Natürlich sind das MT Workloads.Nein. Es sind ST-Workloads die sich am Ende zu einem Ergebnis fügen.

Bestes Beispiel ist hier auch der klassische Datacenter Bereich.Sagte Skysnake schon. Trivialparallel. Der Sync bzw. die Syncs finden nicht während, sondern nach den Berechnungen. Das Beispiel mit dem Webserver passt aber :)

Aber wenn ich eine CPU kaufe gebe ich gerne etwas mehr für zusätzlichen Headroom aus. Das hat sich sowohl damals bei meinem 2600K (4C/8T) und 9900K (8C/16T) bewährt.Der Kontext war IMHO, ob das real Sinn macht und ob es nicht sogar leicht bis mittel kontraproduktiv ist, wenn die paar wenigen Threads zwischendurch ohne Not durch die Kerne gescheut werden, statt in Ruhe erstmal zu Ende da zu rechnen wo sie grad waren.

Sonst wäre das glaub ich JEDEM EGAL, wenn soetwas nie zu beobachten wäre (Preise mal ungeachtet). Und es würde sich JEDER FREUEN, wenn sich das sogar positiv auswirken würde, weil seine Soft mit mehr Threads mitzieht.
Beides fällt aber schonmal negativ auf. Nur deswegen ist das ja ein Thema :wink:

Das Prob ist im Gründe recht ähnlich dem mit der elektrischen Anbindung vom Hauptspeicher. Reicht das was man auf 2 Riegel bekommt ist man schnell dabei, weil man noch mit Takt und Timings so einiges rausholen kann. Wenn es nicht reicht oder Durchsatz eine größere Rolle spielt, wählt man 4 Riegel. Mehr RAM und mehr Durchsatz bringen dann mehr, aber man muss mit Takt und Timings runter.
Die allermeisten daheim haben einen Workload zu erledigen wo sie mit 2 Riegel besser dran sind als mit 4. Das ergibt halt ihre Software. Ähnlich ist es bisher bisher mit der Anzahl der Threads...

PS:
Es ist ja nicht so, daß ich das alles nicht gerne anders hätte. Es geht nicht, wie Lawmachine das gelegentlich sagt, um Frugalismus :wink:

[Zossel]

Nein. Es sind ST-Workloads die sich am Ende zu einem Ergebnis fügen.

Das sind 99% letztendlich auch, du versucht hier eine willkürliche Grenze bzgl. der Jobgröße zu ziehen.

[Badesalz]

Das sind 99% letztendlich auch, du versucht hier eine willkürliche Grenze bzgl. der Jobgröße zu ziehen.Real eher nicht. Für mich hängt das von der Art bzw. den Zeitpunkten der Syncs ab. Schrieb ich aber auch genau so hin... (das mit dem RAM war nur eine Analogie)
Ich dachte die Unterschiede wären mit Skysnakes "Trivialparallel" eh klar :|

Die subjektive persönliche Punchline dessen ist im ersten Absatz unter dem dritten Quote. Für eine pickfeine Ausarbeitung von Definitionen halte ich die Diskussion für nicht geeignet. thx

[basix]

Nein. Es sind ST-Workloads die sich am Ende zu einem Ergebnis fügen.

Es ist schon ein MT-Workload. Oder ist z.B. Cinebench auch kein MT-Workload? Embarrassingly Parallel ist typischerweise ein ST-Problem, welches sich auf beliebig viele Cores verteilen lässt (weil man keine Abhängigkeiten hat) aber trotzdem am selben Problem rechnen kann. Das Gesamtergebnis ist aber dennoch ein MT-Workload. Auch das Beispiel vom Webserver ist ein MT-Workload, jeder Client wird ohne Querabhängigkeiten für sich bearbeitet und ist entsprechend einfach zu parallelisieren. Dort wird das Gesamtresultat am Schluss aber nicht zusammengefügt, da es dieses Resultat beim Webserver schlicht nicht gibt.

AMD könnte doch auch auf 3MB L3 pro Core gehen und somit 36MB auf einem 12C Chiplets unterbringen.
N3 ist arschteuer und bei den APUs kam man bisher sogar mit 2MB pro Core klar.

Somit hätte ein 12C Chiplet immerhin 12,5% mehr L3 als die bisherigen 8C Chiplets. Für die meisten Anwendungen könnte es eventuell auch reichen und für die Kunden mit großem Bedarf an Cache wird es halt einfach die neuen V-Cache Varianten geben.

Immerhin soll das Chiplet nur 75mm² groß werden und es sollen 50% mehr Cores verbaut werden, obwohl nur rund 75% des Chips mit dem besseren Fertigungsprozss skalieren wird. Denn die Cache Zellen werden ja nicht mehr kleiner.

12C + 36MB Cache auf 75mm² klingt für mich irgendwie realistischer.

Es ist einfach effizienter den Cache aus dem teuren Compute Chiplet herauszuholen, welcher im teuren Fertigungsverfahren produziert wird.
Vielleicht gibts bei Zen6 auch erstmals 2 V-Cache layer.
Ich habe mir das mit den 3MB/Core auch kurz durch den Kopf gehen lassen aber ich fürchte dass dies kontraproduktiv sein könnte. Falls sich irgendwelche Server-Software auf die 4MB/Core verlässt, wäre es ein Problem. OK, in dem Falle könnte man eine 9C / CCD Variante für Server auflegen aber das ist dann nicht mit den 4C-Workload Chunks verinbar, welche man für Epyc seit Zen 1 als SW-Guideline verwendet.

Die Cache-Zellen werden nicht kleiner, aber das drumherum schon ;) Der L3-Cache wird in N3P/N3X etwas dichter sein als in N4P. Dass man den L3-Cache irgendwann mal rauslösen wird denke ich auch, aber vermutlich noch nicht bei Zen 6. Ich denke bei Zen 7 könnte es so weit sein. Dann macht man ein evtl. 16C N3X/N2P Die und packt 64MByte in N4C drunter. Cool wäre noch wenn dieses Base-Cache-Die sowas wie die Graphcore IPU (https://semianalysis.com/2022/03/03/graphcore-announces-worlds-first/#) hat, nämlich Deep Trench Capacitors im Base Die. Diese fördern Energieffizienz und Takt. Im Falle von Graphcore waren das +40% Takt oder -20% Verbrauch bei selbem Takt. Wäre doch geil, Zen 7 mit >7 GHz Takt :D

[Badesalz]

@basix
Ja ich versteh das schon. War zu 45% bisschen kezerisch gemeint ;) aber wir stehen uns jetzt nicht gegenüber. Das ist nicht des Pudels Kern :up:
Das ist aber auch alles statisch. Keine Interaktion, kaum Abhängigkeiten zu Laufzeit. Daher könnte man z.B. auch meinen, Cinebench ist auch nicht anders als Bildbearbeitung. Auch da kann man einen statischen Inhalt z.B. in Felder aufteilen.
Scheint aber nicht direkt übertragbar. Bildeditoren skklieren da nur teils bei der Bearbeitung (nicht bei der Speicherung). Nur plakativ: Bis 8 Threads recht brauchbar, mit 12 Threads gibts einen kleinen Knick, mit 16 Threads nur noch unwesentlich den Knick egalisieren und danach stagniert es weitgehend.
Jedenfalls was es so für Normalos egal für welches Geld zu holen gibt. Die NASA-Software kenn ich nicht :usweet:

Vieles was nicht trivialparallel läuft zeigt derartiges (ähnliches) Verhalten. Core count ist im heimischen Desktop (ja, auch nicht nur Office/Web) oft eine Blase der Wunschdenker. Die Probleme einer nichtrivialen ;) Parallelisierung werden von Plebs oft einfach verdrängt.
Die Server-Resterampe des core count die wir fahren, von den Herstellern aber angepriesen als wenn es ein Heil wäre. Ist es aber leider nicht signifikant.
Plebs wills halt nicht schnallen und schiebt alles auf die generische HW der Konsolen :rolleyes: Das ist aber nur eine halbe Seite der Medaille.

Mich nervte das sogar ne Weile soweit, daß ich diese Unsinnigkeit leicht verachtend core flood nannte. In der Desktop-Soft zeigen sich oft als genug ab 16 Threads "Walls" mit welchen man sich dann nicht mehr beschäftigt. (Kosten/Zeit/allg. Aufwand/Knowhow)

[BavarianRealist]

Wenn Zen6 wirklich erst H2/26 kommt, also 2 Jahre nach Zen5, dann erwarte ich hier gravierende Veränderungen, vor allem in Richtung 3D-Chiplet-Design und damit auch neue Aufteilungen der Building-Blocks derart, dass man nicht nur Kosten spart sondern auch gezielt flexibler wird, d.h. einerseits nur noch die CPU/GPU-Cores auf den neuesten Prozessen N3/N2 modular realisieren, sodass man diese günstig und früh realisieren kann und sie gleichzeitg flexibel überall einsetzen kann. Zuletzt liegt im 3D-Design ein großes Leistungs-Verbesserungs-Potenzial, weil die Wege kürzer werden als wenn alles nur 2D verteilt wäre.

AMD hat bereits die reinen CPU-Cores (Zen-Chiplets) für Server/Desktop und teils auch Notebook (Strix-Halo!) auf diese Weise ausgelagert und mit dem X3D günstig leistungsstärker gemacht. Vermutlich wird man den gleicihen Weg auch bei GPU gehen wollen, sobald das auch hier ordentlich funktioniert: für CDNA erwarte ich ebensolchen Ansatz, wonach es dann ebenso reine CDNA-Chiplets geben könnte, die dann modular je nach Bedarf eingesetzt werden, von MI4xx über die zukünftigen Grakas bis hin zu den APUs (hier womöglich etwas später, sofern hier die GPUs noch in den I/O-Dice drin sein sollten, laut Moores-Law-is-dead). Hier könnten dann die X3D-Chiplets als Infinitiy-Caches drauf kommen.

Sind die leistungs-entscheidenden Komponenten in Chiplets "ausgelagert", kann der Rest im I/O-Die dann vermutlich in deutlich älteren Prozessen realisiert werden: ein I/O-Die in 6nm kostet nur einen Bruchteil der Entwicklung eines 3N/2N-Chips. Zudem sind die Herstellungskosten ungleich günstiger.

Gerade die angeblich so lange Entwicklungszeit für die Zen6-Generation von 2 Jahren spricht für mich für Veränderungen in diese Richtung, weil hier AMD gerade große Sprünge im 3D-Design macht. Wirklich effektiv und effizient funktionert das Ganze aber erst, wenn man all die nötigen Komponenten quasi "gleichzeitig" modular verfügbar hat, daher womöglich das lange Loch ohne große Neuerungen, was dann vermutlich auch bei den GPUs so sein dürfte soll nach RDNA4 angeblich direkt CDNA kommen, und dann wohl kein RDNA5 mehr.

[Badesalz]

Wenn Zen6 wirklich erst H2/26 kommt, also 2 Jahre nach Zen5 Noch kann ich mir das nicht vorstellen. Einerseits war die bisherige Kadenz schon ziemlich eng. Fast schon übertrieben ;) Hatten aber auch erst bisschen was aufzuholen, um nun in Epyc wie Ryzen sich so klar absetzen zu können.
Andererseits ist aber grad jetzt klar, daß Intel das mit 200ultra nicht so belassen wird und bald ordenlichen nachlegen muss. FALLS sie nicht vorerst damit klarkommen wollen, daß sie nun der neue AMD sind...

Und das wird wenn denn nicht 2 Jahre dauern. AMD kommt noch lange nicht weiter vorwärts, wenn sie konkurrenzfähig zu Intel sind. Sie müssen noch ne ganze Weile wie bisher schon klar besser sein. Nur so bewegt sich was bei den Marktanteilen.

[Skysnake]

Wenn man mit 16 cores eine Stagnation der Performance sieht muss man aber auch beachten das mit immer mehr cores die richtige Ausführung immer wichtiger wird. Also Pinning, NUMA awareness usw.

Windows ist da einfach abartig schlecht.

Gibt genug CAE Anwendungen die auch unter Windows laufen aber da massive Probleme haben weil das Pinning eben grottig im Vergleich zu Linux ist.

Windows ist für ernsthafte Anwendungen halt einfach ein Bremsklotz...

[amdfanuwe]

daher womöglich das lange Loch ohne große Neuerungen,
Welches lange Loch?
ZEN1 2.März 2017
ZEN2 7. Juli 2019 +28 Monate
ZEN3 5. November 2020 +16 Monate
ZEN4 27. September 2022 +22 Monate
ZEN5 15. August 2024 +23 Monate ( geplant Juli, wären +22 Monate gewesen)
ZEN6 +22 Monate -> Mai 26 ???

Sind im Schnitt 22 Monate.

[Badesalz]

Wenn man mit 16 cores eine Stagnation der Performance sieht muss man aber auch beachten das mit immer mehr cores die richtige Ausführung immer wichtiger wird. Also Pinning, NUMA awareness usw.

Windows ist da einfach abartig schlecht.IST SO. Und das hat meist zufolge, daß die Entwickler erst garnicht versuchen da noch und nöcher was zu holen, weil schon der Unterbau diesbezüglich sehr dürftig ist.
Und das lernen sie schon über Generationen nicht, weil eben sinnlos. Man widmet sich halt den wichtigen Themen, die auch etwas bringen...

PS:
Das passiert trotzdem zwar schon hier und da, aber dann wird diese Arbeit in Regionen vergütet die man privat nicht bezahlen möchte.

[mksn7]

Mit einem 16 core CCD hätte man immerhin kein NUMA Probleme.

[The_Invisible]

Welches lange Loch?
ZEN1 2.März 2017
ZEN2 7. Juli 2019 +28 Monate
ZEN3 5. November 2020 +16 Monate
ZEN4 27. September 2022 +22 Monate
ZEN5 15. August 2024 +23 Monate ( geplant Juli, wären +22 Monate gewesen)
ZEN6 +22 Monate -> Mai 26 ???

Sind im Schnitt 22 Monate.

Ist eh lange, zu Athlon XP Zeiten hat man quasi monatsweise CPU und/oder Board gewechselt :freak:

[HOT]

Welches lange Loch?
ZEN1 2.März 2017
ZEN2 7. Juli 2019 +28 Monate
ZEN3 5. November 2020 +16 Monate
ZEN4 27. September 2022 +22 Monate
ZEN5 15. August 2024 +23 Monate ( geplant Juli, wären +22 Monate gewesen)
ZEN6 +22 Monate -> Mai 26 ???

Sind im Schnitt 22 Monate.

Frühjahr 25 Tape Out -> 5Q -> Spätsommer/Herbst 26 Produktrelease. Wären dann ein paar Monate mehr.

[amdfanuwe]

Wenn es keine größeren Verzögerungen gibt, würde ich auf Computex 2026 als Vorstellungstermin tippen.

[stinki]

Ich denke auch, Zen6 CCD Tape-Out bis spätestens Ende Q1/25 und wenn alles glatt geht dann Launch der ersten Zen6 CPUs/APUs/Epics gegen Ende Q2/26.
Diesmal haben sie ja, wie immer, nur ein CCD (wenn ich mal das 32Core dense CCD aussen vor lasse) aber sie müssen mehrere verschiedene IO-Dies auflegen und testen. Medusa Point, Medusa Ridge, Medusa Halo, Venice, (Venice dense auch neu?) sollen ja alle eigene neue IO-Dies bekommen. Da muss man schon viel validieren.

[BavarianRealist]

Hoch interessantes Video von High-Yield (https://www.youtube.com/watch?v=OlRLuajAgIc)über das Hybrid-Bonding, was AMD für den X3D-Cache verwendet.

[fondness]

Leaks aus China zur Fertigung von Zen 6:

Chiplets TSMC N3E, neues I/O-Die in N4C (eine kostenoptimierten Variante des N4 Prozesses)

https://wccftech.com/amd-ryzen-zen-6-cpus-radeon-udna-gpus-utilize-n3e-high-end-gaming-gpus-3d-stacking-for-next-gen-halo-console-apus-rumor/

[basix]

Leaks aus China zur Fertigung von Zen 6:

Chiplets TSMC N3E, neues I/O-Die in N4C (eine kostenoptimierten Variante des N4 Prozesses)

Naja, ist mit Abstand die naheliegenste Fertigung. N3E wird mMn aber N3P sein, macht mehr Sinn. Samsung IOD wäre zwar denkbar, hat aber Nachteile (andere Foundry = andere Libraries, weniger Erfahrung, erhöhter Logistikaufwand)

[Nightspider]

Zen5c ist doch schon N3E oder?

1,5-2 Jahre später nochmal N3E kann ich mir nicht vorstellen.

[Lehdro]

Ist eh lange, zu Athlon XP Zeiten hat man quasi monatsweise CPU und/oder Board gewechselt :freak:
Ich weiß, das war sicherlich nur eine krasse Übertreibung, aber damals hat man meist nur höher getaktet, aber nicht die Architektur gewechselt. Zwischen dem ersten Athlon (06/1999), Athlon XP(08/2001) und dem ersten Athlon 64 (09/2003) lagen jeweils mehr als 2 Jahre. Zum Phenom dauerte es satte 4 Jahre, Phenom II der eigentlich nur ein riesiger Shrink + Bugfix war, dauerte auch > 1 Jahr. Bulldozer hat dann wieder mehr als 2 Jahre gedauert und Ryzen mal eben ein halbes Jahrzehnt.
Klar in der Zwischenzeit hat man mehrmals die Fertigung gewechselt, am Cache geschraubt, die Frequenzen erhöht oder Kerne dazugefügt, aber die eigentliche Kadenz der "major" Mikroarchitekturen war schon immer im Bereich ~2 Jahre.

Von daher begrüße ich die relative Konstante zwischen den Generationen derzeit doch sehr - das zeigt, das auch ohne die rasante Fertigungsspirale noch viel geht.

[reaperrr]

Naja, ist mit Abstand die naheliegenste Fertigung. N3E wird mMn aber N3P sein, macht mehr Sinn.

Zen5c ist doch schon N3E oder?

1,5-2 Jahre später nochmal N3E kann ich mir nicht vorstellen.

N3P ist vermutlich eh nur Marketing-Bezeichnung für ein PDK-Update für N3E, ich würde vermuten, dass die 2026er AMD-Teile die elektrischen Verbesserungen von N3P so oder so bekommen.

Bei RDNA3 und Zen4 hat AMD das "P" auch nie offiziell bestätigt, aber es ist halt schwer zu glauben, dass sie auf die Verbesserungen verzichten, nur um irgendwo ein paar Kröten zu sparen (auch wenn ich das bei AMD nie gänzlich ausschließen würde...).

[Nightspider]

nie im leben kommt die next gen konsole mit big cores wenn compact cores genau auf das optimiert sind was für konsolen relevant ist: effizienz und chipfläche. die paar prozent performanceunterschied sind da nebensächlich. mein tipp wäre 12x custom "zen 5.5c" wovon 2 cores reserviert sind. alles darüber hinaus nimmt nur der GPU ressourcen weg.

Volle Zustimmung, dass da keine normalen big cores verbaut werden.

Falls die PS6 tatsächlich Stacking nutzen wird, was aus kosten/nutzen Sicht sogar 2027 sinnvoll sein könnte, dann kann es auch sein das man den L3 komplett aus den CPU Kernen verbannt und auf die 2. Ebene verlagert.

Im Gegensatz zu Ryzen CPUs, wo viele CPUs ohne X3D verkauft werden, würden bei der PS6 dann 100% aller APUs auf diesen hypothetischen Cache in der 2. Ebene zugreifen können.
Selbiges trifft natürlich auch auf die GPU zu, wenn man den Infinity Cache auch ins Base Die verlagert.

Auf Grund der Inflation und Co. darf man eh davon ausgehen das die PS6 mindestens 550 bis 600 Euro kosten wird.

[Daredevil]

Bin mir gar nicht sicher ob eine Playstation überhaupt so viel CPU Power benötigt, weil sich die Anforderung an den Fernseher, selbst wenn es 2027 ist, kaum verändert hat.
Wir sind meist immer noch bei 4K60, bestenfalls 4K120.
Die alte PS5 CPU kann man ordentlich mit X3D und schneller fertigung weiter nach oben bringen, an was es aber mangelt ist die GPU Leistung, die man eben nicht mal vervielfachen kann. Bedeutet man würde das Verhältnis CPU/GPU deutlich Richtung CPU verschieben, wobei man das Verhältnis eher Richtung GPU verschieben sollte, weil hier Anforderungen tatsächlich gestiegen sind durch RT und co. 8C X3D wäre demnach schon wahnsinnig viel Leistung kommend von dem alten Zen. Ein netter Unified Memory SoC wäre hier echt nett.

[Nightspider]

Ein GTA6 wird schon zeigen wofür man viel CPU Leistung benötigt.
Auch neue Unreal Engine 5 Spiele werden enorm viel CPU Leistung für die extrem realistischen Welten benötigen.

Für das Gameplay und lebendige Welten mit viel Simulationen ist viel CPU Leistung nunmal der wichtigste Faktor.
90% der Gamer beschweren sich auch bei der PS5 nicht über die geringe interne Renderauflösung.

Mit Faktor 2 mehr CPU Leistung wird man vorraussichtlich gerade mal GTA6 von 30 auf 60fps heben.
Also reichen 8 Zen5c Cores schon mal nicht aus.

Die Playstation 6 soll dann aber wieder ~7 Jahre durchhalten und neue Spielerlebnisse bieten.
Dafür reicht Faktor 2 einfach nicht aus.
Zwischen PS4 und PS5 lag ein Faktor 5-6 vor bei der CPU.

Da Zen6 wahrscheinlich 6-12 Monate vor der PS6 erscheinen wird, ist die Wahrscheinlichkeit zumindest deutlich höher das man Zen6 in der PS6 sehen wird.
Aber ohne viel Cache wird auch bei Zen6 viel von der IPC liegen bleiben, deswegen und weil bei GPUs auch immer mehr Cache wichtig wird, plant wohl Sony mit Stacking für die APU.

Es kann auch sein das Sony bei der PS6 preislich den PS5 Pro Weg gehen wird und erstmal hohe Preise verlangen wird, schon alleine um Scalpern den Markt wegzunehmen.
Dann könnte man ja ja sukzessive den Preis an die Nachfrage anpassen.

Ich hoffe mal das AMD bei Zen6 den Großteil des Caches aus dem Core Chiplet entfernt. Also mindestens den kompletten L3.
Das würde extrem viel Area für Computing und mehr Cores freimachen und die Kosten pro Megabyte Cache dank Stacking massiv reduzieren.

[robbitop]

Die neuen UE5 Spiele scheinen auch CPU Leistung zum Frühstück zu verspeisen. Vielleicht kann man dank c Cores ja auch mal 16C verbauen und dafür mal einen Speung in Spiel Physik machen.

[latiose88]

Physik kann die gpu viel besser als die CPU. Es ist zwar möglich auch bei cpu aber damals konnte cpu nur mittlere psyik und die gpu maximum. Gab ja auch Spiele wo man es sich aussuchen konnte. Daran hat sich ja auch jetzt nichts geändert. Die CPU mag zwar einiges mehr Leistung seid dem geschafft haben aber ob das ausreicht ist ne andere frage.

[robbitop]

Das gilt für Effektphysik. Ich meine aber spielrelevante Physik. Da ist Latenz dann schnell ein Problem wenn das zwischen den IP Blöcken untergeschoben wird. Das ist natürlich in einem SoC mit vereintem Speichermodell besser aber es scheint da trotzdem noch Hindernisse zu geben. Und weiterhin entscheiden sich die meisten Entwickler dann wahrscheinlich in Betrachtung des compute budgets wohl eher für graphics als für Physik.

Weiterhin sind Spiele ja zumeist multi Plattform. Also selbst wenn man die Vorteile eines modernen SoCs nutzt hat man dann mit dem PC ein Problem. Physik auf der CPU hingegen geht immer.

Weiterhin ist es zwar nicht das Effizienteste aber die c Cores kosten nicht so viel Fläche. Aber jeder Entwickler kann sie direkt nutzen und es ist dann auch kein muss. Wenn sie mit dem CPU budget was anderes machen wollen: feuer frei.

[Zossel]

Weiterhin sind Spiele ja zumeist multi Plattform. Also selbst wenn man die Vorteile eines modernen SoCs nutzt hat man dann mit dem PC ein Problem. Physik auf der CPU hingegen geht immer.

Breite Vektorunits (aka AVX) sollten dort helfen. Jedoch stellt sich Intel da als Bremser auf.

[bbott]

Wird AMD mit Zen wirklich nur auf 24C gehen? 12C + 16c waren auch schon mal besser gegen Intels 52 Cores... Aber immer noch verdammt wenig?!

[horn 12]

Nvidia RTX 5070 Ti Supply, AMD Zen 6 Medusa Point Leak, RX 9070 XT Release Date | January Loose Ends

https://www.youtube.com/watch?v=3yM9EKaazXw

[mironicus]

Für Spiele wie GTA 6 könnte auch eine NPU nützlich sein, die ab Zen 5 Mobile-Prozessoren verbaut werden. In Zen 6 dann wohl vielleicht Standard?

[fondness]

AMD wird in Zukunft wie auch schon bei Strix Halo die CCDs auch ins mobile Segment bringen, alle werden dann voraussichtlich dasselbe CCD verwenden

AMD Medusa Point/Ridge/Halo and Range may share the same 12-core Zen6 CCD
https://videocardz.com/newz/amd-medusa-point-ridge-halo-and-range-may-share-the-same-12-core-zen6-ccd

Es soll sich dabei übrigens um ein 2nm CCD handeln.

[Nightspider]

Ist die Schnittstelle mittlerweile überhaupt fertig um auf die NPU zuzugreifen?

Hat schon irgendein Gamestudio angekündigt NPUs nutzen zu wollen?
Ich kann mir das noch nicht richtig vorstellen.

AMD wird in Zukunft wie auch schon bei Strix Halo die CCDs auch ins mobile Segment bringen, alle werden dann voraussichtlich dasselbe CCD verwenden

Das beste daran ist, das man verschiedene Produkte schneller parallel marktreif bringen kann, wenn diese sich alle Chiplets teilen.

Ich hoffe die mobile Zen6 APU mit Medusa Point Chiplets und hoffentlich effizienter RDNA4 Lösung kommen zügig auf den Markt.

Die ganze Zen5 Produktpalette kam ja verspätet auf Grund der Umstellung auf 4nm.

Ich hoffe da auf 20 Monate nach Zen5, also Q2 2026. Aber da AI sowieso die maximal Priorität hat, würde es mich nicht wundern wenn es doch auch wieder zu Verzögerungen kommt.

Eine RDNA4 APU ende 2026 wäre auch wieder zu spät und langweilig, wenn es eigentlich schon Zeit wird für RDNA5 und RTX 6000.

[mironicus]

NPU-Unterstützung gibt es bereits in Windows 11. Es wird als eigene Einheit im Taskmanager angezeigt wie eine GPU und mit DirectML gibt es eine Schnittstelle als Teil von DirectX. Eine Unterstützung könnte es also jederzeit geben, wenn Microsoft/AMD/Intel/NVidia es fördern. Die NVidia-APU die in diesem Jahr erscheint, sollte auch Copilot Plus-fähig sein mit einer entsprechenden NPU. Es ist ein hochspannendes Thema, ChatGPT listet viele Möglichkeiten mit der eine NPU unterstützend für Spiele nützlich sein kann.

[HOT]

Medusa Point und Halo werden wohl weiter zum Jahreswechsel 26/27 gelauncht in den Notebookzyklus. Zum Jahreswechsel 25/26 dürfte es Eagle Pont (Strix Point mit VCache), Kraken und Halo Refresh geben. Medusa Ridge dürfte den Anfang machen 2H 26.

[][immy]

Die neuen UE5 Spiele scheinen auch CPU Leistung zum Frühstück zu verspeisen. Vielleicht kann man dank c Cores ja auch mal 16C verbauen und dafür mal einen Speung in Spiel Physik machen.
Davon träumen wir ja schon einige Jährchen (hatte das nicht vor HL2 angefangen?), getan hat sich seit dem allerdings nicht all zu viel. Es gab sogar deutliche Rückschritte.
Ich denke "Physik" in Spielen macht einfach zu viel kaputt oder ist zu kompliziert geworden. Ist ja schließlich immer noch so, das trotz Unmengen an Speichers (im Vergleich zu damals) trotzdem Objekte, wenn sie nicht mehr an ihrer Position stehen, gerne verschwinden.
So wird es dann auch weiterhin bei Physik nur für ausgewählte Objekte bleiben. Und nach wie vor geht auch die CPU Leistung größtenteils für die Grafik drauf.

[fondness]

AMD soll angeblich die 4-nm-Fertigung von Samsung für neue I/O-Dies nutzen
https://www.computerbase.de/news/prozessoren/cpu-geruechte-amd-koennte-4-nm-fertigung-von-samsung-fuer-neue-io-dies-nutzen.91416/

[HOT]

Wenn der Yield gut ist, warum nicht. Die Kosten sind für AMD sicherlich niedriger.

[Badesalz]

AMD soll angeblich Was ist das für ein seltsamer Text drunter? (CB) TSMC hat in N4 dermassen viel zu tun, daß sie wahrscheinlich die ersten waren die über das Vorhaben von AMD erfuhren und nickend "alles gut, Jungs" antworteten.

Keine Ahnung was der Rißka sich da für ein Krimi dazu ausmalen möchte :rolleyes:

[Nightspider]

Das sie ab und zu mal Prototypen bei Samsung fertigen lassen um den Prozess zu testen kann ich mir durchaus vorstellen.
Ob sie da am Ende in die Massenproduktion gehen, das ist eine andere Frage.

[robbitop]

TSMC hat viel Nachfrage und ist ziemlich teuer geworden. Samsung hat soweit ich gelesen habe mächtig freie Kapazitäten - dann ist das Potential für bessere Preise da. Und für die IOD braucht man sicherlich kein bleeding edge.

[Nightspider]

Also wenn ich so darüber nachdenke könnte AMD bei Medusa Point und Medusa Halo Dinge kombinieren.

Bei Navi 31 waren die MCD via Infinity FanOut Links verbunden und bei Strix Halo wird eine neurere Variante davon genutzt.
Zen6 wird es wohl nur mit dieser Anbindung geben, weshalb die X3D Variante auch gleich mit Ininity FanOut Links kommt und der Cache Die mit Sicherheit wieder unten sein wird.

Wenn man diesen Chiplet mit der hohen Bandbreite direkt an das IOGPU Chiplet anbindet könnte man die GPU auch auf den V-Cache zugreifen lassen, die Latenz wäre kaum höher als bei Navi31 und AMD könnte vielleicht 2 Cache Layer in die X3D Variante einbauen.

Dann müsste zukünftig für stärkere APUs nicht mehr Cache im teuren Node hergestellt werden.
Man stellt sich mal eine Medusa Halo APU vor mit Zen6 Chiplets und 2*V-Cache für CPU und GPU. Damit könnte man auch 56 oder 64 CUs versorgen, die in N3P ungefähr genauso groß sein dürften wie die IGP in Strix Halo.