Zen 4 (Raphael, Phoenix & Genoa, 5 nm, AM5, DDR5, PCIe 5.0, Ende 2022)

[Cyberfries]

Feinere Granularität bei Server Chip SKUs, weniger Verschwendung von wertvoller Silizium Fläche (z.B. 4, 6, 8, 10, 12 Chiplets je nach SKU). Produktstack z.B. 16, 24, 32, 48, 64, 80, 96C

Deine Auflistung halte ich für wenig sinnvoll bei 12CCDs, Resteverwertung ist da kaum möglich:
Irgendwo willst du auch abgespeckte Varianten unterbringen, außerdem bieten sich Cache-Abstufungen an:
12CCDs mit 384mb L3$ mit 96 oder 72 Kernen
10CCDs mit 320mb L3$ mit 80 oder 60 Kernen
8CCDs mit 256mb L3$ mit 64 oder 48 Kernen
6CCDs mit 192mb L3$ mit 48, 36 oder 24 Kernen
Hier im Beispiel mit Cache-Größen wie bei Rome. Soll mWn bei Genoa mehr werden?

Das es bei 8 Cores pro CCD bleibt, könnte auch darauf hindeuten, dass die Cores deutlich wachsen.

Das Wachstum wird aber begrenzt durch die Größe des Gesamtpakets.
Ausgehend von den 8Rome-CCDs mit je 74mm² scheint ca.60mm² für Genoa das Maximum.

Wundert mich, dass es 12CCDs werden sollen, da kommen große Aufgaben auf die Infinity Fabric zu.
Ich hatte 8CCDs mit je zweimal 8 Kernen erwartet, ähnlich Rome mit 8x2x4.

[HPVD]

....
Das Wachstum wird aber begrenzt durch die Größe des Gesamtpakets.
Ausgehend von den 8Rome-CCDs mit je 74mm² scheint ca.60mm² für Genoa das Maximum.


der genannte SP6: wofür?
für die SKUs mit größer 64cores? Und mit mehr RAM Channels?
-> "Big Epyc"?

[HOT]

Das die Cores wachsen würde ja zu meiner Speku passen, dass bei Zen4 der Cache massiv aufgeblasen werden könnte, ähnlich wie bei Ice Lake und Tiger Lake, also 48-64kB L1 und 1-2MB L2. Nur der L3$ wird mMn nicht angetastet, stattdessen wäre eine 4. Cache-Stufe sinnvoller mMn, um den CCX-Nachteil auszugleichen.

[HPVD]

der genannte SP6: wofür?
für die SKUs mit größer 64cores? Und mit mehr RAM Channels?
-> "Big Epyc"?

noch als Gedanke:
vielleicht den Big EPYC nur als single Socket dafür z.B. mit 350W+ und 12Channels?

Bei sovielen Channels und ggf noch nem größerem Sockel (wenn dem so wäre) würde sonst der Platz auf den MOBOs ziemlich eng bei Dual Sockel...

So nen Singl Socket killt dann nicht nur die Dual Socket Xeon Systeme sondern auch gleich die Quad Socket ;D

TR hat ja schon bei Highpower vorgelegt..

[Cyberfries]

der genannte SP6: wofür?

SP3: Epyc
SP4: Embedded
SP5: Epyc
SP6: naheliegend, oder?

Das die Cores wachsen würde ja zu meiner Speku passen, dass bei Zen4 der Cache massiv aufgeblasen werden könnte

Wie gesagt: Platzprobleme.
Außerdem gehst du in deiner Speku doch von Cache im IO-Die aus?
edit: Nicht wirklich sorgfältig gelesen, sorry.

[Windi]

Wenn der Wechsel auf DDR5 stattfindet, kann man eh am besten einen eigenen Sockel für Threadripper und günstige Epycs auflegen. Vor allem, wenn die normalen Epycs auf 12 Chiplets wachsen sollen.

Normaler Desktop: 2 Chiplets
HEDT und small Epyc: 6 Chiplets
Big Epyc: 12 Chiplets

[HOT]

[...]
Wie gesagt: Platzprobleme.
Außerdem gehst du in deiner Speku doch von Cache im IO-Die aus?
edit: Nicht wirklich sorgfältig gelesen, sorry.

Große Caches in N5 lohnen sich ja nicht, da sie pro Fläche teurer sind als in N7. daher würde ich nicht davon ausgehen, dass man den L3 noch weiter vergrößern wird. L1 und L2 ist was anderes, die sind ja eh kleiner. Aber die Cores werden ja auch so breiter werden offenbar bei Zen4.

[Zossel]

Wir haben eine Sache bisher außer Acht gelassen bei der Betrachtung des I/O-Dies. Das könnte ja durchaus in 12LP+ gefertigt sein und der Cache könnte in einem separaten 7nm-Die gestackt oder zusätzlich sein.

Ist 12LP+@GF so schlecht was SRAM angeht das es für einen möglichen L4 nicht reicht?

Mir wäre allerdings eine Schmalspur GPU auf dem IO-Die wesentlich lieber.

[Zossel]

So was wünsche ich mir für Zen(current+1):

https://twitter.com/carlosedp/status/1328424799216021511

[HPVD]

So was wünsche ich mir für Zen(current+1):

https://twitter.com/carlosedp/status/1328424799216021511

yessss!

[HPVD]

wahrscheinlich kommts zu spät für ZEN4.. aber was könnte man daraus machen? ggf in ZEN5?

TSMC baut neuartige 3D-Chips für AMD & Google
https://winfuture.de/news,119558.html

[Platos]

Wie das dann kühlbar sein soll, ist die andere Frage. Der 5800X ist ja schon jetzt praktisch unkühlbar. Selbst mit Custom Wasserkühlungen. Da will ich gar nicht wissen, wie das bei mehreren Cores übereinander anstatt nebeneinander aussieht.

[Savay]

Praktisch unkühlbar. Da fuq.

[Platos]

Ja, selbst mit Custom Wasserkühlung schaffen einige hier ja die 90°, wenn die CPU zu 100% ausgelastet ist. Das nenne ich praktisch unkühlbar.

[Zossel]

wahrscheinlich kommts zu spät für ZEN4.. aber was könnte man daraus machen? ggf in ZEN5?


https://winfuture.de/news,119558.html

Bei AMD versucht man mit dem Ansatz angeblich, sich einen Vorteil gegenüber dem Erzrivalen und x86-Platzhirsch Intel zu verschaffen. Was genau AMD mit den Chips vorhat, ist allerdings noch offen.

Da muss aber jemand lange nicht unter seinem Stein hervor gekommen sein ......

[drmaniac]

Wegen der Kühlung, ich hab irgendwo mal was gelesen, dass man "Kühlkanäle"? auch direkt in Chips einbauen könnte... fragt mich nicht wo. Könnte hier oder in einer Technik News gewesen sein vor Monaten.

[Platos]

Wegen der Kühlung, ich hab irgendwo mal was gelesen, dass man "Kühlkanäle"? auch direkt in Chips einbauen könnte... fragt mich nicht wo. Könnte hier oder in einer Technik News gewesen sein vor Monaten.

Mir scheint das eher nach Träumereien irgend eines Users hier oder sonst wo.

Wo gehen diese "Kühlkanäle" überhaupt hin? Und wie transportiert dieser Kühlkanal die Wärme weg? Denn die Wärme müsste irgendwie vom DIE weg transportiert werden auf eine grössere Fläche. Wie soll das geschehen? Welche Fläche ist das und wie wird die Gekühlt? Wo ist diese Fläche? Etc. etc. Und vor allem so, dass die CPU nicht signifikant teurer wird?

Das ist aus meiner Sicht absolute Träumerei irgend eines Forenusers.

[Langlay]

Das ist aus meiner Sicht absolute Träumerei irgend eines Forenusers.

https://arstechnica.com/science/2020/09/researchers-demonstrate-in-chip-water-cooling/

Jup, eindeutig Träumerei eines Forumuser, aber hauptsache erstmal die Fresse gross aufgerissen.

[woodsdog]

https://arstechnica.com/science/2020/09/researchers-demonstrate-in-chip-water-cooling/

Jup, eindeutig Träumerei eines Forumuser, aber hauptsache erstmal die Fresse gross aufgerissen.

big ooof, dass gibt 'n blauen Fleck. :biggrin:

[Savay]

Naja...

So we're a long way off from seeing this turn up in any hardware. But it's at least nice to see a demonstration that the process can be done efficiently.

[Platos]

https://arstechnica.com/science/2020/09/researchers-demonstrate-in-chip-water-cooling/

Jup, eindeutig Träumerei eines Forumuser, aber hauptsache erstmal die Fresse gross aufgerissen.

Was geht denn bei dir verkehrt? Der, der hier "die Fresse" aufreisst, bist wohl eher du.

Abgesehen davon, steht da, dass es noch lange geht, bis das auch nur in irgend einer Hardware verbaut ist. Das ist gerade im Forschungsstadium, mehr nicht.

Es geht hier übrigens um Zen4/5 und das spekulierte Stacking von DIEs (bei Zen4/5), nicht um irgend etwas, das vlt. in der Zukunft in 10+ Jahren irgendwann einmal kommt (und dann garantiert zuerst einmal bei Server bzw. davor vlt. noch in Grossrechnern/Wissenschaftlichen Einrichtungen).

[Langlay]

Naja...

Es ist trotzdem schon etwas mehr als der feuchte Traum eines Forumusers.

Was geht denn bei dir verkehrt? Der, der hier "die Fresse" aufreisst, bist wohl eher du.


Erst die Aussage eines anderen Users als quasi undurchführbaren Hirnfurz hinstellen und jetzt fleissig am zurückrudern. Lass mal gut sein.

[Platos]

Wie bitte? Ich habe vermutet, dass er das ganze vermutlich irgendwo im Forum aufgeschnappt hat. Und Wiederholung: Es geht um Zen4/5 und da ist es nicht mehr als eine Träumerei. Aber wahrscheinlich hast du nur meinen Kommentar gesehen und die restlichen davor nicht gelesen, stimmts.

Respekt wäre mal angesagt. Dein Ton ist unter aller Sau.

[Langlay]

Wie bitte? Ich habe vermutet, dass er das ganze vermutlich irgendwo im Forum aufgeschnappt hat. Und Wiederholung: Es geht um Zen4/5 und da ist es nicht mehr als eine Träumerei. Aber wahrscheinlich hast du nur meinen Kommentar gesehen und die restlichen davor nicht gelesen, stimmts.


Ich hab ein paar Posts vorher schon gelesen. Und ein 5800X ist schon kühlbar, meine Customwakü liegt auch nur ca 5°C unter dem D15 meiner Frau (wir beide haben einen 5800X). TAber darum gings ja nicht.

Es wurde ja auch nicht gesagt das Zen4 in-die-watercooling hat, es wurde nur erwähnt das es diese Technologie gibt bzw. dran gearbeitet wird. Und das hast du ins Reich der Sagen und Märchen gerückt ohne mal 5 Sekunden googlen ob das auch stimmt.

Das Zen4 nun nicht mit in-die-watercooling erscheint ist glaub ich auch allen klar.

[Platos]

Es ist hier aber der Zen4 Thread und ich dachte nunmal, er meint, er hätte das im Zusammenhang für Zen4 (bzw. Zen5, das wurde hier genannt bezüglich dem Stacken) gelesen. Es war ja eine Antwort auf die Kühlmöglichkeit beim Stacken (weil ich die Kühllösungsmöglichkeiten bezüglich Zen5 und Stacking in Frage gestellt hatte). Deswegen der Bezug zu Zen4/5

Man kann es natürlich auch allgemein verstehen. So oder so, man kann es auch normal schreiben und einfach darauf hinweisen, dass sogar schon daran geforscht wird. Was ich interessant finde.

Eine rein technische Möglichkeit halte ich nicht für ausgeschlossen. Auch nicht wirtschaftlich (irgendwann einmal). Ich halte es aber für eine Träumerei, dass man das wirtschaftlich in naher Zukunft (wie z.B für Zen 5) hinkriegt.

Besser googlen hätte ich aber können. Hab danach gesucht, bin nur leider immer auf Heatpipes gestossen. War wohl der falsche Suchbegriff... Es wäre vlt. besser gewesen, wenn ich mich (ausdrücklich) auf die nahe Zukunft bezogen hätte.

[ZeXes]

Solche fancy Technologien werden wir bei ZEN4 nicht sehen. Warum auch, AMD hat keinerlei Not bei den Consumern CPUs aktuell und ich gehe bei ZEN 4 eher davon aus, dass der Schwerpunkt bei dieser CPU bei DDR5 liegt und der richtigen Nutzung dessen. Zumal noch die 5nm Fertigung dazu kommt und eine neue Plattform für ZEN4 mit AM5.

Von daher, wäre etwas sehr viel für eine Generation. Dieses 3D Stacking könnte ich, wenn überhaupt bei den Server CPUs sehen, weil hier AMD noch einiges zu intel aufholen muss.

Da wäre so ein Hammer schon ganz nett.

[LasterCluster]

Warum auch, AMD hat keinerlei Not bei den Consumern CPUs aktuell

AMD kann nicht nach aktueller Not planen, sondern muss langfristig denken. Aktuelle Anpassungen passieren über den Preis.

und ich gehe bei ZEN 4 eher davon aus, dass der Schwerpunkt bei dieser CPU bei DDR5 liegt und der richtigen Nutzung dessen. Zumal noch die 5nm Fertigung dazu kommt und eine neue Plattform für ZEN4 mit AM5.

Aber gerade neue I/O-Geschichten ist doch der beste Zeitpunkt für weitreichende Änderungen!

Dieses 3D Stacking könnte ich, wenn überhaupt bei den Server CPUs sehen, weil hier AMD noch einiges zu intel aufholen muss.
Klar muss sein, dass Server so oder so den Takt bei Zen-CPUs angeben. Das Chiplet-Design gab es ja auch nicht um zwanghaft 16-Kerner auf AM4 anbieten zu können.

Wir werden sehen was kommen wird. Compute-Dies stapeln ist natürlich Unsinn. Aber warum nicht das I/O-Die als Basis und oben drauf CPU/GPU/HBM/...?

[Platos]

Solche fancy Technologien werden wir bei ZEN4 nicht sehen. Warum auch, AMD hat keinerlei Not bei den Consumern CPUs aktuell und ich gehe bei ZEN 4 eher davon aus, dass der Schwerpunkt bei dieser CPU bei DDR5 liegt und der richtigen Nutzung dessen. Zumal noch die 5nm Fertigung dazu kommt und eine neue Plattform für ZEN4 mit AM5.

Von daher, wäre etwas sehr viel für eine Generation. Dieses 3D Stacking könnte ich, wenn überhaupt bei den Server CPUs sehen, weil hier AMD noch einiges zu intel aufholen muss.

Da wäre so ein Hammer schon ganz nett.

Inwiefern muss AMD hardwareseitig im Serverbereich aufholen?

[CrazyIvan]

Aber gerade neue I/O-Geschichten ist doch der beste Zeitpunkt für weitreichende Änderungen!
Dank Chiplets eben nicht mehr zwingend. Ein mehr oder weniger reiner Shrink des CCD plus neuer IOD ist sehr realistisch.

[dildo4u]

Könnte das nicht auf Herbst 2021 für Zen 4 hindeuten?

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

[HPVD]

Könnte das nicht auf Herbst 2021 für Zen 4 hindeuten?

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

joa, besonders in die Richtung könnte man interpretieren, dass die beiden CPU Produzenten benannt werden statt nur "zusammen mit den ersten DDR5 ready CPUs" o.ä.
edit: könnte aber auch sein, dass man nur die 2 großen Namen in der Pressemitteilung haben wollte um sich mit denen auf einen Höhe zu stellen.
-> man weiß es nicht :-)

TEAMGROUP has made ample preparations in 2020 to take the lead in the DDR5 market and will coordinate its releases with the DDR5 platforms of the top two CPU manufacturers, Intel and AMD. The company’s DDR5 memory is expected to be available as early as Q3 2021.

[HPVD]

It plans to release a 16GB 4800MHz module

teamgroup elite, nur ein Modul, und nur 16GB -> def consumer

aber DDR5 wirklich zuerst im Consumer Bereich? Bei Intel und AMD ?

[Der_Korken]

Ich tippe eher auf einen Zen 3-Refresh, mit dem schon mal der neue AM5-Sockel und ein neuer IO-Die eingeführt werden. Für Zen 4 muss man dann wieder nur die Chiplets ersetzen, wie bei Zen 3, und hat bereits eine halbwegs stabile Plattform.

[HOT]

Das verrückte wird sein, dass das trotz des Beibehaltens von AM4 bei Warhol sicherlich das neue IOD schon gehen könnte, da der Mem-Ctr. auf dem neuen I/O-Die sicherlich eh beides anbinden kann, DDR5 und DDR4. Mal sehen, wie man das deichselt. Man könnte so schon innerhalb der Warhol-Generation mit dem Release von Rembrandt den AM5-Sockel einführen, ohne auf Raphael warten zu müssen oder eine bis dahin APU-Exklusive Plattform einzuführen, einfach, indem man Warhol für beide Plattformen kompatibel macht.

[Langlay]

Fand ich eigentlich auch durfte wenn AMD es wie bei den Phenoms machen würde. Die Phenoms liefen ja auch auf AM2(+) Boards mit DDR2 und auf dem AM3 mit DDR3. Also Zen4 dann halt mit DDR4 auf AM4 (von mir aus auch nur X570 und B550) mit DDR4 und auf AM5 dann halt mit DDR5. Aber so richtig dran glauben tu ich ehrlich gesagt nicht.

[HOT]

Fand ich eigentlich auch durfte wenn AMD es wie bei den Phenoms machen würde. Die Phenoms liefen ja auch auf AM2(+) Boards mit DDR2 und auf dem AM3 mit DDR3. Also Zen4 dann halt mit DDR4 auf AM4 (von mir aus auch nur X570 und B550) mit DDR4 und auf AM5 dann halt mit DDR5. Aber so richtig dran glauben tu ich ehrlich gesagt nicht.
Das werden für Warhol schon 2 verschiedene Packages sein. Aber der Inhalt kann durchaus das Gleiche sein. Nur für AM5 dann mit DDR5 und USB4 (nur 2 Ports offenbar), wärhend AM4 noch mit DDR4 und USB3.2gen2 läuft. PCIe 4 bleibt ja eh bei beiden Plattformen erhalten. Raphael ist 99,999% AM5 und nix weiter.

[dargo]

Könnte das nicht auf Herbst 2021 für Zen 4 hindeuten?

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12519061&postcount=523
Nein.

[basix]

Fand ich eigentlich auch durfte wenn AMD es wie bei den Phenoms machen würde. Die Phenoms liefen ja auch auf AM2(+) Boards mit DDR2 und auf dem AM3 mit DDR3. Also Zen4 dann halt mit DDR4 auf AM4 (von mir aus auch nur X570 und B550) mit DDR4 und auf AM5 dann halt mit DDR5. Aber so richtig dran glauben tu ich ehrlich gesagt nicht.

Ich glaube eher, dass Zen 3+ auf AM5 mitgezogen wird als dass Zen 4 auf AM4 kommen würde. Neues IOD mit DDR4 und DDR5 Support, welches für Zen 3+ und Zen 4 auf AM5 verwendet wird. Das macht mMn deutlich mehr Sinn. Das DDR5 IOD sowie Zen 4 sollten voll auf AM5 zugeschnitten sein und nicht noch Altlasten von AM4 mitschleppen müssen. Mit Zen 3+ kann man günstigere Low End SKUs auf AM5 bieten und schont 5nm Kapazitäten. Ob Zen 3+ dann schon AM5 einläutet? Halte ich für unwahrscheinlich.

Generell: Ein harter Schnitt zwischen Zen 3(+) und Zen 4 und entsprechend AM4 und AM5 wäre für mich voll OK. Wenn man das Zen 3+ CCD auf AM5 mitnehmen kann: Schön. Alles andere halte ich für wenig praktikabel. AM4 ist einfach schon einige Jahre alt. AM5 wird vor allem wegen der modernisierten Plattform interessant werden: DDR5, PCIe 5.0(?) + mehr Lanes (?), USB 4.0. Das hängt alles am IOD. Lieber AM5 vorwärtsgerichtet umsetzen, damit der wieder 4-5 Jahre hält als dass man auf Altlasten Rücksicht nehmen muss.

[Langlay]

Ich glaube eher, dass Zen 3+ auf AM5 mitgezogen wird als dass Zen 4 auf AM4 kommen würde. Neues IOD mit DDR4 und DDR5 Support, welches für Zen 3+ und Zen 4 auf AM5 verwendet wird. Das macht mMn deutlich mehr Sinn. Das DDR5 IOD sowie Zen 4 sollten voll auf AM5 zugeschnitten sein und nicht noch Altlasten von AM4 mitschleppen müssen. Mit Zen 3+ kann man günstigere Low End SKUs auf AM5 bieten und schont 5nm Kapazitäten. Ob Zen 3+ dann schon AM5 einläutet? Halte ich für unwahrscheinlich.


https://www.synopsys.com/dw/ipdir.php?ds=dwc_ddr54_controller

https://www.synopsys.com/dw/ipdir.php?ds=dwc_ddr54_phy

PHYs die DDR5 und DDR4 unterstützten sind kein Hexenwerk und kein Ballast. Die PHY können einfach beides. Intel nutzt immernoch PHY die DDR4 und DDR3 unterstüten. Daher an der DDR4 sollte das bei Zen4 nicht scheitern. Zu 99% wird der PHY eh beides können.

/edit Link geändert, hatte den falschen PHY verlinkt

[basix]

Es geht weniger um die PHY als um den ganzen Rest sowie dessen Kompatibilität mit AM4. I/O Count, Anzahl PCIe Lanes, Anforderungen an die Spannungsversorgung, USB und xGbit Ethernet Version, Routing, Frequenz- und Spannungsunterschiede der Signale, BIOS Updates auf älteren Platformen usw. --> da hängt ein ein grosser Rattenschwanz an Anforderungen dran, wenn es mit AM4 kompatibel sein soll. Natürlich kann man das alles auf AM4 rückwärtskompatibel halten, macht mMn nur nicht viel Sinn.

Das alles erfordert zwingend ein separates Package für AM4 und je nach Chiplayout macht man dort ziemliche Handstände. Das ist nicht unmöglich und man hat es bei Zen 2 zum Teil auch geschafft. Ist aber nicht so einfach wie man sich das vielleicht vorstellt und der Sprung von AM4 zu AM5 ist viel grösser als der Unterschied zwischen Zen 1 und Zen 2. Es ist vermutlich deutlich einfacher, wenn AM5 auf DDR4 oder DDR5 ausgelegt ist, da man es von Anfang an im Design berücksichtigen kann und sich die Unterschiede "nur" auf DDR4/5 beziehen. Der Rest der I/O-Möglichkeiten bleibt identisch. Am CPU Package sowie dem Sockel sollte sich dann nämlich nichts ändern, egal ob nun DDR4 oder DDR5 (Pin Count ist hier sogar gleich). Ob nun DDR4 oder DDR5 hängt dann nur von der Auslegung des Motherboards ab.

Besteht noch die Frage, ob man Zen 3 auf AM5 mitziehen will. Ich würde das gut finden (für günstige SKUs, Schonung von 5nm Kapazitäten). Bedeutet aber, dass man ein zweites Package designed und dass der neue IOD sich mit den Zen 3 CCDs verträgt.

[Windi]

Das Problem bei DDR5 ist halt, das es noch einige Zeit dauert, bis es im Massenmarkt ankommt.

Falls AMD Zen4 exclusiv für DDR5 heraus bringt, haben sie Jahrelang nicht neues im Mainstream zu bieten.

Da würde es sich halt anbieten, Zen4 mit einem Speichercontroller für DDR4 und DDR5 auszustatten.


@basix
OK, wenn es einfacher wäre den Sockel AM5 für beide Speicherarten kompatibel zu machen, wäre das auch eine Lösung. Im Mainstream werden eh größtenteils Komplettrechner verkauft, da ist es nicht so schlimm wenn man ein neues Mainboard bräuchte.

[Langlay]

Es geht weniger um die PHY als um den ganzen Rest sowie dessen Kompatibilität mit AM4. I/O Count, Anzahl PCIe Lanes, Anforderungen an die Spannungsversorgung, USB und xGbit Ethernet Version, Routing, Frequenz- und Spannungsunterschiede der Signale, BIOS Updates auf älteren Platformen usw. --> da hängt ein ein grosser Rattenschwanz an Anforderungen dran, wenn es mit AM4 kompatibel sein soll. Natürlich kann man das alles auf AM4 rückwärtskompatibel halten, macht mMn nur nicht viel Sinn.


Ich sehe da nicht so viele gravierende Probleme. PCI-E Lanes seh ich nicht das das mehr werden. Wenn man gewollte hätte hätte AM4 auch schon mehr PCI-E Lanes haben können. Imo gräbt man sich damit nur den Threadripper Markt ab.

Imo macht es schon irgendwo Sinn auf AM4 rückwärtskompatibel zu sein. So hätte man eine reine DDR4 und eine DDR5 Plattform. Und man könnte halt noch mit den Umwelt/Nachhaltigkeitsgedanken etwas Werbung machen.

[w0mbat]

Das Problem bei DDR5 ist halt, das es noch einige Zeit dauert, bis es im Massenmarkt ankommt.

Falls AMD Zen4 exclusiv für DDR5 heraus bringt, haben sie Jahrelang nicht neues im Mainstream zu bieten.
DDR5 wird nächstes Jahr am Markt aufschlagen und da man mit min. 15 Monaten zwischen Zen3 und Zen4 rechnen muss, wären wir im März 2022 und damit gut für DDR5 aufgestellt. Intel soll ja angeblich noch Ende 2021 ihre DDR5 Platform vorstellen.

[Windi]

DDR5 wird nächstes Jahr am Markt aufschlagen und da man mit min. 15 Monaten zwischen Zen3 und Zen4 rechnen muss, wären wir im März 2022 und damit gut für DDR5 aufgestellt. Intel soll ja angeblich noch Ende 2021 ihre DDR5 Platform vorstellen.

Dann ist DDR5 vorhanden. Aber sehr wahrscheinlich noch viel zu teuer für den Massenmarkt. Ich kann mir nicht vorstellen, das man dann schon Komplett-PCs für 1000€ damit bauen kann. Aber genau das wollen die Großkunden und OEMs.

[basix]

PCI-E Lanes seh ich nicht das das mehr werden. Wenn man gewollte hätte hätte AM4 auch schon mehr PCI-E Lanes haben können. Imo gräbt man sich damit nur den Threadripper Markt ab.
Seit 2015 und der Einführung von AM4 hat sich viel getan. Bristol Ridge kam mit 12x PCIe Lanes daher und Zen 1-3 mit 24x (wobei 32x jeweils physisch vorhanden sind). Alle CPUs lassen also 4x Lanes frei für eine NVMe SSD. Ob man hier bewusst auf 24x Lanes begrenzt hat oder aber man 2 Jahre später bei Zen 32x Lanes hätte bringen können aber nicht mehr konnte ist ein anderes Thema.

Stand heute sind NVMe SSDs aber mehr oder minder Standard bei PC und Notebook Neukauf und man kann man 1x SSD an die CPU anhängen, der Rest (+1..2 Stück mehr) geht über den Chipsatz. Kann man wieder über den Chipsatz lösen oder man macht den Chipsatz kleiner und transferiert es in die CPU. 2-3 NVMe Steckplätze sind mMn für neue Systeme Pflicht, auch ausserhalb von Threadripper. Das Lustige bei Zen 2 ist ja, dass man hier auch ohne Server-Nutzung 32x PCIe Lanes auf dem IOD hätte und 8x davon somit nutzlos sind. Wieso macht man das? Wenn man sie schon in der CPU hat und somit Kosten anfallen: Lanes rausführen und nutzbar machen. Bis jetzt sind die zusätzlichen Kosten anscheinend tragbar gewesen, ohne dass man einen Nutzen davon hätte. Und wenn man es in der CPU hat: Man kann es beim Chipsatz wegstreichen --> geringere Kosten.

Imo macht es schon irgendwo Sinn auf AM4 rückwärtskompatibel zu sein. So hätte man eine reine DDR4 und eine DDR5 Plattform. Und man könnte halt noch mit den Umwelt/Nachhaltigkeitsgedanken etwas Werbung machen.

Sind wir ehrlich: AM4 hat schon sehr viel bezüglich Rückwärtskompatibilität und Nachhaltigkeit/Langlebigkeit geleistet. Irgendwann muss man nach vorne schauen.

[LasterCluster]

DDR5 wird nächstes Jahr am Markt aufschlagen und da man mit min. 15 Monaten zwischen Zen3 und Zen4 rechnen muss, wären wir im März 2022 und damit gut für DDR5 aufgestellt. Intel soll ja angeblich noch Ende 2021 ihre DDR5 Platform vorstellen.

AMD will aufm Dektop jährlich etwas bringen (erst jüngst wieder in einem Interview bestätigt). Deswegen ist erst einmal ne Zwischengen dran, i.e. Warhol als "Zen3+". Das Zen4 dann Q3 oder Q4 '22 auf AM5 mit DDR5 kommt bezweifelt kaum jemand. Die Frage ist nur was Warhol haben wird.

Ich denke eher, dass Warhol dafür da ist, den AM5/DDR5-Start aufm Desktop etwas zu verschieben und rein in AM4/DDR4 kommt.

Mögliche frühe DDR5-Geschichten würde ich aufm Server und/oder HEDT vermuten. Vielleicht kommt die neue Serverplattform schon Ende '21 mit einem Zen3 Refresh

[Berniyh]

Dann ist DDR5 vorhanden. Aber sehr wahrscheinlich noch viel zu teuer für den Massenmarkt. Ich kann mir nicht vorstellen, das man dann schon Komplett-PCs für 1000€ damit bauen kann. Aber genau das wollen die Großkunden und OEMs.
Bis OEMs Zen 4 Systeme in großem Maßstab rausbringen ist sicher Ende 2022, wenn nicht sogar schon 2023.

[Berniyh]

Stand heute sind NVMe SSDs aber mehr oder minder Standard bei PC und Notebook Neukauf und man kann man 1x SSD an die CPU anhängen, der Rest (+1..2 Stück mehr) geht über den Chipsatz. Kann man wieder über den Chipsatz lösen oder man macht den Chipsatz kleiner und transferiert es in die CPU. 2-3 NVMe Steckplätze sind mMn für neue Systeme Pflicht, auch ausserhalb von Threadripper.
Meinetwegen, aber müssen die alle mit 5 GB/s laufen?
Man schafft es doch im relativ normalen Alltag nicht mal eine SSD derart auszunutzen.

Ich würde behaupten mehr als eine PCIe 4.0 4x SSD bei voller Geschwindigkeit ist Threadripper Gebiet und zwar auch zukünftig.
Für praktisch alle anderen genügt es, wenn die zusätzlichen SSDs am Chipsatz hängen (und damit ja bei PCIe 4.0 immer noch > 1GB/s schaffen können, auch wenn die Bandbreite mit anderen Devices geteilt wird).

Insofern: ich seh nicht wirklich eine Notwendig für mehr als 24 PCIe Lanes bei AM5.

[Berniyh]

Mögliche frühe DDR5-Geschichten würde ich aufm Server und/oder HEDT vermuten. Vielleicht kommt die neue Serverplattform schon Ende '21 mit einem Zen3 Refresh
Das wäre ja nur wenige Monate nach Milan. Ne, das wäre schon eine sehr große Überraschung.

[HPVD]

Apple reserviert 80 Prozent der 5 nm-Produktion bei TSMC im Jahr 2021

https://www.notebookcheck.com/Apple-reserviert-80-Prozent-der-5-nm-Produktion-bei-TSMC-im-Jahr-2021.511156.0.html

hmm...

[davidzo]

Apple reserviert 80 Prozent der 5 nm-Produktion bei TSMC im Jahr 2021

https://www.notebookcheck.com/Apple-reserviert-80-Prozent-der-5-nm-Produktion-bei-TSMC-im-Jahr-2021.511156.0.html

hmm...

Das passt, das AMD höchstwahrscheinlich erst 2022 auf 5nm geht und dann eben direkt auf N5P, wurde ja schon mehrfach geleakt. Die paar Test Waferstarts die man in 2021 in EUV braucht gehen locker in den 20% die verbleiben unter.

[basix]

Von Locuza gibt es eine Die Shot Annotation von Rocket-Lake:
https://www.pcgameshardware.de/Rocket-Lake-S-Codename-277112/News/Die-Shot-wurde-von-einem-Nutzer-genauestens-analysiert-und-beschriftet-1365068/

Was mir auffällt: Der L3$ scheint extrem dicht zu sein. Sogar dichter als bei AMDs CCD, obwohl 14nm vs. 7nm. Gäbe es hier also noch grosses Optimierungspotential? Nicht nur für Zen, auch RDNA und CDNA könnten davon stark profitieren (Infinity Cache)

[HOT]

Da steht dabei, dass die nicht richtig zueinander skaliert sind. RKL ist ja fast 300mm² groß.
Und sonst passts doch ganz gut, da RKL ja erheblich weniger $ hat. Außerdem sind GPU und Displayctrl. anders aufegeteilt. Da scheinen Bereiche bei RKL näher an der GPU zu sein und bei TGL näher am Display-Ctrl.

[Leonidas]

Könnte das nicht auf Herbst 2021 für Zen 4 hindeuten?

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


Nicht wirklich. Das bezieht sich auf Intels Alder Lake. Im Herbst 2021 ist von AMD bestenfalls ein Zen 3+ mit Codenamen "Warhol" zu erwarten - aber noch kein Zen 4. Der kommt erst 2022, womöglich sogar erst tief im Jahr 2022.

[basix]

Hab mich extra angemeldet, weil ich gewartet hab bis es jemand evtl. postet und diskutiert.
Nun mach ich es eben selbst :P

Reddit (https://www.reddit.com/r/GamingLeaksAndRumours/comments/jpmejf/amd_zen_4_cpus/)



Die Sache ist, ohne Verifikation könnten das sich viele sich aus den Fingern saugen und aufschreiben.
Was aber eher unüblich bei fakes ist, dass hier teilweise so genaue Angaben wie 3300mhz IF clock; 4 CCD und prozentuale Angaben, wie sich die IPC Steigerung zusammensetzt.

Ich will nicht sagen, dass es unbedingt echt ist, aber es ist interessant genug, um es mir zu bookmarken.
Wenn in einem Jahr Gerüchte zum FLCK und zu den CCDs auftauchen und es übereinstimmt, wäre ich nicht überrascht.

Um nochmals auf dieses Gerücht zurückzukommen:

+40% IPC
4x CCDs
Grosser L4$
7nm IOD
Optional: Navi (siehe geleakte Roadmap mit Raphael)


Ich konzentriere mich auf die letzten 3 Punkte, IPC lasse ich mal aussen vor. 4x CCDs wären 32 Cores. Das halte ich für eher unwahrscheinlich (ausser sie lassen Threadripper sterben). Ich tippe auf 2x CCDs und dass 4x CCDs einfach während der Entwicklung zur Diskussion standen. Es kann sein, dass das AM5 Package darauf ausgelegt ist, 1x IOD + 4x CCD zu tragen. Evtl. kommt das aber erst später z.B. mit Zen 5. Dito wäre ein Ansatz mit 2-3 CPU CCDs und einem GPU-CCD (RDNA3).

Was ich eher interessant finde ist IOD + L4$ + Navi. 7nm würde Sinn machen wenn die GPU direkt auf dem IOD sitzt (minimalst Konfiguration mit z.B. 4 CUs). Sonst würde ich eher in Richtung GloFo 12LP+ tendieren. Mit der GPU würde ich den L4$ (aka Infinity Cache) dann auch als sinnvoll betrachten (ob 3D-Stacked oder nicht ist eine andere Frage), auch wenn die GPU sehr klein ist für diesen "garguantuan" Cache. Aber GPU-CCDs wären auch denkbar (siehe oben).

Was mich an dem Gerücht am meisten stört: Die stark gestiegene Komplexität. Neben teureren Chiplets hätten wir mehr davon und im Falle GPU und L4$ nochmals erhöhte Siliziumfläche. Damit würde AMD seine Marge reduzieren oder die Preise steigen. Irgendwie sträube ich mich dagegen. Einzige Auflösung ist, dass AMD einen flexiblen Aufbau zulässt, wo man je nach Marktsegment die optimale Konfiguration zusammenstellen kann. Aber das bedeutet wiederum Komplexität.

[HOT]

Das wird ja immer mehr IPC :eek:, waren das nicht mal 30%? Aber das ist eh BS. AMD wird im nächsten Schritt sicherlich versuchen, die Latenzen, die durch das IOD entstehen, anzugehen. Die Grenzen werden fließender zwischen IOD und CCDs.
Zudem ist die Chance sehr sehr hoch, dass es beim 8C CCD bleiben wird, denn ich finde es plausibel, dass die Infrastruktur beim 8C CCX bleiben wird. Mehr ist im Desktop auch quatsch, 16C ist die Grenze der Sinnhaftigkeit beim Desktop-Sockel. Die Kerne auf dem Genoa-Träger sollen dennoch 96C betragen, das sind dann aber eben 12 und nicht mehr 8 CCDs.
Des Weiteren werden sicherlich die Caches über alles größer werden, also alle Stufen - ein L4 ist nicht unwahrscheinlich mit dem I$-Gedanken und es wird sicherlich 2 RDNA3-WGPs geben. Das IOD wird aber mMn 12LP+ sein, die geringen Kosten und höhere Verfügbarkeit bei GloFo dürfte da den Ausschlag geben. Wieviel Leistung das Ding letztendlich freisetzt ist offen. Ich werde mir dazu genaue Aussagen momentan verkneifen, denn das kann bei den Änderungen ein sehr inkonsistentes Leistungsbild geben, also schätzungsweise viele rechenintensive Anwendungen profitieren vielleicht überhaupt nicht, andere jedoch schon und viele I/O-intensive könnten sehr viel besser aussehen mMn.

[Der_Korken]

Wenn ein IOD in 7nm mit L4 kommt, dann würde ich darauf tippen, dass es auch einen ohne L4 gibt, der dann mit dem 6-Kerner und dem kleinen 8-Kerner gepaart wird und nur einen CCD supportet. Sonst hätte man das Problem, dass ein 6-Kerner fast genauso viel Silizium braucht wie ein 16-Kerner: 5nm CCD wird <60mm² landen und ein IOD mit 128MB L4 würde >150mm² groß. Selbst wenn man für 5nm den doppelten Preis pro Fläche annimmt, hätten die 1-CCD-Modelle schnell >=70% der Waferkosten wie die 2-CCD-Modelle.

Vielleicht denken wir auch nur zu kompliziert. Vielleicht bleibt es bei 12nm für den IOD, der bei ca. 120mm² bleibt (höherer IF-Takt bedeutet auch weniger Packdichte), sodass genau zwei CCDs drauf passen. Die Leitungen laufen von der Mitte des CCDs in die Mitte des IODs, von wo schneller zum IMC geroutet werden kann. Das könnte weitere 5-10ns Latenz sparen und den Verbrauch des IODs drücken, weil man keine externen Interfaces auf dem Package mehr hat. Es müsste dann aber auch der Verbrauch der CPUs sinken, weil jetzt nur noch 120mm² für 2xCCD und IOD übrig bleiben. Single-CCD-Modelle werden max. 65W TDP haben, 6-Kerner vielleicht sogar nur 45W.

[Grabhopser]

Bei den Spekulationen bezüglich des IODs sollte man das WSA zwischen AMD und GF nicht außer Acht lassen.
Auch wenn die genauen Abgabemengen nur bis Ende 2021 festgezurrt sind so läuft das Agreement doch bis 2024. Die „purchase targets“ ab 2022 sollten genauer Schlüsse zulassen.

[Der_Korken]

Da AMD mittlerweile in allen Bereichen oben mitspielt, könnte es für AMD auch finanziell günstiger sein sich aus einem Vertrag rauszukaufen statt minderwertige Komponenten abzunehmen und zu verbauen. Wenn die CPUs dadurch zu viel an Performance einbüßen und weniger Marge abwerfen, kann das langfristig teurer werden.

[HOT]

Das ergibt keinen Sinn, da GloFos 12nm ja auch die besten am Markt sein werden bei 12LP+. Aber ich würd auch sagen, ein Cache ist irgendwie wahrscheinlich aber eben sehr teuer. Von daher tendiere ich auch zu kein L4. Nur wird der IOD auf jeden Fall größer bei 12LP+, da die GPU hinzu kommt.

[basix]

Bei den Spekulationen bezüglich des IODs sollte man das WSA zwischen AMD und GF nicht außer Acht lassen.
Auch wenn die genauen Abgabemengen nur bis Ende 2021 festgezurrt sind so läuft das Agreement doch bis 2024. Die „purchase targets“ ab 2022 sollten genauer Schlüsse zulassen.

Jupp. Ich sehe auch LP12+ als mögliche Lösung an. Aber es gibt da noch EPYC, welcher ein entsprechendes IOD mitbringen könnte. Maximaler IF-Takt ist dort nicht von grosser Relevanz. Eher Stromverbrauch und dort scheint LP12+ anhand der GloFo Angaben nicht so schlecht zu sein.

[dargo]

Zudem ist die Chance sehr sehr hoch, dass es beim 8C CCD bleiben wird, denn ich finde es plausibel, dass die Infrastruktur beim 8C CCX bleiben wird. Mehr ist im Desktop auch quatsch, 16C ist die Grenze der Sinnhaftigkeit beim Desktop-Sockel.
Wie kommst du auf den Trichter? Nicht die Anzahl der Kerne limitiert dich bei AM4 oder dann halt AM5 sondern der Stromverbrauch. Solange es in 105W TDP passt kann Zen4 auch mit 64 Cores (überspitzt jetzt) auf AM5 kommen. Ich fände es jedenfalls schade wenn Zen4 wieder nur 8 Cores pro Chiplet hätte. Man sieht ja schon am 5800X, dass AMD hier langsam thermische Probleme bekommt. Die Fläche von einen 5800X ist einfach zu klein um diese Dinger kühl bei hoher Last zu halten. Ich fände es besser wenn AMD bei 5nm 12 Cores in einen Chiplet packt damit die Fläche auch größer wird. Mal angenommen das Ding wird pro Chiplet noch kleiner als Zen3. Wie will man die Abwärme schnell genug abführen? Mir ist natürlich auch klar, dass Die-Size kostet. Da wird AMD wieder einen guten Kompromiss finden müssen.

[Der_Korken]

Wie kommst du auf den Trichter? Nicht die Anzahl der Kerne limitiert dich bei AM4 oder dann halt AM5 sondern der Stromverbrauch. Solange es in 105W TDP passt kann Zen4 auch mit 64 Cores (überspitzt jetzt) auf AM5 kommen. Ich fände es jedenfalls schade wenn Zen4 wieder nur 8 Cores pro Chiplet hätte. Man sieht ja schon am 5800X, dass AMD hier langsam thermische Probleme bekommt. Die Fläche von einen 5800X ist einfach zu klein um diese Dinger kühl bei hoher Last zu halten. Ich fände es besser wenn AMD bei 5nm 12 Cores in einen Chiplet packt damit die Fläche auch größer wird. Mal angenommen das Ding wird pro Chiplet noch kleiner als Zen3. Wie will man die Abwärme schnell genug abführen? Mir ist natürlich auch klar, dass Die-Size kostet. Da wird AMD wieder einen guten Kompromiss finden müssen.

Das Kühlproblem existiert afaik nur beim 5800X, weil der ein genauso hohes PPT hat wie der doppelt so breite 5950X. Mit 65W TDP wäre er nur marginal langsamer, aber Temps wären überhaupt kein Problem. Sind sie beim 5950X ja auch nicht. 12 Kerne pro Chiplet halte ich für sehr unwahrscheinlich, weil der L3-Cache mir nicht so "modular" wie der von Intel erscheint, d.h. ein CCX muss idealerweise eine Zweierpotenz als Größe haben. AMD schaltet z.B. bei 6C keine Cache-Slices ab, d.h. die sind nicht so flexibel wie Intel, dafür sind die Latenzen aber etwas besser.

16 Kerne als zwei CCX auf einem Die sind natürlich möglich, aber die Masse kauft halt 8 Kerne oder kleiner und da verschwendest du dann maßlos Waferspace, wenn du deine 16 Kerner alle als 8-Kerner verkaufen musst. Statt 24 oder 32 Kerne hätte ich lieber erstmal 16 Kerne für <500€ und <100W, denn selbst von einer wirklichen Nutzung von 12 Kernen sind wir zumindest im Spielemarkt noch meilenwert entfernt.

[dargo]

Klar... mit weniger Wattage beim Solo-Chiplet könnte man dem entgegenwirken. Zwischen 65W TDP und 105W TDP ist noch eine Menge Platz. Warum nicht einfach 85W TDP mit dann entsprechenden PPT? :)

[Der_Korken]

Ich glaube, dass durch 5nm auch nochmal der Verbrauch ein gutes Stück sinken wird, wie bei Zen 2. Der 3700X war quasi ein 2700X mit 88W statt 140W PPT und der besseren Zen 2 IPC. Es würde mich wie gesagt nicht wundern, wenn die 8-Kerner max. auf 65W/88W gehen (der 5800X reizt oft genug seine 140W nichtmal aus, weil einfach längst irgendwelche Ströme limitieren), der 12-Kerner auf 95W/126W und nur noch der 16-Kerner bei 105W/140W bleibt. Die 15- und 35W-APUs sagen imho wohin die Reise geht mit dem Verbrauch.

[HOT]

Wie kommst du auf den Trichter? Nicht die Anzahl der Kerne limitiert dich bei AM4 oder dann halt AM5 sondern der Stromverbrauch. Solange es in 105W TDP passt kann Zen4 auch mit 64 Cores (überspitzt jetzt) auf AM5 kommen. Ich fände es jedenfalls schade wenn Zen4 wieder nur 8 Cores pro Chiplet hätte. Man sieht ja schon am 5800X, dass AMD hier langsam thermische Probleme bekommt. Die Fläche von einen 5800X ist einfach zu klein um diese Dinger kühl bei hoher Last zu halten. Ich fände es besser wenn AMD bei 5nm 12 Cores in einen Chiplet packt damit die Fläche auch größer wird. Mal angenommen das Ding wird pro Chiplet noch kleiner als Zen3. Wie will man die Abwärme schnell genug abführen? Mir ist natürlich auch klar, dass Die-Size kostet. Da wird AMD wieder einen guten Kompromiss finden müssen.
Abnehmender Ertrag, ganz einfach. Mehr als 16C (das sind 32Threads!) ist für die meisten Desktop-Anwendungen nicht sinnvoll nutzbar und wenn die Mehrzahl der Anwendungen nicht davon profitiert ist mehr als 16C schlichtweg sinnlos. Dazu gab es auch softwaretechnisch unterstützte Prognosen zu x86-Code, nebenbei. Leider finde ich sowas nicht mehr, ist ja auch Jahre her... Aber als Faustregel kann man denke ich festhalten, dass für die meisten Anwendungen (erst recht Echtzeit) irgendwann der Verwaltungsaufwand den Nutzen von mehr Threads übersteigt, dieser Peak war bei 16C IIRC.

Der_Korken
Mal sehen, was man sich für AM5 für Kühllösungen ausdenkt. Da muss halt langsam was passieren, Peltier-Elemente, Vapor-Chambers, WaKü als Standard - irgendwas. Dann kann man noch ein paar Generationen überbrücken ;).

[vinacis_vivids]

Abnehmender Ertrag, ganz einfach. Mehr als 16C (das sind 32Threads!) ist für die meisten Desktop-Anwendungen nicht sinnvoll nutzbar und wenn die Mehrzahl der Anwendungen nicht davon profitiert ist mehr als 16C schlichtweg sinnlos. Dazu gab es auch softwaretechnisch unterstützte Prognosen zu x86-Code, nebenbei. Leider finde ich sowas nicht mehr, ist ja auch Jahre her... Aber als Faustregel kann man denke ich festhalten, dass für die meisten Anwendungen (erst recht Echtzeit) irgendwann der Verwaltungsaufwand den Nutzen von mehr Threads übersteigt, dieser Peak war bei 16C IIRC.

Das stimmt so nicht.

Im Zeitalter von AI, Internet of things, Blockchain und Big Data sind mehr Kerne viel besser. Dass heutzutage 16C/32T für den normaluser völlig OP sind, ist klar.

[reaperrr]

Ich fände es besser wenn AMD bei 5nm 12 Cores in einen Chiplet packt damit die Fläche auch größer wird. Mal angenommen das Ding wird pro Chiplet noch kleiner als Zen3. Wie will man die Abwärme schnell genug abführen?
Das ist doch Quark. Bei gleichem Takt und gleicher Spannung bleibt auch der Stromverbrauch je Kern gleich, heißt, 12C-Chiplets bei ansonsten identischen Einstellungen bräuchten auch 50% mehr Saft und würden 50% mehr Hitze und damit genauso viel Hitze je mm² erzeugen.

Wie schon geschrieben wurde, die Fläche der Chiplets ist nicht das Problem, beim 5800X liegt es nur an der Kombi aus Takt/Spannung/PT.
Werden die Chiplets näher am Sweet-Spot betrieben, ist die Hitze kein Problem, das wird auch in 5nm so sein.

[Der_Korken]

Mal sehen, was man sich für AM5 für Kühllösungen ausdenkt. Da muss halt langsam was passieren, Peltier-Elemente, Vapor-Chambers, WaKü als Standard - irgendwas. Dann kann man noch ein paar Generationen überbrücken ;).

Ich glaube nicht, dass sowas aufwändiges kommt. Wenn etwas nicht gekühlt werden kann, wird entsprechend der Verbrauch gedeckelt bzw. mehr in Richtung Effizienz entwickelt. Eigentlich ist das Thema Wärmedichte nur bei Highend-Desktop-CPUs ein Problem, das bei Midrange-Desktop, Mobile, HEDT und Server nicht vorkommt. Wir hier sind also eigentlich die Außenseiter :D.

[YfOrU]

Das ergibt keinen Sinn, da GloFos 12nm ja auch die besten am Markt sein werden bei 12LP+. Aber ich würd auch sagen, ein Cache ist irgendwie wahrscheinlich aber eben sehr teuer. Von daher tendiere ich auch zu kein L4. Nur wird der IOD auf jeden Fall größer bei 12LP+, da die GPU hinzu kommt.

Die IGP bei Raphael spricht ziemlich eindeutig dafür das dieses Design nicht nur Desktop sondern auch Mobile bedient. Praktisch wird AMD hier 2022 auch etwas oberhalb von Rembrandt brauchen wenn man ganz vorne dabei sein will. Für mich zeigt das insgesamt schon eher in die gleiche Richtung wie es Intel grundsätzlich handhabt. Zwei Designs mit jeweils einmal mehr Kernen und einmal fetterer IGP.

Das hier (Client) ein IOD in GFs 12LP+ der optimale Weg ist halte ich nicht für wahrscheinlich denn effektiv müssen sowohl eine niedrige Leistungsaufnahme als auch hohe Frequenzen möglich sein. Sobald es dann aber Richtung 7/5mn geht stellt sich die Frage welchen Vorteil ein MCM noch bieten kann denn das sollte alles (5nm) in um die 180mm² passen.

Gegenüber dem jetzigen Design haben sich die Vorzeichen schon etwas geändert. Bei 7nm ist AMD früh eingestiegen und ursprünglich (Planung) hätte es mit GF einen zweiten Fertiger gegeben. Auch mussten mit Blick auf Volumen und Marktanteile Kompromisse eingegangen werden.

Bis Raphael kommt ist 5nm sicherlich eine Runde Sache (Apple). Ein Design Richtung 200mm² sollte im mittleren bis oberen Preissegment kein Problem sein. Darunter Rembrandt und eine Entry APU.

[Zossel]

Das stimmt so nicht.

Im Zeitalter von AI, Internet of things, Blockchain und Big Data sind mehr Kerne viel besser. Dass heutzutage 16C/32T für den normaluser völlig OP sind, ist klar.

Irgendwie ist dieses Zeitalter bei mir nicht angekommen da ich diesen Hipster-Kram zu hause nicht nutze.
Hat man besseren Sex wenn man AI, Internet of things, Blockchain und Big Data zu hause nutzt?

[amdfanuwe]

Bei 7nm ist AMD früh eingestiegen und ursprünglich (Planung) hätte es mit GF einen zweiten Fertiger gegeben.
Kann man so nicht sagen. Ursprünglich plante man doch mit GF 7nm wegen WSA.
Erst als sich verdeutlichte, dass GF 7nm nicht auf die Reihe bekommt, ist man bei TSMC 7nm All In gegangen.

[HOT]

Kann man so nicht sagen. Ursprünglich plante man doch mit GF 7nm wegen WSA.
Erst als sich verdeutlichte, dass GF 7nm nicht auf die Reihe bekommt, ist man bei TSMC 7nm All In gegangen.
Das ist schlicht falsch. Matisse muss schon Anfang 2018 TapeOut gehabt haben, das bedeutet, AMD wusste schon 2016 oder gar davor, dass es TSMCs 7nm werden würde. AMD und GloFo muss vorher schon klar gewesen sein, dass die eigenen 7nm nicht zum gleichen Zeitpunkt erscheinen werden und zu Lebzeiten von Matisse nicht zum Einsatz kommen werden.

[vinacis_vivids]

Irgendwie ist dieses Zeitalter bei mir nicht angekommen da ich diesen Hipster-Kram zu hause nicht nutze.
Hat man besseren Sex wenn man AI, Internet of things, Blockchain und Big Data zu hause nutzt?

Dass du Sex im Hirn hast, hat vermutlich mit der Suchmaschinen-AI zu tun, die du unbewusst verwendest um nach bestimmten keywords zu suchen, die deine Neugier und Wissensdurst zu befriedigen versuchst.

AI, Internet of things, Blockchain und Big Data haben durchaus was mit "besseren Sex" zu tun.

Es gibt einige Studien, die untersuchen wieviel Anteil von dieser Art von content im traffic verursacht wird. Du wirst es vllt. nicht glauben, aber die technische Entwicklung hat dazu geführt, dass immer mehr Menschen (auch Jugendliche) immer früher Kontakt mit sexuellen Content (nackte Schönheitsideale) bekommt.

Um eben die Psychologie der Massen steuern zu können, ist AI, Internet of things, Blockchain und Big Data auch für zu Hause sehr interessant.

Was du persönlich und praxisrelevant aus diesem Kontext ziehen kannst, ist in deiner Vorstellungswelt verankert. Ich denke wirst in der weiten Welt einiges herausfinden, die Information ist da. ;D

[YfOrU]

Das ist schlicht falsch. Matisse muss schon Anfang 2018 TapeOut gehabt haben, das bedeutet, AMD wusste schon 2016 oder gar davor, dass es TSMCs 7nm werden würde. AMD und GloFo muss vorher schon klar gewesen sein, dass die eigenen 7nm nicht zum gleichen Zeitpunkt erscheinen werden und zu Lebzeiten von Matisse nicht zum Einsatz kommen werden.

Siehe: https://www.anandtech.com/show/12312/getting-radeon-vega-everywhere-an-exclusive-interview-with-dr-lisa-su-amd-ceo

Das die ersten 7nm Chips von TSMC kommen würden war sicherlich frühzeitig absehbar. Das aber keine von GF kommen war AMD noch nicht mal Anfang 2018 klar. Allerdings war das gewählte Design (CCDs+IOD) gegen dieses Risiko vergleichsweise resistent. Es haben sicherlich noch viele weitere Faktoren wie das WSA mit GF, Skalierung im Enterprise, Volumen, R&D Ressourcen etc. am Ende den Ausschlag gegeben. Für die Zeit war es auf jeden Fall eine genialer Lösungsansatz. Für die Zukunft sehe ich im Client Segment eher wieder den Weg zu monolithischen Designs. Zumindest solange Interposter, Stacking etc. nicht wirklich großflächig in Mainstream Produkten ankommen. Enterprise dagegen klar MCMs und hier könnte AMD dann auch ohne Kompromisse agieren. Also angepasste Kerne und größere CCDs als heute.

[Nightspider]

Weil hier letzte Seite über die Wärmedichte gesprochen wurde:
Ich glaub da müssen wir uns jetzt keine so großen Sorgen machen.
Zen3 ist ~16% größer als Zen2 im gleichen Fertigungsprozess und wir können mit großer Sicherheit davon ausgehen das Zen4 nochmal deutlich anwachsen wird, was die Anzahl der Transistoren angeht.
Ich würde grob davon ausgehen das Zen4 25-35% größer als Zen3 ausfallen wird und TSMC gibt für 5nm grob 30% geringeren Verbrauch an.
Dazu werden viele der Transistoren auch für eine bessere IPC und größere Caches und (damit) bessere Effizienz draufgehen. Das wird schon passen.

Ich könnte mir aber auch vorstellen das die Yields bei einem 12C Chiplet in 5nm so gut werden, das man den Markt für 1-4 Kerne quasi wegsterben lässt.
Selbst die APUs für Laptops sind ja jetzt schon bei 6-8 Kernen bei AMD. Und in 1-1,5 Jahren wäre es doch für niemanden ein Problem wenn es erst bei 6-8 Kernen losgeht mit Zen4 oder?
Für den LowEnd Markt (Büro-Computer) würden doch die Cezanne und Rembrandt APUs ausreichen. Die 7nm Produkte würden 2022 jedenfalls deutlich billiger sein.
Niemand braucht einen Zen4 mit 4 Kernen weil die "Einsteiger-Gamer" sich 2022 noch mehr Richtung 6-8 Kernen orientieren müssen als jetzt schon und ein Büro-Computer braucht kein Zen4.
Und wenn doch kommt eben ein 8C Derivat oder höher hinein.

Der Ryzen 5900X mit 12 Kernen ist jetzt schon eine der beliebtesten CPUs. Zen4 mit einem 12Kern Chiplet würde eigentlich ideal passen.
Ein hypothetischer 6600X hätte dann halt 8 Kerne und man könnte noch einen 6700X mit 10 Kernen einführen.

Oder AMD belässt die Kern-Aufteilung einfach so und designt ein 8C Chiplet für den Desktop-Markt und bringt ein 12C Chiplet für den HPC Markt.
Die Frage ist nur ob sich das mehr lohnt als einfach den 4C-Markt wegsterben zu lassen und selbst den 6C Markt nur schlecht bedienen zu können, weil es bei einem 12C Chiplet gar nicht so viele fehlerhafte Dies geben wird, als das man 6 Kerner in großer Zahl liefern könnte. (Siehe Zen2 Quadcores)

Ich weiß, im Moment sieht man noch absolut gar keine Auswirkungen der PS5 und Xbox Series X aber die haben 5-6 mal so viel CPU Leistung und bei Spielen werden früher oder später die Anforderungen an die CPU massiv nach oben schießen.
Es werden also immer mehr Gamer zu mehr CPU Kernen greifen (müssen).

[dargo]

Weil hier letzte Seite über die Wärmedichte gesprochen wurde:
Ich glaub da müssen wir uns jetzt keine so großen Sorgen machen.
Zen3 ist ~16% größer als Zen2 im gleichen Fertigungsprozess und wir können mit großer Sicherheit davon ausgehen das Zen4 nochmal deutlich anwachsen wird, was die Anzahl der Transistoren angeht.
Ich würde grob davon ausgehen das Zen4 25-35% größer als Zen3 ausfallen wird und TSMC gibt für 5nm grob 30% geringeren Verbrauch an.
Dazu werden viele der Transistoren auch für eine bessere IPC und größere Caches und (damit) bessere Effizienz draufgehen. Das wird schon passen.

Wie kommst du darauf, dass Zen4 größer als Zen3 wird? Das ist noch völlig offen. Es könnte sogar sein, dass Zen4 dank 5nm kleiner ausfällt. Je nachdem wie viele Transistoren AMD bei Zen4 investiert und ob es je Chiplet bei 8 Cores bleibt oder eher Richtung 12 Cores geht. Auch die angeblichen -30% Verbrauch bei 5nm sind erstmal nichts wert bzw. kann man davon nichts ableiten. Je nachdem wie hoch die Frequenzen bei Zen4 ansteigen kann sich das auch schnell in Luft auflösen.

[Nightspider]

Natürlich kern-und prozessnormiert.

[dargo]

Ich fände es jedenfalls besser wenn AMD sich zukünftig von den 142W PPT bei einem Chiplet verabschiedet. Das ist einfach zu viel imho. Schon 105W PPT macht einen riesen Unterschied bei den Temps. Auch diese TDP-Angaben nerven. Das hat nichts mit der Praxis zu tun. Da wird eine CPU als 105W TDP beworben und dann säuft das Teil bei Cinebench MT mal eben 35% mehr. Da frage ich mich echt... was soll das? Imho sollten TDP-Angaben wieder max. Verbrauch entsprechen wie das Powerlimit bei GPUs.

Edit:
Auch die Unterschiede bei TDP vs. PPT finde ich Käse.

65W TDP = 88W PPT
105W TDP = 142W PPT

Beides ergibt zwar je +35%. Beim Zweiteren müssen aber 14W mehr abgeführt werden.

[Slipknot79]

Gibts bereits (gerüchteweise) nen groben Zeitraum wann Zen4 auf den Markt rausgeballert werden soll?

[basix]

? Imho sollten TDP-Angaben wieder max. Verbrauch entsprechen wie das Powerlimit bei GPUs.

Edit:
Auch die Unterschiede bei TDP vs. PPT finde ich Käse.

65W TDP = 88W PPT
105W TDP = 142W PPT

Beides ergibt zwar je +35%. Beim Zweiteren müssen aber 14W mehr abgeführt werden.

Japp, Verbrauch wäre die sinnvollste Angabe. Eindeutig und unwiderlegbar. Bei der TDP kann man halt etwas "bescheissen" (gilt für beide Lager).

Und +35% für beide ist nicht Käse. Ein relatives Limit ist deutlich sinnvoller als ein absolutes. Extremes Beispiel: 15W CPU mit 38W oder 200W CPU mit 223W. Welches der beiden Kühllösungen ist wohl deutlich über dem Limit, wenn für die TDP designed?

[memory_stick]

bisher hat AMD jeweils ca. 15 Monate zwischen 2 Zen Generationen benötigt.
Zen3 = Nov(11) 20
Zen4 = Nov20 +15Mo = Feb22?
Wäre demnach Frühjahr 22.
Alles unter der Prämisse, das AMD den Releasezeitplan so beibehalten kann und der verwendete Node verfügbar ist.

Momentan gibts ja noch Warhol (Zen3+) der noch unklar ist, kann demnach den Release von Zen4 beeinflussen (Zwischen Zen1 und Zen2 waren auch mehr als 15 Monate, dafür gabs Zen+. Zen1 - 12mo - Zen1+ - 15mo Zen2 - 15Mo - Zen3 - ?)

[dargo]

Und +35% für beide ist nicht Käse. Ein relatives Limit ist deutlich sinnvoller als ein absolutes. Extremes Beispiel: 15W CPU mit 38W oder 200W CPU mit 223W. Welches der beiden Kühllösungen ist wohl deutlich über dem Limit, wenn für die TDP designed?
Der Vergleich ist unpassend da nicht die gleiche CPU. Eine 15W CPU gibts garantiert nie im Desktop. ;) Ich wollte eigentlich damit nur zeigen, dass diese 142W PPT für einen Chiplet absolut grenzwertig sind. Imo eher schon zu hoch. 128W würden schon eine recht brauchbare Abmilderung schaffen.

Edit:
Noch besser fände ich...

5600X = 75W TDP
5800X = 105W TDP

TDP = max. Verbrauch. Erst ab 5900X (also zwei Chiplets) würde ich dann die 105W TDP sprengen.

[Der_Korken]

Ich würde grob davon ausgehen das Zen4 25-35% größer als Zen3 ausfallen wird und TSMC gibt für 5nm grob 30% geringeren Verbrauch an.
Dazu werden viele der Transistoren auch für eine bessere IPC und größere Caches und (damit) bessere Effizienz draufgehen. Das wird schon passen.

[...]

Der Ryzen 5900X mit 12 Kernen ist jetzt schon eine der beliebtesten CPUs. Zen4 mit einem 12Kern Chiplet würde eigentlich ideal passen.
Ein hypothetischer 6600X hätte dann halt 8 Kerne und man könnte noch einen 6700X mit 10 Kernen einführen.

25-35% ist imho viel zu viel. Zen 3 war laut AMD ein major redesign, da wäre es unlogisch, wenn jetzt plötzlich so viel dazu kommt. Man darf nicht vergessen, dass 50% der Zen 3-Chiplets für den L3 draufgehen, d.h. wenn der gleich bleibt, müsste der Core schon um 50-70% wachsen, um die Gesamtgröße um 25-35% steigen zu lassen. Für Big-Little-Design könnte AMD vielleicht dermaßen riesige Cores verbauen, aber für ein One-Size-Fits-All scheint mir das zu viel Energieverschwendung (siehe die riesigen, durstigen Cove-Cores von Intel) zu sein.

Und zu 12C-Chiplets habe ich auch schon geschrieben, dass ich das für unwahrscheinlich halte, weil AMD bei den Cache-Slices nicht so flexibel ist wie Intel. Alle Ryzen-CPUs laufen entweder mit vollem Cache bzw. einige Zen 1-Ausnahmen liefen mit halbem Cache. Das legt die Vermutung nahe, dass ein CCX immer eine Zweierpotenz an Cache-Slices braucht. 12C würde also nur gehen, wenn man noch mal weitere Verschlechterungen an der Cache-Latenz in Kauf nimmt. Der nächste Schritt (für den nächsten major redesign, also frühestens Zen 5) wäre imho entweder 16C-CCX oder ein L4.

Außerdem glaube ich, dass der Boost von Zen 3 nicht so sehr daher kommt, dass jetzt 8 Kerne an einem L3 hängen, sondern dass einzelne Kerne mehr Gesamtcache schnappen können. Ansonsten müssten z.B. 3900X vs 3800X und 5900X vs 5800X in der Mehrheit der Spiele Performance-Nachteile haben, weil sie nur 75% der Kerne pro CCX haben. Das ist bis auf ganz wenige Ausnahmen aber nicht der Fall.

Wie kommst du darauf, dass Zen4 größer als Zen3 wird? Das ist noch völlig offen. Es könnte sogar sein, dass Zen4 dank 5nm kleiner ausfällt. Je nachdem wie viele Transistoren AMD bei Zen4 investiert und ob es je Chiplet bei 8 Cores bleibt oder eher Richtung 12 Cores geht. Auch die angeblichen -30% Verbrauch bei 5nm sind erstmal nichts wert bzw. kann man davon nichts ableiten. Je nachdem wie hoch die Frequenzen bei Zen4 ansteigen kann sich das auch schnell in Luft auflösen.

Ich denke wir können ziemlich sicher sein, dass ein Zen 4-Core weniger Fläche brauchen wird als ein Zen 3-Core, da wir von 5nm mindestens 50% mehr Packdichte erwarten können. Ich hoffe auch, dass der Verbrauch pro Core deutlich sinken wird und wir eher eine Verteilung sehen wie:

6C: 45W TDP
8C: 45-65W TDP
12C: 65-95W TDP
16C: 95-105W TDP

Der Prozess würde das locker hergeben und mehr Verbrauch wird auch nicht zu nennenswert mehr Takt führen. Aber realistisch betrachtet wird AMD wieder versuchen auch den 8-Kerner auf 105W TDP hochzuprügeln, auch wenn das nur 1% schneller ist als 65W.

[Nightspider]

25-35% ist imho viel zu viel. Zen 3 war laut AMD ein major redesign, da wäre es unlogisch, wenn jetzt plötzlich so viel dazu kommt. Man darf nicht vergessen, dass 50% der Zen 3-Chiplets für den L3 draufgehen, d.h. wenn der gleich bleibt, müsste der Core schon um 50-70% wachsen, um die Gesamtgröße um 25-35% steigen zu lassen.

Ich würde schon davon ausgehen das Zen4 mehr Cache bekommt und AMD das Cache-System weiter optimiert.
Das der Cache viel vom Platzbedarf ausmacht hatte ich ja gerade im Hinterkopf als ich schrieb die Wärmedichte wird bestimmt kein großes Problem.

Hat AMD denn irgendwo gesagt das Zen5 ein Major Redesign wird oder Zen4 nicht?

[HOT]

Ich würde schon davon ausgehen das Zen4 mehr Cache bekommt und AMD das Cache-System weiter optimiert.
Das der Cache viel vom Platzbedarf ausmacht hatte ich ja gerade im Hinterkopf als ich schrieb die Wärmedichte wird bestimmt kein großes Problem.

Hat AMD denn irgendwo gesagt das Zen5 ein Major Redesign wird oder Zen4 nicht?
Nein. Zen5 ist sehr unklar, bis vor kurzem war bei Zen5 noch vollkommen unklar, ob es den überhaupt geben wird. Neulich hat Lisa IIRC verlautbart, dass es Zen5 geben wird.
Ich nehme an, das wird mit der N3-Verzögerung zu tun haben und dass die Preise für N3 durch die Decke gehen, weil ja jetzt Intel und Apple darum buhlen, da hat man wenig Chancen, da noch genügend Kapazitäten zu bekommen.
Vielleicht bezog sich die Samsung-Nummer ja auf Zen5, dass man den direkt in 3LPE fertigen möchte. Ist aber alles hoch spekulativ.

Ich halte für Warhol halbwegs sicher, dass das identische Hardware zu Vermeer ist und dass Zen4 pro CCD bei 8 Kernen bleibt, um die Wärmestromdichte aber nicht allzu stark aus dem Ruder laufen zu lassen, wird man SRAM massiv ausbauen in vielen Bereichen mMn. Da ist also ein ähnliches Vorgehen wie bei Tiger Lake zu erwarten mMn, dessen massive SRAM-Erhöhungen unter einem ähnlichen Gesichtspunkt einordnen würde.

[Nightspider]

Ich denke Zen4 könnte genauso ein großes Redesign werden wie Zen3.

Alleine schon weil man viel mehr Platz hat und mehr Möglichkeiten umsetzen kann.

[robbitop]

Ich habe Zen 3 als Redesign wahrgenommen mit dem Ziel eine Art Rebalancing durchzuführen, um mehr IPC zu bekommen jedoch ohnet alles aufzublähen (Frontend, Backend, OoO Window, alle möglichen Buffer, L1, L2). Und das macht Zen 3 so energieeffizient - auch im core-to-core Vergleich mit einem Willow Cove.

Meine persönliche Annahme ist, dass sie mit Zen 4 das tun, was Intel mit den Coves tut. Alles breiter machen. Dafür hat man nach dem Zen 3 Rebalance/Redesign ein gutes Fundament. Entsprechend braucht man den nächsten Shrink um die gesteigerte Leistungsaufnahme wieder zu kompensieren. Je nach dem wie stark sie das Design breiter machen, kann man schon erwarten, dass da gute Steigerungen drin sind. Taktnormiert zwischen 15 und 25% ist nicht gänzlich unrealistisch. Alles darüber würde mich mit zunehmendem Grad skeptischer machen. :)

Es wird interessant zu sehen, ob man auch mehr Cores pro Chiplet verbaut (oder einfach mehr Chiplets pro SKU).

[HOT]

Angeblich soll Genoa eine neue I/O-Topologie bekommen mit InfinityArchitecture 3 und das IOD dann 12 Chiplets anbinden, was 96 Cores ermöglicht. Gibt ja auch völlig neue Infrastruktur mit DDR5 und PCIe5.

[Elite_Warrior]

Edit:
Noch besser fände ich...

5600X = 75W TDP
5800X = 105W TDP

TDP = max. Verbrauch. Erst ab 5900X (also zwei Chiplets) würde ich dann die 105W TDP sprengen.

Stimmt so, nur sieht es auf der Verpackung dann eben nicht mehr so "cool" aus. Ist halt Marketing

[Hammer des Thor]

Wie kommst du darauf, dass Zen4 größer als Zen3 wird? Das ist noch völlig offen. Es könnte sogar sein, dass Zen4 dank 5nm kleiner ausfällt. Je nachdem wie viele Transistoren AMD bei Zen4 investiert und ob es je Chiplet bei 8 Cores bleibt oder eher Richtung 12 Cores geht. Auch die angeblichen -30% Verbrauch bei 5nm sind erstmal nichts wert bzw. kann man davon nichts ableiten. Je nachdem wie hoch die Frequenzen bei Zen4 ansteigen kann sich das auch schnell in Luft auflösen.


Zumal AMD 3D CPUs plant und als Zwischenschritt 2,5D auf ihren Folien. Mit 2,5D und 12 Kernen pro CCD dürften nen Zen4-CCD kleiner sein als nen Zen-3 CCD!

[Nightspider]

Naja wir könnten uns jetzt darüber streiten ob die Architektur zu einem Fertigungsprozess gehört.

Zen4 in 7nm würde viel größer werden als Zen3. Das wird eben nur mehr als kompensiert durch 5nm.

Es sollte eigentlich aus dem Zusammenhang klar sein was gemeint ist.

Bei Intels RKL Backport sieht man ja auch das die neue Architektur deutlich größer ausfällt.
Die ist nicht zwingend an einen Fertigungsprozess gebunden.

So wie es auch oft GPU Architekturen in vers. Fertigungsstufen gab. G80->G92.

Zumal AMD 3D CPUs plant und als Zwischenschritt 2,5D auf ihren Folien.

Nur hat das überhaupt rein gar nichts mit Zen4 zu tun.

[Hammer des Thor]

Nur hat das überhaupt rein gar nichts mit Zen4 zu tun.

? 2,5D dann erst am Zen 5 oder was?

[Nightspider]

Stell die Frage in 1,5 Jahren nochmal.

Erstmal bleibt man bei Chiplets.

Am ehesten sehen wir vielleicht noch andere Packaging Technologien im Desktop/Server/Mobile Bereich wie Fan-out wafer-level packaging.

Das erhöht aber auch den Aufwand und die Kosten und da ist die Frage in welcher Stückzahl sowas heute produzierbar ist.

[reaperrr]

und 12 Kernen pro CCD
Ich bezweifle stark, dass wir je CCDs mit mehr als 8 Kernen sehen werden. Die daduch komplizierter werdende Verdrahtung und Verschlechterung der Yield würde sämtliche (wahrscheinlich eh marginalen) Vorteile mehr als auffressen.

[Hammer des Thor]

Ich bezweifle stark, dass wir je CCDs mit mehr als 8 Kernen sehen werden. Die daduch komplizierter werdende Verdrahtung und Verschlechterung der Yield würde sämtliche (wahrscheinlich eh marginalen) Vorteile mehr als auffressen.

Bei 3D Architektur sollte das gehen. Intel Server- und HEDT-CPUs haben doch auch bis zu 28 Kerne oder 18 Kerne auf einen Chip!

[Cyberfries]

Ich denke, gemeint ist CCX nicht CCD.
Zen 1/+/2 hatten 4Kern-CCX mit 6 Direktverbindungen zwischen den einzelnen Kernen (3950X mit 4CCX auf 2CCD)
Die Anzahl an benötigten Direktverbindungen steigt jedoch überproportional:
4-Kerne: 6 Direktverbindungen
5-Kerne: 10, 6 Kerne: 15, 8 Kerne: 28, 12 Kerne: 66, 16 Kerne: 120
Dass das nicht machbar ist, ist logisch.
Intel setzt bei kleinen CPUs auf einen einfachen oder doppelten Ringbus, der aber auch in Skalierungsprobleme läuft.
Bei großen CPUs mit vielen Kernen (Xeons) wird ein "Mesh" eingesetzt.

Die interessante Frage ist, wie läuft das bei Zen 3? Auf die Schnelle konnte ich nichts finden.
An sich spricht aber selbst mit 8-Kern-CCX nichts gegen mehr als 8 Kerne auf einem CCD (Chiplet) analog zu Zen2.

[=Floi=]

Zen 3 hat einen CCX mit 8 kernen und daraus resultiert ein weiterer performancegewinn.
https://de.wikipedia.org/wiki/Zen_3

Das thema ist schon sehr faszinierend.

[basix]

Die interessante Frage ist, wie läuft das bei Zen 3? Auf die Schnelle konnte ich nichts finden.
An sich spricht aber selbst mit 8-Kern-CCX nichts gegen mehr als 8 Kerne auf einem CCD (Chiplet) analog zu Zen2.

Ich meinte irgendwo gelesen zu haben, dass es immer noch "irgendwie direkt" ist aber nicht mehr einer 1zu1 Verbindung entspricht. Kann es aber gerade nicht finden. War ein Statement von AMD an einen Redakteur. Was ich aber gefunden habe:

Anandtech
"We asked AMD about the topology of the new cache but they wouldn’t comment on it besides stating that it’s still an address-hash based system across the 8 cache slices, with a flat memory latency across the depth of the cache, from the view of a single core."
https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-dive-review-5950x-5900x-5800x-and-5700x-tested/4

PCGH:
"Wenn man sich diese Zahlen (https://extreme.pcgameshardware.de/threads/cpu-interne-latenzen-sisoftware-benchmark.498039/page-3#post-10575223) anschaut, sieht's durchaus nach einer Butter(fly)-Donut Topologie mit max. 2 Hops aus."
https://www.pcgameshardware.de/Vermeer-Codename-276905/Specials/Zen-3-analysiert-1361112/
https://extreme.pcgameshardware.de/threads/amd-ryzen-5000-die-zen-3-architektur-im-detail.593952/#post-10576671
https://www.eecg.utoronto.ca/~enright/Kannan_MICRO48.pdf

[Cyberfries]

@basix
Danke für die Links, interessant.
Wenn ich das richtig verstehe, war Zen bisher also eine Art Butterfly +.
Zen 3 dann zweimal das ganze nebeneinander plus Direktverbindungen zwischen 1&5, 2&6, 3&7, 4&8.
Insgesamt also 16 Direktverbindungen, etwas mehr als halb so viele wie oben skizziert.
Das ergibt Sinn.

Wobei noch gesagt werden muss, dass es nur die Kommunikation zwischen den Kernen geht.
Es gibt schließlich auch noch Verbindungen zur Außenwelt, die das ganze nochmals komplexer machen.

[reaperrr]

An sich spricht aber selbst mit 8-Kern-CCX nichts gegen mehr als 8 Kerne auf einem CCD (Chiplet) analog zu Zen2.
Technisch nicht, aber der Knackpunkt ist: In Hinblick auf Latenz bzw. benötigte IF-Bandbreite besteht so gut wie kein Unterschied zwischen 2x8C und 1x16C Chiplets, solange die Zahl der CCX gleich ist.
Ergo, kein Nutzen.
Dafür aber deutliche Nachteile bei Yield und Binning. Bei einem 81mm² 8C-Chiplet ist die Wahrscheinlichkeit, dass das Chiplet sowohl voll funktionstüchtig ist, als auch alle Kerne eine gewisse Takt/Spannung-Kombi schaffen, deutlich höher als dies bei einem 16C-Chiplet mit 2 CCX der Fall wäre.
Die Taktraten des 5950X wären mit monolithischem 2x8C-CCX-CCD niemals in 105W TDP/142W drin gewesen.

Intel's Ice Lake-SP hat sich deshalb immer weiter verzögert, weil sie durch die Kombi schlechter Prozess + monolithisches Design kaum Chips rausbekommen, bei denen mehr als 32 von 42 Kernen funktionieren, und die dann teilweise auch noch saufen wie ein Loch.
Hätte Intel für Ice Lake schon eine Chiplet-Architektur auf dem Niveau von Zen2 gehabt mit 8-10 Kernen je Chiplet, gäbe es schon seit einem Jahr Ice Lake-SP mit 48-64 Kernen. Nicht mit konkurrenzfähigen Taktraten, weil 10nm (und auch Ice Lake uArch an sich) vor SuperFin dafür einfach zu ineffizient ist, aber zumindest die Probleme mit der Ausbeute wären nicht halb so dramatisch.

[Cyberfries]

Es ist durchaus ein Unterschied vorhanden, ob innerhalb eines Chiplets oder zwischen zwei Chiplets kommuniziert wird.
Anandtech (https://www.anandtech.com/show/15708/amds-mobile-revival-redefining-the-notebook-business-with-the-ryzen-9-4900hs-a-review/2) maß 7-18ns innerhalb eines CCX, 81-89ns innerhalb eines CCD und 110-118ns zwischen CCDs.

Aber es geht ja nicht um die Überlegung, ob bei Zen2 oder Zen3 16Kern-Chiplets sinnvoll gewesen wären (nein, natürlich nicht).
Deine Aussage war, dass wir 16-Kern-CCDs nie sehen werden.
Und das ist zweifelhaft, denn bei anderer Fertigung und mehr Kernen kann in Zukunft das Optimum anderswo liegen.
Wenn nicht zwischenzeitlich eine gänzlich andere Anordnung umgesetzt wird...

[mboeller]

Deine Aussage war, dass wir 16-Kern-CCDs nie sehen werden.
Und das ist zweifelhaft, denn bei anderer Fertigung und mehr Kernen kann in Zukunft das Optimum anderswo liegen.
Wenn nicht zwischenzeitlich eine gänzlich andere Anordnung umgesetzt wird...

Wenn du dir diese Bilder von Intel anschaust, dann ist es sogar sehr zweifelhaft, dass wir jemals was mit >8Cores sehen werden. es geht eher in die andere Richtung:

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

Vor allem bei Time-to-Market (und damit Kosten) ist ein massiver Unterschied.

[basix]

Doch, doch. 16 Kerner werden wir sehen. Das Intel Schaubild kann auch in 3D gesehen werden. Ein Zen 2/3 Chiplet besteht zur Hälfte aus L3$. Nimmt man den raus und 3D-Stacked den, hat man automatisch doppelten Platz. Das Scaling bei 5nm ist 1.8x und bei 3nm ist es 1.7x (jeweils Logik). Passen also sicher nochmals 2x Kerne auf die selbe Fläche. Resultat: 1/2 Chipfläche bei 2x Kernen (40mm2, 16 Kerne). Mich würde aber nicht verwundern, wenn dieser 3nm Chip immer noch "monolithisch" ist. Ist schlussendlich eine Kostenfrage und auch eine Frage der thermischen Machbarkeit.

[Tarkin]

https://chipsandcheese.com/2021/02/05/amds-past-and-future-cpus/

Hat jemand eine Ahnung wer diesen Blog betreibt???

Ich zieh mal die interessanten Infos raus:

Zen 4 is what a lot of people are waiting for, and well, the info I have will make that wait even more worth it. I have heard many things about Zen 4, all of which is positive. Over 25% IPC gain, total performance gain of 40%, possibly 5GHz all core because of the new N5 node from TSMC! Now, I don’t know what is true and what is an over exaggeration, however I was told from a trusted source that a Genoa ES server was 29% faster than a Milan server with the same core config and the same clocks, factor this in with what I have heard about the possible clock gains that N5 will bring over N7, and Zen 4 sounds like it is going to be a monster of a CPU.

Now I said I had Zen 5 info, but unfortunately what I have is a source separate from my Zen 4 info that has said that the jump from will be about as much as Piledriver to Zen 1, which if you recall to earlier in this article was 40%. I was told from a 3rd source that Zen 5’s original design goal was 2.5 to 3 times the IPC of Zen 1 which roughly lines up with the previous info of a Piledriver to Zen 1 like jump.

[Der_Korken]

Klingt ähnlich übertrieben wie dieser reddit post, der hier zweimal auftauchte. Da wurden 30-40% IPC gain durch besseres IF versprochen. Ich zweifel das wie auch davor mal massiv an, denn historisch sind IPC gains immer schwieriger geworden und ich wüsste nicht warum sich dieser Trend plötzlich umkehren sollte. Zen 1 war natürlich ein massiver Sprung, der komplett aus dem Schema fällt, aber da kam man auch von einer außerordentlich schlechten Grundarchitektur.

Eventuell sind die 25% aber über Spezialfälle mit extremen Zuwächsen gemittelt. Eventuell hat Zen 4 eine dritte FMA-Unit und/oder Fullspeed AVX512. Dadurch kann die IPC in AVX-lastigen Benches direkt mal um 50 bis 100% steigen und dadurch den ganzen Schnitt nach oben ziehen. 10 bis 15% in real-world benches würde ich noch mitgehen, aber dass der komplette Overhaul á la Zen 3 "nur" knapp 20% bringt und der "Tick" mit Zen 4 so viel mehr, finde ich nicht plausibel. Bei der Energieeffizienz könnte es dagegen viel Fortschritt geben durch 5nm, ähnlich wie Zen 2 zu Zen 1.

[mboeller]

ZEN1 -> ZEN3 sind im Cinebench MT @ 4GHz anscheinend auch +35% IPC:

https://www.techspot.com/article/2143-ryzen-5000-ipc-performance/

AMD scheint da mehr Erfolg zu haben als Intel. Vielleicht bleibt das ja so.

[amdfanuwe]

Klar doch, mit 140 PS schaff ich 200km/h. Sollten doch mit 280PS 400km/h drin sein :freak:
Sicher ist in 5nm durch mehr Transistoren, effizienteren Verbindungen, breiteren Datenbussen noch was an IPC rauszuholen um Bottlenecks zu beseitigen.
Höherer Takt bringt noch etwas mehr an Performance.
Aber Wunder sollte man nicht erwarten.

[BlacKi]

die cpu willst du dann aber erst recht nicht bezahlen. wo stehen wir dann? bei 500€ fürn 6 kerner?

[r3ptil3]

Ich sehe es schon kommen, bald gibt's die Wiedereinführung der AMD FX CPUs, natürlich inkl. dem Preis
Inflationsbereinigt darf man dann 1500+ Euro für die gute Ware zahlen.

[amdfanuwe]

Das regelt der Markt.
1500€ für ne CPU sind ja noch billig, im Serverbereich biste auch schon bei über 5000€.

[Zossel]

Klar doch, mit 140 PS schaff ich 200km/h. Sollten doch mit 280PS 400km/h drin sein

Wie lange liegt die Leistung an?

[amdfanuwe]

Wie lange liegt die Leistung an?
Spielt das ne Rolle? Man braucht ja auch Stadt Gelände Wagen damit man besser auf dem Gehweg parken kann oder durch den Stadtpark kommt.
(P.S. gibt schon schöne Strecken, da kann man schon mal ne Stunde durchtreten.)

[Lehdro]

Ich zweifel das wie auch davor mal massiv an, denn historisch sind IPC gains immer schwieriger geworden und ich wüsste nicht warum sich dieser Trend plötzlich umkehren sollte.
Ist dem denn wirklich so? AMD hat doch mit Zen 2 und Zen 3 bewiesen das eine grobe Jahreskadenz(!) durchaus >15% IPC pro Generation bringen kann. Und das mehrfach hintereinander.

Wenn man das mit "früher" vergleicht, ist das mehr als nur vergleichbar. Man schaue sich mal an was "früher" an Leistung quasi nur durch massive Taktsprünge passiert ist (Athlon XP 1.33 GHz -> Athlon XP 2.2 GHz, Zeitraum: 2 Jahre, Pentium 4 1.5 GHz -> Pentium 4 3.8 GHz, Zeitraum 3-4 Jahre). IPC Sprünge in Zen Regionen sind auch damals absurd selten gewesen, auch damals, vor allem auch auf den Zeitraum gesehen.
Einzig vergleichbar ist noch Pentium 4 -> Core-Architektur und Nehalem gegenüber Core 2. Seit dem ist vorallem bei Intel bis Ice Lake wirklich nichts außergewöhnliches passiert, Taktraten stiegen halt mehr als heute, was dann die schwächeren IPC Gewinne kaschierte.

Du musst schon weit über 20 Jahre zurückgehen um die heutige Entwicklungsgeschwindigkeit der IPC wieder zu finden. Leistungstechnisch wurde eben in den letzten 20 Jahren sehr viel über Effizienz und Takt geholt, gerade in aufeinanderfolgenden, voneinander abstammenden CPU Generationen (zb Nehalem -> Skylake-abarten).

[Neosix]

Ich weiß nicht, AMD hat aus einer unterlegenen Position mit einem Design mit Kompromissen (Zen1) viel erreicht. Nun haben sie Intel in Spielen eingeholt bzw in Anwendungen überholt. (auch weil Intel ewig auf der Stelle getreten ist) Aber Gesetzt des Abnehmenden Ertrags werden auch hier zuschlagen. Klar mit 5/3nm wird man wieder breiter bauen können. Aber jede Generation ~15% IPC Gains wird auch AMD nicht ewig durchhalten. Auch die 5Ghz Wand ist im Grunde erreicht oder fast. Bei ausreichendes Kühlung hängen auch die AMD CPUs bei der 5GHz Mauer, hier ist mit Silizium plus Luft anscheinend einfach nicht mehr drin. (oder fast, denke mit Zen3+ /XT Modellen werden wir die 5Ghz auch bei kleineren CPUs dann sehen)

[Lehdro]

Aber Gesetzt des Abnehmenden Ertrags werden auch hier zuschlagen.
Das habe ich schon zu Skylake Zeiten so oft hier zu hören bekommen - schau wo wir jetzt stehen -> Tiger Lake und da kommt auch noch viel mehr hinterher. Apple zeigt auch was geht, wenn man will - selbst mit Emulationsbremse. Die stehen alle nicht still - Intel ist mit der Nehalem -> Skylake Serie der absolute Ausreißer, nicht die anderen. Das ist alles eine Verlegenheitslösung gewesen um pünktlich jedes Jahr etwas neues mit "Performancesprung" zu bringen - ein Kartenhaus basierend auf der eigenen damals überlegenen Fertigungstechnologie, extra handgeschneidert für die BWLer in der Führungsetage. Das änderte sich aber jetzt, da sie diesen Faktor der Fertigungsüberlegenheit eben nicht mehr haben.
Jedenfalls meine Meinung dazu.

[LasterCluster]

Dem Gesetz des abnehmenden Grenzertrages steht halt eine nachwievor expontiell steigende Transistorenzahl gegenüber, die man dafür verheizen kann. Sorgen mache ich mir deswegen weniger um die IPC-Steigerungen, sondern eher um deren Kosten - sowohl in € als auch in Watt.

Big.Little bei Intel spricht ja Bände. (Zen2 bei Van Gogh vlt auch)

[AlterSack]

Das regelt der Markt.
1500€ für ne CPU sind ja noch billig, im Serverbereich biste auch schon bei über 5000€.

Zu lange durch die Maske geschnüffelt? :D

Ich sehe es inzwischen so: ...eigentlich reicht mir mein 1600er ryzen vollauf.
Soll sich AMD ihre 5000er Serie unter die Vorhaut jubeln. ;D

[amdfanuwe]

Da reicht ein Polo, sich aber über Preise fürn Ferrari aufregen :rolleyes:

[davidzo]

Wenn man sieht was Apples Firestorm Cores mit nur 3,2Ghz so gestemmt bekommen (nämlich Zen3 5Ghz Leistung), glaube ich nicht an abnehmende Grenzerträge für AMD. Einfach weil die vermeintliche "Grenze" noch weit entfernt ist, gibt es auch keine abnehmenden Erträge. Selbst Apple hat die letzte Gens die Grezen um zweistellige Beträge weiter verschoben und die hatten bereits die Architektur mit der mit Abstand höchsten IPC.

[Der_Korken]

OK, die hohe IPC bei Apple ist ein Argument. Wobei sich für mich die Frage stellt, inwieweit das von ARM vs x86 abhängt. Kann es sein, dass der legacy Kram von x86 zu schwer überwindbaren Abhängigkeiten und Latenzen führt? Es wurde ja schon mal thematisiert: Die M1-Kerne können acht Instruktionen pro Takt dekodieren, während seit Sandy Bridge (oder Nehalem?) alle x86-Cores bei vier festhängen. Wenn man Instruktionen mit fester Länge hat, kann man theoretisch parallel lesen und dekodieren. Bei x86 sind die Längen variabel, d.h. man weiß quasi erst wo die nächste Instruktion überhaupt anfängt, wenn man die alte (teil-)dekodiert hat. Mit deutlich weniger Instruktionen (quasi x86 2.0) und mehr Einschränkungen bei Instruktionslänge wäre das dekodieren doch deutlich einfacher? Oder ist das einfach überhaupt kein Flaschenhals? (und falls nein, warum hatten so alte CPUs dann bereits ein so breites Frontend wenn selbst die viel breiteren CPUs von heute das gar nicht ausreizen?).

Ansonsten wird als Argument für den Grenzertrag immer die langsame Entwicklung nach Sandy Bridge angeführt. Conroe war gegenüber Netburst ähnlich krass wenn nicht noch krasser als Bulldozer vs Zen 1. Nehalem hat teilweise nochmal bis zu 30% gebracht durch IMC, wegfallen des FSB, monolithischem Core-Layout und komplett neuen Caches. Sandy Bridge nochmal so afaik 15-17% plus viel mehr Takt durch 32nm. Danach hat Intel ja durchaus noch an den Cores gewerkelt, aber es kam in der Praxis kaum noch was bei rum. Zwischen Sandy Bridge und Skylake lagen vllt. 20-25%. Wenn es schon immer so "einfach" war auch über Skylake-IPC hinaus in regelmäßigen Abständen die IPC um 15%+ zu steigern, waren die Intel-Ingenieure von 2011 bis 2020 dann alle besoffen? Klingt polemischer als ich das meine, aber wie ist dieser Stillstand zu erklären? Ich dachte immer er wäre technisch bedingt.

[maximus_hertus]

Etwas vereinfacht: Intel hat mit Sandy AMD endgültig abgehängt und ins Niemandsland befördert. Ab da hat man primär auf die eigene MArge geschaut bzw. den Gewinn optimiert.

Wenn es "normal" wie seit Jahrzehnten gelaufen wäre, wäre Zen 1 ein ganz kurzes Strohfeuer geworden und spätestens 2018 wäre Intel wieder mit gutem (aber nicht mehr gigantischem) Vorsprung vorne gewesen. Aber zum ersten MAl gab es den "Totalfail" bei der Fertigung, welcher ja noch 2021 anhält. Gerade im CPU BEreich arbeitet man ja mit sehr vielen Jahren im Vorraus, ergo hat es entsprechend lange gedauert, bis man bei Intel fertige Produkte hatte / bzw haben wird.

[rentex]

Trotzdem bleibt INTEL, "too big to fail". Sie sind habauch breit aufgestellt und haben den nötigen Absatz ihrer Produkte.

[robbitop]

Und ihr Betriebsergebnis sieht immernoch extrem gut aus. Bis Intel in echte Schwierigkeiten käme, würde das eine ganze Weile dauern. Ich würde mich nicht wundern, wenn sie recht bald zurück sind. Man knirscht sicher seit 2017 (Zen) die Zähne und erhöht den Druck.
Aber dieses Mal wird man AMD nicht wieder so abschütteln können wie 2006. Dafür ist AMD zu gut in der Execution geworden.

[Tobalt]

Es wurde ja schon mal thematisiert: Die M1-Kerne können acht Instruktionen pro Takt dekodieren, während seit Sandy Bridge (oder Nehalem?) alle x86-Cores bei vier festhängen. Wenn man Instruktionen mit fester Länge hat, kann man theoretisch parallel lesen und dekodieren. Bei x86 sind die Längen variabel, d.h. man weiß quasi erst wo die nächste Instruktion überhaupt anfängt, wenn man die alte (teil-)dekodiert hat. Mit deutlich weniger Instruktionen (quasi x86 2.0) und mehr Einschränkungen bei Instruktionslänge wäre das dekodieren doch deutlich einfacher? Oder ist das einfach überhaupt kein Flaschenhals?
Würde mich auch interessieren. Es klingt zumindest plausibel dass in 5 GHz Gefilden so eine lange Instruktionskette irgendwann nicht mehr passt.
Beim Übergang auf eine konstante Länge kann man diese ja relativ lang wählen, damit man trotzdem viele verschiedene Befehle hat.

wie seht ihr die Chance dass sich AMD oder Intel Mal an einem RISC Design versuchen, von mir aus ARM kompatibel ?

[Zossel]

wie seht ihr die Chance dass sich AMD oder Intel Mal an einem RISC Design versuchen, von mir aus ARM kompatibel ?

Hat Intel bereits verkackt, wie Intel alles verkackt was nicht X86 ist.

Ansonsten gibt es variable Instruktionslängen bei ARM schon lange, nennt sich Thumb.

[Lehdro]

Conroe war gegenüber Netburst ähnlich krass wenn nicht noch krasser als Bulldozer vs Zen 1.
Ist halt ein falscher Vergleich, weil Conroe bereits die "zweite" Gen ist. Core gab es auch vorher, der hat damals schon Netburst zerfetzt, Jahre bevor Conroe durch die News geisterte. Du kannst halt nicht einfach den alten Netburst der am Ende nur noch kosmetische Updates brachte gegen Conroe stellen - das sind zwei verschiedene Philosophien aus verschiedenen "Zeitaltern". Du kannst aber zb Prescott vs Dothan stellen: 15 Jahre alte Benchmarks (https://www.computerbase.de/2019-11/intel-pentium-m-desktop-test-rueckblick/).

[robbitop]

Schon der P6 Core hat den neueren Netburst zerfetzt. Speziell Tualatin. Netburst war ein Rückschritt pro Takt. Ein größerer Rückschritt als es Bulldozer ggü K10 war.
Warum AMD allerdings soetwas wie Bulldozer in 2011 noch probieren wollte obwohl man durch Netburst wusste, dass das reine Verfolgen von Takt auf Kosten der IPC nicht gut geht, bleibt ein Rätsel.

[Tobalt]

laut Wiki hat AMD ja in Form von K12 schon länger einen ARM Entwicklungspfad. Ursprünglich von Keller parallel zu Zen begonnen. Vielleicht kommt hier noch was

[Gratzner]

Wenn man sieht was Apples Firestorm Cores mit nur 3,2Ghz so gestemmt bekommen (nämlich Zen3 5Ghz Leistung)
OK, die hohe IPC bei Apple ist ein Argument. Wobei sich für mich die Frage stellt, inwieweit das von ARM vs x86 abhängt. Kann es sein, dass der legacy Kram von x86 zu schwer überwindbaren Abhängigkeiten und Latenzen führt? Es wurde ja schon mal thematisiert: Die M1-Kerne können acht Instruktionen pro Takt dekodieren, während seit Sandy Bridge (oder Nehalem?) alle x86-Cores bei vier festhängen.

Ihr könnt nicht einfach den Takt klein reden. Man macht ja gerade bei einer Pipeline den Tradeoff (mit zusätzlichen Pipeline-Stufen) IPC zu opfern, um im ähnlichen Maße an Takt zu gewinnen.

Die 3,2GHz *8Dekodierungen/Takt ergeben ein theoretischen Maximum von 25,6 *10^9 Dekodierungen/s
Irgendein Intel 14nm++++ Prozessor mit 5GHz und 4Dekodierungen/s wären es dann -> 20 *10^9 Dekodierungen/s im theoretischen Maximum

25,6(*10^9) zu 20(*10^9) ist nur noch rund 1/4 mehr Instruktionen/Zeit für M1 ggü. x86. Ich denke aus x86-Sicht ist der Rückstand ok, es wird hier immerhin ein 5nm Prozessor mit ein 14nm Prozessor verglichen

[Brillus]

Würde mich auch interessieren. Es klingt zumindest plausibel dass in 5 GHz Gefilden so eine lange Instruktionskette irgendwann nicht mehr passt.
Beim Übergang auf eine konstante Länge kann man diese ja relativ lang wählen, damit man trotzdem viele verschiedene Befehle hat.

wie seht ihr die Chance dass sich AMD oder Intel Mal an einem RISC Design versuchen, von mir aus ARM kompatibel ?

In irgendeiner alten Architekturerklärung zum AMD (glaub noch Athlon) stand das die einfach probieren ab jedem Byte Instruktionen zu dekodieren. Dahingehend denke ist es nicht so kritisch, macht insgesamt den Dekoder dicker aber soviel Platz nimmt der auch nicht ein.

[y33H@]

ARM sagte bei der Einführung des uOp Cache beim A77, das wäre primär wegen Performance - bei Sandy Bridge damals hingegen vor allem wegen der Effizienz.

[davidzo]

OK, die hohe IPC bei Apple ist ein Argument. Wobei sich für mich die Frage stellt, inwieweit das von ARM vs x86 abhängt. Kann es sein, dass der legacy Kram von x86 zu schwer überwindbaren Abhängigkeiten und Latenzen führt? Es wurde ja schon mal thematisiert: Die M1-Kerne können acht Instruktionen pro Takt dekodieren, während seit Sandy Bridge (oder Nehalem?) alle x86-Cores bei vier festhängen. Wenn man Instruktionen mit fester Länge hat, kann man theoretisch parallel lesen und dekodieren. Bei x86 sind die Längen variabel, d.h. man weiß quasi erst wo die nächste Instruktion überhaupt anfängt, wenn man die alte (teil-)dekodiert hat. Mit deutlich weniger Instruktionen (quasi x86 2.0) und mehr Einschränkungen bei Instruktionslänge wäre das dekodieren doch deutlich einfacher? Oder ist das einfach überhaupt kein Flaschenhals? (und falls nein, warum hatten so alte CPUs dann bereits ein so breites Frontend wenn selbst die viel breiteren CPUs von heute das gar nicht ausreizen?).


Ich bin mir nicht so sicher ob das breite Frontend wirklich der Grund für die hohe IPC der Firestorm kerne ist. Es gibt auch andere Unterschiede, das extrem breite on chip Fabric, scratchpad memory, etc.

Allerdings ist es wohl wirklich so, dass die x86 decoder, fetch, opcache unr branch prediction einen Großteil der Energie verbrauchen, sonst hätten AMD und Intel sie schon früher breiter gemacht anstatt immer nur Änderungen weiter hinten in der Pipeline vorzunehmen.



Wenn es "normal" wie seit Jahrzehnten gelaufen wäre, wäre Zen 1 ein ganz kurzes Strohfeuer geworden und spätestens 2018 wäre Intel wieder mit gutem (aber nicht mehr gigantischem) Vorsprung vorne gewesen. Aber zum ersten MAl gab es den "Totalfail" bei der Fertigung, welcher ja noch 2021 anhält.
Gerade das bezweifle ich. Es ist nicht nur die Fertigung, die einen "Totalausfall" hat. Auch Strategisch liegt man um mehrere Jahre zurück. Intels Forscher haben früh an advanced packaging geforscht, aber durch Fehlentscheidungen des Managements hat man es nie zu einer richtigen Chipletstrategie gebracht. Jetzt sieht man dass man sie braucht und kriegt das auf die Schnelle nicht hin, so dass Sapphire Rapids wieder erstmal als MCM kommen muss.
Architekturell liegt man auch weit abgeschlagen, selbst wenn die 7nm Fertigung laufen würde. Die vergleichbare IPC zu Zen3 täuscht darüber hinweg, dass die Cove Kerne enorme Energiefresser sind und auch vom Transistorbudget weit abgeschlagen von Zen3 liegen.

Intel braucht 50% größere Register, 50% größere L1D, 70% größere L2 caches und gegenüber cezanne und Zen2 Matisse ist auch der L3 50% größer pro Core. Man musste die Bandbreite des Ringbusses verdoppeln damit der LPDDR4X überhaupt noch mit skaliert. Das ganze frisst erheblich ins Power-budget, insbesondere die gigantischen Register. Die wahren Kosten dieser "fat cores" werden wir mit Rocket Lake noch sehen.

Nebenbei kostet das so viele Transistoren, dass ein 4C Tigerlake Core-complex trotz konkurrenzfähiger 10nmLP Fertigung (ähnliche Transistordichte wie N7P) doppelt so groß ist wie ein 4C Zen2 CCX.

Intel redet ja von "big cores" und wir gehen automatisch davon aus dass AMDs Cores seit dem Ende der Cat-cores auch "big" Cores wären. Dem ist aber nicht so, Zen Cores sind im Vergleich zu Intel relativ schmale Cores, von der Komplexität und Transistorbudget eher vergleichbar mit Haswell als mit den Cove-kernen. Nur skalieren die AMD Cores halt viel besser mit aktueller Software. Stattdessen steckt AMD den Aufwand lieber in Caches und Fabric, was sich langfristig auszahlt.

Intels Cove Core Strategie kommt aus derselben Zeit wie die Einstellung der Xeon-Phi Many-core Prozessoren. Den Managern war damals wichtig, dass man etwas in die CPUs einbaut was den Siegeszug der GPU aufhalten soll. Die Bedrohung kam für Sie also nicht aus dem CPU Umfeld, sondern man wollte mit GPUs konkurrieren. Dementsprechend hat man alle Ressuorcen in die FPU investiert, 512bit FPUs verbaut, bfloat-16 support für ai-workloads etc. Chiplet/Foveros früh einzuführen war deshalb wegen der benötigten Bandbreite auch erstmal vom Tisch.
Damit hat man völlig verschlafen dass die Realität der Workloads noch ganz anders aussieht und AMD mit solider Integer Performance in der Praxis mit den "fat cores" von Intel gleichziehen kann. Dass man gegen GPUs trotzdem keinen Stich kriegt, hat ja zuletzt nicht nur Linus Torvalds festgestellt.

Das wird sich auch mit Golden Cove nicht ändern, die langfristige Core Roadmap bei Intel ist einfach zu unflexibel und am Bedarf vorbei geplant. Einen Paradigmenwechsel werden wir erst nach der Cove-Roadmap sehen.

AMD war da wohl einfach flexibler ihre Cores für die tatsächlichen Workloads in 2020-21 anzupassen. Das ist nicht nur Glaskugel, sondern auch eine Frage des Projektmanagements der Dev-Teams und inwieweit einem Strategie und Features von Managern außerhalb des Teams diktiert werden.

Ihr könnt nicht einfach den Takt klein reden. Man macht ja gerade bei einer Pipeline den Tradeoff (mit zusätzlichen Pipeline-Stufen) IPC zu opfern, um im ähnlichen Maße an Takt zu gewinnen.

Die 3,2GHz *8Dekodierungen/Takt ergeben ein theoretischen Maximum von 25,6 *10^9 Dekodierungen/s
Irgendein Intel 14nm++++ Prozessor mit 5GHz und 4Dekodierungen/s wären es dann -> 20 *10^9 Dekodierungen/s im theoretischen Maximum

25,6(*10^9) zu 20(*10^9) ist nur noch rund 1/4 mehr Instruktionen/Zeit für M1 ggü. x86. Ich denke aus x86-Sicht ist der Rückstand ok, es wird hier immerhin ein 5nm Prozessor mit ein 14nm Prozessor verglichen

Naja, die IPC der x86 Cores ist wohl eher mit den Icestorms vergleichbar. Das ist schon hart, vor allem wenn man bedenkt dass der M1 das mit ca. 1/3 des Energieverbrauchs schafft wie Intel.

Wenn man aktuelle x86 Chips in aktuellen Fertigungsverfahren heranzieht, z.B. AMD Cezanne ist die Leistung besser vergleichbar. N5 early ist nun auch nicht soo weit von ausgereiftem N7P bei der Schaltcharakteristik und Leakage.

Cezanne hat immerhin 10,78 Mrd Transistoren, der M1 hat 15. Die M1 GPU ist allerdings auch wesentlich größer und potenter als die AMD Vega. Als TBDR holt sie aus dem LPDDR4X Interface gut die doppelte Leistung gegenüber der AMD Vega. Die 4,3 Mrd. würde ich also für GPU und die Neural net engine verbuchen, während die CPUteile insgesamt vergleichbar groß sein dürften.

Beide haben 8 Cores, Apple allerdings Big Little, während AMD sie wesentlich höher taktet und dabei auch wesentlich mehr Energie verbraucht. Bei der SC Leistung hat Apple trotz erheblichem taktdefizit minimal die Nase vorne, bei der MC führt AMD nicht zuletzt durch SMT deutlich. Bei 6 oder 8 Firestorm Cores, 4Ghz + oder verdoppelten Icestorms wäre der Ausgang wohl eindeutig im Sinne von Apple, wofür man wohl nicht mal eine höhere TDP als AMD bräuchte wenn man den Praxisverbrauch anguckt (die meisten U-CPUs haben 25W für den Benchmark-Zeitraum).
Die entscheidende Kenngröße ist aber nicht die TDP, sondern die Joule pro erledigten Task und nicht zuletzt bei Mobilgeräten die Idle Power. Bei beidem liegt der M1 gut Faktor 2x vor AMD, genauer kann man es wohl nicht sagen mangels vergleichbarer Geräte und Software.
Das ist imo mehr als der reine Gewinn durch die neuere 5nm Fertigung.

[y33H@]

Sollte der M1X tatsächlich 8C Firestorm haben, wird der ziemlich spannend.

[amdfanuwe]

wie seht ihr die Chance dass sich AMD oder Intel Mal an einem RISC Design versuchen, von mir aus ARM kompatibel ?

Intern arbeiten die doch auf RISC Basis, steht nur noch der X86 Decoder obendrüber.
Das Problem an der ganzen Geschichte ist die Software.
Im PC, Server und HPC Bereich ist X86 etabliert. Da hat man mit einer anderen ISA kaum eine Chance.
Ebenso mit ARM für Mobile.
Apple kann es sich leisten da sie den ganzen Softwarestack kontrollieren.
Wenn man auf Jahrelange kompatibilität zur nächsten Prozessorgeneration keinen Wert legt, wie in embedded Systems, spielt die ISA keine Rolle.

Man sieht ja auch wie lange AMD im Serverbereich braucht um akzeptiert zu werden. Mit einer anderen ISA keine Chance außer vielleicht in Spezialbereichen.


Ansonsten gibt es variable Instruktionslängen bei ARM schon lange, nennt sich Thumb.
Thumb ist ein abgespeckter Befehlssatz, hat aber keine Variablen Instruktionslängen.


Warum AMD allerdings soetwas wie Bulldozer in 2011 noch probieren wollte obwohl man durch Netburst wusste, dass das reine Verfolgen von Takt auf Kosten der IPC nicht gut geht, bleibt ein Rätsel.

Die Entwicklung dauert 4+ Jahre. Ab einem bestimmten Punkt zieht man es halt durch, vor allem wenn man keine Alternative hat.

laut Wiki hat AMD ja in Form von K12 schon länger einen ARM Entwicklungspfad. Ursprünglich von Keller parallel zu Zen begonnen. Vielleicht kommt hier noch was
Denke nicht, dass da noch was kommt. War ein Versuch aus dem X86 Markt auszubrechen wo man gegen Intel nicht mehr ankam.
Man sieht aber auch, dass AMD da flexibel sein kann und wenn im Servermarkt ARM weiter Boden gut macht, ist AMD dann sicher auch dabei.
Im Prinzip müßten sie bei ZEN den X86 Decoder gegen einen ARM Decoder tauschen und hätten einen leistungsfähigen ARM Chip. Nur besteht dafür noch kein Markt.

[Gratzner]

Ihr könnt nicht einfach den Takt klein reden. Man macht ja gerade bei einer Pipeline den Tradeoff (mit zusätzlichen Pipeline-Stufen) IPC zu opfern, um im ähnlichen Maße an Takt zu gewinnen.

Naja, die IPC der x86 Cores ist wohl eher mit den Icestorms vergleichbar. Das ist schon hart, vor allem wenn man bedenkt dass der M1 das mit ca. 1/3 des Energieverbrauchs schafft wie Intel.


Ich glaube, Du hast meinen Punkt überhaupt nicht verstanden. Häng dich mal nicht so sehr an den Takt und der IPC fest, ohne das jeweils andere zu betrachten.

Mal von Anfang an, es gibt keine Transistoren mit Takteingang. Also kann der Takt auch gar nicht die Schaltgeschwindigkeit der Transistoren beschreiben. (In der Sequentiellen Logik gibt es nur Flipflops als Gatter, welche ein Takteingang haben. Man könnte daher den Takt als 'Zeitsignal' für die FFs beschreiben und wie schnell man die FFs Takten kann, hängt dann vor allem von der längst möglichen Gatterlaufzeit zwischen zwei FFs einer Taktdomäne ab (kritischer Pfad)).

Ich will das jetzt nicht nähert ausführen (kenne mich damit auch nicht gut aus). Ich will nur sagen, das Taktlimit hängt nicht nur von den Schaltgeschwindigkeit der Transistoren ab, sondern ebenfalls vom beispielsweise dem kritischen Pfad. Nur weil AMD 5GHz schafft, heißt das noch lange nicht, das man jeden Prozessor mit gleicher/besserer Fertigung und mit genügend Strom/Spannung auf 5GHz bringen kann. Sondern der Takt ist von der genauen Architektur abhängig. Bei deinen IPC vergleichen gibst du den x86 Kernen überhaupt keine Kredit dafür, das die mit einer längeren Pipeline IPC opfern um Takt zu gewinnen. Deine reinen IPC Vergleiche zwischen zwei grundverschiedene Architekturen sind genauso sinnlos wie den Takt als alleiniges Leistungsmerkmal zu betrachten.


Cezanne hat immerhin 10,78 Mrd Transistoren, der M1 hat 15. Die M1 GPU ist allerdings auch wesentlich größer und potenter als die AMD Vega. Als TBDR holt sie aus dem LPDDR4X Interface gut die doppelte Leistung gegenüber der AMD Vega. Die 4,3 Mrd. würde ich also für GPU und die Neural net engine verbuchen, während die CPUteile insgesamt vergleichbar groß sein dürften.


Ich kann genauso auf x86 Seite dagegenhalten, das die viel Chipfläche (und Stromverbrauch) für PCIe-Lanes, Sata-Controller etc. nutzen, was der M1 alles nicht hat (dazu möchte ich noch anmerken, das gefühlt die Hälfte der Chipfläche von Renoir oder Cezanne für IO draufgeht). Der M1 auf der anderen Seite geht sogar noch ein paar Nachteile am Speicherinterface ein, um Strom zu sparen. Das heißt, es wird nicht nur verlöteter Lpddrx Speicher verwendet, sondern der Speicher wird im selben Package wie die CPU untergebracht (für kürzere Signalwege). Scheinbar mit den Nachteil, das Apple bzw. TSMC da nicht mehr als 16Gb integrieren kann.

Edit: @y33H@ hast natürlich recht, es steht nirgends direkt, das der M1 nur 16Gb ansteuern kann. Hatte ich nur falsch in der Erinnerung gehabt. Wobei meine Erinnerung nicht ganz falsch war, z.B.: the verge hatten tatsächlich sowas geschrieben wie: "Right now, the M1 cannot support more memory"[link] (https://www.theverge.com/2020/11/10/21559200/apple-m1-macbook-pro-mac-mini-16gb-ram-memory-limit), ohne es genauer zu erklären, wie sie es meinen

[y33H@]

Wer sagt, dass der M1 tatsächlich nur 16GB ansteuern kann?

[Brillus]

Beide haben 8 Cores, Apple allerdings Big Little, während AMD sie wesentlich höher taktet und dabei auch wesentlich mehr Energie verbraucht. Bei der SC Leistung hat Apple trotz erheblichem taktdefizit minimal die Nase vorne, bei der MC führt AMD nicht zuletzt durch SMT deutlich. Bei 6 oder 8 Firestorm Cores, 4Ghz + oder verdoppelten Icestorms wäre der Ausgang wohl eindeutig im Sinne von Apple, wofür man wohl nicht mal eine höhere TDP als AMD bräuchte wenn man den Praxisverbrauch anguckt (die meisten U-CPUs haben 25W für den Benchmark-Zeitraum).


Da wäre erstmal die Frage ob ein Firestorm 4GHz hinbekommen würde. In den hohen Takraten geht viel Transistoren und Strom drauf das das überhaupt klappt. Oder anders gefragt warum glaubst du das Zen3 es bis knapp 5GHz schafft, Navi im gleichen Prozess nichtmal auf 3GHz.

[davidzo]

Da wäre erstmal die Frage ob ein Firestorm 4GHz hinbekommen würde. In den hohen Takraten geht viel Transistoren und Strom drauf das das überhaupt klappt. Oder anders gefragt warum glaubst du das Zen3 es bis knapp 5GHz schafft, Navi im gleichen Prozess nichtmal auf 3GHz.

Wenn Apple mit einem relativ unausgereiften 5nm Prozess konsistent über den ganzen yield schon 3,2Ghz schafft (ja, es gibt keine niedrigeren Bins!), dann sind sicher auch 4Ghz drin mit ein wenig binning und ggf. einer leichten Spannungserhöhung.
Sicher, Beiweise habe ich dafür nicht, aber jeder chip hat eine frequency/voltage Curve und ich kann eins und eins zusammen rechnen. Und da ist noch gar nicht mit eingeschätzt was man auf Transistorebene, mit anderen design-libraries etc. optimieren könnte, wenn man gewollt wäre mehr power für mehr leistung einzutauschen.

[Gratzner]

Deine vorgeschlagene Takterhöhung ist fast so groß (von 3,2GHz auf 4GHz), wie TSMC angibt, man durch den Wechseln von N16 auf N7 erreicht. Und das durch, Zitat, "ein wenig Binning und ggf. leichter Spannungserhöhung"

Edit: man könnte noch hinzufügen, das die von den Fertigern angegebenen Takterhöhungen selten erreicht wurden, also nur ein best case darstellen

[Lehdro]

Wenn Apple mit einem relativ unausgereiften 5nm Prozess konsistent über den ganzen yield schon 3,2Ghz schafft (ja, es gibt keine niedrigeren Bins!), dann sind sicher auch 4Ghz drin mit ein wenig binning und ggf. einer leichten Spannungserhöhung.
Sicher, Beiweise habe ich dafür nicht, aber jeder chip hat eine frequency/voltage Curve und ich kann eins und eins zusammen rechnen. Und da ist noch gar nicht mit eingeschätzt was man auf Transistorebene, mit anderen design-libraries etc. optimieren könnte, wenn man gewollt wäre mehr power für mehr leistung einzutauschen.
Gegenbeispiel "Zen": 3.2 GHz schaffte jeder, 4 GHz waren relativ selten. Und das war nun kein wirklich unausgereifter Prozess. Will sagen: So einfach ist das nicht, das Design und die Fertigung bestimmen die Taktgrenzen, nicht nur eins von beiden, sondern beide zusammen.

Einen Chip für mehr Frequenz optimieren geht zwar auch, allerdings ist dass dann quasi ein komplett neuer Chip. Siehe Vega in AMDs GPUs/APUs, da hat sich zwar die Taktgrenze mit jeder Iteration nach oben bewegt, viel wichtiger ist aber der massive Rahmen in dem sich der Sweetspot bewegt hat. Das sind interne Optimierungen die man mit einem Haufen Erfahrungen aus anderen Bereichen erreicht hat, kein einfaches Fingerschnippen mit ein paar drübergekleckerten Massetransistoren (überspitzt gesagt). Hat Apple schon Erfahrungen mit Hochtaktdesigns? Eher nicht, das kommt jetzt erst alles.

[basix]

Auf ARM bezogen sind die 3.2 GHz schon nicht wenig. Insbesondere auch wenn man die hohe IPC mit berücksichtigt.

[vinacis_vivids]

Die baseclocks und maxclk sind bei AMD 8C/16T in den letzten Jahren so
Zen: 3.0Ghz (bronze) - 3.4Ghz (silver) - 3.6Ghz (gold)
Max: ~4.0 Ghz

Zen²: 3.2Ghz (silver) - 3.7Ghz (gold)
Max: ~4.35 Ghz

Matisse: 3.6Ghz (silver) - 3.9Ghz (gold)
Max: ~4.5 Ghz

Matisse²: 3.8Ghz (silver) - 3.9Ghz (gold)
Max: ~4.7 Ghz

Vermeer: 3.4Ghz - 3.7-3.8Ghz - 3.9Ghz (gold)
Max: ~4.7 Ghz (silver) - 4.9Ghz (gold)

Aber im mobilen Bereich liegt Cezanne 8C/16T bei 2.8Ghz baseclock und 4.4Ghz boostclock. Insofern sind die 3.2Ghz von Apple schon sehr sehr gut, weil das sind ja ~ 14% Vorsprung für Apple.

Ein händisch optimierter Cezanne auf 3.2 Ghz allcore und UV gegen den M1 3.2Ghz allvore wäre schon sehr sehr interessant. Damit kann man die IPC sehr gut miteinander vergleichen wobei AMD ja eine Node hinten liegt und deutlich günstiger ist.

[Geächteter]

Mal schauen, ob sie auch bei 5 nm wieder ihre Steinzeittechnik als I/O bei den Desktop-Varianten beimischen.

[robbitop]

Die Entwicklung dauert 4+ Jahre. Ab einem bestimmten Punkt zieht man es halt durch, vor allem wenn man keine Alternative hat.
Pentium 4 kam 2000 auf den Markt. 11 Jahre vor Bulldozer. 2006 zeigte Conroe wo es lang geht. 5 Jahre vor Bulldozer.
IMO hat man sich da verrannt.

[unl34shed]

Mal schauen, ob sie auch bei 5 nm wieder ihre Steinzeittechnik als I/O bei den Desktop-Varianten beimischen.

Wie meinen?

[Savay]

Wie meinen?

Sicher irgendwas mit "GF 14nm blablablablub". :freak:

[Akkarin]

AIUI den einzigen Vorteil den RISC heute noch hat ist dass das Decoden der Instructions einfacher ist, da die x86 ops quasi beliebig lang sein können und man deshalb auch erst mal den Anfang einer Instruction suchen muss. Wurde zwar ne Zeitlang gesagt das sei Heutzutage nicht mehr so wichtig, aber wenn man sich an sieht viel breiter die ARM Decoder sind scheint der Vorteil ja immer noch zu Existieren.

Jetzt meine dumme Frage: wie viel Aufwand wäre es eine RISC ISA zu bauen die alle x86 instructions kann, aber halt keine (komplett) variable Länge der Instructionen ? Alle bisherigen Programme könnte man durch nen Translator schmeißen und bekommt dann nativen Code zurück, aber man könnte (theoretisch ?) das Frontend breiter und/oder Energieeffizienter machen ?

[amdfanuwe]

Pentium 4 kam 2000 auf den Markt. 11 Jahre vor Bulldozer. 2006 zeigte Conroe wo es lang geht. 5 Jahre vor Bulldozer.
IMO hat man sich da verrannt.
Mal sehen, was die Erinnerung sagt:
2006 ATI Kauf
2007 Barcelona Desaster
Gewinneinbrüche wegen Intel Marktmanipulationen
Aktienkurs fällt von 40$ in 2006 auf 1,6$ in 2008
Wirtschaftskriese Ende 2008
Verkauf eigener Fabs 2008

Vielleicht wäre Bulldozer mit mehr Mitteln, besserer Fab und gleichwertigem Prozessnode zu Intel noch ganz gut geworden.
So wie es gelaufen ist, wars rückblickend eine Fehlentscheidung.

Von Konzept her gefällt mir die Modulbauweise jedoch besser als Big-Little.
Ich bin jedenfalls gespannt, wie es die nächsten Jahre noch weitergeht.

[Screemer]

Mir war so als hätte ich gelesen, dass moderne x86 CPUs eigentlich RISC Kerne mit passendem decoder sind. Die Instruktionen werden ja in Micro Ops zerlegt, sei eine definierte lange haben.

[Zossel]

Thumb ist ein abgespeckter Befehlssatz, hat aber keine Variablen Instruktionslängen.

Trotzdem haben Instruktionen, je nach Anzahl der Operanden, unterschiedlichen Platzbedarf.
Eine feste Ausrichtung wo ein Befehl anfängt ist daher nicht gegeben.

Beispiel: Lade Register N mit der Adresse foo wird mehr Platz als ein NOP brauchen.

[Der_Korken]

Eine Frage ist auch wie fragmentiert der Op-Code-Space von x86 ist. Das ist ja im Grunde ein Wildwuchs, der ber 30 Jahre gewachsen ist und wo einzelne Hersteller immer wieder mal eigene Erweiterungen eingebaut haben. Ich kann mir nicht vorstellen, dass man dabei immer sparsam mit dem Code-Space umgegangen ist. Oder anders gesagt: Selbst wenn man alle x86-Instruktionen drinlässt, würde eine Umsortierung der Codes wahrscheinlich schon CPUs schneller machen, weil weniger Platz im L1I gebaucht wird, dadurch auch weniger Bits übertragen werden müssen und es insgesamt kürzere bzw. weniger variantenreiche Code-Längen gäbe.

[amdfanuwe]

Trotzdem haben Instruktionen, je nach Anzahl der Operanden, unterschiedlichen Platzbedarf.
Eine feste Ausrichtung wo ein Befehl anfängt ist daher nicht gegeben.

Beispiel: Lade Register N mit der Adresse foo wird mehr Platz als ein NOP brauchen.
Nö.
Thumb sind 16 Bit befehle, normal ARM ist 32 Bit.
Um eine Konstante >12 Bit zu laden, wird diese vom compiler an eine Adresse relativ zum Programm Counter(PC) abgelegt, z.B. am Anfang der Funktion.
Die Funktion lautet dann in etwas: Move den Wert an Adresse PC - Offset (0 bis 4096) in das Register xyz.
Alle Befehle sind 32 Bit lang und es gibt keine zusätzlichen Operanden.
Konstanten werden entweder aus dem Speicher geholt oder werden häppchenweise durch shiftoperationen, additionen etc. zusammengebaut. Erledigt der Compiler und der ist da verdammt tricky. Es gibt aber keine Befehle die im Befehlscode weitere Operanden haben.
Das führt dazu, dass für bestimmte Aktionen mehrere Befehle ausgeführt werden müssen wo das bei X86 eben mit einem Befehl und mehreren Operanden erledigt wird.

Bei Thumbs funktioniert das ganze auf 16 Bit Basis mit eingeschränktem Befehlssatz.
Intern wird Thumb auf 32 Bit aufgeblasen und hat nur den Zweck Speicher zu sparen.

[Zossel]

Nö.
Die Funktion lautet dann in etwas: Move den Wert an Adresse PC - Offset (0 bis 4096)

Das wäre ein ziemlich dummer Computer welcher nur 4K Daten adressieren kann, insbesondere da ziemlich selten Daten +-2^12 um dem aktuellen PC liegen. Und keine immediate Adressierungsart zu haben ist ineffizient.

[Zossel]

Eine Frage ist auch wie fragmentiert der Op-Code-Space von x86 ist. Das ist ja im Grunde ein Wildwuchs, der ber 30 Jahre gewachsen ist und wo einzelne Hersteller immer wieder mal eigene Erweiterungen eingebaut haben. Ich kann mir nicht vorstellen, dass man dabei immer sparsam mit dem Code-Space umgegangen ist. Oder anders gesagt: Selbst wenn man alle x86-Instruktionen drinlässt, würde eine Umsortierung der Codes wahrscheinlich schon CPUs schneller machen, weil weniger Platz im L1I gebaucht wird, dadurch auch weniger Bits übertragen werden müssen und es insgesamt kürzere bzw. weniger variantenreiche Code-Längen gäbe.

RISC ist bzgl. codedensity schlechter als CISC. Lässt sich mit dem Zipper deiner Wahl einfach überprüfen.

[Brillus]

Das wäre ein ziemlich dummer Computer welcher nur 4K Daten adressieren kann, insbesondere da ziemlich selten Daten +-2^12 um dem aktuellen PC liegen. Und keine immediate Adressierungsart zu haben ist ineffizient.
Nach meiner Erinnerung an ARM-Assembler ist es aber genau so, kannst noch auf die 12 Bit einen Bitshift vollführen, für alles was du mehr willst musst du entweder in mehrern Schritten ein Addresse in ein Register schreiben oder eine Addresse an erreichbarer Stelle im Speicher stehen haben.

[Zossel]

Nach meiner Erinnerung an ARM-Assembler ist es aber genau so, kannst noch auf die 12 Bit einen Bitshift vollführen, für alles was du mehr willst musst du entweder in mehrern Schritten ein Addresse in ein Register schreiben oder eine Addresse an erreichbarer Stelle im Speicher stehen haben.

Hier sehe ich jede Menge Befehle die eine immediate Adressierungsart haben dürfen: https://modexp.wordpress.com/2018/10/30/arm64-assembly/.

Und pc-relativ ist eher was für branches (spart Platz weil das Sprungziel oft in der "Nähe" ist), gerne auch mit dem im Operanden "im" Opcode mit drin wenn der Operand nur wenige Bits braucht. Evtl. verwechselt amdfanuwe da was mit sp-relativ.

Hat jemand hier einen gcc für arm64 griffbereit?

[amdfanuwe]

Evtl. verwechselt amdfanuwe da was mit sp-relativ.

Gibt mehrere Möglichkeiten. Große Datenmengen an Konstanten werden im Const Datenbereich abgelegt.
PC relativ bezieht sich auf die Konstanten, die in der Funktion benötigt werden, z.B. die Adresse des Const Datenbereichs.
Ist bei kleinen Funktionen effektiv, da die Wahrscheinlichkeit das der Wert im Cache steht ziemlich groß ist.
Als ich damals noch auf Intels Strongarm und Xscale programmiert habe, hat das der GCC noch so gemacht.

also z.B. Funktion liegt ab Adresse xFF1000 im Speicher,
gibt es ein paar "Funktionskonstanten" bis xFF1020 und der eigentliche Programmcode und die Einsprungadresse der Funktion liegt auf xFF1024.
Funktionskonstanten wie I/O Adressen, Const Segment Adresse, benötigte Offsets etc.
Und ja, es ist nur eine 12 Bit Konstante die direkt im Befehl mitgegeben werden kann, durch shift und invertieren kann man damit einiges anstellen.
Wenns dumm läuft werden halt 2 Befehle gebraucht um eine 32 Bit Konstante in ein Register zu bekommen. Vertrau dem Compiler. Hab damals über ne Stunde gebraucht um nachzurechnen und zu verstehen, dass meine Konstante auch wirklich im Register steht.
Hilfreich bei ARM ist natürlich auch, dass mehr Register wie bei X86 zur Verfügung stehen. Hat sich aber auch mit 64Bit bei beiden geändert. Ist nicht mehr meine Welt.
Hab damals die Firmware von einem Z80 Gerät auf StrongARM, Xscale portiert. Hat noch Spaß gemacht ohne OS. Später nochmals auf ein Modul mit Atmel CPU und embedded Linux das Firmenweit für verschiedene Projekte eingesetzt wurde.

Edit: wie soll SP relativ funktionieren? Stackpointer zeigt in den nicht initialisierten RAM Bereich, da kann der Compiler keine Konstanten hinterlegen.

[Zossel]

also z.B. Funktion liegt ab Adresse xFF1000 im Speicher,
gibt es ein paar "Funktionskonstanten" bis xFF1020 und der eigentliche Programmcode und die Einsprungadresse der Funktion liegt auf xFF1024.
Funktionskonstanten wie I/O Adressen, Const Segment Adresse, benötigte Offsets etc.


Code und Daten werden kaum in der selben 4K-Page bei einem OS mit Speicherschutz liegen.
Strings liegen allerdings im Speicher, um einen Pointer darauf zu laden bietet sich die Adressierungsart immediate an.


Edit: wie soll SP relativ funktionieren? Stackpointer zeigt in den nicht initialisierten RAM Bereich, da kann der Compiler keine Konstanten hinterlegen.

Da liegen die lokalen Variablen.

Hier sieht man die Verwendung von sp-.relativ und immediate am Beispiel einer for Schleife ziemlich gut, leider nur X64, auf ARM wird das ähnlich aussehen:

movl $1, -4(%rbp)
jmp .L4
.L5:
movl -4(%rbp), %eax
movl %eax, %edi
call foo
addl $1, -4(%rbp)
.L4:
cmpl $10, -4(%rbp)
jle .L5
nop

----------------------------

for (i=1; i<=10;i++) {
foo(i);
}

[Leonidas]

(Zen 4 Genoa)
It has taped out, I can confirm that.
https://twitter.com/Vyor_1/status/1358825626858307584

[HOT]

Also jetzt + 5 Quartale.

[Nightspider]

Wenn Warhol mit Zen3+ noch zwischendurch gegen Oktober/November auf den Markt kommt sehen wir Zen4 für AM5 wohl erst im 2. Halbjahr 2022.

Vielleicht bedient AMD diesmal den HPC Bereich zuerst. Wenn Genoa wirklich so ein Biest wird, selbst bei gleicher Kernzahl, dann kann AMD deutlich höhere Preise verlangen.

Intel sieht ja nicht mal gegen Zen2 im Server-Bereich Land.

[basix]

Also jetzt + 5 Quartale.

Etwas rund um Sommer/Herbst 2022 war schon immer am Wahrscheinlichsten. Insbesondere seitdem Zen 3+ ein Thema ist.

[HOT]

+5 Q wäre Mai. 5.5. ist damit wohl schaffbar. Und Warhol hat damit nix zu tun, da keine neue HW.

[Nightspider]

Die letzten Gerüchte besagen Warhol ist neue Hardware mit einem größeren Sprung in der IPC als Zen+.

[mksn7]

Hat jemand hier einen gcc für arm64 griffbereit?


Dafür ist der Compiler Explorer ein tolles Tool:

https://godbolt.org/z/zE1n1x

Edit: Da kann man bei "output" sogar "compile to binary" einstellen, da sieht man dass für ARM jeder Befehl gleich lang ist, anders als bei x86.

[HOT]

Die letzten Gerüchte besagen Warhol ist neue Hardware mit einem größeren Sprung in der IPC als Zen+.
Folge der Diskussion. Nein, Warhol ist sehr sicher alte HW, Zen3+ ist 6nm Rembrandt.

[prinz_valium_2]

Ihr seid optimistisch. Eher Ende 2022. Zen 3 gibt es ja immer noch nur auf dem Papier

[Lehdro]

Ihr seid optimistisch. Eher Ende 2022. Zen 3 gibt es ja immer noch nur auf dem Papier
Bist du dir da sicher?

[maximus_hertus]

Ihr seid optimistisch. Eher Ende 2022. Zen 3 gibt es ja immer noch nur auf dem Papier

Was hat das eine mit dem anderen zu tun?

Sobald Zen 4 "fertig" ist, wird er kommen. Ob bis dahin Zen 3 gut oder schlecht verfügbar war, spielt gar keine Rolle.

Also ca. Sommer bis Herbst 2022, meiner Meinung nach.

[davidzo]

Ihr seid optimistisch. Eher Ende 2022. Zen 3 gibt es ja immer noch nur auf dem Papier

Umgekehrt Zen3, Ryzen5K und Milan gibt es überall in Hardware, nur nicht immer auf dem Papier.

Serve the Home hat Milan Systeme seit November 2020, wollte das Review eigentlich vor Jahresende posten, ist aber noch unter NDA, bzw. sieht keinen Sinn darin ohne public launch von AMD.

AMD setzt damit Intel bzgl. Icelake unter Druck, denn der ist offiziell "in produktion" aber eben nicht verfügbar. Man will sich das Narrativ in der "Nextgen Platform" halt nicht von Intel aufdrücken lassen. Intel wird in den Launchreviews Schwierigkeiten haben gegen Zen2, da man sowohl beim Corecount als auch i/o wie PCIe Lanes weiterhin hinten liegt. Epyc Milan wird dann von AMD als "truly one Generation ahead" vorgestellt werden.

AMD entspannt darüber wohl auch die eigene supply chain während der 7nm Knappheit bei TSMC. HPC und Hyperscaler haben derweil Milan längst in Stückzahlen bekommen und im Produktiveinsatz. Die ersten samples waren Ja 06/2020 zu sehen, Benchmarks von third parties waren in 7/2020 da, final steppings ab september in produktion und retail silicon wurde selbst an kleinere rechenzentren wie STH noch in Q4 2020 verschickt.

AMD has been in production of Milan since at least September 2020 and delivering parts to large customers. Milan’s public launch we were hearing for some time was pushed to January, now our best guess is still in Q1, but likely in the last third of the month. Again, we know that Milan is in production with “retail marked” parts, but we are awaiting the formal launch.
https://www.servethehome.com/intel-ice-lake-xeon-now-in-production/

This may seem like a nuance, but it is extremely important. AMD has been shipping production Zen 3 parts since 2020 both on the desktop (Ryzen) and in the server (EPYC) segments. The delta between the CCDs in desktop and server parts for AMD is nowhere near Ice Lake desktop/ mobile and server parts. AMD was shipping its next-gen in Q4 2020, even if the EPYC 7003 “Milan” launch we have pegged for the back half of Q1 2021.


While AMD has been shipping retail stepping Zen 3 since Q4 2020, even with Milan’s public launch delayed, Intel is not at the point yet where all of its partners are doing qualifications/ customer demos are happening on final stepping silicon.

We already have retail AMD EPYC 7003 in-house but the SKUs we have are frankly too sensitive to publish. Editorially, although we have numbers for Milan from retail purchased (non-NDA) chips, if we publish them we could have a significant market impact.
https://www.servethehome.com/sth-q4-2020-update-a-letter-from-the-editor/

[Linmoum]

Zen4 kommt spätestens im Mai 2022, damit befindet sich AMD noch innerhalb des immer wieder hervorgehobenen 12-18 Monatszyklus. Da bekannt ist, dass es zwei Designteams gibt, die immer parallel an etwaigen Zen-Iterationen arbeiten, ist das Risiko für Verspätungen auch extrem niedrig, zumal AMD bekanntermaßen ja auch einfach etwaige Features auf den Nachfolger verschiebt, wenn es zeitlich nicht mehr gereicht hat.

[Opprobrium]

Ihr seid optimistisch. Eher Ende 2022. Zen 3 gibt es ja immer noch nur auf dem Papier

Eigentlich gut lieferbar, 5800X derzeit für 448€ bei Mindfactory. Wobei man für 12/16 Kerner etwas mehr zahlen muss und evtl. ein paar Tage länger warten muss.

Aber "nur auf dem Papier" sieht anders aus...

[Complicated]

Also jetzt + 5 Quartale.
Und wenn das Tapeout vor 2. Quartalen war?

In dem Tweet steht kein Zeitpunkt und es ist nicht sehr wahrscheinlich, dass der Tweet den Tag des Tapeouts markiert. Ist das ein Leak der 1 oder 2 Quartale braucht um zu leaken?
Ich denke ein "spätestens in 5 Quartalen" wäre die bessere Bezeichnung, bezogen auf einen Leak. Sind ja keine Presseerklärungen, auch wenn das immer mehr so scheint hier im Forum.

[Zossel]

Dafür ist der Compiler Explorer ein tolles Tool:

https://godbolt.org/z/zE1n1x

Edit: Da kann man bei "output" sogar "compile to binary" einstellen, da sieht man dass für ARM jeder Befehl gleich lang ist, anders als bei x86.

So sieht die for Schleife in arm64 aus:

foo:
stp x29, x30, [sp, -32]!
mov x29, sp
mov w0, 1
str w0, [sp, 28]
b .L2
.L3:
ldrsw x0, [sp, 28]
bl malloc
ldr w0, [sp, 28]
add w0, w0, 1
str w0, [sp, 28]
.L2:
ldr w0, [sp, 28]
cmp w0, 10
ble .L3
nop
ldp x29, x30, [sp], 32
ret

Jede Menge sp-relatives Zeuge und immediate Adressierung wo der (unterschiedlich lange) Operand nach dem Opcode kommt und der Instruktionsdekoder den Operanden nicht dekodieren sollte. Sondern den nächsten Opcode dessen Position erst bekannt ist wenn die vorherigen Opcodes vollständif dekodiert wurden.

[amdfanuwe]

So sieht die for Schleife in arm64 aus:

foo:
stp x29, x30, [sp, -32]!
mov x29, sp
mov w0, 1
str w0, [sp, 28]
b .L2
.L3:
ldrsw x0, [sp, 28]
bl malloc
ldr w0, [sp, 28]
add w0, w0, 1
str w0, [sp, 28]
.L2:
ldr w0, [sp, 28]
cmp w0, 10
ble .L3
nop
ldp x29, x30, [sp], 32
ret

Jede Menge sp-relatives Zeuge und immediate Adressierung wo der (unterschiedlich lange) Operand nach dem Opcode kommt und der Instruktionsdekoder den Operanden nicht dekodieren sollte. Sondern den nächsten Opcode dessen Position erst bekannt ist wenn die vorherigen Opcodes vollständif dekodiert wurden.
Und wenn du die Binaries dazu ansiest, siehst du dass du blödsinn schreibst und alle Befehle nur in 32 Bit ohne zusätzliche Operanden codiert werden.
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=74129&d=1612897167

[Zossel]

Und wenn du die Binaries dazu ansiest, siehst du dass du blödsinn schreibst und alle Befehle nur in 32 Bit ohne zusätzliche Operanden codiert werden.
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=74129&d=1612897167

Geile CPU. Man kann definierte 64-Bit Konstanten in Register laden die keinen Platz verbrauchen, muss ich haben!

Wo kann man den Binäroutput einstellen? "Compile to binary" ist ausgegraut.

[amdfanuwe]

Wo kann man den Binäroutput einstellen? "Compile to binary" ist ausgegraut.
Bei mir im Firefox nicht, wenn ich dem Link folge.
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=74135&stc=1&d=1612904661

[amdfanuwe]

Hier auch ein Beispiel mit PC relativer Ablage von Konstanten im Programmcode.
Arm gcc 8.2 Compilerflag Optimierung auf -O3

ldr r3, [pc, #4] ; 1053c <square(int)+0x14>
Da wird in Adresse 10530 die Konstante die im Speicher an Adresse 1053c liegt in r3 PC Relativ geladen.
Ab 10540 beginnt der Code der nächsten Funktion.
Hier legt er die Konstanten am Ende der Funktion ab, ich meine, der Compiler damals hätte die vor der Funktion abgelegt.
Egal, Konstanten können direkt im Code vorhanden sein und werden PC relativ angesprochen.

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

[Duplex]

Offtopic...Hier geht es nicht um ARM!

[Zossel]

Offtopic...Hier geht es nicht um ARM!

Welcher Thread wäre der richtige um unabhängig von konkreten Implementierungen und Herstellern Unterschiede der ISA von ARM und X64 zu diskutieren?

[Opprobrium]

Welcher Thread wäre der richtige um unabhängig von konkreten Implementierungen und Herstellern Unterschiede der ISA von ARM und X64 zu diskutieren?

Man könnte ja einen erstellen :uponder:

Hier scheint es tatsächlich etwas deplaziert.

[Piefkee]

96-cores (192 threads)
12-channel DDR5-5200
128 PCIe 5.0 lanes (160 for 2P)
320W TDP (cTDP 400W) ��
SP5 (LGA-6096) socket

Genoa everyone ��

https://twitter.com/execufix/status/1365981401808580614?s=21


Außerdem bleibt es bei 8C CCD. Also 12x8C

[w0mbat]

Mach Sinn, AMD braucht nicht mehr Kerne auf nem CCD, das macht alles nur viel zu komplex. Die packen einfach mehr CCDs auf ne CPU.

[Piefkee]

Damit könnte natürlich der Desktop dann 24C bekommen...

[Der_Korken]

320W für 96 Kerne? Das wäre in etwa so viel W/Core wie Rome hatte. Ich hätte eher erwartet, dass die W/Core nochmal gut nach unten gehen. Gut wir wissen den Takt nicht.

[w0mbat]

Und wir wissen die IPC nicht.

[Der_Korken]

Ich glaube nicht an diese Phantasie-Gewinne bei der IPC aus den bisherigen Gerüchten. Zen 3 war ein major redesign, welches alle 3-4 Jahre mal gemacht werden muss, da wird ein inkrementelles Upgrade nicht plötzlich mehr bringen.

Und mit Takt meinte ich oben auch nicht den Maximaltakt der Architektur, sondern den Base-Takt des Flaggschiffs. Die 2,2Ghz von Rome liegen da mglw. ein gutes Stück unter dem Sweetspot von Zen 4.

[Complicated]

Ist ja auch sinnvoll im Serversegment das bestehende Powerbudget auszureizen und die Leistung hoch zu schraube ans thermische Limit der vorhandenen Kühllösungen.

[Complicated]

..., da wird ein inkrementelles Upgrade nicht plötzlich mehr bringen.Und das entgegen der bisherig nachweislichen inkrementellen Upgrades Zen1 +15% -> Zen2 +19% ->Zen3?

[Piefkee]

Und das entgegen der bisherig nachweislichen inkrementellen Upgrades Zen1 +15% -> Zen2 +19% ->Zen3?


Zen1 (52%) nicht vergessen
Es hat einen Grund wenn AMD eine Vollezahl erählt oder dahinter nur ein + (Zen+,Zen3+).

Zen4 min. 15%IPC --> ich persönlich glaube eher um die 25-30%

[Der_Korken]

Und das entgegen der bisherig nachweislichen inkrementellen Upgrades Zen1 +15% -> Zen2 +19% ->Zen3?

Zen 3 war ja eben kein inkrementelles Upgrade, sondern ein größeres Redesign, sagt AMD ja selber. Ich würde für Zen 4 dann wieder was in der Größenordnung von Zen 2 erwarten, aber eben keine 25% oder was teilweise spekuliert wurde. Sowas sieht man imho erst mit dem nächsten Redesign wieder, z.B. Zen 5 in 2023.

[robbitop]

Zen 3 hat durch sein Redesign die bisherige Breite (Execution, Decoder, ooo window etc) möglichst gut ausgereizt.
Ich kann mir gut vorstellen, dass man das als Fundament nutzt, um mit Zen 4 die uArch nun auch zu verbreitern (wie Intel es mit den Coves gemacht hat). Möglich ist damit grundsätzlich schon ein guter Sprung. Eine Erhöhung der Breite bringt besonders viel, wenn die uArch möglichst wenig auf Speicherzugriffe warten muss. Und genau daran hat man mit Zen 2 und Zen 3 stark gearbeitet. Ich wäre nicht überrascht, wenn ein ähnlich großer Sprung möglich ist, wie es Zen 3 ggü dem Vorgänger gezeigt hat.

[Windi]

96-cores (192 threads)
12-channel DDR5-5200
128 PCIe 5.0 lanes (160 for 2P)
320W TDP (cTDP 400W) ��
SP5 (LGA-6096) socket

Genoa everyone ��

So ein großer Sockel.

Eigentlich bräuchte man dazu noch einen günstigen Server-Sockel (8-channel DDR5, 96 PCIe 5.0)

Und einen Threadripper-Sockel (4-channel DDR5, 64 PCIe 5.0)

Keine Ahnung wie AMD sich die DDR5-Sockel Welt vorstellt. Aber der große Sockel alleine wäre wahrscheinlich für viele zu teuer. Aber gleich 3 verschiedene Sockel mit jeweils eigenem IO Chip wäre vielleicht auch zu viel. Im Gegensatz zum Zen1 Start hat AMD jetzt aber mehr Marktanteile und könnte sich das vielleicht doch leisten.

[Der_Korken]

Breitere Cores im Sinne von mehr ALUs wären natürlich möglich, sind aber auch sehr teuer wie man bei Intel sieht. Damit ließen sich natürlich sowohl die hohen IPC-Gewinne als auch der relativ (zu 5nm) hohe Verbrauch der Kerne erklären. Das würde AMD nur dann machen, wenn sich entweder die Perf/W trotz des breiten Designs erhöht (was sicher nicht einfach ist, da die Komplexität nicht linear skaliert, siehe den hohen Verbrauch von Ice Lake vs Skylake) oder wenn sie es zusätzlich mit Big-Little kombinieren, um genug MT-Performance aus der Chipfläche rauszuholen. Würde ich aber wie gesagt erst mit Zen 5 erwarten.

[robbitop]

Ich würde annehmen, dass man es auch nicht gleich übertreiben muss. Man kann den Prozessvorteil von 5 nm in Bezug auf Leistungsaufnahme pro Transistor nutzen, um den Mehrbedarf der größeren uArch zu kompensieren. Das hat man im Prinzip die letzten Jahrzehnte genau so gemacht.

[KarlKastor]

So ein großer Sockel.

Eigentlich bräuchte man dazu noch einen günstigen Server-Sockel (8-channel DDR5, 96 PCIe 5.0)

Und einen Threadripper-Sockel (4-channel DDR5, 64 PCIe 5.0)

Ein weiterer Sockel wird dann definitiv kommen. Es wird ja auch weiterhin Bedarf an kleinere CPUs geben. Die Stückzahlen sind ja auch schon viel höher als zu Beginn von SP3.
Drei Sockel sind ja auch gar nicht nötig. Threadripper haben sie ja auch von 16 Kerne an genutzt und fast die Hälfte der Kontakte war unbenutzt.
Ich könnte mir vorstellen, dass sie einen Sockel mit 6 Speicherkanälen und 64 PCIe Lanes und bis zu 8 Chiplets (64 Kerne) bringen.
Der Sockel könnte dann noch ein Stück kleiner als SP3 werden.
Für Threadripper ideal. Eine kleinere Server Plattform wäre wohl auch nicht schlecht.

[fondness]

Noch ein paar Infos, siehe Edit bei CB:
https://www.computerbase.de/2021-02/cpu-amd-genoa-server-96-zen-4-kerne/

Kurz:
- AVX-512, BFLOAT16 und andere neue ISA Instructions sollen kommen
- Der neue Sockel soll 72 mm × 75,4 mm messen statt 58,5 mm × 75,4 mm wie beim SP3 Sockel bisher.

[LasterCluster]

Auch CB:

Apropos Dies: Laut Gerüchten sollen es auch bei Zen 4 weiterhin Acht-Kern-Dies sein, also müssten 12 Chiplets plus I/O-Die verbaut werden. Da die Anzahl der Kontakte um 50 Prozent steigt und damit auch das Package deutlich wachsen muss, ist der Platz dafür vorhanden; es könnte einfach an jeder Ecke einer zusätzlicher CPU-Die angebaut werden.

Ist zwar plausibel, aber welche Gerüchte sind/waren das?

[HOT]

Noch ein paar Infos, siehe Edit bei CB:
https://www.computerbase.de/2021-02/cpu-amd-genoa-server-96-zen-4-kerne/

Kurz:
- AVX-512, BFLOAT16 und andere neue ISA Instructions sollen kommen
- Der neue Sockel soll 72 mm × 75,4 mm messen statt 58,5 mm × 75,4 mm wie beim SP3 Sockel bisher.

Ersteres sind Spekulationen.

LasterCluster
Diese Info geisterte letztes Jahr schon herum, dass es bei 8C-CCDs bleibt.
Ich finds aber auch logisch, man wird die Topologie des CCX bei Zen4 nicht schon wieder verändern, hat man bei Zen2 ja auch nicht getan. Wenn man eh ein größeres Package baut, ergibt das auch total Sinn mehr CCDs zu verbauen.

[Locuza]

Laut ExecutableFix basiert seine Attrappe auf der echten Platzierung der Chips, mitsamt der echten Chip- und Packagegrößen:
https://twitter.com/ExecuFix/status/1366310317635088385

https://abload.de/img/zen4-die-siodkgkpu.jpg

Sollte das stimmen, dann ist der neue Server IOD ein gutes Stück kleiner geworden.
Von 428.73mm², die Fritzchens Fritz/OC_Burner für Romes SIOD gemessen hat, runter auf ungefähr 384.45mm².
Die CPU Chiplets wären nur ein kleines Stück kleiner.
Anstatt 75.75mm² unter Zen2, wären es ~71.84mm² unter Zen4 Chiplets.
Da nach wie vor 8-Kerne verbaut werden, muss Zen4 massiv größer in mehreren Bereichen geworden sein.
Gerüchte sprachen von 1MiB L2$ pro Kern, gegenüber den aktuellen 512KiB.
Mit AVX512-Support wird die FPU wieder wachsen, offen ist wie AMD das genau umsetzt und ob es gar getrennte CPU-Chiplets für Server und Client geben wird?
Keine Ahnung, ob man den L3$ vergrößern möchte oder es bei 32MiB belässt.


* Fritzchens Fritz/OC-Burners Messungen:
https://www.flickr.com/photos/130561288@N04/48988900942/
https://www.flickr.com/photos/130561288@N04/49046159127/

[Screemer]

langsam muss man die dinger stapeln. die laufzeiten von den äußeren dies waren ja schon "hoch". das wird so sicher nicht besser.

[Locuza]

Close! The picture is not 100% accurate to the mm, so here are the real sizes:

Genoa IOD: 396.64mm²
Zen4 CCD: 72.225mm²
https://twitter.com/ExecuFix/status/1366393857089409030

[robbitop]

Ggf. ein Zeichen dafür, dass AMD die Zen 4 Kerne auch ein Stück breiter machen wird. Ob man auch mehr L3 verbaut ist IMO fraglich. Da kommt man ggf. auch schnell mal in den Bereich, an dem es sich kaum noch lohnt. 32 MiB kosten in 7nm ~30 mm². So extrem gut ist die Skalierung der Fläche von SRAM nicht mehr IIRC bei den heutigen Shrinks. Ich würde auf weiterhin 32 MiB gesamt L3 tippen.
Ggf. wird man versuchen, die Fabric schneller zu machen, um die Gesamtlatenz zu senken. Dazu ggf noch Verbesserungen im Prefetcher und in der Branchprediction um die Hitrate weiter zu stärken. Hier hat man ja mit dem TAGE Predictor seit Zen 2 sehr gut vorgelegt.

Es gab aber Gerüchte um L4 im Compute Die. Damit sich das lohnt, müsste der ja wenigstens 64 MiB haben. Der Fakt, dass der IOD trotz gesteigerter Komplexität kleiner wird (ja es wird offenbar einen Shrink auf 7 nm geben), spricht eher ein wenig dagegen. SRAM ist leider nicht gerade klein. EDRAM hingegen wäre etwas anderes. Das ist aber leider bei relativ wenigen Prozessen sinnvoll möglich.

------------------
Stapeln ist thermisch zumindest mit mehreren Compute Dies schwierig.

[HOT]

Das ist zu vermuten. Vllt. untersützt man sogar AVX512 und/oder AMX, man wird aber mMn keine 512Bit Breite machen, sonden dann 2 Passes rechnen. 512Bit ist einfach Unfug für ein Chiplet, dessen Anwendungsbereich zu 99,5% nicht mit solchen Workloards arbeitet.

Das IOD ist sicherlich ein 10nm-Derivat, also vllt. auch 8 LPP. Gerüchte um AMD+ Samsung gibt es ja schon sehr lange.

[robbitop]

512 bit in 2 Passes wäre wirklich sinnvoll. Es gibt zu wenige Anwendungen die wirklich stark prodifitieren. Da kann man die Transistoren im Moment noch woanders besser investieren. Die reine Unterstützung ist aus Kompatibilitätsgründen aber sicherlich sinnvoll.

Ein anderer Prozess als 7 nm von TSMC ist sicherlich sinnvoll aus Gründen der Verfügbarkeit und Diversifizierung. Allerdings scheint Samsungs Kapazität im Moment (wie so ziemlich alles andere auch) seine Grenzen zu haben. Man sieht es ja auch ganz gut an Ampere.

[HOT]

Wobei bei Ampere offenbar die Begrenzung gar nicht mal so stark an den einzelnen Chips selbst liegt sondern an den Bauteilen. NV konnte ja auch viel liefern, wie man an den Geschäftszahlen sieht, aber wenn man die natürlich vornehmlich an Miner verkauft bleibt nix für den normalen Markt übrig. NV macht diese Diversifizierung bei Miningkarten ja auch nicht aus Profitgründen (also auch, weil man ja Turings zusätzlich anbietet), sondern, weil sie Gefahr laufen ihre Stammkundschaft zu verlieren, also nicht die Nerds, die auch AMD ne Chance geben, sondern diejenigen, die eigentlich keine Ahnung haben aber niemals was anderes als Geforce einbauen würden. Da reicht ja ein Kauf, damit diese Leute auch künftig mal Radeons kaufen. Und das sind viele.

7nm wird mMn zu teuer für die IODs. 10nm wird sicherlich aufgrund der höheren Strukturdichte besser und mittlerweile auch billiger sein als 500mm²+ 12nm IODs. 8LPP wäre nur ne Vermutung, kann ja auch N10 sein (falls es den überhaupt noch gibt?). Vielleicht ist auch 12LP+ so durchschlagend.

[Der_Korken]

70mm² in 5nm wären natürlich ne krasse Ansage. Da bekäme man auch die deutlich fetteren Kerne locker unter. Vermeer besteht zu 50% aus L3, d.h. wenn man die Kerne doppelt so groß machen würde, würde der gesamte Chip trotzdem "nur" um 50% wachsen.

[robbitop]

7nm wird mMn zu teuer für die IODs. 10nm wird sicherlich aufgrund der höheren Strukturdichte besser und mittlerweile auch billiger sein als 500mm²+ 12nm IODs. 8LPP wäre nur ne Vermutung, kann ja auch N10 sein (falls es den überhaupt noch gibt?). Vielleicht ist auch 12LP+ so durchschlagend.
Ich gehe davon aus, dass schon ein ordentlicher Shrink dahintersteckt. Immerhin ist davon auszugehen, dass die Transistoranzahl und Komplexität steigen wird (IF für bis zu 96 Cores, mehr Memorychannels, DDR5, PCIe 5.0). Und man muss im Hinterkopf haben, dass I/O nur begrenzt skaliert in Bezug auf Größenreduktion bei einem Shrink.
10 nm wird es sicherlich wenigstens sein müssen. In den Gerüchten war oftmals von 7 nm die Rede.

Wenn man im Hinterkopf hat, dass Genoa ein 2022 Produkt ist, sollte 7 nm ein wenig besser dastehen. Die bleeding edge wander zu 5 nm. Es wird also ggf. Kapazität bei 7 nm frei. Auch sind bis dahin schon mehr Abschreibungen getätigt.
Yields/Prozessreife werden sicherlich auch nochmal einen Tucken besser sein.
Ich bin mir hier nicht sicher aber ggf. sind bis dahin ja noch ein paar Lines mehr auf 7 nm umgerüstet von älteren Nodes oder von sonstigen Expandierungsplänen.
7 nm ist in 2022 absolut nicht mehr das was es in 2019/20 war. Der Mininghype und die Pandemie (im Moment sehr große Einflüsse) sind zu der Zeit als die Grundpfeiler von Genoa festgelegt worden sind, sicherlich noch nicht bekannt gewesen.

Will sagen, 7 nm sehe ich hier als nicht unwahrscheinliche Option.

[Nightspider]

Keine Ahnung ob das stimmt aber hier hätte wohl niemand erwartet das Zen4 Kerne incl. Caches fast doppelt so viel Fläche einnehmen würden.
Wenn das so stimmt könnte das mit dem riesigen IPC Sprung aus den Gerüchten ja vielleicht sogar stimmen.

Falls es stimmt und man Zen3 IPC+ ~30% und auch Taktraten um die 5Ghz erwarten kann, dann wäre das schon krass.

Gleich große Chiplets im neuen 5nm Prozess würde aber auch noch höhere Kosten und Preise bedeuten.

Auf der gleichen Fläche hätte AMD ja auch 16 Zen3 Kerne unterbringen können.

Edit: Okay, Cache und ein paar andere Teile skalieren schlechter und man würde wahrscheinlich nicht doppelt so viele Zen3 Kerne in der gleichen Fläche bei 5nm unterbringen können aber es wären schon einige mehr gewesen.

Vielleicht hätte man 14 Zen3 Kerne in 5nm unterbringen können, wo es mit 7nm nur 8 Kerne waren.

[HOT]

Ich gehe davon aus, dass schon ein ordentlicher Shrink dahintersteckt. Immerhin ist davon auszugehen, dass die Transistoranzahl und Komplexität steigen wird (IF für bis zu 96 Cores, mehr Memorychannels, DDR5, PCIe 5.0). Und man muss im Hinterkopf haben, dass I/O nur begrenzt skaliert in Bezug auf Größenreduktion bei einem Shrink.
10 nm wird es sicherlich wenigstens sein müssen. In den Gerüchten war oftmals von 7 nm die Rede.

Wenn man im Hinterkopf hat, dass Genoa ein 2022 Produkt ist, sollte 7 nm ein wenig besser dastehen. Die bleeding edge wander zu 5 nm. Es wird also ggf. Kapazität bei 7 nm frei. Auch sind bis dahin schon mehr Abschreibungen getätigt.
Yields/Prozessreife werden sicherlich auch nochmal einen Tucken besser sein.
Ich bin mir hier nicht sicher aber ggf. sind bis dahin ja noch ein paar Lines mehr auf 7 nm umgerüstet von älteren Nodes oder von sonstigen Expandierungsplänen.
7 nm ist in 2022 absolut nicht mehr das was es in 2019/20 war. Der Mininghype und die Pandemie (im Moment sehr große Einflüsse) sind zu der Zeit als die Grundpfeiler von Genoa festgelegt worden sind, sicherlich noch nicht bekannt gewesen.

Will sagen, 7 nm sehe ich hier als nicht unwahrscheinliche Option.

Ok, find ich überzeugend. Also könnte man hier von N7 oder 8LPP ausgehen als die wahrscheinlichsten Optionen.

[basix]

Ist N6 nicht günstiger als N7?

[davidzo]

Ist N6 nicht günstiger als N7?

Günstiger als N7+
N6 ist ein EUV Prozess und teilt sich daher die Kapazitäten mit N5 und N3.
Ich denke es macht Sinn wenn man beim großen I/O DIE auf ein Verfahren setzt in dem reichlich Kapazität verfügbar ist und das wäre bei N7 / N7P gegeben. Zudem kann man da die Erfahrungen/Designblöcke von Renoir/Cezanne anwenden (SI, Cache, PCIe,Fabric...).

[Der_Korken]

Wie teuer wäre und sinnig wäre es die Chiplets auf einen IO-Die zu stacken? Bei Genoa wird es wohl eher nicht passieren, aber im Desktop wäre es ja nicht abwegig einen 150mm² IO-Die in 12LP+ zu bringen, der genau die richtige Größe für zwei Chiplets oben drauf hat. Eventuelle Vorteile: Geringerer Idle-Verbrauch und geringere IF-Latenzen, da keine externen Interfaces nötig sind. Nachteile: Kosten (meine Frage), Kühlbarkeit, wobei der IOD jetzt nicht so viel verbraucht und 142W PPT in 5nm nicht mehr unbedingt nötig sind bei gleicher Kernzahl.

[HOT]

Ich bin eher gespannt, wie die interne Grafik beim Raphael umgesetzt ist. Ob das auch ein separates Chiplet ist? Also 3-4 Chips? Und einige dann ohne IGP? Oder doch ein komplett unabhängiges IOD von Genoa (anders als bisher)?

[amdfanuwe]

Günstiger als N7+
...
Zudem kann man da die Erfahrungen/Designblöcke von Renoir/Cezanne anwenden (SI, Cache, PCIe,Fabric...).
Auch günstiger als N7. Zudem sammelt AMD mit Rembrandt in N6 schon Erfahrung und Design Rules sind die selben wie bei N7.
Von daher auch nicht ausgeschlossen.

[smalM]

8LPP wäre nur ne Vermutung, kann ja auch N10 sein (falls es den überhaupt noch gibt?). Vielleicht ist auch 12LP+ so durchschlagend.
N10 ist tot.

Günstiger als N7+
N6 ist ein EUV Prozess und teilt sich daher die Kapazitäten mit N5 und N3.
Ich denke es macht Sinn wenn man beim großen I/O DIE auf ein Verfahren setzt in dem reichlich Kapazität verfügbar ist und das wäre bei N7 / N7P gegeben. Zudem kann man da die Erfahrungen/Designblöcke von Renoir/Cezanne anwenden (SI, Cache, PCIe,Fabric...).
N6 teilt sich die Produktionskapazität mit N7, N7P und N7+; die Produktion hat mit N5 oder gar N3 nichts zu tun, da diese beiden Prozesse in der neuen Fab 18 laufen (N5 in Phase 1 – 3, N3 ab 2022 in Phase 4 – 6). Die N7-Kapazität ist voll ausgebucht.

Die IO-Dies schöpfen übrigens die mögliche Dichte von 14LPP/12LP bei weitem nicht aus.
Die Begrenzung könnte durchaus eher im Metal-Stack als in der Transistorebene liegen...

[amdfanuwe]

Die Begrenzung könnte durchaus eher im Metal-Stack als in der Transistorebene liegen...
Was ich nicht verstehe: Der I/O wird etwas kleiner, hat aber ~ 50% mehr Pins zu bedienen mit ordentlich höherer Treiberleistung für PCIe 5.0 und schnellerem DDR 5. Dazu 50% mehr IF, der wohl auch nicht langsamer wird.
Da müßte der Verbrauch doch ordentlich steigen. Wie passt das zusammen?

[stinki]

N6 teilt sich die Produktionskapazität mit N7, N7P und N7+; die Produktion hat mit N5 oder gar N3 nichts zu tun, da diese beiden Prozesse in der neuen Fab 18 laufen (N5 in Phase 1 – 3, N3 ab 2022 in Phase 4 – 6). Die N7-Kapazität ist voll ausgebucht.


Das stimmt so nicht ganz, für N6 braucht man, genau wie für N5 und N3, EUV Belichter. Die braucht man für N7/N7P nicht.

N6 läuft vielleicht im gleichen Reinraum wie N7/N7P, aber wenn EUV Belichter Mangelware sind dann wird man diese eher in den N5/N3 Fabs aufbauen als bei N6.

[smalM]

Du glaubst anscheinend, TSMC habe nur in der Fab 18 EUV-Belichter stehen.
Wie sollen sie dann die Kirin 990 5G in N7+ herstellt haben, Telekinese?

[lastshady]

Habe grad die Gelegenheit mein 3600er mit einer 5900X zutauschen.
Nun ich zocke auf dem Fernseher in 4K, da sollte eig. die 3600 ausreichen.
Denke aber schmeiss einfach den 12 Kerner rein und überspringe einfach die erste DDR5 Gen., die noch lange auf sich warten lässt und wahr. eh am Anfang sehr teuer sein wird. Oder lass die drin bis die bei 4K nich mehr mitkommt. Klingt das logisch?

Alder Lake sowie Zen4 sind bei 4K wahr. kein Gramm schneller, da hier die CPU kaum belastet wird oder?

[basix]

Was ich nicht verstehe: Der I/O wird etwas kleiner, hat aber ~ 50% mehr Pins zu bedienen mit ordentlich höherer Treiberleistung für PCIe 5.0 und schnellerem DDR 5. Dazu 50% mehr IF, der wohl auch nicht langsamer wird.
Da müßte der Verbrauch doch ordentlich steigen. Wie passt das zusammen?

12LP+ sollte einen deutlichen Sprung der Energieffizienz ergeben und für mich sieht der IOD auch von der Chipgrösse nach 12LP+ (https://www.anandtech.com/show/14905/globalfoundries-unveils-12lp-technology-massive-performance-power-improvements) könnte es passen, wenn man das Design optimiert. Am meisten Kopfschmerzen machen mir die Gerüchte um 12CH Speciherinterfaces, dann wird es knapp mit der Chipgrösse. Und ob die Treiberleistung wirklich steigen muss? Hängt doch auch vom Substrat sowie Motherboard Design ab und zumindest bei DDR5 sinkt die Spannung. Bei PCIe 5.0 weiss ich das nicht.

Dass es irgendwie Samsung 8nm oder TSMC N7/10 ist glaube ich irgendwie nicht. Macht für mich keinen Sinn.

[amdfanuwe]

Und ob die Treiberleistung wirklich steigen muss?
Bei jedem Schaltvorgang am Transistor müssen Kapazitäten umgeladen werden. Bei höheren Frequenzen braucht es höhere Ströme um das Signal in gegebener Zeit stabil anliegen zu haben. Höhere Ströme -> mehr Heizung.
Eine geringere Signalspannung mildert das etwas ab. Bei PCIe bleiben die Signalspannungen wohl gleich, sonst gäbe es Probleme mit der Kompatibilität.

Kleinere Transistoren können weniger Last schalten. Für hohe Ströme schaltet man dann mehrere Transistoren parallel. Deshalb shrinkt der I/O Bereich ja auch so schlecht, weil man entsprechend viele Transistoren braucht um die benötigte Treiberleistung für USB, SATA, PCIe und sonstiges bereitzustellen.

Bei RAM und IF kann man bei einer neuen Generation mit niedrigeren Spannungen arbeiten, weshalb diese I/O etwas besser shrinken sollte.
Für den Zugriff auf den IF$ sind keine besonderen Ströme nötig, ist ja alles intern. Dürfte also einiges sparen.

[basix]

Das mit höheren Frequenzen und Strömen stimmt schon. Nur deswegen habe ich ja geschrieben, dass das auch am Design liegt ;) Zen 4 könnte mit LGA daherkommen und sonstwie optimierten Signalwegen um Substrat sowie Mainboard, um die Leiterbahnimpedanzen zu optimieren, womit weniger Energie für I/O drauf geht. AM4 ist aus dieser Sicht eigentlich schon recht alt und initial für PCIe 3.0 konzipiert worden.

[Tobalt]

Mal eine Frage, ist denn schon klar ob künftig auf dem Io Die ein Cache oder eine GPU sitzt? Wenn nicht, macht dann eine kleine teure Bulk Si Node überhaupt soviel sinn im Vergleich zu bspw. FDSOI. Nun hat Glofo zB zwar nur 22FDX weil 12FDX nicht fertig wird aber vielleicht eine andere Fab ?

[Tobalt]

Dp

[stinki]

Du glaubst anscheinend, TSMC habe nur in der Fab 18 EUV-Belichter stehen.
Wie sollen sie dann die Kirin 990 5G in N7+ herstellt haben, Telekinese?
Nein, das glaube ich nicht, und das habe ich auch nirgends geschrieben. Bitte richtig lesen und versuchen zu verstehen was ich schreibe. Ich weiß, dass für N7+ EUV Belichter in der Fab stehen und benutzt werden. Glaubst du an Telekinese oder warum fragst du?
Mir ging es um die Abhängigkeit des Ausbaus der N6 Fertigung, da für die Vergrößerung der Produktion sowohl für N6 als auch N5 mehr/neue EUV Belichter benötigt werden und diese nunmal ein beschränktes Gut sind, muss TSMC sich genau überlegen, wie sie die wenigen die sie bekommen, zwischen der N6 und der N5 Fertigung aufteilen, nicht mehr und nicht weniger wollte ich sagen. Die wenigen der N7+ Fertigung werden für das angepeilte N6 Volumen nicht reichen und damit gibt es eine Abhängigkeit zwischen der N6 und N5 Fertigung über die Zuteilung der neuen EUV Belichter.

[w0mbat]

Mal eine Frage, ist denn schon klar ob künftig auf dem Io Die ein Cache oder eine GPU sitzt? Wenn nicht, macht dann eine kleine teure Bulk Si Node überhaupt soviel sinn im Vergleich zu bspw. FDSOI. Nun hat Glofo zB zwar nur 22FDX weil 12FDX nicht fertig wird aber vielleicht eine andere Fab ?
Wir wissen nocht gar nichts. Das Zen4 IOD soll aber kleiner werden.

[robbitop]

Und das spricht auch gegen einen L4 oder eine igp. Der würde ja erst ab 64 mib Sinn machen. Und das wären nochmal ~60 mm2 in Top.
Aber der IOD wurde deutlich kleiner trotz gesteigerter Komplexität.

[S940]

Und das spricht auch gegen einen L4 oder eine igp. Der würde ja erst ab 64 mib Sinn machen. Und das wären nochmal ~60 mm2 in Top.Nö, mit EDRAM wären 64MB Kinderkram:
https://fuse.wikichip.org/news/3383/ibm-doubles-its-14nm-edram-density-adds-hundreds-of-megabytes-of-cache/

[HOT]

Wenn ein IF für Zen4 kommt ist das eh zusammen mit der Gfx ein eigenes Chiplet, ich erinnere daran, Raphael steht mit RDNA3 in der Roadmap. Das ist nicht im IOD.

[LasterCluster]

Es gibt doch eh nicht DAS Zen4 IOD. Das erwähnte und etwas kleinere ist das für Genoa. Wer weiß was genau für Raphael kommt. Vielleicht auch mehrere?

[robbitop]

Nö, mit EDRAM wären 64MB Kinderkram:
https://fuse.wikichip.org/news/3383/ibm-doubles-its-14nm-edram-density-adds-hundreds-of-megabytes-of-cache/
Wäre schön. Aber eDRAM IIRC ist in fast keinem Prozess umsetzbar. Aktuell können das nur die FD-SOI Prozesse meines Wissens nach. Da gibt es aber noch nichts, was wirklich klein ist. Sub 10 nm. Nichts was die sehr geringe Größe vom Zen 4 Genoa IOD trotz gesteigertem IO erklären würde.

[Nightspider]

Würde es Sinn ergeben nochmal einige Teile des IO-Chips in einen 2. Chip (mit anderem Prozess?) auszulagern und auf den IO Chip zu stacken?

Der wird schließlich nicht sehr heiß, da könnte man thermisch gesehen wunderbar stacking betreiben.

Weiß zwar nicht ob das im Server-Bereich vom Kosten-Nutzen Verhältnis sinnvoll wäre aber damit würde man zumindest Platz für mehr Chiplets gewinnen.

[robbitop]

Möglich ist sicherlich vieles. Aber jedes weitere Chiplet (ob gestackt oder nicht) kostet extra. Ist ja Waferfläche. Es bleibt spannend. :)

[S940]

Wäre schön. Aber eDRAM IIRC ist in fast keinem Prozess umsetzbar. Aktuell können das nur die FD-SOI Prozesse meines Wissens nach. Da gibt es aber noch nichts, was wirklich klein ist. Sub 10 nm. Nichts was die sehr geringe Größe vom Zen 4 Genoa IOD trotz gesteigertem IO erklären würde.Naja, im Fritzchen Die-Shot sieht man doch auch ne Menge SRAM im IOD. Wenn man den auf EDRAM umstellt, spart man viel Fläche ein. Außerdem macht ein kleinerer Prozess fürs IOD wg. der Anschlüsse doch auch keinen Sinn.

So oder so: Es ist ja auch nicht zu 100% sicher, dass die Mockup-Maße wirklich zu 100% stimmen.

[robbitop]

Naja, im Fritzchen Die-Shot sieht man doch auch ne Menge SRAM im IOD. Wenn man den auf EDRAM umstellt, spart man viel Fläche ein. Außerdem macht ein kleinerer Prozess fürs IOD wg. der Anschlüsse doch auch keinen Sinn.

So oder so: Es ist ja auch nicht zu 100% sicher, dass die Mockup-Maße wirklich zu 100% stimmen.
Nochmal: die top notch bulk prozesse können kein AFAIK leider keinen eDRAM. Ein top notch FDSOI Prozess <= 10 nm, der frei verfügbar wäre, ist mir nicht bekannt. Selbst einer, der auf ähnliche Dichte wie GF's 12 nm kommt - mir ist keiner bekannt.

[HOT]

Häää? Und in was hat Intel dann den eDRAM für Broadwell gefertigt?

[mboeller]

GF 14HP Process:

https://fuse.wikichip.org/news/956/globalfoundries-14hp-process-a-marriage-of-two-technologies/4/

0,0174µm²/bit eDRAM

[Gipsel]

Häää? Und in was hat Intel dann den eDRAM für Broadwell gefertigt?Das war ein angepaßter 22nm Prozeß. Deswegen war das ja auch ein separates Die.

[robbitop]

GF 14HP Process:

https://fuse.wikichip.org/news/956/globalfoundries-14hp-process-a-marriage-of-two-technologies/4/

0,0174µm²/bit eDRAM
Tja und ist der auch in ausreichenden Massen verfügbar? Zweifelhaft.
Dazu kommt, dass die grundsätzliche Dichte wahrscheinlich nicht ausreicht, damit ein IOD von Genoa trotz deutlich mehr Komplexität deutlich kleiner wird.
EDRAM wäre super. Aber IMO leider auch unwahrscheinlich.

[Opprobrium]

Mal eine Frage, ist denn schon klar ob künftig auf dem Io Die ein Cache oder eine GPU sitzt? Wenn nicht, macht dann eine kleine teure Bulk Si Node überhaupt soviel sinn im Vergleich zu bspw. FDSOI. Nun hat Glofo zB zwar nur 22FDX weil 12FDX nicht fertig wird aber vielleicht eine andere Fab ?
Ist afaik noch nichts bekannt. Ich persönlich gehe nicht davon aus, auch wenn ich es sehr begrüßen würde. Hat schon was, wenn man eine rudimentäre GPU gleich integriert hat. Für viele (auch CPU intensive) Anwendungen ist eine dedizierte GPU letztlich Overkill, und auch wenn man eine GPU braucht, so ist es doch praktisch wenn man temporäre Durststrecken (GraKa kaputt, pandemisch bedingte GPU-Knappheit...) mit der iGPU überwinden kann.

[S940]

Nochmal: die top notch bulk prozesse können kein AFAIK leider keinen eDRAM. Ein top notch FDSOI Prozess <= 10 nm, der frei verfügbar wäre, ist mir nicht bekannt. Selbst einer, der auf ähnliche Dichte wie GF's 12 nm kommt - mir ist keiner bekannt.
Huh? Wozu brauchst Du nen topnotch Prozess?

Mal ausführlicher:

Es braucht keinen "topnotch <=10nm", um ein kleineres Die zu bekommen. Wenn man die bestehenden SRAMs des IODs durch die deutlich kompakteren EDRAMs ersetzt, schrumpft die Die-Größe ebenfalls, auch mit 12nm oder 14nm.
Ich zitiere mal direkt aus dem Link, den keiner zu lesen scheint :freak:
To give you an idea of how dense it is, even on their 14 nm process, the cell size is 0.0174 µm². Currently, the densest SRAM cell reported to date on a production node is 0.021 µm2 by TSMC on their yet-to-ramp 5-nanometer process. That puts IBM's 14 nm eDRAM bit cell at about 20% denser than the densest 5 nm SRAM cell to date.

Keiner braucht Topnotch-Prozesse, wenn die Cellsize besser ist :biggrin:

Ansonsten hat mboeller ja auch nen Link dazu gepostet (Danke dafür), das sollte nun hoffentlich als Info genügen ;)

[S940]

Nun hat Glofo zB zwar nur 22FDX weil 12FDX nicht fertig wird aber vielleicht eine andere Fab ?
12FDX ist fertig, man bietet es nur nicht an, weil es nicht nachgefragt wird. So zumindest die offizielle Info:

“We have R&D getting ready for 12FDX, but not until we have a segment that we can differentiate a solution where we come in and do something on that front,” said Thomas Caulfield, CEO of GlobalFoundries. “This is not high-speed digital where it’s the race to the next feature side, because the complexity is really in the device and doing a single function. We are an SoC type company. So, we bring big features together of many features together in one piece of silicon. And the device doesn’t matter as much as the feature size. Yeah. So the answer is yes, we have a 12 FDX roadmap. We will launch it when it has the right solution space for our customers to differentiate their products and ours.”


GlobalFoundries itself does not deny that it had to delay its 12FDX platform because there are no market segments it could address just yet. Those companies who need performance and transistor density of 10nm-class nodes for their designs can now use GlobalFoundries’s 12LP+, whereas for low-power/low-cost high-volume designs there is 22FDX. At present, 12FDX is largely overkill for the markets addressed by 22FDX and more complex devices for emerging applications that will need 12FDX yet have to be developed.

https://www.eetasia.com/globalfoundries-details-ambitious-technology-roadmap/

GF ist halt jetzt vordringlich im low-cost Markt, wo 12FDX noch keiner braucht - aber wenn AMD ankäme, würden sie ganz sicher Wafer belichten ;)


Und selbst wenn nicht: es gäbe immer noch 14HP mit SOI, eben den Prozess, den auch IBM für die EDram-Chips nutzt:
https://fuse.wikichip.org/news/956/globalfoundries-14hp-process-a-marriage-of-two-technologies/

[HOT]

14HP ist glaub ich dafür aber zu teuer. Vielleicht ist AMD ja tatsächlich der erste 12FDX Abnehmer.

Ich glaubs aber ehrlich gesagt nicht, ich denke weiterhin, dass es sich hier um SRAM handelt und das IOD vom GFX+I$-Die nochmal getrennt wird, man als 2-4 Chiplets auf einem AM5-Träger haben kann, abhängig davon, ob man GFX braucht oder nicht, ob man das letzte bisschen Leistung braucht oder nicht, ob man >8C braucht oder nicht. Der Löwenanteil des Marktes würde dann ja nach wie vor mit 2 Chiplets bedient werden, ein CCD + IOD. Alles zusätzliche ist dann für höhere Preisklassen vorgesehen.

[robbitop]

RnD fertig heisst aber nicht dass das ein volume Prozess mit anständigen yields und anständigen Waferstarts ist. Und das müsste er jetzt sein damit Zen 4 Anfang 2022 als Massenprodukt verkauft werden kann.

Zur Chpgröße des IOD. Es sind 4x Memorykanäle mehr und PCIe5 und DDR5. Und das Ding ist iirc 80 mm2 kleiner. Nur durch die Substitution von sram durch edram wird man da schwer hinkommen.

Ich wette gegen edram. Würde mich aber freuen wenn ich falsch liegen würde. ;)

[w0mbat]

Ich warte mega gespannt auf neues zu Zen4, bzw. ob es einen Zen3+ gegebn wird oder nicht. Nach dem RKL launch bin ich mir nicht sicher, ob AMD überhaupt "antworten" muss. Zen3 scheint auch gegenüber RKL besser dazustehen, bzw. vielleicht sogar noch besser als gegenüber CML.

[robbitop]

Kann mir gut vorstellen, dass Zen3+ eher gegen ADL gestellt wird. Ähnlich wie Zen 2 XT ggü CML.
Zen 3 ist ja auch noch nicht lange veröffentlicht. Da wäre jedes neue Produkt IMO noch stark verfrüht.

[r3ptil3]

Ich warte mega gespannt auf neues zu Zen4, bzw. ob es einen Zen3+ gegebn wird oder nicht. Nach dem RKL launch bin ich mir nicht sicher, ob AMD überhaupt "antworten" muss. Zen3 scheint auch gegenüber RKL besser dazustehen, bzw. vielleicht sogar noch besser als gegenüber CML.

Könnte durchaus Auswirkungen haben, siehe Intel 2011-2016.
AMD wird da irgendwann auch änhlich reagieren und eher Performance zurückhalten, welche natürlich dem Verbrauch und ggf. der Effizienz zu Gute kommt.

Ich verweise da an die Gerüchte im Februar, als noch die Rede war von einem 8 Kerner mit 5 Ghz - davon hört man nichts mehr.

https://www.pcgameshardware.de/Vermeer-Codename-276905/News/Ryzen-5000-Geruechte-um-Sondermodell-mit-ueber-5-GHz-1366838/

[Linmoum]

AMD hat für jede Generation einen Zyklus von 12-18 Monaten. Da AMD flexibel ist und zwei unabhängige Teams hat (das von Zen2 arbeitet atm an Zen4, das von Zen3 ist für Zen5 zuständig), gibt es wenig Grund, warum der Zeitplan verschoben werden sollte. An TSMC N5 wird es sowieso nicht scheitern.

Ich rechne mit einer Ankündigung bzw. Vorstellung zur CES 2022, der Launch dann im Februar/März. Das wären 13-14 Monate nach Zen3, das wiederum 14 Monate nach Zen2 launchte.

Laut letzter Gerüchte soll der "Launch" (nicht Vorstellung/Ankündigung, das wohl im September) von ADL im Dezember sein. Und dann ist noch nicht einmal klar, ob erst Mobile oder Desktop.

Ich sehe nach dem RKL-Launch keinen Sinn für Warhol, maximal für sowas wie die XT-Modelle bei Matisse, wo man dann genug gesammelt hat um das schon einmal angesprochene 5GHz-Modell zu bringen. Mehr ist gar nicht nötig und auch Aufwand, den es nicht braucht. Das erledigt alles zeitnah dann Zen4.