AMD - Zen 4 (Raphael, Phoenix & Genoa, 5 nm, AM5, DDR5, PCIe 5.0, Ende 2022) [Archiv] - Seite 5

Platos

2021-10-02, 11:41:02

Dann kann man aber die Anzahl kleinen Kerne nicht mehr regulieren. So ist dann die Anzahl immer fix. Kann natürlich sein, dass AMD sagt, pro grosser Kern gibts einfach immer x kleine Kerne. Aber dann kann man weniger Produktabstufungen machen, wie z.B bei Intel einmal 8+4 und einmal 8+8 oder 8+8 und 8+16.

Also ein Chiplet für z.B 8 kleine Kerne und eins für 16, eins für 32 usw. Das ist deutlich smarter und erweiterbarer.

Andererseits je mehr Chiplets vorhanden sind, desto schwieriger wird es wahrscheinlich, diese zu verbinden. Aber bei Intel sieht ja die Zukunft auch vor, dass irgendwann ein "Prozessor" aus ganz vielen kleinen eigenen "Chiplets" besteht, in dem man z.B die stärke der GPU quasi "frei" wählen kann (oder aber eben die Anzahl kleinen Cores). Also sollte das schon gehen, denke ich.

Wenn man die kleinen und grossen Kerne in ein Chiplet nimmt, geht man ja theoretisch wieder etwas weg von der Philosophie, dass man eben alles in Chiplets auslagert.

Nightspider

2021-10-02, 12:01:18

Wenn wir dann von 3nm sprechen bei Zen5 mit big.LITTLE ist davon auszugehen, das wir wohl mehr als 8 Big Cores pro Chiplet sehen werden bzw. eben 8 Zen5 und 8 Zen4 Cores beispielsweise.
Ob es Sinn macht in ein Chiplet A 12-16 Zen5 Cores zu setzen und ein Chiplet B mit 16-32 Zen4 Cores weiß ich nicht.

Vielleicht sitzen dann auch 32 Zen5 Kerne mit 64Zen4 Kernen auf einem 80mm² Chiplet und der komplette L3 Cache liegt außerhalb des Dies unter dem Compute Die.
Dass das möglich wäre zeigt ja Zen3.

Logic in N3 wird verdammt klein. Den L3 auszulagern macht irgendwie eh Sinn, weil er schlecht skaliert.

Wer weiß wie die CPUs in 3 Jahren wirklich aussehen werden.

Wahrscheinlich müsste AMD dann nur mehrere Chips auflegen, weil die gestacken Chips dann einfach in einer sehr hohen Preisklasse liegen würden.
Für den günstigen Markt bräuchte man dann noch Chips wo der L3 direkt mit auf dem Die ist.

Platos

2021-10-02, 12:41:46

Man wird im Consumerbereich bestimmt nicht mehr wie 8 grosse Kerne verbauen pro Chiplet. Gerade mit dem Einführen von kleinen Cores ist es umsomehr ausgeschlossen. Aber es ist so oder so nicht denkbar. Mit 16C Chiplets müsste man 8 deaktiveren für nen 8-Kerner und die Preise von Zen3 sprechen in allen Punkten gegen eine Kernerhöhung bei selbem Preispunkt. 6-Kerner wären sowieso nicht mehr möglich damit und bei nem Listenpreis bei Zen3 von 300$ ist das alles sowieso absolutes Wunschdenken.

Und wenn Zen5 Big in 3nm kommt, wird vlt. Zen4 little in 5nm kommen.

Nightspider

2021-10-02, 12:54:00

AMD interessiert es doch gar nicht ob irgendjemand in der Zukunft noch mit 8 Kernen auskommen würde.

Genauso wie AMD sich schon seit Jahren nicht mehr für QuadCores interessiert.

Irgendwann kommt der Punkt wo eben einfach keine "kleinen" 8 Kerner mehr angeboten werden.

Das AMD den CoreCount nicht ausbremst wie Intel ein Jahrzehnt lang, haben sie doch schon gezeigt.

Muss jetzt nicht bei Zen5 der Fall sein aber da gäbe es zumindest noch schnelle Zen4 8 Kerner, wer unbedingt auf "nur 6 oder 8 Kerne" wechseln will.

Wer mehr SC Leistung will muss ab einem bestimmten Zeitpunkt dann irgendwann zu mehr Kernen greifen. Das war schon immer so.

Ob der Punkt mit 3nm erreicht wird, sei mal dahingestellt.

Wer weniger Kerne will wird sich dann vielleicht auch bei den APUs mit monolithischem Die umschauen müssen.

Platos

2021-10-02, 13:02:14

Den "Core Count" bremst AMD sehr wohl aus und zwar mit Zen3

Und wer mehr SC Leistung will, muss zu mehr Kernen greifen??? Merkst du was xD

Ich halte dagegen: Man wird im Consumerbereich keine CCDs/Chiplets mit mehr wie 8 grossen Kernen machen.

Windi

2021-10-02, 13:47:02

Warum macht man sich eigentlich solche Sorgen über die Chipfläche?

AMD lässt momentan (in 7nm) riesige APUs fertigen, die dann für unter 100€ an die Konsolenhersteller verkauft werden.

Dann sollen in Zukunft ein paar little Kerne auf den Chiplets ein Problem werden? Who cares?

Das AMD Chipfläche "verschwendet" ist völlig normal. Schon die ersten Zen1 Chips wurden nicht nur für die normalen Ryzen, Threadripper und Epycs verwendet, sondern auch für PRO-Modelle, Embedded und billige Athlons (teils für unter 40€). Und überall wurden andere Dinge aktiviert und deaktiviert.
Beim Epyc Modell mit nur 8 Kernen und dafür giganischem Cache werden gleich 7 der 8 Kernen pro Chiplet deaktiviert.
Bei den APUs gibt es auch Vermutungen, das AMD hier Fläche verschwendet hat, um sie schneller auf den Markt bringen zu können. Man hat hier anscheinend bereits vorhandene Baueinheiten zusammengepuzzelt, die die Fläche nicht optimal nutzten. Man hätte natürlich alles nocheinmal optimieren können, hat aber den schnelleren Marktstart vorgezogen.
Bei Zen3 ist auf der Fläche des L3 Caches die Ansteuerungslogik so ausgelegt worden, das man noch einmal bis zu 8 weitere Cache Chips darauf stapeln und ansteuern könnte. Deshalb passt bei der Cachefläche auf der CPU nur 32MB und bei der selben Fläche auf den Cache Chiplets 64MB Cache. Völlige Verschwendung für ein Großteil der verkauften Prozessoren.
Das ist alles bewusste "Verschwendung" von Chipfläche, weil andere Dinge anscheined wichtiger scheinen. Und ein deutliches Zeichen dafür, das Chipfläche doch nicht so teuer zu sein scheint, solange man nicht gewisse Grenzen sprengt.

Chipfläche spielt dank dem Multichip Design keine so große Rolle mehr. Vor allem im Server und HighEnd Bereich, wo höhere Preise verlangt werden können. Wenn dann in Zukunft auch noch der L3 Cache seperat gefertigt und gestapelt wird, bestehen die Chiplets nur noch aus Kernen. Die Chiplets können aber auch nicht unendlich klein werden.

Platos

2021-10-02, 14:00:49

Genau, im Server Bereich, aber nicht im Consumerbereich. Und Konsolen mit Abnahmezahl von 150 Millionen Stück mindestens über die nächsten x Jahre ist das auch was anderes.

Und nochmals: Wenn man kleine Kerne einführt, wird man nicht die Anzahl der grossen Kerne erhöhen. Vergesst es ^^ Und vor allem: Warum sollten sie das bitte tun? Man wird durch kleinere Strukturen die Kerne fetter machen und nicht einfach mehr und mehr verbauen.

Bringt nix.

amdfanuwe

2021-10-02, 14:59:29

Die reinen Produktionskosten eines Chips sind nicht so hoch.
Dürfte bei 20-40$ für einen 200mm² Chip liegen.
Lasst es mal 100$ für einen 400mm² Chip sein.
Natürlich nur in Massenproduktion.

Wirklich teuer werden aber zunehmend die Entwicklungs- und Testkosten, die zugekaufte IP etc.
Schließlich kommen immer mehr Transistoren auf den Chip, der Designaufwand die entsprechend zu verwenden steigt und die Testfälle steigen exponential an. Immer mehr Kontakte erfordern auch entsprechendes Equipment.

Bei der Flächenoptimierung spart man als letztes bzw. lohnt das nur für spezielle Chips für einen bestimmten Einsatzzweck in Massenproduktion.

Wenn dann Athlons für 40€ verkauft werden, ist das auch eine marktpolitische Sache, Mischkalkulation bzw. billiger als entsorgen.

Also wegen ein paar mm² "verschwendeter" Fläche reg ich mich da nicht auf.

Google arbeitet aber schon an eine AI, die das Chipdesign wieder billiger machen könnte.
Designs that take humans months can be matched or beaten by AI in six hours
https://www.theverge.com/2021/6/10/22527476/google-machine-learning-chip-design-tpu-floorplanning
Da hoffe ich mal, dass AMD nicht den Anschluß verliert.

Nightspider

2021-10-02, 20:15:28

Den "Core Count" bremst AMD sehr wohl aus und zwar mit Zen3

AMD bot mit 12nm 8 Kerne an. Doppelt so viel wie Intel.

Mit 7nm bietet AMD mittlerweile 64 Kerne an, mit relativ linearem Preisanstieg pro Chiplet.

Mit 5nm geht AMD bei Threadripper eventuell auf 96 Kerne, bei gleichzeitig deutlich höherer IPC.

Wenn AMD bremst, was macht dann Intel? Achja, Intel bietet viele kleine Kerne an weil sie es nicht schaffen so viele große Kerne
effizient und kühlbar in eine Plattform zu pressen.

Und wer mehr SC Leistung will, muss zu mehr Kernen greifen??? Merkst du was xD

[ ] Du hast meinen Beitrag verstanden.

Wenn es Zen5 beispielsweise nur mit mehr als 8 Kernen geben sollte und du von Zen4 aus kommend mehr SC Leistung willst dann musst du zu mehr Kernen greifen.

Und da Zen5 in 3nm kommt und das 2 Full Node Sprünge sind, ist es gar nicht mal so weit hergeholt das die Chiplets eventuell mehr als 8 Big Cores bekommen und dazu wohl noch etliche kleine Kerne. Ob das dann 16P/0E Cores werden oder 10P/10E oder 12/8 oder oder oder steht eh in den Sternen. Aber tendenziell brauchen mehr Kerne auch mehr Cache, der immer schlechter skaliert mit neuen Fertigungsprozessen.
Das man in ein Chiplet deutlich mehr Kerne packt und den L3 (fast)komplett aus dem Compute Chip entfernt und auslagert halte ich langfristig schon für ziemlich wahrscheinlich. Alleine schon weil die Latenzen besser werden wenn man den großen Cache in die 3. Dimension verlagert. Vielleicht verlagert man wegen den besseren Latenzen bei größerer Kapazität auch den L2 in die 3. Dimension.

reaperrr

2021-10-02, 21:21:28

Ich wette darauf, dass wir so schnell nichts anderes als 8C-Chiplets sehen werden.

Die Energieeffizienz je Transistor steigt längst nicht so schnell wie die Packdichte, und die Kosten je mm² verdoppeln sich inzwischen fast je FullNode-Shrink, so dass sich der Vorteil vom Shrinken fast komplett auf die elektrischen Vorteile beschränkt.
Unter solchen Umständen wird eine möglichst hohe Yieldrate noch wichtiger als sie ohnehin schon ist, und allein schon deswegen halte ich eine Verdoppelung der Kerne je CCD in absehbarer Zeit für extrem unwahrscheinlich.

Mit Zen5 soll AMD laut Gerüchteküche auch massiv Transistoren in die IPC investieren, so dass ein 8C-Zen5-CCD in 3nm vermutlich kaum kleiner als ein Zen4-CCD in 5nm wird, der schon kaum kleiner als ein Zen3-CCD in 7nm wird.

big.LITTLE wird IMO auch mit separaten Chiplets umgesetzt, einem 8C-Zen5-Chiplet und einem auf 3nm geshrinkten Zen4-Chiplet, dessen Kerne die 'LITTLE'-Rolle übernehmen.
Beim AM5-Topmodell werden dann vmtl. je zwei von jedem Chiplet verbaut.

Platos

2021-10-02, 21:42:43

@ Nightspider. Mir ging es um den Consumermarkt und da bremst AMD momentan aus, weil sie eine Teuerung gebracht haben und somit die 8-Kerner Klasse wieder weit ausserhalb des Mainstream gebracht haben.

Und Intel erhöht immerhin die Preise nicht so signifikant. Also...

Edit: Und was mal vor x Jahren war, interessiert mich nicht. Es zählt alleine, was das Unternehmen jetzt macht und nicht, was es mal irgendwann früher gemacht hat.

Complicated

2021-10-03, 01:09:54

Und da Zen5 in 3nm kommt und das 2 Full Node Sprünge sind,

Könntest Du näher ausführen was du mit 2 Fullnode Sprüngen bei 3nm meinst? Von wo gerechnet?

Nightspider

2021-10-03, 03:32:44

Nochmal als Reminder:

Laut dieser Folie kann man mit N3 ja eine rund 43% geringere Leistungsaufnahme im Vergleich zu N7 erwarten und eine 3,1 fache Transistordichte.

Also in die gleiche Logic Area passen mit N3 ca. 3,1 mal mehr Transistoren rein als noch bei N7.

Man kann davon ausgehen das SRAM genauso schlecht skalieren wird wie von N7 auf auf N5.

https://semiwiki.com/wp-content/uploads/2020/09/A72_core_high_density-768x459.jpg.webp

Könntest Du näher ausführen was du mit 2 Fullnode Sprüngen bei 3nm meinst? Von wo gerechnet?
https://en.wikichip.org/wiki/technology_node

Complicated

2021-10-03, 08:00:49

Zum einen ist da ARM abgebildet und zum anderen kommt Zen4 ja in 5nm. Deshalb wundere ich mich wann AMD da von 7nm auf 3nm springen soll.

Ramius

2021-10-03, 10:05:14

Zum einen ist da ARM abgebildet und zum anderen kommt Zen4 ja in 5nm. Deshalb wundere ich mich wann AMD da von 7nm auf 3nm springen soll.

Von Zen3 (=7nm) -> Zen5 (=3nm).

Platos

2021-10-03, 10:33:03

basix

2021-10-03, 11:10:10

Kommt drauf an, was für Transistoren (z.B. SRAM braucht deutlich weniger Energie) und wie viele gleichzeitig aktiv sind. Dazu noch Designverbesserungen usw., was z.B. eine Low Power Optimierung von Zen 4D sein kann.

Man kann davon ausgehen, dass die Vorteile des Logic Scalings maximal ausgenutzt werden. Deswegen erwarte ich >2x Transistoren pro CCD zwischen Zen 3 und Zen 5.

Den "Core Count" bremst AMD sehr wohl aus und zwar mit Zen3

OK. Mit Zen 2 die Kernzahl glatt verdoppelt und bei Zen 3 die Performance pro Kern stark verbessert. AMD bremst wahnsinnig. Kannst ja mal auf Intels 8C Rocket Lake schauen. Rückgang(!) von 10C auf 8C. Zum Teil verringerte MT-Performance. Das nenn ich bremsen ;)

Nightspider

2021-10-03, 11:40:46

Zum einen ist da ARM abgebildet und zum anderen kommt Zen4 ja in 5nm. Deshalb wundere ich mich wann AMD da von 7nm auf 3nm springen soll.

Spielt doch keine Rolle ob das von ARM stammt. Die Tendenz ist klar.

Und das sich das auf Zen5 bezog mit N3 stand doch sogar in dem Satz, den du zitiert hast.

Nightspider

2021-10-03, 11:45:47

Man kann nicht einfach nur schauen, wie viel mehr Transistoren da rein passen. Die Powerreduktion ist bei -43%, also passen bei selbem Takt und Strombedarf ca 1.7x mehr Transistoren rein. In der Theorie zumindest.

Das ist ein(nicht zwei) sehr lamer Fullnode

Aber es herrscht hier im Thread wieder mal Wunschdenken. Dann glaubt ihr mal daran.

Das da auch sehr viele Transistoren in die Optimierung zur Steigerung der Effizienz fließen müssen sollte schon klar sein.

Glaube das ist hier auch den meisten bewusst.

Da kommen nicht mehr Kerne. Hier sind einfach wieder mal ein paar am fantasieren, weil sie sich so sehr mehr Kerne wünschen.

So verallgemeinert formuliert ist deine Aussage einfach nur falsch.
Und obwohl du so auf die fehlende Effizienz pochst, bringt AMD 50% mehr Kerne bei Genoa.
(Mir ist dabei aber bewusst das Genoar ein höheres Power Budget zur Verfügung steht.)

Bei Zen5 könnte AMD im Consumer Bereich noch bei 8 Big Cores bleiben, ja. Und fahre dein toxisches Ego mal bisschen runter, danke.

Noch weiß niemand wie viel effizienter Zen4 und 5 werden. Zen 2 hatte da einen riesigen Sprung gemacht. Größer als durch den reinen Node Sprung möglich gewesen wäre.
Das hängt aber natürlich auch immer stark vom Betriebspunkt (Stichwort Sweetspot) ab. Bei geringerem AllCore Boost lassen sich schnell deutlich mehr Kerne mit gleichem Verbrauch betreiben.

Und beim feingranularem Boost auf den einzelnen Cores sind AMD und Intel mittlerweile richtig gut geworden.

Platos

2021-10-03, 15:30:12

Architekturverbesserungen sind natürlich indirekt immer eine Effizienzsteigerung, wenn bei selbem Strombedarf mehr Leistung möglich ist. Im Normalfall steigert sich aber die Rechenleistung und der Strombedarf bleibt gleich. D.h bei mehr Kernen steigt auch der Strombedarf extrem an.

Aber wie auch immer. Warum denkst du denn überhaupt, sollte das kommen? Was soll denn der Grund sein, dass AMD ihre Kernanzahl verdoppelt bei CPUs (und Chiplets)? Warum sollten sie das tun?

Im Endeffekt müsste dann auch der Preis gesenkt werden, denn es werden natürlich nicht im Consumermarkt 32-Kerne zum doppeltem Preis angeboten und die 6-Kerner stehen dann mit 10 deaktivierten Kernen da. Und sowieso: 6-Kerner würden komplett weg fallen und vlt. sogar 8-Kerner. Bei 16-Kern-Chiplets wäre dann der 12-Kerner quasi die Budget-Lösung.

Oder kurz gesagt: Die Preise pro (grossem) Kern müssten massiv fallen. Die Leute fangen ja nicht einfach an auf einmal an teurer zu kaufen. Denkst du wirklich, das wird bei Zen5/6 im Consumermarkt (Dekstop) passieren? Also wirklich, eine ernst gemeinte Frage. Wie stellst du dir das bitte vor? AMD erhöht die Preise letztes Jahr und soll sie dann in 3-4 Jahren grob halbieren (anders gehts nicht)? Und AMD führt genau etwa um die Zeit kleine Kerne ein, damit sie dann die Anzahl der Grossen verdoppeln?

Aus was ziehst du da deine Schlüsse? Die vorhandenen Informationen (es kommen kleine Kerne, Preise wurden letztes Jahr erhöht, bei Zen5 sollen die Kerne deutlich fetter werden) sprechen alle dagegen.

Edit: Also nicht falsch verstehen: Mehr CPU Kerne können von mir aus ja kommen (sollen ja angeblich auch), aber die sind dann auch teurer (ähnlich i9 bei Intel, eine neue Klasse).

HOT

2021-10-04, 15:20:34

Es ist doch schon klar mittlerweile, dass das Zen4-CCD weiterhin 8C hat.
Bei Zen5 wird das anders sein, da das Granite Ridge CCD ja offenbar neben den 8 Zen5-Kernen zusätzlich noch 4 Zen4D-Kerne unterbringt (Zen4D wird für Dual oder Duo stehen, man wird 2 Zen4-Kerne in den Platz eines Zen5-Kernes unterbringen mit einem shared L2$ mMn).

Sweepi

2021-10-04, 15:24:45

Wenn man auf 16 Core Chiplets umsteigt, dann kann der Kleinkram ja mit einer monolithischen n-Core APU abgedeckt werden, mit 8<=n<=12

HOT

2021-10-04, 15:30:09

Der Trend geht weg von monolithischen Chips, das gilt auch für APUs. Der Vorteil ist doch, die Fertigung billiger zu machen. Das geht mit kleineren Chips, nicht mit größeren.

Wenn man 2 Zen5-CCDs sieht, hätte man 24x2 Threads macht 48 Threads für einen 2 CCD-Prozessor. Intel will mit Arrow Lake selbst 48 Threads bieten (8x2 + 32). Ich sehe einfach keinen Platz im Portfolio für 16C-Chiplets.

Sweepi

2021-10-04, 18:35:27

Bis jetzt haben die APUs keine Chiplets bekommen.
Mit 5nm / 3nm wäre eine 8C-12C APU klein genug, um neben 16C Chiplets einen Platz im Portfolio zu haben
Heute mit 7nm gibt es ja auch monolithische 6C / 8C APUs von AMD

Thunder99

2021-10-04, 18:38:09

16-C werden nicht kommen. Wenn dann eher Zwischenschritte auf 10/12

Sweepi

2021-10-04, 18:42:07

Kann gut sein. Meine nur, dass „Geht nicht, weil Budget 6C/8C Angebote dann >= 50% ungenutzte Chipfläche haben müssten“ nicht der Fall ist.

Complicated

2021-10-04, 18:47:03

Dies könnte sich nun mit dem neuen Packaging-Verfahren, welches die 3D-Caches onDie sozusagen versenkt bald ändern.
https://i0.wp.com/semiengineering.com/wp-content/uploads/Cadence_TSMC-3D-fabric-fig2.jpg?ssl=1
AMD nutzt SoIC CoW um die Caches mit dem Die zu verbinden.
Der Grund warum APUs derzeit nicht mit Chiplets kommen, ist eben der hohe Energieverbrauch der Interconnects (IF) zwichen den beteiligten Chiplets. Das sieht man ja auch an mobile, wo APUs zum Einsatz kommen.

Dieser Energie-Overhead als Schwachstelle könnte künftig entfallen, wenn stattdessen RDNA3 GPU-Chiplets auf die selbe Weise verbunden werden im CoW-Verfahren, wie der 3DV Cache.

https://www.pcgameshardware.de/screenshots/original/2021/08/AMD-Hotchips-33-3D-V-Cache-3D-packaging-5--pcgh.jpg

Platos

2021-10-04, 19:29:48

Wäre natürlich möglich, dass man für 6- und 8-Kerner einfach keine Chiplet-basierten Prozessoren anbietet. Aber ich bleibe bei meiner Behauptung: Im Consumerbereich (keine APUs) am Desktop wird man die Kernanzahl der grossen Kerne pro Chiplet nicht erhöhen (mittelfristig, also Zen5 eingeschlossen). Die Entwicklung mit der riesen Anzahl an kleinen Kernen spricht vollstänig dagegen.

Kann gut sein. Meine nur, dass „Geht nicht, weil Budget 6C/8C Angebote dann >= 50% ungenutzte Chipfläche haben müssten“ nicht der Fall ist.

Ich habe aber nie von APUs gesprochen, falls das auf die Diskussion von weiter oben bezogen ist. Also nur Dekstop-CPUs (also auch nicht die APUs von AMD).

Also meinst du, dass AMD evtl. in Zukunft bei 6- und 8 Kernern wieder weg vom Chiplet-Design geht, weil die Chips irgendwann wieder so klein werden ? Wobei du sagst, unterhalb von 12-Kernern werden nur noch APUs angeboten. Das könnte man natürlich auch machen, aber die unterscheiden sich nicht nur durch die GPU. Die haben auch weniger PCI-E Lanes usw. usw. Also so einfach ist das nicht, die APUs sind kein Ersatz.

Allerdings wie gesagt: AMD will ja mit Zen5 die Kerne erheblich "fetter" machen, so dass die benötigte Fläche unter 3nm ähnlich der Fläche eines Zen4 unter 5nm ist. Kann die Quelle gerade nicht finden dazu.

Es ist doch schon klar mittlerweile, dass das Zen4-CCD weiterhin 8C hat.
Bei Zen5 wird das anders sein, da das Granite Ridge CCD ja offenbar neben den 8 Zen5-Kernen zusätzlich noch 4 Zen4D-Kerne unterbringt (Zen4D wird für Dual oder Duo stehen, man wird 2 Zen4-Kerne in den Platz eines Zen5-Kernes unterbringen mit einem shared L2$ mMn).

Ja es ging ja eig. nur um die grossen Kerne. Und ausserdem ist es nicht sicher, ob die kleinen Kerne nicht ein eigenes Chiplet bekommen.

Nightspider

2021-10-04, 19:32:56

Zeig uns mal eine Quelle das AMD Zen5 erheblich fetter machen will. :)

Platos

2021-10-04, 19:53:11

Zeig uns mal eine Quelle das AMD Zen5 erheblich fetter machen will. :)

Ich finde die Quelle leider nicht mehr, aber das gabs mal in der Gerüchteküche.

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12809074#post12809074

Vlt. weiss ja reaperrr noch, wie die Quelle heisst.

Sweepi

2021-10-04, 20:18:03

Also meinst du, dass AMD evtl. in Zukunft bei 6- und 8 Kernern wieder weg vom Chiplet-Design geht, weil die Chips irgendwann wieder so klein werden ? Wobei du sagst, unterhalb von 12-Kernern werden nur noch APUs angeboten. Das könnte man natürlich auch machen, aber die unterscheiden sich nicht nur durch die GPU. Die haben auch weniger PCI-E Lanes usw. usw. Also so einfach ist das nicht, die APUs sind kein Ersatz.

Genau. Das ist aber nur eine wilde Idee von mir:
Im Desktop, Workstation und Server weiterhin Chiplet(s) + IO-Die.
Im Einsteiger Desktop und Notebook monolithisches Design. Anzahl PCIe Lanes könnte dann entweder besser als heute sein oder man sagt als kostensparende Lösung: Bleibt gleich, ist in dem Marktsegment nicht so wichtig.

Wie gesagt: Wilde Idee, keine Prognose.

HOT

2021-10-04, 21:50:05

[...]

Ja es ging ja eig. nur um die grossen Kerne. Und ausserdem ist es nicht sicher, ob die kleinen Kerne nicht ein eigenes Chiplet bekommen.

Was hat das denn für einen Sinn :freak:.
Das sieht aus wie bei den Intels, die Kerne hängen am Ringbus, genau wie bei Zen3, nur dass es 2 Stops mehr gibt für 2x2 Zen4D eben. Einfacher kann man das wohl kaum machen.
Zen4 ist aber nicht .mont, die sind ja mit SMT, du hast also mit 4 Zen4D 8 Threads für little dann.

Complicated
Sehe ich auch so, dass die APUs auch Chiplets werden. Ob das jetzt darüber gemacht wird oder über einen speziellen Träger wird sich noch zeigen, aber die Zeit der Monolithen ist nach Phoenix dann auch vorbei genau wie die Zeit der Monolithen mit RDNA4 im GFX-Bereich Geschichte sein wird.

Zeig uns mal eine Quelle das AMD Zen5 erheblich fetter machen will. :)

Wenn Zen4 die little-Cores sind wird Zen5 wohl fetter werden :freak:

https://www.techspot.com/news/89855-amd-3nm-based-zen-5-processors-appear-leaked.html

Ich spekulier mal, dass das wie folgt aussieht:

Grantie Ridge ist evtl. nicht der Codename für den Zen5-Prozessor, sondern Strix Point. Bisher waren die .ridges immer die CCDs, das wird hier nicht anders sein.
Man wird nur noch ein oder zwei Zen5+Zen4D-Chiplet und verschiene GFX-Chiplets und Cache-Chiplets stapeln können per CoW, es gibt also keinen Unterschied mehr zwischen APU und CPU ab diesem Zeitpunkt mMn. Die Produkte sind mMn eben voll modular geworden ab Strix Point. Da geht die Reise hin, das ergibt einfach voll Sinn. Man hat keine unnötigen Stromschlucker mehr, man hat es mit sehr kleinen Chiplets in verschiedenen, z.T. recht billigen, Prozessen zu tun usw. Das Packaging spart massiv Kosten und man hat trotz N3 günstige CPUs.

basix

2021-10-04, 23:47:30

Zen 5 wird vermutlich schon grösser als Zen 4 werden, aber Zen 4D wohl auch kleiner als Zen 4 ;)

Das Zeugs ein wenig zurechtstutzen und die Caches/Core reduzieren und man kann einiges an Cores unterbringen (z.B. Zen 4D bei 512kB L2$ / 1MByte L3$ vs. Zen 5 bei 1MB L2$ / 4MByte L3$). Da hat man rein schon bei den Caches mehr als die Hälfte der Fläche pro Core eingespart. Dazu Zen 4 etwas zurückstutzen und Zen 5 wird nochmals etwas grösser und voilà, man bring 2x Zen 4D Cores auf die Fläche von 1x Zen 5 Core.

Ich habe es grob abgeschätzt und je nachdem wie gross die Cores dann effektiv werden, könnten 8+8C in 3nm auf 70...80mm2 passen. Aber eigentlich ist hier Zen 4 das Thema :)

HOT

2021-10-05, 00:30:13

basix

2021-10-05, 07:02:29

Brillus

2021-10-05, 09:42:13

Schlussendlich geht es um reduzierte Fläche bei maximiertem MT Verbrauch.

Ich geh jetzt einfach mal davon aus du meinst Leistung und nicht Verbrauch.

basix

2021-10-05, 10:50:48

Ich geh jetzt einfach mal davon aus du meinst Leistung und nicht Verbrauch.

Leistung, Verbrauch - ich nehm Watt' ich will ;D

(habs gefixed ;))

Ramius

2021-10-05, 11:59:41

Schlussendlich geht es um reduzierte Fläche bei maximierter MT Verbrauch Performance. Ob man da bei Zen4D das ähnlich wie Intels Gracemont macht? Ich weiss nicht. Shared L2$ ist deutlich mehr Design-Aufwand, als einfach die Kapazität zu reduzieren. Und je nachdem wie fett Zen 4 wird macht es schon Sinn, den Kern zu entschlacken. Gracemont ist vermutlich deutlich kompakter.

Zen4D kann neben "Dual" auch "Down(stripped)" oder "Drololol" bedeuten ;)

Solange man sich kein Eigentor schießt wie Intel bei Alderlake ist alles ok. Bei Alderlake können die P-Cores AVX-512 nicht nutzen da Windows nicht damit zurechtkommt, dass unterschiedliche Cores unterschiedliche Befehlssätze haben.

basix

2021-10-05, 13:32:28

Deswegen macht Zen 4 auch Sinn als Little Core, da AVX-512 mit dabei. AMX wäre aber auch noch was. Reduzierte Caches sowie andere Entschlackungen welche die IPC und Taktbarkeit reduzieren sind mMn sinnvoll. Befehlssätze sollten möglichst auf allen Kernen unterstützt werden, zumindest auf Windows. Wie das bei Servern und Linux aussieht, weiss ich nicht.

robbitop

2021-10-05, 16:11:39

Die Leaks sagen alle, dass ADL den AMD in MT 12C schlägt und sich mit dem 16C anlegt. So schlecht kann Gracemont folglich nicht sein.

HOT

2021-10-05, 16:28:31

Die Leistung kommt vornehmlich aus den großen Kernen. Was an Powerbudget übrig ist wandert in die kleinen.

robbitop

2021-10-05, 17:17:43

8 große Kerne reißen es allein nicht heraus, wenn man gegen 16 andere große antreten muss. ;)
Gracemont muss eine gewisse Leistung haben. Ich finde es albern, das abzustreiten. Intel hat das Performanceziel in den Folien dargestellt. Skylake IPC. Das ist nicht besonders klein im klassischen Sinn.

][immy

2021-10-05, 17:20:31

Die Leaks sagen alle, dass ADL den AMD in MT 12C schlägt und sich mit dem 16C anlegt. So schlecht kann Gracemont folglich nicht sein.
basierten diese leaks nicht auf Geekbench?
Abgesehen davon, optimiert intel seine CPUs jetzt schon seit einigen Jahren für Boost-Taktraten die Benchmarks überstehen, aber dabei absurd hohe Verbrauchswerte haben.
Daher wäre ich bei solchen Leaks erst mal vorsichtig.

Gipsel

2021-10-05, 17:26:00

Cinebench gab es auch noch. Und selbst wenn man ein paar Prozent abzieht (250W vs. 125W), kommt man doch schon nahe an den Zen3-16Kerner ran.
In anderen Anwendungen mag es anders aussehen, die Reviews werden es zeigen.
Auf jeden Fall hat AMD wohl einen ordentliche ST-Steigerung hinzulegen, um in diesem Bereich mit Zen4 wieder zu Alderlake aufzuschließen (oder gar vorbeizuziehen?).

ryan

2021-10-05, 17:30:49

[immy;12811386']basierten diese leaks nicht auf Geekbench?

Die basierten auf Cinebench R20 und R23.

robbitop

2021-10-05, 19:01:59

[immy;12811386']basierten diese leaks nicht auf Geekbench?
Abgesehen davon, optimiert intel seine CPUs jetzt schon seit einigen Jahren für Boost-Taktraten die Benchmarks überstehen, aber dabei absurd hohe Verbrauchswerte haben.
Daher wäre ich bei solchen Leaks erst mal vorsichtig.

Auch auf AoTS und Cinebench.

vinacis_vivids

2021-10-05, 19:17:01

https://abload.de/thumb/5800xgeekbench4lkr3.png (https://abload.de/image.php?img=5800xgeekbench4lkr3.png)

https://abload.de/thumb/geekbenck12700eik5l.jpg (https://abload.de/image.php?img=geekbenck12700eik5l.jpg)

Ergebnisse:

5800X: SC: 1759 MC: 10880

12700: SC: 1763 MC: 11895

Bei SC schließt Adler-Lake zu Zen3 auf und beim Multicore verbraucht Adlerlake vllt. > 200W währen Zen3 sich mit 105W zufrieden gibt.

Bei CineBench R20 MultiCore liegt Alder-Lake hinten:

5950X: 12.302 Pkt.
12900K: 11.632 Pkt.

https://www.allround-pc.com/news/2021/intel-alder-lake-core-12000-cpus-zeigen-leistung-in-benchmark
https://abload.de/thumb/5950xcinebenchr206ljar.png (https://abload.de/image.php?img=5950xcinebenchr206ljar.png)

Zossel

2021-10-05, 20:01:37

Befehlssätze sollten möglichst auf allen Kernen unterstützt werden, zumindest auf Windows. Wie das bei Servern und Linux aussieht, weiss ich nicht.

Ohh, es gibt keine Server mehr auf denen Windows läuft?

Allerdings schrieb ich bereits das unterschiedliche Featuresets nicht unbedingt ein Problem sein müssen. Im letzten Jahrtausend konnte man auch schon Software mit FPU-Befehlen fahren obwohl der Sockel für die FPU leer war.

Und Windows ist da schon lange kein Maßstab mehr.

WedgeAntilles

2021-10-05, 21:40:26

5800X: SC: 1759 MC: 10880

12700: SC: 1763 MC: 11895

Ein Benchmark für AlderLake unter Win 10 ist ziemlich nichtssagend.

Was AL bringt muss man unter Win 11 testen - und dann natürlich in realen Szenarien.

basix

2021-10-05, 21:45:26

Ohh, es gibt keine Server mehr auf denen Windows läuft?

Allerdings schrieb ich bereits das unterschiedliche Featuresets nicht unbedingt ein Problem sein müssen. Im letzten Jahrtausend konnte man auch schon Software mit FPU-Befehlen fahren obwohl der Sockel für die FPU leer war.

Und Windows ist da schon lange kein Maßstab mehr.

Wenn das geht, passt doch. Bei Alderlake geht es aber anscheinend nicht. Und Intel ist jetzt nicht eine kleine Bude, auch was SW betrifft. Microsoft ebenfalls nicht.

][immy

2021-10-06, 15:21:26

Ein Benchmark für AlderLake unter Win 10 ist ziemlich nichtssagend.

Was AL bringt muss man unter Win 11 testen - und dann natürlich in realen Szenarien.
Du kannst davon ausgehen, das wenn da schon Tests leaken, diese unter Optimalen Voraussetzungen getestet werden.
Wenn ich mich recht dran entsinne, gab es auch für Bulldozer damals sehr positive Leaks im voraus (und natürlich große Worte von AMD). Und bei Datenbank-Anwendungen war Bulldozer tatsächlich gar nicht mal so schlecht. Hat letztlich nur bei allem anderen nicht wirklich geholfen.

Fragt sich natürlich ob sich die kleinen Kernchen nicht wirklich hoch takten lassen und dann in den Aufgaben in denen sie glänzen mit guter Single-Therad Leistung glänzen können. Die Multicore-Ergebnisse sind da ja schon etwas zu gut, wenn man sich die Single-Core Ergebnisse anschaut. Durch die kleineren Kerne dürfte es die 8+8 Kern CPU ansonsten nicht mit einem (in der Single-Thread Leistung unterlegenen) 16 Kerner aufnehmen können. Aber wenn natürlich der Benchmark auch auf den kleinen Kernen voll Umfänglich läuft und mit hohen Taktraten, sollte das sicher kein Problem darstellen.

Aber eigentlich geht es in diesem Thread doch um Zen4.

Zossel

2021-10-06, 19:04:04

Wenn das geht, passt doch. Bei Alderlake geht es aber anscheinend nicht. Und Intel ist jetzt nicht eine kleine Bude, auch was SW betrifft. Microsoft ebenfalls nicht.

Seit wann liefern große Buden zwingend gute Produkte?

basix

2021-10-06, 20:46:18

Hat niemand behauptet. Nur hätten beide das Geld und die Manpower, wenn sie den dazu gewillt wären. Oder: Es ist mit dem technischen Unterbau von Windows ohne grösseren Umbau nicht möglich.

Intel ist daran interessiert, viele CPUs abzusetzen. Das geht besser, wenn die CPUs schneller sind. Ergo: Wenn es so einfach wäre, würden sie es umsetzen wollen. Die Ressourcen und das Know How dazu hätten sie.Jetzt haben sie eine fette AVX-512 Einheit im Core und verschwenden damit Siliziumfläche für nix. Wirtschaftlich ein zusätzlicher Nachteil.

Microsoft hätte ebenfalls genug Ressourcen und mit Linux und MacOS zwei Gegner. Dennoch setzen sie es nicht um.

Ergo: Eine Low Hanging Fruit ist es nicht.

Wake

2021-10-12, 17:01:23

yE9PsKWYYXA

Desktop spezifisch sticht heraus:
- AM5 mit PCIe 5.0 bestätigt (4.0 debunked ;) )
- AM5 wird kompatibel mit AM4-Kühler bleiben
- Zen 3 mit 3D V-cache für Anfang 2022 geplant

fondness

2021-10-12, 17:12:52

8 große Kerne reißen es allein nicht heraus, wenn man gegen 16 andere große antreten muss. ;)

Zen3 ist wohl kaum ein großer Kern im Vergleich zu Intel. ;) Im bin gespannt, ob Gracemont überhaupt bedeutend kleiner ist.

basix

2021-10-12, 17:37:35

https://youtu.be/yE9PsKWYYXA

Desktop spezifisch sticht heraus:
- AM5 mit PCIe 5.0 bestätigt (4.0 debunked ;) )
- AM5 wird kompatibel mit AM4-Kühler bleiben
- Zen 3 mit 3D V-cache für Anfang 2022 geplant

Nice :D

Irgendwie hätte mich PCIe 4.0 überrascht wie auch enttäuscht. AM5 wird erst gegen Ende 2022 so richtig Fahrt aufnehmen und wohl mindestens bis Ende 2025 bleiben (3 Jahre).

Unicous

2021-10-12, 18:40:21

Natürlich kann der Sockel PCIe 5.0, alles andere wäre ein massiver Fail seitens AMD. Dass es überhaupt Leute gibt die daran gezweifelt haben.:rolleyes:
Elektrisch hat sich da afaik nicht viel getan, ähnlich wie bei PCIe 3.0 zu 4.0. Das Protokoll ist die wichtigste Komponente, die Pins und Leiterbahnen so zu designen, dass sie die Signalstärke aufrechterhalten, dürfte das geringere Übel darstellen.

Das heißt aber nicht, dass jede CPU bzw. MB PCIe 5.0 beherrscht bzw. beherrschen muss. Das ist offensichtlich eine Kosten-/Nutzen-Abwägung, eine low cost APU braucht bis auf Weiteres kein PCIe 5.0, und selbst bei HighEnd Chips (außerhalb Server und unter Umständen Workstation) ist der Nutzen bislang nicht erkennbar. PCI-SIG haut die Spezifikationen raus wie warme Semmeln, dabei steckt die Industrie noch im letzten Jahrzehnt, buchstäblich, die finale Spec von PCIe 4.0 wurde erst 2017 veröffentlicht. 5.0 schon zwei Jahre später, 6.0 ist auch schon so gut wie final. Davor ging es deutlich behäbiger zu Werke.

robbitop

2021-10-12, 19:14:44

Zen3 ist wohl kaum ein großer Kern im Vergleich zu Intel. ;) Im bin gespannt, ob Gracemont überhaupt bedeutend kleiner ist.
Abwarten. Verglichen mit SKL ist Gracemont 4x kleiner bei gleicher IPC und verbraucht ein Bruchteil.
Ich würde vermuten, Zen liegt irgendwo zwischen dem was Intel in 2021 als groß und klein ansetzt. Natürlich ist das Ganze ein "moving target".

basix

2021-10-12, 19:28:49

Elektrisch hat sich da afaik nicht viel getan, ähnlich wie bei PCIe 3.0 zu 4.0. Das Protokoll ist die wichtigste Komponente, die Pins und Leiterbahnen so zu designen, dass sie die Signalstärke aufrechterhalten, dürfte das geringere Übel darstellen.

:confused:

Soweit ich weiss, hat sich die Datenrate pro Pin bei PCIe 3.0 -> 4.0 -> 5.0 jeweils verdoppelt, also doppelte Taktraten. Da hat sich elektrisch sehr viel getan (deswegen säuft PCIe 4.0 auch mehr und die End-to-End Distanzen sind kürzer). Das ist nicht einfach pipifax "einfach ein Layer mehr aufs MoBo und das klappt dann schon". PCIe 5.0 wird deswegen mit sehr hoher wahrscheinlichkeit auf den ersten PCIe 16x Slot sowie die direkt an die CPU angebundenen NVMe Drives beschränkt sein.

Bei Protokoll hast du recht, das ist afaik gleich seit PCIe 3.0.

Der_Korken

2021-10-12, 19:56:32

Abwarten. Verglichen mit SKL ist Gracemont 4x kleiner bei gleicher IPC und verbraucht ein Bruchteil.

Wenn, dann ist Gracemont 1/4 von Golden Cove, aber nicht von Skylake. Sunny Cove war schon deutlich größer als Skylake, Golden Cove also erst recht.

Unicous

2021-10-12, 20:13:22

@basix

Die Datenrate hat sich erhöht?:eek: Wirklich?:eek:

https://3s81si1s5ygj3mzby34dq6qf-wpengine.netdna-ssl.com/wp-content/uploads/2017/07/pci-express-bandwidths.jpg

Ja, die MBs werden u.U. nochmals komplexer, aber was hat das mit dem Sockel zu tun?:confused:
Der bekommt vermutlich ein paar mehr pins, und das wars. Alles andere ist ein Problem der Chip-Hersteller. Vermutlich muss das Substrat angepasst werden, das PHY sowieso usw.. Der Sockel dürfte hier das geringste Übel darstellen, AM3+ hat auch einen FX-9590 ausgehalten, die pins sind da auch nicht verkokelt.:freak:

Beim pinout von AMDs Serversockel sieht es so aus:

https://www.pcgameshardware.de/screenshots/original/2019/11/AMD-LGA-Sockel-SP3-Pinout-Map-pcgh.jpg

Die violette Farbe steht für die pins die für PCIe genutzt werden:

Bei AM4 sieht es nicht viel anders aus:
https://en.wikichip.org/w/images/f/f8/OPGA-1331_pinmap.svg

AM5 bekommt knapp 30% mehr pins, ich wette PCIe wird da nur einen geringen Teil ausmachen.

edit: Bei AM3 war es noch Hypertransport mit entsprechendem "Umweg" über die Northbridge:
https://en.wikichip.org/w/images/3/39/Socket_AM3_pinmap.svg

basix

2021-10-12, 20:40:45

Mein Punkt: Doppelte Taktraten bei PCIe 5.0 sind kein Zuckerschlecken, von wegen "elektrisch hat sich nicht viel getan". Doch, es hat sich viel getan. Kannst ja mal selber solche HF-Designs machen, da wird um jedes Prozent gekämpft ;)

Und auch der Sockel kann zum Problem werden. AM4 mit seinen Pins hat afaik eine höhere Induktivität, was nicht so dolle ist. Das ist bei AM5 (afaik mit LGA) besser.

Unicous

2021-10-12, 21:19:04

Mein Punkt: Der Sockel ist hier nicht das (größte) Problem.:freak:

Du nimmst AM4 als Beispiel um dann zu sagen, bei AM5 wird das Problem mitigiert?:freak: Ich bitte um einen Artikel/Quelle zu den angeblichen Vorteilen bei der Induktivität (kann es sein, dass du gerade LGA mit BGA verwechselst?).:smile:

AMD setzt offensichtlich auf LGA weil sie mehr pins unterbringen können und der Flächenbedarf mit PGA sonst weiter explodieren würde. AM4 ist jetzt schon deutlich größer als LGA 1151/1200, auch wenn es ein paar mehr pins (1331) sind. LGA 1700 wird wohl "nur" ein paar Millimeter länger, bei ca 40% pins. AM5 mit 1718 soll das 40x40mm Package beibehalten können, das ist eine ordentliche Leistung, denn afaik wäre das sogar geringfügig kleiner als das Intel Package.

HOT

2021-10-12, 22:13:58

Ich nehme an, dass PCIe4-Gerücht ist schlicht missinterpretiert worden, da ja Rembrandt defintiv ohne PCIe5 kommt. Das muss aber nicht für Raphael gelten.

Lehdro

2021-10-12, 22:47:18

Ich fand viel krasser dass aus einem einzelnen Tweet PCIe 4.0 bei Zen 4 als unumstößlich dargestellt wurde. Gerade im Hinblick auf Zen 2 und AMDs Plattformpolitik (Je erste GPU und CPU mit 4.0) sollte doch klar sein, dass man hier immer vorne mitspielen würde. Anders würde das gar keinen Sinn ergeben, da die Verzögerung dann durchaus mal 2 Jahre+ betragen könnte - Zen 5 wäre der nächste mögliche und logische Zeitpunkt. Das wäre dann schon wieder krass spät, so wie Intel mit PCIe 4.0 quasi.

Zudem: AMD hat hier und Not und Tugend, schließlich wird man auch PCIe 5.0 GPUs bauen und damit bewerben wollen. Blöd wenn man dann selber keine Plattform dafür stellen würde...

basix

2021-10-12, 22:57:50

Mein Punkt: Der Sockel ist hier nicht das (größte) Problem.:freak:
Da hast du recht ;) Das MoBo hat mehr Last zu tragen.

Du nimmst AM4 als Beispiel um dann zu sagen, bei AM5 wird das Problem mitigiert?:freak: Ich bitte um einen Artikel/Quelle zu den angeblichen Vorteilen bei der Induktivität (kann es sein, dass du gerade LGA mit BGA verwechselst?).:smile:

Nö, nö. Ich kenne den Unterschied zwischen LGA und BGA ;)
LGA wird z.B. hier explizit als "Low Inductance" angegeben: https://books.google.ch/books?id=1wDTBwAAQBAJ&pg=PA261&lpg=PA261&dq=lga+vs+pga+inductivity&ots=S_rYlL2TY4&sig=ACfU3U3x_2iRNg4xnpVpCjb2mdIi8exn9w&hl=de#v=onepage&q=lga%20vs%20pga%20inductivity&f=false

Habe jetzt aber nicht weiter danach gesucht. Die dicken Pins bei PGA sind naturgemäss für eine höhere Induktivität verantwortlich. Umso steiler die Stromtransienten (was man z.B. bei höheren Taktraten von PCIe 5.0 erhalten wird), desto höher Spannungsspitzen und -einbrüche. Ergo: Schlecht für die Signalqualität. Dies wiederum führt zu kürzeren Leitungsdistanzen oder man muss den PHY-Treiber stärker prügeln. Beides nicht so toll.

(1) u = L*di/dt (siehe auch: https://de.wikipedia.org/wiki/Induktivit%C3%A4t)

di/dt wird durch PCIe 5.0 grösser, da höhere Taktraten. Verringert man gleichzeitig L, kompensiert man den Effekt. Also ja: AM5 mitigiert die Probleme ;)

Was man natürlich auch machen kann: di verringern. Das geschieht vor allem durchs PCB Design (impedanzkontrolliertes Layout (https://www.elektronikpraxis.vogel.de/die-grundlagen-von-impedanzkontrollierten-leiterplatten-a-120074/)). Das liegt aber nicht gerade in meinem täglichen Arbeitsgebiet.

AMD setzt offensichtlich auf LGA weil sie mehr pins unterbringen können und der Flächenbedarf mit PGA sonst weiter explodieren würde. AM4 ist jetzt schon deutlich größer als LGA 1151/1200, auch wenn es ein paar mehr pins (1331) sind. LGA 1700 wird wohl "nur" ein paar Millimeter länger, bei ca 40% pins. AM5 mit 1718 soll das 40x40mm Package beibehalten können, das ist eine ordentliche Leistung, denn afaik wäre das sogar geringfügig kleiner als das Intel Package.
Guter Punkt. Pin Density. Hatte ich nicht auf dem Radar. Daneben interessanterweise tiefere Kosten als PGA. Dafür kompliziertere Sockel-Mechanik, damit die Platzierung der LGA-Pads mit den Sockelkontakten auch übereinstimmt.

HOT

2021-10-12, 23:04:53

[...]
Zudem: AMD hat hier und Not und Tugend, schließlich wird man auch PCIe 5.0 GPUs bauen und damit bewerben wollen. Blöd wenn man dann selber keine Plattform dafür stellen würde...

Das ist allerdings sowas von wahr ;).
Hm, ob die neuen GPUs auch direkt mit dem neuen PCIe5-Stecker kommen? Fänd ich cool :).

davidzo

2021-10-12, 23:26:25

Guter Punkt. Pin Density. Hatte ich nicht auf dem Radar. Daneben interessanterweise tiefere Kosten als PGA. Dafür kompliziertere Sockel-Mechanik, damit die Platzierung der LGA-Pads mit den Sockelkontakten auch übereinstimmt.

Die Platzierung ist weniger das problem. Das übernimmt der schwarze GF-plasikrahmen ganz gut. Das Problem ist eher das loading so dass alle Pins im Sockel guten Kontakt machen ohne dass welche plattgedrückt werden. Leute die versucht haben Threadripper nur über den Kühleranpressdruck auf dem Sockel zu kontaltieren sind damit frustrierend gescheitert (siehe der 8auer). Daher Intels Prinzip des ILM, der an zwei mittig liegenden Punkten gleichemäßigen und definierten Druck auf das Package verteilt.

Die Stanzteile aus V2A und verzinktem Stahlblech (Backplate) sehen vielleicht grob aus, sind allerdings extreme Präzisionsteile. Wenn der Anpressdruck nicht super eben wäre, würde der LGA nicht funktionieren.
Das heißt nicht dass sie sehr teuer sind, Stanzteile, selbst aus V2A wie der Oberteil, sind eher massenware, aber billig sind sie im Vergleich zu einm Kunststoffsockelgehäuse ganz bestimmt auch nicht.

Unicous

2021-10-12, 23:50:20

Piefkee

2021-10-13, 07:53:01

Abwarten. Verglichen mit SKL ist Gracemont 4x kleiner bei gleicher IPC und verbraucht ein Bruchteil.
Ich würde vermuten, Zen liegt irgendwo zwischen dem was Intel in 2021 als groß und klein ansetzt. Natürlich ist das Ganze ein "moving target".

Quelle? Oder ist das noch die alte Intel PR?
Bitte hört mal auf alles so darzustellen wie wenns in Stein gemeiselt ist.

basix

2021-10-13, 09:26:19

@basix

Ein Buch von 2001.:freak:

Come on.:rolleyes:

Du solltest du schon ein wenig mehr graben, als "lga vs pga inductivity" zu googlen.:wink:

PGA -> Pluggable. Seriously.:freak: Higher Cost dürfte übrigens auch bullshit sein, die Kosten nehmen sich nichts mehr afaik (logisch, weil Skaleneffekt, meines Erachtens ist LGA mittlerweile sogar etwas teurer, u.a. wegen dem Schließmechanismus, aber da habe ich jetzt keine Quelle zu).

In 20 Jahren ist viel passiert. Sockel A hatte im Jahr 2000 462 pins, 2016/17 sind wir bei 1331 angekommen. Die pins sind mittlerweile auch dünner geworden btw.:wink: (Von 1,27mm bei AM3+ auf 1mm bei AM4). Man könnte theoretisch(!) den pitch noch weiter verringern (z.B. auf 0,8mm), bei einem Consumer-Produkt macht das aber keinen Sinn, die pins würden zu oft brechen und de facto das gesamte Produkt zerstören. Allein deswegen nutzt man im Serverbereich so gut wie ausschließlich LGA. Der Chip ist (meistens) deutlich teurer als das Mainboard. Das Risiko wäre für PGA zu groß (und natürlich braucht man meist eh mehr pins für I/O oder MCM, daher ist LGA dort ideal). Selbst bei BGA stößt man da ja zunehmend an Grenzen und da bewegt man sich ja zum Teil schon unterhalb von 0,5mm.

Es spricht an sich nichts gegen PGA... also außer dem Fakt, dass ein größerer Sockel eine Kaskade an Designänderungen und höhere Kosten hervorruft und man diese einsparen kann. Testament dafür ist allein schon der Fakt, dass die Kühler kompatibel bleiben, was auch keine Selbstverständlichkeit ist.

Ich habe schon etwas mehr investiert, als diese eine Google-Search ;) Das Problem ist, dass man in Sockel-Datenblättern entweder solche Angaben vermisst, oder dass es nicht wirklich vergleichbar ist. Es sollte schon ein Sockel mit ähnlichem Anwendungszweck sein (LGA & PGA gibt es nicht nur für CPUs).
Zusätzlich erschwert wird das ganze, dass man die Gesamtimpedanz von Chip+Sockel betrachten müsste. Hier entsprechende Infos zu finden, ist nicht so einfach. Evtl. gibt es was in diesem Gigabyte Leak von AM5 ;)

Induktivität vs. Pins ist einfach Physik. Dünnere Pins helfen da definitiv. AM4 ist aber der letzte PGA-Sockel. Intel nutzt schon seit Ewigkeiten LGA, AMD beim Server auch. Ob hier jeweils nur die Pin Density und Handling-Sicherheit der CPU eine Rolle spielt? Ich weiss es nicht.

Edit:
Induktivität ist ebenfalls schlecht im Power Delivery Pfad, da dies den Vdroop erhöht. Bei Tendenz zu höheren TDPs ist das also auch noch ein Faktor.

robbitop

2021-10-13, 12:15:43

Quelle? Oder ist das noch die alte Intel PR?
Bitte hört mal auf alles so darzustellen wie wenns in Stein gemeiselt ist.

Sorry es war Golden Cove = 4x Gracemont in size. Und das kommt direkt von Intel.

Tobalt

2021-10-31, 19:06:52

Locuza

2021-10-31, 19:22:25

Sorry es war Golden Cove = 4x Gracemont in size. Und das kommt direkt von Intel.
Intel ist da aber nicht so genau ;)
https://abload.de/img/1600-px-gre-compressefukwi.jpg

Man könnte für Golden Cove ohne den 1.25MiB Cache ungefähr 5.3-5.5mm² veranschlagen.
Das wäre dann "nur" 3.24x (5.5 vs. 1.7) soviel im Vergleich zu Gacemont.
Ein Golden Cove mit 1.25MB L2$ und den power-elements(?) ist ungefähr 7.39mm² groß, während ein Gracemont-Cluster mit 2MiB L2$ um die 8.78mm² benötigt, also ~19% mehr Fläche.

Edit:
Habe ein wenig den Kontext verfolgt.
Zen3 ist 3.24mm² groß (+91$ vs. 1.7mm²) , Zen2 2.83mm² (+66% vs. 1.7mm²).
https://i.redd.it/o59e4sz43vy51.png

Die kleinen Gracemont-Kerne machen scheinbar um die 4GHz mit, dass wäre aber ein gutes Stück unter Zen3, der bis zu 5GHz schafft.
Ich glaube Intel das die IPC ähnlich wie bei Skylake ausfällt, bei Integer-Workloads, wie sieht es aber bei FP aus?

PS: Die Mitte von Golden Cove und Gracemont, ohne den L2 Cache, liegt bei ungefähr 3.5-3.6mm², also Zen3 landet da wirklich fast zwischen den Intel-Cores.

basix

2021-11-01, 09:39:35

basix: *dickere* pins haben weniger Induktivität als dünnere. Wird dir jeder online calculator bestätigen. ;-) was aber die Induktivität maßgeblich senkt ist ein kleinerer Pin pitch der sich natürlich nur mit entsprechend dünnen Pins umsetzen lässt..Dadurch können die VDD+GND paare möglichst dicht zusammen und die Induktivität massiv senkt. Bei gleichem Pitch sind aber dicke Pins trotzdem besser ;)

Zweiter wichtiger Punkt: Die Gesamtfläche des Pinarrays sollte möglichst hoch sein.. Mehr Pins für VDD und GND heißt weniger Induktivität.

Ich wollte gerade sagen: Die geringere Induktivität bei breiteren/dickeren oder näher stehenden Leitern was mit dem Querschnitt und dem Abstand gegenüber GND zu tun, was aufgrund des entstehenden Kondensators die effektive Induktivität reduziert.

Aber ja, mit der Induktivität @ dick habe ich anscheinend was verwechselt. Spannungstransienten bei Lastwechseln können aufgrund der geringeren Dämfpung (Widerstand) höher sein. Den selben Effekt hätte prinzipiell auch eine höhere Induktivität. Hatten mal so Fälle, wo sehr lange und dickere Kabel in einem System Probleme mit Spannungsüberhöhungen gemacht haben. Das ist dann mehr so ein Leitungsbelag-Thema.

w0mbat

2021-11-03, 22:49:19

Laut MLID ist Zen4D = Zen4Dense, eine 16C-Chiplet Version mit halben cache für extremes MT:

dE9N95uSqHA

basix

2021-11-04, 01:08:24

Zen 4D hätte ich auch so erwartet: Half-Rate AVX-512, halbierter L2$, reduzierter L3$. Ich hätte einen geviertelten L3$ erwartet (1MB/Core) aber 16*2 MByte macht Sinn: 8*4MByte von Zen 4. Anwendungen, welche mit 32MByte gut laufen sind darüber glücklich und mit gleichbleibenden 32MByte bekommt man noch die V-Cache Option. Je nachdem wie viel man wegstrippt, ist das 16C Zen 4D Chiplet ähnlich gross wie das 8C Zen 4 Chiplet.

Ich finde die hervorgebrachte Idee noch interessant, dass man das 16C Zen 4D Chiplet mit Zen 4 oder später Zen 5 kombiniert. Da hätten wir die 24C Variante mit zwei Chiplets: 8C Zen 4/5 + 16C Zen 4D. Bei Zen 5 hätte man ausserdem die Option auf Dual-Sourcing bezüglich 5nm und 3nm. Das Threading und Scheduling wird aufgrund der gesplitteten Chiplets dann aber interessant (ausser AMD spendiert eine LSI-Bridge zwischen den Chiplets).

In dem Sinne: Die Überlegungen und Infos von MLID machen Sinn und scheinen stimmig zu sein.

][immy

2021-11-04, 01:22:16

@basix

Die Datenrate hat sich erhöht?:eek: Wirklich?:eek:

https://3s81si1s5ygj3mzby34dq6qf-wpengine.netdna-ssl.com/wp-content/uploads/2017/07/pci-express-bandwidths.jpg
...

Bei PCIe 5.0 fragt man sich ja schon fast, was die ganze Bandbreite bringen soll, wenn man nicht grad aus den Caches der CPU liest. Denn DDR4 ist da auf jeden Fall im Dual-Channel System nicht. Und DDR5 wird wohl auch noch eine Weile nicht dran kommen (in normalen Systemen).
Einzig die Zugriffszeiten könnten sinken, dadurch das die Daten einfach in kürzerer Zeit geschickt werden können. Für die Zukunft sicher interessant, aber rein technisch aktuell wohl noch etwas zu früh um dadurch wirklich was zu reißen (außer die Mainboard-Kosten zu erhöhen).
Im Speicherbereich gab es ja schon lange keine "verdopplung" der Bandbreite mehr, hier hat PCIe einfach mal den Speicher eingeholt. Nun könnte man sich sicher fragen, warum man diese Transferraten über den relativ langen PCIe Bus hin bekommt (der ja auch noch verlängert werden kann) aber nicht über die relativ kurzen Speicherwege.

iamthebear

2021-11-04, 01:58:44

Man sollte bei der Überlegung bedenken, dass AMD ja auch von 7nm auf 5nm shrinked.
Falls die Compute Dies gleich groß bleiben würde das Daumen mal Pi bedeuten, dass Zen 4D in etwa die Größe eines Zen3 Cores hat.

Mit Zen5 sollen ja laut Leaks schon 50% IPC Unterschied zu Zen3 liegen. Ein ähnliches Verhältnis hat ja Intel mit Alder Lake auch.
So wie es aussieht macht AMD grob dasselbe wie Intel nur halt bei den Kernen eine Stufe größer.

Zossel

2021-11-04, 09:35:54

[immy;12837045']Bei PCIe 5.0 fragt man sich ja schon fast, was die ganze Bandbreite bringen soll, wenn man nicht grad aus den Caches der CPU liest. Denn DDR4 ist da auf jeden Fall im Dual-Channel System nicht. Und DDR5 wird wohl auch noch eine Weile nicht dran kommen (in normalen Systemen).

PCIe-DMA ist IMHO nicht zwingend kohärent.

OgrEGT

2021-11-06, 11:38:16

Weiß nicht mehr wo die Frage auzfkam ob Zen4 PCIe 5.0 unterstützen wird.
Im Interview mit Robert Hallock hat dieser gesagt, dass die AM5 Plattform PCIe 5.0 unterstützen wird. Für welche CPUs die dann dort Platz nehmen das gelten wird... who knows... man kann es mMn nicht komplett für Raphael ausschließen.

https://videocardz.com/newz/amd-confirms-3d-v-cache-zen3-cpus-are-coming-early-next-year-zen4-later-in-2022

HOT

2021-11-06, 13:26:28

Das ist nur so vorsichtig formuliert, weil Rembrandt kein PCIe5 hat. Bei Raphael sollte das relativ klar sein.

reaperrr

2021-11-07, 13:40:54

Man sollte bei der Überlegung bedenken, dass AMD ja auch von 7nm auf 5nm shrinked.
Falls die Compute Dies gleich groß bleiben würde das Daumen mal Pi bedeuten, dass Zen 4D in etwa die Größe eines Zen3 Cores hat.

Du meinst, gleiche Größe wenn sie im gleichen Prozess hergestellt würden? Kann schon sein.

Allerdings, 5nm hat nicht mal ansatzweise die doppelte Packdichte von 7nm.
SRAM (Cache) lässt sich nur ca. 30% dichter packen, Analoges (dazu sollten die IF-Interfaces der Chiplets zählen) nur um ca. 20%.
Nur die reinen Logiktransistoren lassen sich bis zu 84% dichter packen, aber auch das ist keine Verdoppelung und wird aus Gründen der Vermeidung von Hotspots etc. sicher auch nicht ganz ausgereizt.

Ich denke deshalb auch, dass das Zen4D-Chiplet bei 16 Kernen trotz 5nm eher größer ausfallen wird als ein Zen3-Chiplet. Tippe so auf rund 100-105mm².

Zossel

2021-11-07, 15:22:41

Laut MLID ist Zen4D = Zen4Dense, eine 16C-Chiplet Version mit halben cache für extremes MT:

Die FP-Register brauchen ja richtig Platz: https://www.youtube.com/watch?v=dE9N95uSqHA&t=582s

Zossel

2021-11-07, 15:29:15

Ich denke deshalb auch, dass das Zen4D-Chiplet bei 16 Kernen trotz 5nm eher größer ausfallen wird als ein Zen3-Chiplet. Tippe so auf rund 100-105mm².

Hängt auch davon ab wie viel Cache das Ding bekommt. Und es wird sicherlich eine Option auf ein aufgeklebtes zusätzliches Cache-Die geben.

amdfanuwe

2021-11-07, 16:51:30

Wenn die zusätzlichen Kosten für die Stacked Technik nicht zu groß sind, könnte da auch L2 Cache "ausgelagert" werden, überhaupt eine komplett andere Cachestrucktur mit größeren L1 und L2. AMD wird da schon ein optimum rausholen.

basix

2021-11-07, 19:14:47

Halbierter L2 und L3 halbiert bereits deren Fläche verglichen mit Zen 4. 16C und dann wieder 32MB L3 machen Sinn, da kann man bei Zen 4D den V-Cache von Zen 4 verwenden. verringert man die Core Fläche auf 2/3 (ausgehend von Zen 4), wird man 16C in etwa 85mm2 unterbringen können.

Der_Korken

2021-11-07, 21:59:06

Die FP-Register brauchen ja richtig Platz: https://www.youtube.com/watch?v=dE9N95uSqHA&t=582s

Das sieht für mich nach keiner guten Entwicklung aus, wenn AMD so viel Chiparea für Register verbrät, von denen die allermeisten Anwendungen nichts haben. Es würde die kolportierten 71mm² für ein 8C-Z4-Chiplet erklären, wo man durch 5nm doch eigentlich eine deutlichere Reduktion der Fläche erwartet hat. Wenn AMD das wirklich beibehalten will, klingt die Idee von Z4D wiederum ganz einleuchtend. Man braucht keine neue Architektur, sondern profitiert von allen Entwicklungen der Hauptreihe und schmeißt im Nachhinein Kram raus, der viel Fläche kostet, aber wenig (für die vorgesehenen Anwendungen) bringt. Klar erreicht man dadurch nicht Faktor 4 wie Golden Cove vs Gracemont, aber dafür recyclet man die eigene Architektur maximal. Für die Desktop-User und Gamer wäre eigentlich ein Zwischenschritt genial: AVX512 raus, dafür die großen Caches behalten :D.

Savay

2021-11-07, 23:00:21

Also die Register braucht es doch auch wenn es "double-pumped" AVX512 für Zen4D wird oder steht ich aufm Schlauch?! ;)

Und da AMD mit dem Konstrukt sicher kein GoldenCove/Gracemont Dilemma haben will bzgl. Befehlssätze, ist das wo man am ehesten sparen kann ggü. dem regulären Zen4 die Caches und die Breite der FPU im Backend.

iamthebear

2021-11-07, 23:55:54

Es sind nur relativ weniger Anwendungen, die wirklich von AVX512 profitieren als dass es Sinn macht nur deswegen das Ganze Design auf den Kopf zu stellen. Die Boostlogik wird auch einfacher, wenn man nicht damit rechnen muss, dass spontan ein Spike mit AVX512 auf allen 32 Threads daher kommt.

Oder anders gefragt:
Welche Applikationen laufen mit 8 Zen4 Cores mit AVX512 wirklich so viel besser als auf 16 Zen4D Cores mit AVX2?

Du meinst, gleiche Größe wenn sie im gleichen Prozess hergestellt würden? Kann schon sein.

Allerdings, 5nm hat nicht mal ansatzweise die doppelte Packdichte von 7nm.
SRAM (Cache) lässt sich nur ca. 30% dichter packen, Analoges (dazu sollten die IF-Interfaces der Chiplets zählen) nur um ca. 20%.
Nur die reinen Logiktransistoren lassen sich bis zu 84% dichter packen, aber auch das ist keine Verdoppelung und wird aus Gründen der Vermeidung von Hotspots etc. sicher auch nicht ganz ausgereizt.

Ich denke deshalb auch, dass das Zen4D-Chiplet bei 16 Kernen trotz 5nm eher größer ausfallen wird als ein Zen3-Chiplet. Tippe so auf rund 100-105mm².

Also ich habe das einmal grob überschlagen.

Nach den Die Shots geschätzt besteht ein Compute Die aus:
8x4mm² für die Zen3 Cores
32mm² für 32MB L3
16mm² für diversen Rest

TSMC 7nm auf 5nm bedeuet:
1.85x für logic
1.2x für SRAM

Angenommen die Kerne skalieren 1.6x (Großteils Logik mit ein bisschen Cache) und L3 bzw. der Rest skalieren 1.2x

Für 16 Zen3 Kerne + 32MB L3 würde das bedeuten:
16x4mm² / 1.6 = 40mm²
32mm² / 1.2 = 27mm²
16mm² / 1.2 = 13mm²

Damit wären wir grob wieder bei 80mm²

Für die Verlustleistung gibt TSMC -30% an:
16 / 8 * (1-0.3) = 1.4 also ziehen die 16 Zen4D Kerne 40% mehr als Energie als 8x Zen3

Wenn man jetzt den Takt um 10% reduziert wäre man schon wieder bei.

Für die Versionen mit 2 Compute Dies hat AMD ja nun die TDP des Sockels auf 170W erhöht.

Wenn dann noch einige Optimierungen für kompaktere Chips dazu kommen, bzw. man ja auch den Vorteil von DDR5 mitnimmt könnte ein Zen4D 6800X gut mit einem 5950X mithalten nur zu deutlich besserem Preis.

Für Zen4 könnte AMD einfach die doppelte Anzahl Transistoren verwenden bzw. könnte 50% mehr Energie gegenüber einen geshrinkten Zen3 verwenden und wäre mit 8x5mm² immer noch bei der selben Compute Die Größe. Damit lässt sich sicher einiges rausholen.
Beim L3 ist es denke ich nicht sinnvoll, wenn AMD hier über 32MB geht. Wenn man mehr braucht, so ist es sinnvoller 64MB VCache oben drauf zu packen. Den VCache kann man in 7nm günstig fertigen und bekommt auf selber Fläche den doppelten Speicher raus (wie auch immer das funktioniert).

Ramius

2021-11-08, 00:01:25

Die FP-Register brauchen ja richtig Platz: https://www.youtube.com/watch?v=dE9N95uSqHA&t=582s

Nein brauchen sie nicht. Das ist nur mal wieder saublöd dargestellt. Die aktuellen Register in Zen3 brauchen 0.22mm² mit 256 Bit. Also brauchen die 512 Bit großen Register den doppelten Platz = 0.44mm². Dann runden wir das ganze noch auf und so werden es 0.5mm² pro Core. Dann multiplizieren wir das noch mit 8 wegen den 8 Cores je Chiplet und sind bei 4 mm² pro Chiplet. Und ups das ist ja mehr Platz wie ein Zen3 Core benötigt.

Der_Korken

2021-11-08, 08:08:07

Also die Register braucht es doch auch wenn es "double-pumped" AVX512 für Zen4D wird oder steht ich aufm Schlauch?! ;)

Nicht unbedingt. AVX2 hat 16 logische Register mit je 256Bit und AVX512 hat 32 logische Register mit je 512Bit (https://de.wikipedia.org/wiki/Advanced_Vector_Extensions). Soweit so gut. Zen 3 hat aber 160 physische FP-Register mit je 256Bit, die dann für die out-of-order execution entsprechend umbenannt werden. Da wäre also bereits jetzt genug Platz drin, um AVX512 abzubilden und nur aus Kompatiblitätsgründen zu unterstützen. Ein paar mehr FP-Register machen für Zen 4 wahrscheinlich eh Sinn, wenn man das Design verbreitert, aber sie gleich zu vervierfachen für ein paar Nischeninstruktionen, kommt mir total überzogen vor. Dann lieber mehr Kerne oder einfach eine dritte 256bit-FPU, die auch ohne AVX512 Vorteile bietet.

HOT

2021-11-08, 08:37:40

Irgerndwie glaube ich nicht, dass das Ding 8+8 hat, der wird 8+4 haben.

basix

2021-11-08, 08:59:37

Nicht unbedingt. AVX2 hat 16 logische Register mit je 256Bit und AVX512 hat 32 logische Register mit je 512Bit (https://de.wikipedia.org/wiki/Advanced_Vector_Extensions). Soweit so gut. Zen 3 hat aber 160 physische FP-Register mit je 256Bit, die dann für die out-of-order execution entsprechend umbenannt werden. Da wäre also bereits jetzt genug Platz drin, um AVX512 abzubilden und nur aus Kompatiblitätsgründen zu unterstützen. Ein paar mehr FP-Register machen für Zen 4 wahrscheinlich eh Sinn, wenn man das Design verbreitert, aber sie gleich zu vervierfachen für ein paar Nischeninstruktionen, kommt mir total überzogen vor. Dann lieber mehr Kerne oder einfach eine dritte 256bit-FPU, die auch ohne AVX512 Vorteile bietet.

Ich habe mir auch überlegt, ob es nicht sinnvoller wäre, mehr AVX2 Einheiten zu verbauen und dafür nur AXV512 @ Half-Rate. Damit hätte man deutlich mehr Anwendungsfälle mit einem Benefit und die Nischenanwendungen wären mit minimalem Area-Penalty dennoch sehr performant. Nimmt man den Taktnachteil bei Intels AVX512 mit dazu, sind 2x AVX512@Full-Rate vs. 3x AVX512@Half-Rate wohl nur in sehr wenigen Szenarien wirklich relevant schneller. Somit wäre AVX512 nur geringfügig langsamer, dafür AVX2 viel schneller. Unter dem Strich wäre das mMn ein Win-Win.

32 * 2 * 512bit ergibt 128x 256bit Register. Bei 3x AVX512 fähigen FP-Units wären es also 192x 256bit Register. Man müsste von 160 wohl auf ~240 FP-Register hoch, was aber durch die dritte AVX2-Einheit eh sinnvoll wäre.

Diese Steigerung/Verbreiterung der FP-Einheiten erwarte ich aber irgendwie erst bei Zen 5.

Edit:
Ich habe mal grob überschlagen, wie viel grösser der Zen 4 Core gegenüber Zen 3 sein kann. Ich bin auf +20...30% gekommen. Da liegt eine dritte AVX2-Einheit eher nicht drin.
- 5nm vs. 7nm
- 72 vs. 81mm2
- 1MB vs. 512kB L2$
- 32MB vs. 32MB L3$

w0mbat

2021-11-08, 10:31:32

Nach den Die Shots geschätzt besteht ein Compute Die aus:
8x4mm² für die Zen3 Cores
32mm² für 32MB L3
16mm² für diversen Rest

TSMC 7nm auf 5nm bedeuet:
1.85x für logic
1.2x für SRAM

Angenommen die Kerne skalieren 1.6x (Großteils Logik mit ein bisschen Cache) und L3 bzw. der Rest skalieren 1.2x

Für 16 Zen3 Kerne + 32MB L3 würde das bedeuten:
16x4mm² / 1.6 = 40mm²
32mm² / 1.2 = 27mm²
16mm² / 1.2 = 13mm²

Damit wären wir grob wieder bei 80mm²

Und genau aus diesem Grund macht stacked cache so viel Sinn. Der cache nimmt ja nur so viel Platz ein, weil die verwendeten libraries auf Logik optimiert sind. Wenn man den cache separat, mit auf cache optimierten libraries herstellt, kann man fast 50% der Fläche einsparen.

Stell dir mal Zen3 mit nur 8MB on-die L3 vor, und dann 2x 16MB silces on top. Man hätte insg. 40MB L3, also mehr als jetzt, und würde sehr viel die Fläche sparen. Die Frage ist halt, wie teuer ist das packaging ist.

Zen4D macht vor allem Sinn, wenn man mit 3D V-Cache plant. Bzw. macht das insg. bei allen zukünftigen designs Sinn, egal ob "dense" oder nicht.

Der_Korken

2021-11-08, 11:17:18

Die 50% Einsparung sind imho nicht ganz richtig, weil sich auf dem Base-Die bereits die Logik für den gesamte L3 befindet. Würde man also alle L3-Zellen auslagern wollen, würde trotzdem noch ein guter Rest auf dem Base-Die verbleiben. Trotzdem ist die Feststellung richtig dass man zur Minimierung der Waferfläche eigentlich immer stacken will. Wenn Logik auf 5nm nochmal 20-30% gegenüber SRAM rausholt, werden die eingesparten Kosten nochmals höher.

w0mbat

2021-11-08, 11:24:52

Deswegen habe ich auch "fast 50%" geschrieben, zudem ist in meinem Bsp. ja noch L3 cache auf dem base die. Je kleiner die Strukturbreite, desto höher der Flächenanteil vom cache, außer man lagert eben aus.

Für mich ganz klar die Zukunft, Apple wird das auch nicht ungenutzt lassen.

basix

2021-11-08, 14:37:16

Hans de Vries hat für Zen 5 bereits sowas mit Stacking beschrieben. Zusätzlicher Vorteil: 16C anstatt 8C pro CCD ;) Ziemlich genau so, wie ich es mir auch vorgestellt hätte (einfach ohne PCIe 6.0, das wird eher erst mit Zen 6 oder auch nur EPYC kommen):
https://twitter.com/HansDeVriesNL/status/1454781714958635013

HPVD

2021-11-08, 15:48:31

hatten wir schon, welche AVX512 instructions ZEN 4 unterstützt?
https://twitter.com/HansDeVriesNL/status/1456183755610144769

basix

2021-11-08, 16:28:59

Hier glaube ich noch nicht. Aber ja, Zen 4 liegt auf Ice Lake + Cooper Lake Niveau. Nur Tigerlake / Rocketlake / Sapphire Rapids / Alderlake (ohne E-Cores) unterstützen noch einen Ticken mehr Instruktionen.

Savay

2021-11-08, 16:42:03

Wenn ich den Angaben auf Wikipedia trauen soll, dann unterstützt aber nur ADL und Sapphire Rapids definitiv mehr. (FP16 und VP2INTERSECT)
TGL und RKL fehlt ggü. Zen4 dann allgemein der BF16 Support.
Dafür soll TGL halt noch VP2INTERSECT haben.

Aber...der Support von AVX512 ist mal echt generell ein riesen Clusterfuck. :freak:

HOT

2021-11-08, 19:04:50

https://www.computerbase.de/2021-11/amd-zen-4-in-5-nm-genoa-bringt-96-bergamo-mit-zen-4c-sogar-128-kerne/

Na da ist der ominöse Zen4D ja im Prinzip geklärt, oder? AMD nennt das Ding Zen4c, das c dürfte für compact stehen, kann schon sein, dass man das Ding Zen4D in der Entwicklung genannt hat. Da ist aber nix mit big.LITTLE, dem hatte AMD ja sowieso ne Absage erteilt. Das waren stets Vermutungen von denjenigen, die frühzeitig davon gehört hatten.
Ich denke, das es wird also 2 Packages geben, Genoa mit 12 8C-Compute-Dies und Begamo mit 8 16C-Compute-Dies, alles N5. Alles in N3 dürfte Zen5 sein und fertig.

w0mbat

2021-11-08, 19:23:05

"C" steht für "Cloud" :ugly:

Ramius

2021-11-08, 19:45:32

Sehe ich genauso. Zen4D = Zen4c (mit abgeschalteten Cloud-Funktionen). Das wird in beiden Fällen das gleiche Chiplet sein.

konkretor

2021-11-08, 19:56:46

https://www.heise.de/news/AMD-Genoa-und-Bergamo-Zen-4-Prozessoren-mit-bis-zu-128-CPU-Kernen-6260667.html

Zen4c soll wohl ohne SMT sein

basix

2021-11-08, 20:09:28

https://www.heise.de/news/AMD-Genoa-und-Bergamo-Zen-4-Prozessoren-mit-bis-zu-128-CPU-Kernen-6260667.html

Zen4c soll wohl ohne SMT sein

Heise schiesst sich dort selbst ab:
Zu Bergamo verriet AMD noch nicht viel, außer die 128 Zen-4c-Kerne, die "softwarekompatibel mit Zen 4 sind" und eine "maximale Thread-Dichte" für Cloud-Rechenzentren bieten sollen. Laut vorangegangenen Gerüchten entschlackt AMD bei Zen 4c die Pipeline und verzichtet auf SMT, um im Gegenzug mehr Kerne in einem Chiplet unterzubringen.

Maximale Thread-Dichte, aber SMT deaktivieren? :freak:

konkretor

2021-11-08, 20:17:34

Aus Security sicht kann das schon Sinn machen auf SMT zu verzichten

Unicous

2021-11-08, 20:17:51

Diese Aussage basiert aber auf diesem Artikel:

Als Alder-Lake-Konter hat AMD bekanntlich seinen Ryzen mit Stapel-Cache in Stellung gebracht. Mit einem viel größeren Kaliber zielt AMD dann Ende 2022 auf Server: Dann soll nämlich nicht nur der Zen-4-Epyc 7004 „Genoa“ mit 96 Kernen kommen, sondern angeblich auch der 128-Kerner „Bergamo“. Um die Leistungsaufnahme im Zaum zu halten, verzichtet Bergamo möglicherweise auf Simultaneous Multithreading (SMT). Das verspricht auch Vorteile bei der Sicherheit von Cloudservern, weil dann jede Instanz einen oder mehrere physische Kerne exklusiv nutzt. Bei SMT teilen sich zwei oder mehr Threads die Ressourcen eines CPU-Kerns, also Rechenwerke, Register und Caches, was sich für manche Seitenkanalangriffe ausnutzen lässt. Mit diesem Argument verzichtet beispielsweise ARM bei seinen „Neoverse“-Rechenkernen für Server bisher auf SMT. Und solche ARM-SoCs für Cloudserver dürfte AMD mit dem Bergamo ins Visier nehmen: Möglichst viele Kerne pro Server senken Kosten und Energiebedarf in den riesigen Hyperscale-Rechenzentren von Amazon, Microsoft, Google & Co.

Leider kann man hier nicht mehr zwischen verwursteten Online-Gerüchten und echtem Hintergrundwissen unterscheiden, wie es bei Prozessorgeflüster zum goßen Teil noch der Fall war. Wäre aber lustig, wenn MLID von SMT2 spricht und am Ende SMT komplett entfällt.:freak:

basix

2021-11-08, 20:23:56

AMD spricht hochoffiziell von Leadership Socket-Performance und Thread-Density. Hier SMT zu deaktivieren macht als Schlussfolgerung einfach keinen Sinn, Genoa hätte dann ja mehr Threads. Bei Bedarf können Kunden ja immer noch in Eigenregie SMT deaktivieren, das schliesst sich ja nicht aus.

Edit:
Zen 4c wird vermutlich den L2$/Core sowie L3$/Core halbieren. Damit gewinnt man bereits einiges an Fläche, ohne extrem viel Performance zu verlieren. Mittels Bergamo@V-Cache könnte man den L3$ dann wieder bei Bedarf steigern. Evtl. sogar mit 2x Stacks pro Chiplet, ergäbe dann 10MB/Core L3$, was nicht weit weg von Milan-X mit 12MB/Core liegt.

amdfanuwe

2021-11-08, 21:11:21

basix

2021-11-08, 21:21:47

Spontan dachte ich bei Genua an herkömmliches Design mit 12 x 8Core Chiplets mit und ohne V-Cache.
Bei Bergamo dachte ich eher an 8 x 16Core Chiplets nur mit V-Cache da kein L3 Cache mehr auf dem Compute Chiplet.

8x 16C stimmt vermutlich auch. Nur noch V-Cache ist ein interessanter Ansatz. Ich glaube aber, dass noch L3$ verbaut ist. 2MB/Core L3$ wären immer noch recht viel. V-Cache macht den Basisaufbau einfach komplexer und teurer. Das wird nicht jeder Kunde bezahlen wollen.

Aber ja, "density optimized cache hierarchy" kann vieles bedeuten.

Nightspider

2021-11-08, 21:27:27

Hätte bei Bergamo jetzt auch eher 8*16 Cores mit halbiertem oder noch weniger L3 gerechnet + V-Cache.

Das Ding wird eh teuer. Wieso sollte es nicht nur V-Cache Varianten geben?

Wenn der bisherige V-Cache Ansatz weiter verfolgt wird und Bergamo im Compute Chip gar kein L3 hätte, dann würde auch nur 33% des L3-Caches der L3-Genoa Monster fehlen. Dafür aber +33% mehr Kerne.

Und wenn AMD es auf die Spitze treibt stapelt man 2 Cache-Lagen hat hat pro Kern sogar mehr L3 bei Bergamo als bei Milan-X und Genoa.

Im Prinzip diversifiziert AMD sein Portfolio um vers. Gruppen gezielter anzusprechen, je nach Bedarf.

Damit baut AMD im HPC Segment seinen Vorsprung weiter aus.

basix

2021-11-08, 21:30:52

Man konkurriert ja mit z.B. 128 Core ARM Chips von Ampere. Nicht jeder Service oder Workload benötigt so viel Cache. Ich sehe V-Cache eher als Option denn als Standard-Lösung. Mit V-Cache: Aus Genoa wird Genoa-X und aus Bergamo wird Bergamo-X

HOT

2021-11-08, 21:47:44

Hm, vielleicht hat das Ding auch einen virtuellen Cache, also nur große L2, die miteinander verbunden sind, aber keine L3. Macht IBM nicht auch sowas? AMD spricht ja von optimierter Cache-Hierarchie.

Nightspider

2021-11-08, 22:35:22

Mal was anderes:

Was meint ihr, verleitet AMD dazu beim angekündigten 5nm HPC Prozess +25% Leistung zu schreiben?

https://pics.computerbase.de/1/0/1/2/1/1-2eb94c74a1fd3009/7-1080.62ac3933.jpg

Bisher blieb bei so einer Angabe meist kaum ein realer Zuwachs bei der realen Taktrate übrig.

Mit IPC hat es ja auch nichts zu tun. Real hätte ich jetzt eher 5-10% mehr Takt bei Zen4 erwartet. Die genannten über 25% bei 5nm HPC (es wird wohl der TSMC N5HPC gemeint sein) finde ich irritierend.

Und wo kommen die 2x Effizienz auf einmal her? Bisher hieß es eher 30-40% durch den neuen Fertigungsprozess. Da kann AMD ja nur die IPC und weitere Architekturverbesserungen irgendwie mit verrechnet haben.

HOT

2021-11-08, 22:56:18

AMD vergleicht ja einen angepassten N7 HPC mit einem angepassten N5 HPC. Effizienz kann man ja an irgendnem Sweetspot abgreifen, das heißt nicht viel.

iamthebear

2021-11-08, 23:56:04

Ich habe mal grob überschlagen, wie viel grösser der Zen 4 Core gegenüber Zen 3 sein kann. Ich bin auf +20...30% gekommen. Da liegt eine dritte AVX2-Einheit eher nicht drin.
- 5nm vs. 7nm
- 72 vs. 81mm2
- 1MB vs. 512kB L2$
- 32MB vs. 32MB L3$

Gelten die 72mm² denn auch für die Desktop Compute Dies? Was ich mich erinnern kann war das doch für die Server CPUs.

Wenn es tatsächlich nur 72mm² sind:
13mm² statt 16mm² Rest (1.2x)
27mm² statt 32mm² L3
Bleiben weiterhin 8x4mm² für die Zen4 Kerne
Wenn die Kerne 1.6x skalieren (da ja hauptsächlich Logic) dann hätte AMD immerhin 60% mehr Transistoren zur Verfügung. Damit hören sich 20% IPC nicht so unrealistisch an.

Hans de Vries hat für Zen 5 bereits sowas mit Stacking beschrieben. Zusätzlicher Vorteil: 16C anstatt 8C pro CCD ;) Ziemlich genau so, wie ich es mir auch vorgestellt hätte (einfach ohne PCIe 6.0, das wird eher erst mit Zen 6 oder auch nur EPYC kommen):
https://twitter.com/HansDeVriesNL/status/1454781714958635013

Die Frage ist nur ob sich das dann noch kühlen lässt. Selbst wenn der L3 jetzt nicht der große Stromfresser aber es sind doppelt so viele Kerne auf einem Chip.

Aus Security sicht kann das schon Sinn machen auf SMT zu verzichten

Also ich bin da auch sehr skeptisch ob SMT auf Cloud Servern so eine gute Idee ist zumindest wenn Kunden freien Zugang zu den virtuellen Maschinen haben. Selbst wenn einmal die groben Löcher gestopft sind werden sich 2 Threads auf einem Kern immer irgendwie beieinflussen.
Abgesehen davon wird es schwierig ein bestimmtes Performancelevel zu garantieren, da niemand weiß ob die Aufteilung der 2 Threads wirklich 50/50 ist.

Ich denke das wird früher oder später schief gehen es sei denn der Hypervisor kann garantieren, dass 2 SMT Threads nur von derselben virtuellen Maschine verwendet werden.

Leider kann man hier nicht mehr zwischen verwursteten Online-Gerüchten und echtem Hintergrundwissen unterscheiden, wie es bei Prozessorgeflüster zum goßen Teil noch der Fall war. Wäre aber lustig, wenn MLID von SMT2 spricht und am Ende SMT komplett entfällt.:freak:

Was ist denn mit SMT2 gemeint? Ich dachte immer SMT2 währe das gewöhnliche SMT mit 2 Threads pro Kern?

Zen 4c wird vermutlich den L2$/Core sowie L3$/Core halbieren. Damit gewinnt man bereits einiges an Fläche, ohne extrem viel Performance zu verlieren. Mittels Bergamo@V-Cache könnte man den L3$ dann wieder bei Bedarf steigern. Evtl. sogar mit 2x Stacks pro Chiplet, ergäbe dann 10MB/Core L3$, was nicht weit weg von Milan-X mit 12MB/Core liegt.

Halber L2/L3 pro Kern bedeutet, dass die Gesamtmenge an L2/3 pro Compute Die gleich bleibt wenn die Anzahl an Kernen verdoppelt wird. Da müssten die Kerne doch etwas abgespeckt werden.

Und wo kommen die 2x Effizienz auf einmal her? Bisher hieß es eher 30-40% durch den neuen Fertigungsprozess. Da kann AMD ja nur die IPC und weitere Architekturverbesserungen irgendwie mit verrechnet haben.

Ich bin bei so Angaben zur Energieeffizienz immer etwas vorsichtig. Hier lässt sich die Wahrheit oft ziemlich biegen wenn man den Bezugspunkt richtig wählt. Angenommen TSMC 5nm würde 200MHz mehr Takt liefern und man misst bei 5.2GHz wo man Zen3 schon mit übermäßig viel Spannung grillen müsste weit über dem was sinnvoll ist.

Brillus

2021-11-09, 00:15:46

Also ich bin da auch sehr skeptisch ob SMT auf Cloud Servern so eine gute Idee ist zumindest wenn Kunden freien Zugang zu den virtuellen Maschinen haben. Selbst wenn einmal die groben Löcher gestopft sind werden sich 2 Threads auf einem Kern immer irgendwie beieinflussen.
Abgesehen davon wird es schwierig ein bestimmtes Performancelevel zu garantieren, da niemand weiß ob die Aufteilung der 2 Threads wirklich 50/50 ist.

Sehe ich jetzt nicht so das Problem, dieses oder nächstes Linux führt Trusted Threads als Option ein, damit dürfen dann auf einem Kern nur noch Threads laufen die sich gegenseitig vertrauen, d.h. z.b. vom gleichen Kunden sind.

Zossel

2021-11-09, 08:55:51

Same "Zen4" ISA:

https://images.anandtech.com/doci/17055/image_2021_11_08T15_17_57_082Z.png

Zossel

2021-11-09, 08:58:41

robbitop

2021-11-09, 09:39:52

CrazyIvan

2021-11-09, 11:14:54

Gelten die 72mm² denn auch für die Desktop Compute Dies? Was ich mich erinnern kann war das doch für die Server CPUs.

Ist die Frage ernst gemeint? Bislang sind die Compute Dies bei Server und Desktop identisch, also exakt dasselbe Produkt. Das ist ja gerade der Gag an der Chiplet Strategie.

maximus_hertus

2021-11-09, 11:53:23

Ein paar Gedanken:

- SMT kostet kaum Transistoren
- es aus der uArch rauszunehmen kostet sicher einiges an Aufwand
- der Core soll ggf auch bei nicht cloud Produkten zum Einsatz kommen - oder auch in der Mischkonfiguration - die Option auf SMT wäre sicherlich gut

Warum nicht einfach anlassen und der Endkunde kann per UEFI selbst entscheiden ob er es an oder ausschaltet. Je nach Bedarf.

Evtl. ist SMT physisch vorhanend, aber bei Zen4C schlicht von HAsue aus (duerhaft) deaktiviert.

Bei Zen 5 (Big/Little)
kommen dann die Zen4C Kerne zum Einsatz, jedoch mit aktiviertem SMT, dann aber Zen4D genannt :)

HOT

2021-11-09, 12:21:44

Die haben doch alle Features der normalen Zen4-Kerne, das non-SMT ist einfach blanker Unsinn. Apple und Intel haben eben auch passende Kerne dafür, Zen4 ist ja für SMT ausgelegt. Da hat wieder irgendjemand was rumspekuliert und das hat die Runde gemacht.

BavarianRealist

2021-11-09, 14:49:27

Wenn ich es nicht falsch verstanden habe, müsste Zen4c architektonisch zu Zen4 eigenlich völlig identisch bleiben, um eine weitere aufwändige Validierung zu ersparen: Zen4c soll sich ja möglich 100,00% identisch zu Zen4 verhalten, d.h. es muss auch genauso SMT vorhanden sein, wie alle anderen Befehlserweiterungen auch.

Ich denke, es reicht, einen dichteren Lowpower-Prozess zu verwenden und die Caches etwas zu reduzieren, um statt 96 dann eben 128 Cores unter zu bringen.

robbitop

2021-11-09, 14:57:02

Ich vermute, dass es kein anderer Prozess ist, sondern die Synthetisierung des Layouts anders getunt wird. Weniger Takt und dafür mehr Packdichte.

Lehdro

2021-11-09, 15:40:57

Ich vermute, dass es kein anderer Prozess ist, sondern die Synthetisierung des Layouts anders getunt wird. Weniger Takt und dafür mehr Packdichte.
Und damit die Rückkehr der CCX auf dem CCD?
Ansonsten muss man wohl deutlich umbauen, 16 Cores sind deutlich komplexer untereinander zu verdrahten als nur 8.

amdfanuwe

2021-11-09, 16:44:59

Wo unterscheiden sich die Anforderungen von HPC (Genoa) und Cloud (Bergamo)?

basix

2021-11-09, 18:08:26

Und damit die Rückkehr der CCX auf dem CCD?
Ansonsten muss man wohl deutlich umbauen, 16 Cores sind deutlich komplexer untereinander zu verdrahten als nur 8.

Ist es das mit einem Ring? Latenzen leiden sicher, aber sonst?

Savay

2021-11-09, 18:46:32

Und damit die Rückkehr der CCX auf dem CCD?

Liegt zumindest Nahe. Sonst müsste man ja wirklich noch mehr am Core und Fabric und den Interconnects umbauen.
Das es nur 128C werden spricht irgendwie auch dafür während Genoa 96C hat.
Die CCX muss man ja auch irgendwie ans IF bekommen.

128/8 = 16 CCX auf 8 CCDs
96/8 = 12 CCX auf 12 CCDs

Das IOD wird sicher nur eine begrenzte Menge an CCX anbinden können...deshalb sind es auch bestimmt für Bergamo keine 12 CCD. :uponder:

iamthebear

2021-11-09, 19:42:11

Sehe ich jetzt nicht so das Problem, dieses oder nächstes Linux führt Trusted Threads als Option ein, damit dürfen dann auf einem Kern nur noch Threads laufen die sich gegenseitig vertrauen, d.h. z.b. vom gleichen Kunden sind.

Grundsätzlich der richtige Weg. Ich schätze einmal das bezieht sich dann auf den Hypervisor. Die Frage ist wie lange wird es dauern bis alles Anbieter das Konzept übernommen haben.

Ein paar Gedanken:

- SMT kostet kaum Transistoren
- es aus der uArch rauszunehmen kostet sicher einiges an Aufwand
- der Core soll ggf auch bei nicht cloud Produkten zum Einsatz kommen - oder auch in der Mischkonfiguration - die Option auf SMT wäre sicherlich gut

Ursprünglich gab es einmal die Angabe, dass SMT 5-10% Performance kostet. Die Frage ist ob das immer noch stimmt.
Nachträglich raus nehmen macht natürlich keinen Sinn aber ob es unbedingt so sinnvoll in jedem Design ist daran habe ich mittlerweile so meine Zweifel. Apple ist z.B. sehr erfolgreich ohne SMT.

Aber wenn Zen4 SMT hat dann muss es Zen4D eigentlich auch haben.[/quote]

Warum nicht einfach anlassen und der Endkunde kann per UEFI selbst entscheiden ob er es an oder ausschaltet. Je nach Bedarf.

Es ist halt eine Kosten/Nutzen Abschätzung. Wenn es ca. 20% mehr Performance bringt und 10% Transistoren kostet, dann muss es mindestens die Hälfte der Kunden nutzen sonst macht es keinen Sinn weil dann ist man besser dran wenn man einfach 10% mehr Kerne verbaut.

Eine weitere Überlegung ist ob die Software überhaupt so viele Threads hat bzw. man diese gescheduled bekommt.

Ist die Frage ernst gemeint? Bislang sind die Compute Dies bei Server und Desktop identisch, also exakt dasselbe Produkt. Das ist ja gerade der Gag an der Chiplet Strategie.

Ja die Frage ist, ob das bereits bestätigt ist (bzw. es Leaks gibt), ob es bei Zen4D genauso sein wird oder ob wir das nur annehmen.

Wenn ich es nicht falsch verstanden habe, müsste Zen4c architektonisch zu Zen4 eigenlich völlig identisch bleiben, um eine weitere aufwändige Validierung zu ersparen: Zen4c soll sich ja möglich 100,00% identisch zu Zen4 verhalten, d.h. es muss auch genauso SMT vorhanden sein, wie alle anderen Befehlserweiterungen auch.

SMT ja da man dies nicht so einfach ausbauen kann (zumindest bringt es nichts).
Was die Befehlserweiterungen angeht wird es wahrscheinlich gleich sein, allerdings sehe ich bei Zen4 noch keinen zwingenden Grund dafür. Man könnte z.B. AVX512 auch ohne Probleme weglassen. Erst wenn man Zen4D dann mit Zen5 kombiniert wird das ein Thema.

Ich denke, es reicht, einen dichteren Lowpower-Prozess zu verwenden und die Caches etwas zu reduzieren, um statt 96 dann eben 128 Cores unter zu bringen.

Nach aktuellen Stand geht es um 8C+32MB vs. 16C+32MB. Denkst du, dass ein dichterer Prozess hier tatsächlich so viel ausmachen kann bzw. hast du da zufällig Zahlen? Für mich hört sich das vom Flächenbedarf spannend an. Die Verlustleistung ist kein Problem. Die regelt man mit niedrigeren Taktraten.

Und damit die Rückkehr der CCX auf dem CCD?
Ansonsten muss man wohl deutlich umbauen, 16 Cores sind deutlich komplexer untereinander zu verdrahten als nur 8.

Das ist die Frage. Ich würde jedoch eher zu einem 16 Kern Block tendieren. Zumindest hat das Zen 3 relativ gut getan keine 2 CCX zu haben. Aber ist schwer zu sagen ab wann der Overhead zu groß wird.

robbitop

2021-11-09, 19:56:46

10% ist Utopisch. Es gab mal eine Aussage von Intel und da lag SMT eher im Bereich von 5% mehr Transistoren. Und dafür gibt es in MT mindestens 30% Performance.

memory_stick

2021-11-09, 20:00:11

Des Rätsels Lösung: 16 chiplets/package, weiterhin 8 Cores/CCX, 1 CCX/CCD, 16CCDs = 128Cores.
Bei der Präsi war ein Package von Bergamo im Hintergrund zu sehen, Kamerawinkel ist vermutlich mit Absicht ungünstig gewählt, aber es lässt sich erahnen das mindestens 3 CCDs nebeneinander pro Reihe rechts und links des MCDs sitzen. Da die CCDs viel weiter zum Rand des Packages versetzt sind als z.Bsp. bei Milan, und es unwahrscheinlich ist das AMD nun 128/12 = 10.666Cores/CCD verbaut, muss zwangsläufig die Möglichkeit von 4CCDs pro Reihe in Betracht gezogen werden. Sind 4x4=16CCDs und damit wieder 8Core/CCD.

Zurück zu mehreren CCX/CCDs werden sie vermutlich nicht mehr gehen, da es eigentlich nix bringt. Der Speicherzugriff und die Core-Core Kommunikation ist ähnlich aufwendig wie off chip bei 1CCX/CCD, aber kleinere chiplets kann man einfacher wiederverwenden. (Annahme: Mehr als 8 Cores pro CCX lassen sich schlecht umsetzen, CCX-CCX direkte kommunikation via L3 caches ist topologisch nicht vorgesehen/möglich)

Das IOD müsste dann aber natürlich 16 bidirektionale IF links haben für 16CCDs.

Irgendwie passen 12 CCDs und 16/8 CCDs bei Genoa/Bergamo nicht ganz zusammen

amdfanuwe

2021-11-09, 22:22:02

Bei der Präsi war ein Package von Bergamo im Hintergrund zu sehen,
Bei 34:34. Ist das gleiche Bild wie bei Genoa bei 32:58. Lisa steht nur geschickt davor damit das nicht offensichtlich ist.
Wäre natürlich auch möglich, das über und unter dem I/O noch je 2 Chiplets untergebracht sind und damit insgesamt 16 Chiplets.
Ich denke aber eher, dass bei Bergamo 16 Core Chiplets eingesetzt werden.
Eine weitere Möglichkeit wäre ein neues Packaging Verfahren. Eine Art Tick Tock. Genoa nach bewährter Manier und Bergamo mit neuem I/O und Chipletanbindung mit EFB wie beim MI200 als nächste Stufe.
Scheint zumindest gut zu laufen, sonst hätte Lisa Bergamo noch nicht angekündigt.

16 Cores in 5nm bei doppelter Density und halbem Verbrauch wären theoretisch kein Problem. Da Cache nicht so gut scaliert muß da eventuell etwas abgespeckt werden.
Ich frage mich eher, was bei den Genoa Chiplets mit der freien Fläche und den zusätzlich verfügbaren Transistoren angestellt wird. Die Chiplets scheinen ja nicht kleiner zu werden. Werden die Kerne doppelt so groß? Kommt mehr Cache auf das Die oder packen die noch FPGA mit drauf?

Mal gespannt, was AMD da vorstellen wird.

=Floi=

2021-11-09, 23:16:50

Ob das bild passend ist wissen wir auch nicht.
Irgendwie kommt man nicht sinnvoll auf die 128 kerne. Höchstens mit 16x8. Oder glaubt ihr an 8x16chiplets? :D

CrazyIvan

2021-11-09, 23:32:49

Ja die Frage ist, ob das bereits bestätigt ist (bzw. es Leaks gibt), ob es bei Zen4D genauso sein wird oder ob wir das nur annehmen.
Shifting goalposts?
Deine Frage war, ob die Fläche der Zen4 (normal) Server CCD identisch ist zu der Fläche der Zen4 Desktop CCD. Die Antwort lautet schlicht und ergreifend: Ja!

Unicous

2021-11-09, 23:34:11

Wo unterscheiden sich die Anforderungen von HPC (Genoa) und Cloud (Bergamo)?

Da noch niemand geantwortet hat: rohe Compute-Power vs. core count.

HPC generell mag große und schnelle Caches denn die Daten in den RAM zu senden ist "teuer".

Cloud-Server/Webhosting/Filehosting braucht an sich keine hohe Rechenleistung dafür aber viele einzelne meist abgeschirmte Instanzen, also eine möglichst hohe Anzahl an dedizierten Kernen die zudem auch noch sparsam sind. Deswegen hofft man auch ARM in Schach halten zu können indem man die Kernzahl pro Sockel erhöht und die Taktraten niedrig hält und möglicherweise den Cache verkleinert.
Alibaba hat gerade erst einen 128-Kern ARM-Chip vorgestellt und Ampere hat mit Altra auch Chips mit 128 Kernen. I/O ist auch nicht unwichtig, je mehr PCIe Lanes etc. desto besser. Aber hier ist die ST-Leistung natürlich vergleichsweise niedrig und je nach Anwendungsfall wird das irgendwann zum Flaschenhals.

amdfanuwe

2021-11-10, 01:41:44

Cloud-Server/Webhosting/Filehosting
Danke, hat mir sehr geholfen. Hatte einfach nicht die richtigen Assoziationen.

Savay

2021-11-10, 19:45:29

Zumindest hat das Zen 3 relativ gut getan keine 2 CCX zu haben. Aber ist schwer zu sagen ab wann der Overhead zu groß wird.

Jedes CCD stellt bei Zen 3 ein CCX dar, das heißt aber ja nicht das in Zukunft nicht wieder mehrere CCX pro CCD geben kann, wenn es für Fertigung oder Packaging oder Skalierbarkeit einen Vorteil hat.
Alle CPUs mit >8C haben eh schon mehrere CCX, irgendwann nimmt der nutzen immer größerer CCX halt auch ab da die Abhängigkeiten abnehmen.

Ich denke mit 8C/CCX hat man aktuell nen ganz guten Sweetspot zwischen Komplexität und Skalierbarkeit.
Die Intercore Kommunikation wird durch mehr Cores/CCX ja auch nicht zwingend besser.
Wenn Zen4c aber ne art Minimal "Schrumpfkur" des normalen Zen4 ist wird man sicher vermeiden wollen extrem an dem CCX Aufbau zu schrauben, da das ja auch vom Design Aufwand erzeugt den man sich für diesen Usecase (Threaddichte und gut Parallelisierbare Anwendungen) eigentlich sparen kann.

Thunder99

2021-11-11, 09:20:40

Es wurde ja schon gesagt, dass die 128C Variante weniger Cache hat. Dadurch werden die Ciplets kleiner und es passen mehr auf den Träger.
Verdrahtung Anbindung etc, keine Ahnung, aber irgendwie muss es ja passen wenn es in den gleichen Sockel kommt.

Zossel

2021-11-11, 20:29:55

https://www.computerbase.de/2021-11/interconnect-technologie-gen-z-gibt-auf-cxl-gehoert-die-zukunft-im-server/

CXL in der Spezifikation 1 basiert „physisch und elektrisch“ auf PCI Express 5.0. Die ersten Produkte werden im kommenden Jahr erscheinen, sowohl Intels als auch AMDs Server-Plattformen werden CXL unterstützen. Intel Sapphire Rapids macht den Anfang, AMD Genoa auf Basis von Zen 4 folgt. Damit steht der umfassenden Marktdurchdringung kaum mehr etwas im Weg.

Es wird auch Zeit das vernünftiges Ethernet auf das IO-DIE kommt.

S940

2021-11-11, 23:31:37

Ein paar Gedanken:

- SMT kostet kaum Transistoren
- es aus der uArch rauszunehmen kostet sicher einiges an Aufwand
- der Core soll ggf auch bei nicht cloud Produkten zum Einsatz kommen - oder auch in der Mischkonfiguration - die Option auf SMT wäre sicherlich gut

Warum nicht einfach anlassen und der Endkunde kann per UEFI selbst entscheiden ob er es an oder ausschaltet. Je nach Bedarf.

Ja, das Gerückt kapier ich auch nicht. Vor den Hintergrund, dass bei bei sinkender Cachegröße die Speicherzugriffe steigen - die bekanntlich eine deutlich höhere Latenz haben, der CPU-Kern also öfters nichts zu tun hat - ein 2. Thread also gut laufen würde, wäre das ne schlechte Idee.

Wie wärs umgedreht mit Quad-SMT?

=Floi=

2021-11-12, 03:16:56

glaube das will man wegen der sicherheit gerade nicht mehr in der cloud haben. längerfristig wird man da devinitiv von wegkommen, wenn man auch einfach einen ganzen kern bekommen kann.

OgrEGT

2021-11-12, 06:47:22

basix

2021-11-12, 07:37:48

AMD hat offiziell eigentlich gar nicht von weniger Cache gesprochen, sondern von "density-optimized cache hierarchy".

Was könnte das sein? So stelle ich mir das vor:
- Weniger Cache pro Core. 2MB L3$ pro Core ist immer noch anständig viel. Bei 16C CCX wären das wieder 32MB unified für das CCX/CCD
- 32MB wären zufälligerweise dann auch gleich viel wie bei den 8C Zen3/4 Die: 3D V-Cache wäre verwendbar (optional, je nach SKU)
- Reduzierter L2$. Zen 4 soll mit 1MB kommen. 512kB wie bei Zen 3 wären aber vermutlich auch noch ganz gut

Alternativen:
- Andere Cache Libraries nutzen (siehe den V-Cache Die), welche eine höhere Density zulassen aber weniger schnell sind --> höhere Latenzen, geringere Bandbreiten
- Unified L2$ Pools wie bei Intels Gracemont

Lehdro

2021-11-12, 11:32:08

- Unified L2$ Pools wie bei Intels Gracemont
Oder IBMs Cache Approach kopieren. (https://www.anandtech.com/show/16924/did-ibm-just-preview-the-future-of-caches) Wobei ich nicht einschätzen kann wie viel Rework da am eigentlichen Zen 4 Design notwendig wäre.

reaperrr

2021-11-12, 12:12:15

Auf halbierten L3 je Kern und evtl. eben auch halbierten L2 würde ich ebenfalls tippen. Mglw. dafür mit leicht reduzierten Latenzen, um den IPC-Verlust so weit wie möglich zu reduzieren.

Eine zusätzliche Möglichkeit für Zen4c, die hier glaube ich noch nicht erwähnt wurde:
N5P statt N5HPC.

Dass N5HPC für die erhöhte Performance etwas Packdichte opfert, wurde in der Vergangenheit schon angedeutet, insofern wäre das aber eine Möglichkeit, gegenüber den regulären Zen4-CCDs auf noch mehr Packdichte zu kommen.

basix

2021-11-12, 12:52:22

Oder IBMs Cache Approach kopieren. (https://www.anandtech.com/show/16924/did-ibm-just-preview-the-future-of-caches) Wobei ich nicht einschätzen kann wie viel Rework da am eigentlichen Zen 4 Design notwendig wäre.

Wäre auch ein zusätzliche Idee. Ich hätte dann aber behauptet, dass das mit SW-Kompatibilität zum normalen Zen 4 deutlich schwieriger wird. Den Ansatz hätte ich dann auch eher gesehen, um den L3$ von mehreren CCDs zusammenzuführen. Auf einem einzelnen CCD/CCX und bei der geringen Grösse des L2$ scheint mir das zu aufwändig verglichen mit dem Nutzen.

Eine zusätzliche Möglichkeit für Zen4c, die hier glaube ich noch nicht erwähnt wurde:
N5P statt N5HPC.

Dass N5HPC für die erhöhte Performance etwas Packdichte opfert, wurde in der Vergangenheit schon angedeutet, insofern wäre das aber eine Möglichkeit, gegenüber den regulären Zen4-CCDs auf noch mehr Packdichte zu kommen.

Wie wäre es mit N4P? Soll gegen Ende 2022 den Ramp-Up erfahren, könnte mit Zen 4c / Bergamo Release H1/2023 zusammenpassen: https://pr.tsmc.com/english/news/2874
As the third major enhancement of TSMC’s 5nm family, N4P will deliver an 11% performance boost over the original N5 technology and a 6% boost over N4. Compared to N5, N4P will also deliver a 22% improvement in power efficiency as well as a 6% improvement in transistor density. In addition, N4P lowers process complexity and improves wafer cycle time by reducing the number of masks. N4P demonstrates TSMC’s pursuit and investment in continuous improvement of our process technologies.
...the first products based on N4P technology are expected to tape out by the second half of 2022.
Zu N5P: https://www.eetasia.com/tsmc-adds-a-n5p-process/
Der Unterschied ist hier nicht extrem gross, N4P soll aber einiges weniger and Prozessschritten beinhalten und dementsprechend günstiger sein.
The N5P starting risk production next year could squeeze anther 7% in speed or 15% in power from N5 using the same design rules. The gains come in part from enhancements to a fully strained high-mobility channel.

amdfanuwe

2021-11-12, 13:02:03

Bzgl. Weniger Cache... ich habe verstanden dass das Zen4c Chiplet wenn es 2D ist weniger hat als das Zen4 Chiplet. Man muss davon ausgehen dass aber in beiden Fällen da noch ausreichend Cache darauf gestapelt wird.

Die bisherigen CPUs gingen ja mehr Richtung HPC/Universal Anwendungen. Da profitiert einiges von viel Cache.
ZEN4c ist für Cloud Aufgaben bestimmt. Die Frage ist, wieviel und welches Cachedesign ist da nötig?

reaperrr

2021-11-13, 01:16:01

Wie wäre es mit N4P? Soll gegen Ende 2022 den Ramp-Up erfahren, könnte mit Zen 4c / Bergamo Release H1/2023 zusammenpassen: https://pr.tsmc.com/english/news/2874
Weniger als 12 Monate zwischen ersten Tape-Outs und Bergamo-Release halte ich für ein Server-Produkt für zu kurz. Man soll niemals nie sagen, aber was anderes als eine N5-Variante würde mich überraschen.

Ramius

2021-11-13, 10:26:50

[QUOTE=basix;12844205]AMD hat offiziell eigentlich gar nicht von weniger Cache gesprochen, sondern von "density-optimized cache hierarchy".

Was könnte das sein? So stelle ich mir das vor:

- Andere Cache Libraries nutzen (siehe den V-Cache Die), welche eine höhere Density zulassen aber weniger schnell sind --> höhere Latenzen, geringere Bandbreiten

Darauf könnte es hinauslaufen. Den Platzverbrauch des L3-Caches halbieren und auf dem freigewordenen Platz 8 zusätzliche Cores unterbringen.

robbitop

2021-11-13, 10:39:57

OgrEGT

2021-11-13, 10:46:07

Die bisherigen CPUs gingen ja mehr Richtung HPC/Universal Anwendungen. Da profitiert einiges von viel Cache.
ZEN4c ist für Cloud Aufgaben bestimmt. Die Frage ist, wieviel und welches Cachedesign ist da nötig?

Ich glaube es gibt nicht die eine Cloud Anwendung mit dem einen Anforderungsprofil. Gerade Microsoft Azure profitiert bei einigen Anwendungen vom größeren MilanX Cache.

https://www.planet3dnow.de/cms/63917-amd-epyc-milan-x-mit-3d-v-cache-zuerst-in-azure-cloud/

AMD kann ja durchaus flexibel sein und Zen4 sowie Zen4c sowohl mit (ggf variabler Größe?) als auch ohne 3D Cache anbieten...

amdfanuwe

2021-11-13, 11:05:36

Ich glaube es gibt nicht die eine Cloud Anwendung mit dem einen Anforderungsprofil. Gerade Microsoft Azure profitiert bei einigen Anwendungen vom größeren MilanX Cache.

Deshalb bietet AMD ja verschiedene Prozessoren an.
Azure mit VM hat sicherlich andere Anforderungen als ein Webhoster oder Audio/Video Streamingservice, die kaum Rechenleistung benötigen.

OgrEGT

2021-11-13, 13:28:11

Ob man in einem Dual Socket System Zen4 und Zen4c kombinieren kann?

Zossel

2021-11-13, 13:37:17

Ob man in einem Dual Socket System Zen4 und Zen4c kombinieren kann?

Mach einen Patch für den Linux-Kernel klar.

OgrEGT

2021-11-13, 20:14:14

Mach einen Patch für den Linux-Kernel klar.

Ich dachte unter der Voraussetzung dass die Kerne und Befehlssätze identisch sind...

Nightspider

2021-11-14, 20:19:38

Ggf ja auch beides. Höhere Dichte und weniger Cache. Letzteres macht AMD für den L3 ja auch bei den APUs um Platz zu sparen. Zen 4 führt angeblich ja 1 mib L2 pro core ein - 512kib für die Zen 4c würde sich ja anbieten.

Wir wissen ja auch das AMD den V-Cache schon mit grob doppelter Dichte packen kann wie den internen L3 Cache bei Zen3 unter 7nm.

Wir wissen nur nicht ob es am Prozess liegt (wird doch EUV verwendet beim V-Cache-Die oder ein Cache optimierter Prozess?) und nur bei einem eigenständigen Cache-Chip realisierbar ist oder ob AMD diese Dichte auch im Prozessor unter 7nm erreichen könnte.

Wenn AMD diese Cache Dichte bei Zen4 intern erreichen kann und dazu noch der Dichtevorteil von N5(HPC) dazukommt dann AMD den L3 in Zen4 massiv dichter packen. So oder so wird Cache in 5nm dichter sein. Nach meinem Verständnis lassen sich durch dichteren Cache etwas bessere Latenzen erreichen durch kürzere Wege und um die Latenz noch weiter runter zu bekommen müsste man den Cache noch schneller takten und anders anbinden, was wiederum zu lasten der Dichte geht und den Cache vergrößert.
Vielleicht wird der "externe" V-Cache sogar zu einem L4 herabgestuft, wenn man die gleichen Chips von Zen3D weiter verwendet und den "internen" L3 schneller macht.
Da AMD die Kapazität des Last Level Cache durchs stacking quasi beliebig steigern kann verliert die Kapazität generell aber auch die Größe des "internen" Last Level Caches an Bedeutung und für etliche Anwendungen müsste man die Latenzen weiter drücken für eine bessere Skalierung.

Falls AMD den aktuellen 7nm V-Cache Chip bei Zen4 weiterverwenden will sollte die Fläche des "internen" Caches weiterhin so groß bleiben wie bei Zen3 damit sich die Flächen thermisch überlappen. Das geht eben nur indem er unter 5nm deutlich anwächst, was wegen dem großen V-Cache imo weniger Sinn ergibt, oder indem der interne L3 deutlich schneller wird und dadurch auch mehr Fläche beansprucht. Daher meine Überlegung gerade ob der "alte", "langsame" V-Cache Gen1 zu einem L4 degradiert wird.

Angesichts der enormen Vorteile vom V-Cache und die damit erreichbaren höheren Preissegmente, Prestige usw. würde es mich nicht wundern wenn die Non-V-Cache Varianten sogar leichte Nachteile durchs Chipdesign hinnehmen könnten. Beispielsweise das der interne Cache eben stärker auf Latenz optimiert wird und man für Anwendungen die viel Cache wollen zur V-Cache Variante greifen muss - man dafür aber nochmal einen gewaltigen Sprung bekommt und damit quasi der Abstand zwischen Non-V-Cache und V-Cache Varianten größer wird.

Wenn AMD dann 2023 V-Cache mit 2 (oder mehr) Lagen anbietet und der interne Cache deutlich bessere Latenzen hat als aktuell, dann wissen wir woher die IPC Sprünge bei Zen4 und Zen5 teilweise kommen werden.

Falls Zen4c kleinere Caches und mehr Kerne bekommt würde der V-Cache Gen1 über einigen Kernen liegen, wäre aus thermischer Sicht also inkompatibel zum V-Cache so wie wir ihn kennen. Entweder bekommt Zen4c ein neues Stacking-Design oder einfach keinen V-Cache.

basix

2021-11-14, 20:43:00

Ramius

2021-11-14, 21:05:56

Ich glaube, dass Zen 4 und 4c beide 32 MByte/CCD bekommen und das selbe V-Cache Die obendrauf nutzen können. Das wäre aus meiner Sicht 8C Zen 4 und 16C Zen 4c. mMn wird Zen 4 hier einen neuen V-Vache Die bekommen, also kein Re-Use von Zen 3.

Das glaube ich nicht. Das CCD für Zen4 und Zen4c soll die gleiche Größe haben. Damit wird man nicht einmal 8C +32MB L3 und ein anderes mal 16C + 32MB L3 unterbringen können außer man halbiert die Größe des Zen4c woran ich aber auch nicht glaube.

Denniss

2021-11-14, 21:10:49

Der VCache ist nicht dichter gepackt als der OnBoard bei Zen3, das ist einfach reiner Cache ohne Steuerlogik.

w0mbat

2021-11-14, 21:38:47

Doch, er ist deutlich dichter gepackt, da AMD hier libraries verwendet, die für cache optimiert sind. Die fehlende Steuerlogik macht nur einen kleinen Teil der Einsparungen aus.

Nightspider

2021-11-14, 21:50:10

Gibts dazu offizielle Aussagen oder wo nimmst du das her?

w0mbat

2021-11-14, 22:35:30

Erstens macht das Sinn (nur das wegfallen der Kontrollogik verdoppelt nicht die Dichte) und zweitens hat AMD das so erklärt.

Complicated

2021-11-15, 08:19:11

https://fuse.wikichip.org/news/5531/amd-3d-stacks-sram-bumplessly/
The 64 MiB 3D V-Cache die itself is measured 36 mm² (a 6 mm x 6 mm square). This is roughly 9 mm² more than the 32 MiB of L3 on the CCD which occupies around 27 mm² of silicon so the SRAM in the 3D V-Cache appears to be more tightly packed. Architecturally, the V-Cache die itself adds 64 MiB of SRAM capacity directly on top of the existing 32 MiB of L3 for a single, large, 96 MiB of L3 capacity.

basix

2021-11-15, 08:57:55

Das glaube ich nicht. Das CCD für Zen4 und Zen4c soll die gleiche Größe haben. Damit wird man nicht einmal 8C +32MB L3 und ein anderes mal 16C + 32MB L3 unterbringen können außer man halbiert die Größe des Zen4c woran ich aber auch nicht glaube.

Woher nimmst du die Info, dass das Zen 4c CCD die gleiche Grösse hat? Wäre mir neu. Wenn dem so ist, müssten sie wirklich halbiert werden von der Grösse. Das würde aus meiner Sicht aber mindestens bedeuten, dass man die AVX-Einheiten pro Core halbiert. Den Rest mit reduzierter Core-Logik und angepasstem Phyiscal-Design (Density optimized).

Complicated

2021-11-15, 09:08:44

Zen4 hat 96 Kerne und Zen4c 128 Kerne im maximal-Ausbau mit 5nm.
https://scr3.golem.de/screenshots/2111/Epyc-Genoa-Bergamo/thumb620/Epyc-Genoa-Bergamo-02.png
https://scr3.golem.de/screenshots/2111/Epyc-Genoa-Bergamo/thumb620/Epyc-Genoa-Bergamo-03.png

Ich denke, dass mit Optimierungen durchaus die zusätzlichen 32 Kerne Platz finden können, ohne Cache zu reduzieren.

https://scr3.golem.de/screenshots/2111/Epyc-Genoa-Bergamo/thumb620/Epyc-Genoa-Bergamo-04.png

basix

2021-11-15, 11:00:06

Platz ist sicher genug da auf dem Package. Wenn man keinen V-Cache (oder ein anderes V-Cache Die) verwendet, kann man mit dem CCD in die Breite und Länge wachsen. Nimmt man den normalen Zen 4 V-Cache, kann man nur in der Länge wachsen. Dann werden die Cores recht schmal.

robbitop

2021-11-15, 12:17:58

Ich glaube, dass Zen 4 und 4c beide 32 MByte/CCD bekommen und das selbe V-Cache Die obendrauf nutzen können. Das wäre aus meiner Sicht 8C Zen 4 und 16C Zen 4c. mMn wird Zen 4 hier einen neuen V-Vache Die bekommen, also kein Re-Use von Zen 3.

Unmöglich wäre Re-Use evtl. nicht, der heutige V-Cache würde dann noch etwas über den L2$ ragen. Könnte also schon klappen. Die Position der TSVs müsste aber identisch sein, was das Design des CCD deutlich verkompliziert.

Das ginge aber nur, wenn bei Zen 4c 16 Cores in einen CCX kommen. Dann wird der Ringbus im CCX nochmal langsamer oder muss zu einem Doppelring umgebaut werden.
Ich würde eher darauf tippen, dass Zen4c keinen VCache bekommen wird. Pro 16C 32 MiB wäre eine Halbierung - aber wer weiß - ggf viertelt man diesen auch. Siehe APUs. 2x CCX a 8 Cores mit je 8 16 MiB L3. Das wäre mein persönlicher Tipp. Warum? Weil man es schon gemacht hat und weniger umstricken muss. Extra einen 16c CCX bauen dafür -> mehr Aufwand.

edit: L3 Cachegröße für Zen 3 APU Cezanne korrigiert

amdfanuwe

2021-11-15, 12:20:04

Das CCD für Zen4 und Zen4c soll die gleiche Größe haben.
Das Package ist Sockel compatibel. Heißt nicht, dass die Chiplets gleich groß sind.

Complicated

2021-11-15, 12:41:29

AMD hat gegenüber Anandtech schon bestätigt, dass die Zen4c Chiplets eigene Masken erhalten werden, also es ein komplett neues eigenes Design ist. Die Kosten dafür scheinen also gesetzt zu sein. https://www.anandtech.com/show/17055/amd-gives-details-on-epyc-zen4-genoa-and-bergamo-up-to-96-and-128-cores
AMD has stated to us in our briefing that Genoa and Bergamo will be socket compatible, with Genoa coming in the 2022 timeframe, while Bergamo in late 2022/early 2023 (with a focus more on the early 2023 target). When asked, AMD did not want to narrow down the Genoa timeframe in a similar light. Bergamo however will have the same features as Genoa: DDR5, PCIe 5.0, CXL 1.1, RAS, and AMD's security suite.

The use of two different core optimization points is going to be an interesting one for AMD. Normally it creates one core chiplet design that can be used across consumer and server processors, but the development of a Zen 4c chiplet now means the company has to manage stock of both independently. Also, both being on 5nm means that the mask development costs are likely to be double than a singular design across all.

fondness

2021-11-15, 12:59:07

robbitop

2021-11-15, 13:11:57

Stimmt. OK 1x 16 MiB. Entsprechend könnte man 2x 16 MiB für Zen 4c.

basix

2021-11-15, 13:25:39

Das ginge aber nur, wenn bei Zen 4c 16 Cores in einen CCX kommen. Dann wird der Ringbus im CCX nochmal langsamer oder muss zu einem Doppelring umgebaut werden.
Ich würde eher darauf tippen, dass Zen4c keinen VCache bekommen wird. Pro 16C 32 MiB wäre eine Halbierung - aber wer weiß - ggf viertelt man diesen auch. Siehe APUs. 2x CCX a 8 Cores mit je 8 16 MiB L3. Das wäre mein persönlicher Tipp. Warum? Weil man es schon gemacht hat und weniger umstricken muss. Extra einen 16c CCX bauen dafür -> mehr Aufwand.

edit: L3 Cachegröße für Zen 3 APU Cezanne korrigiert

AMD sagt ja "density optimized cache-hierarchy". Das kann vieles bedeuten. Einfach 2x 8C CCX mit halbem L2/3$ pro Core auf das CCD zu knallen wäre sicher naheliegend und am einfachsten. Du hättest dann aber viel mehr Traffic via IFOP über den IOD. Weiss nicht, ob dies mit einem einzelnen IFOP und dem dem 1:2 Verhältnis Read/Write von IFOP gut klappt (wenn es gleich wie bei Zen 2/3 ist). Dazu noch reduzierter Cache pro CCX? Hmm, ich weiss nicht. Hört sich nach Flaschenhals an.

Ein 16C CCX mit dann halt grösseren Ringen oder gewissen Nachteilen bezüglich Bandbreite usw. halte ich für die bessere Lösung. Ohne Kompromisse geht es aber sicher nicht. AMD hat ja entsprechende Studien gemacht gehabt bezüglich Cache und Verbindung der Cores: Butterfly, Butter-Donut usw. Topologien.

AMD hat gegenüber Anandtech schon bestätigt, dass die Zen4c Chiplets eigene Masken erhalten werden, also es ein komplett neues eigenes Design ist. Die Kosten dafür scheinen also gesetzt zu sein. https://www.anandtech.com/show/17055/amd-gives-details-on-epyc-zen4-genoa-and-bergamo-up-to-96-and-128-cores
Etwas anderes wäre ja auch gar nicht möglich. Beim Design selbst und der IP kann man vermutlich sehr viel wiederverwenden und einfach beim Physical Design auf Density/Low Power optimieren. Das macht man bei den APUs ja auch. Peak Clock ist dann 4-4.5 GHz und nicht mehr 5.0 GHz. Dafür effizienteres Verhalten bei 2-3.5 GHz, wo typischerweise dann die Betriebsfrequenz liegen wird.

Edit:
Im Anandtech Artikel ist auch angegeben, dass sie N5HPC für Zen 4c verwenden werden. Also nichts N5 oder N4P oder sonst was. In N5HPC kann man aber natürlich auch die High Density Cells verwenden, wenn man Fläche sparen will und im Gegensatz etwas Performance opfert.
The Zen 4c chiplet, according to AMD, is built on an HPC variant of TSMC N5.

BavarianRealist

2021-11-15, 14:19:05

Wenn ich es nicht ganz falsch verstanden haben, will AMD den gestackten 3D-L3-Cache weiter verfolgen, zumal die Caches kaum mehr shrinken, sodass man auf diese Weise teuren 5nm-Diespace einsparen kann, wenn man diesen in die 3D-L3-Chiplets in 7nm verlagert.

D.h. die 3D-Chiplets lohnen sich beim teuren 5nm-Prozess in Zukunft noch viel mehr als bei den heutigen Zen3-Chiplets in 7nm, zumal die reinen Cache-Chiplets mit weit weniger Metal-Layers auskommen dürften, sodass der L3-Cache in Form der 7nm-Chiplets am Ende wohl nur einen kleinen Bruchteil dessen kostet, was er auf dem 5nm-CPU-Die an Kosten verursacht.

Innerhalb der verschiedenen 5nm-Prozesse (auch die N4-Prozesse sind ja eigentlich 5nm-Prozesse) dürfte die Dichte des L3 noch viel weniger variieren, vermutlich nur minimal, d.h. es würde sich für AMD sicher lohnen, für Genua als auch Bergamo am Ende jeweils genau den gleichen L3 zu installieren, um die 3D-Chiplets für beide verwenden zu können.

Letztlich könnten beide jeweils wie bisher bei Zen3 weiterhin 32MB-L3 auf dem CPU-Chiplet haben, den sich bei Genau (Zen4) dann 8 Cores (wie bei Zen3) aber bei Bergamo (Zen4D) dann eben 12 CPU-Cores teilen und der mit Hilfe eine 3D-Chiplets wieder jeweils auf 96MB erhöht werden kann. Die Zen4D-Cores hätten dann letztlich nur 2/3 des L3-Caches von Zen4.

Complicated

2021-11-15, 14:25:04

Ich vermute AMD wird eher 2x 8c-CCX verbauen als einen 16c-CCX. Damit hätte ein CCD wieder 2 CCX, wie bei Zen1 nur mit 8 anstatt 4 Cores/CCX. Das würde, mit schnellerem IF und mehr L3$, für die anvisierte Produktklasse Anbindungen bedeuten, die schon verwendet wurden.

robbitop

2021-11-15, 15:17:24

AMD sagt ja "density optimized cache-hierarchy". Das kann vieles bedeuten. Einfach 2x 8C CCX mit halbem L2/3$ pro Core auf das CCD zu knallen wäre sicher naheliegend und am einfachsten. Du hättest dann aber viel mehr Traffic via IFOP über den IOD. Weiss nicht, ob dies mit einem einzelnen IFOP und dem dem 1:2 Verhältnis Read/Write von IFOP gut klappt (wenn es gleich wie bei Zen 2/3 ist). Dazu noch reduzierter Cache pro CCX? Hmm, ich weiss nicht. Hört sich nach Flaschenhals an.

Ein 16C CCX mit dann halt grösseren Ringen oder gewissen Nachteilen bezüglich Bandbreite usw. halte ich für die bessere Lösung. Ohne Kompromisse geht es aber sicher nicht. AMD hat ja entsprechende Studien gemacht gehabt bezüglich Cache und Verbindung der Cores: Butterfly, Butter-Donut usw. Topologien.
Man kann gespannt bleiben. Es ist ja nicht so, dass AMD in den letzten paar Jahren nicht auch oft genug überrascht hat. :)

Zossel

2021-11-23, 23:09:21

Na dann:
The latest Linux patches explicitly say, "The newer AMD Family 19h Models 10h-1Fh and A0h-AFh can support up to 12 CCDs. Update the driver to read up to 12 CCDs."
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Zen-12-CCDs-hwmon

TheAntitheist

2021-11-26, 02:25:36

Man kann gespannt bleiben. Es ist ja nicht so, dass AMD in den letzten paar Jahren nicht auch oft genug überrascht hat. :)
leider ja, hoffentlich in Zukunft mehr positive Überraschungen.

robbitop

2021-11-26, 08:56:46

leider ja, hoffentlich in Zukunft mehr positive Überraschungen.
Ich meinte es eigentlich im Positiven und kann - zumindest was die CPU Sparte angeht - auch seit 2017 keine wesentlichen negativen Überraschungen sehen.
Mit Zen kam man 2017 aus dem nichts zurück und konnte in jeder uArch Iteration wesentlich Leistung steigern und mit Intel mithalten und z.T. auch überholen, obwohl man um Größenordnungen kleiner ist.

Die GPU Sparte war da IMO enttäuschender (auch wenn es zuletzt doch bergauf geht - aber mit NV hat man einen Wettbewerber der sich nicht ausgeruht hat :D).

aceCrasher

2022-01-04, 16:43:45

Der in der Halo Infinite Demo verwendete Zen 4 Chip lief wohl mit 5GHz all core boost - sehr interessant. Ich bin gespannt wie viel ST Boost da letztendlich rumkommt.

Berniyh

2022-01-04, 16:45:14

Der in der Halo Infinite Demo verwendete Zen 4 Chip lief wohl mit 5GHz all core boost - sehr interessant. Ich bin gespannt wie viel ST Boost da letztendlich rumkommt.
Und war kombiniert mit einer RTX 3080. :freak::confused:

mboeller

2022-01-04, 16:46:33

hat die gerade wirklich erzählt, dass alle Cores beim ZEN4 Demo mit 5GHz gelaufen sind?

Berniyh

2022-01-04, 16:50:02

hat die gerade wirklich erzählt, dass alle Cores beim ZEN4 Demo mit 5GHz gelaufen sind?
Ja

Nightspider

2022-01-04, 17:12:38

Den Energieverbrauch hätten sie wenigstens noch zeigen können.

Daredevil

2022-01-04, 17:13:48

Sie hätten vielleicht irgendwas zeigen können. :D

Neurosphere

2022-01-04, 17:20:29

Sie hätten vielleicht irgendwas zeigen können. :D

Soviel besser waren die ersten 15 Minuten von Nvidia bislang auch nicht wirklich...

Ich hab mich allerdings gefragt ob man die VCache Geschichte nicht zusammengestrichen hat um Zen 4 nicht später in die Quere zu kommen.

robbitop

2022-01-04, 19:29:11

Wobei man wuch Zen 4 sicherlich mit vcache ausstatten kann.

MSABK

2022-01-04, 20:40:44

Was schätzt ihr wie lange AM5 genutzt wird?

amdfanuwe

2022-01-04, 20:57:55

So lange es DDR5 gibt. Heißt aber nicht, dass die ersten AM5 Boards noch kompatibel sind mit den Prozessoren in 4 Jahren.
Ich habe einen 1600X mit AM4 320er Board. Unterstüzt nur bis Ryzen 3xxx.

bbott

2022-01-04, 23:15:28

Und war kombiniert mit einer RTX 3080. :freak::confused:

Man verkauft lieber jede RX6900 :biggrin:

BoMbY

2022-01-05, 20:03:31

https://i.imgur.com/F9Tgy5P.jpg
Der Code ist: 114986FV10075
https://i.imgur.com/Mdpw5dg.jpg

Von: https://www.reddit.com/r/Amd/comments/rwgmxi/sp5_leak/

Nightspider

2022-01-05, 20:42:58

Eine GPU in der Größe hätte ich gerne. ^^

basix

2022-01-05, 21:04:52

Schon krass, wie fett solche CPUs geworden sind :D

TheAntitheist

2022-01-06, 17:31:10

So lange es DDR5 gibt. Heißt aber nicht, dass die ersten AM5 Boards noch kompatibel sind mit den Prozessoren in 4 Jahren.
Ich habe einen 1600X mit AM4 320er Board. Unterstüzt nur bis Ryzen 3xxx.
Aber erinnere dich mal zurück, erst nach einem Shitstorm gab es den ryzen 3xxx support... erst wenn die Leute einen Aufstand machen hält AMD ihre Versprechen von Long Time Support ihrer Plattformen

robbitop

2022-01-06, 17:36:02

Du meinst Ryzen 5xxx?

Linmoum

2022-01-06, 17:49:53

Aber erinnere dich mal zurück, erst nach einem Shitstorm gab es den ryzen 3xxx support... erst wenn die Leute einen Aufstand machen hält AMD ihre Versprechen von Long Time Support ihrer PlattformenDas Versprechen hätten sie auch gehalten ohne Zen3 auf X470 und darunter. Was ein Quatsch schon wieder.

Und wie robbitop richtig anmerkt ist es Ryzen 5xxx, nicht 3xxx.

robbitop

2022-01-06, 19:20:58

In Summe war AM4 schon super lange:
Bristol Ridge APU (Excavator)
Summit Ridge (Zen1) / Raven Ridge APU
Pinnacle Ridge (Zen1+) / Picasso API
Matisse (Zen2) / Renoir APU
Vermeer (Zen3) / Cezanne
Zen3D

Das sind schon eine Menge Produkte. Natürlich trotzdem schade, dass AMD die Entscheidung traf die 3xx Chipsätze ab Zen 3 auszuschließen. Es gibt einzelne 3xx Boards die sogar ein BIOS bekommen haben mit dem es geht und andere bios mods zeigen, dass es geht.
Die Bedenken wegen der BIOS Chipgröße kann ich verstehen. Aber dann hätte man es den Vendors als „Beta BIOS - no warranty claim“ machen lassen können. Für Erfahrene ohne Gewähr und gut ist. Hätte zumindest etwas Ruf gebracht. Technisch möglich war es.
Naja aber selbst ohne Zen 3 ist es schon mehr als wir von Intel je gesehen haben. Und dazu nich der Upgradepfad auf bis zu 16 Kerne von original 8 (Summit Ridge) respektive bloß 4 Kerne (Bristol Ridge).

Berniyh

2022-01-06, 19:28:13

Es gab ja auch einige Gründe, warum es schwierig wurde, wie z.B. Fragezeichen bei der Spannungsversorgung, PCIe Support sowie BIOS Chips.
ggf. hat man hier dazu gelernt und gibt die Eckdaten der Boards so vor, dass die Wahrscheinlichkeit steigt sie über mehrere Generationen verwenden zu können.

Eine Garantie wird es aber sicher nicht geben, unvorhergesehene Probleme können über die Zeit ja immer auftauchen.

Könnte mir aber vor allem auch vorstellen, dass AMD mit AM5 das TDP Limit etwas anhebt und es dann aber zwei Klassen von Boards geben wird, so dass die kleineren Boards nicht 150W TDP oder so abkönnen müssen (laut Spec, experimentell schaffen sie es sicherlich).

Brillus

2022-01-06, 19:45:30

HOT

2022-01-06, 19:48:20

Die BIOS-Chipgröße war nie ein Problem. Alle AM4-Bretter haben mindestens 16MB und selbst Gigabytes X570-Bretter sind auch bei 16MB geblieben.
Was weichen musste war eben Bristol Ridge, der wird heute von keinem BIOS mehr supportet, dass >Ryzen3k ist.

Was aber echt kacke war, waren viele VRM bei 300er-Brettern. Warum AMD die Entscheidung getroffen hat, den Vermeer-Support bei 300er-Brettern auf > AGESA Combo2 1.0.0.0D komplett auszuschließen, bleibt allerdings ein Rätsel. Ohne diesen Ausschluss hätten es immerhin Boards mit guter VRM noch geschafft mit Vermeer und Cezanne. 1.0.0.0D funzt noch, daher gibts ein paar 300er-BIOSse, bei denen Vermeer läuft. Aber bei allen Boards, die jetzt neu 1.2.0.5 bekommen haben ist bei Renoir schluss, z.B. Gigabytes 300er-Serie.

Berniyh

2022-01-06, 22:10:33

Die BIOS-Chipgröße war nie ein Problem.
Sagst du.
Was man so vernommen hat, war es das schon.

Letztendlich ist es aber auch nicht so wichtig, die wesentliche Aussage war ja einfach nur, dass AMD ja ggf. aus den Fehlern bei AM4 gelernt haben könnte. ;)

HOT

2022-01-07, 09:24:19

Sagst du.
Was man so vernommen hat, war es das schon.

Letztendlich ist es aber auch nicht so wichtig, die wesentliche Aussage war ja einfach nur, dass AMD ja ggf. aus den Fehlern bei AM4 gelernt haben könnte. ;)
Ich korrigiere micht: War es ne Zeit lang ein Problem, bis AGESA Combo 1004. Ab da hätte AMD die 16MB im Griff. Natürlich müssen sich die AMD-Ingeneure auch weiterhin Gedanken machen, die 16GB nicht zu sprengen. Das Hauptproblem für die Boardhersteller ist aber nur, dass die ihr eigenes Softwaregedöns u.U. einschränken müssen.

Schönes Interview zum Thema:
https://www.tomshardware.com/news/amd-exploring-ryzen-5000-support-on-300-series

Nichts anderes sagt er auch hier:

Due to the incredible number of processors supported with the AM4 socket (the longest-lived desktop socket yet), AMD has battled with a 16MB SPI ROM capacity limitation. These small chips store the BIOS and associated data that enable chip support, but AMD's massive support matrix led to split support on some platforms. In some cases, motherboard vendors have even resorted to de-featuring BIOS interfaces, discarding fanciful GUIs and moving to simple text-based menus to expand the number of supported chips. But that isn't the only issue.

Die haben Probleme damit gehabt und die Mobo-Hersteller müssen sich bei 16MB mit ihrem eigenen Gedöns einschränken und der Support für Bristol musste halt weichen. Aber: AMD hats eben hinbekommen, auch wenns nicht leicht war. Ein Gigabyte X570 Ultra hat nur ein 16MB-BIOS und unterstützt alles CPUs vom Ryzen 1000 (wenn auch inoffiziell, aber läuft) bis Ryzen5X3D.

Das hier ist aber der entscheidende Satz:

The other thing is between many of those early 300-series motherboards and later boards in the AM4 ecosystem, there have been some fairly significant changes to the IRM definition for the product, the current delivery capability of motherboards, etc. So you're going to drop it in there [Ryzen 5950X], and it's not going to deliver the performance the product is capable of. But by the same token, providing the opportunity for somebody to do that, if they wanted to, is not a matter of if the board is functionally capable of supporting that or not; it's really about will it get the most performance? At the moment, the official answer from AMD would be these 300-series motherboards are not a supported configuration in our engineering validation coverage matrix. There are potential issues that could be in there that we're simply not aware of at this point in time.

Linmoum

2022-01-07, 12:36:47

“Well, we’ve been extremely pleased with how AM4 has evolved….we said we would keep that socket for a long time and we have. We continue to believe that it has been good for the community and frankly, it’s been good for us as well. As we bring things along, it was time to do a socket transition for the new I/O in the new technology, but I think strategy-wise, it should be similar. I don’t have an exact number of years but I would say that you should expect that AM5 will be a long-lived platform as AM4 has been. I think we’re expecting AM4 to stay in the marketplace for quite some years and it will be sort of an overlapping type of thing.”

Bzgl. des IHS und der Frage nach dem "Warum?":
AMD Zen4 desktop (Ryzen 7000) integrated heat spreader design has been chosen not for its looks, but to make room for the capacitors that would otherwise have to be installed on the other side of the processor. The decision to place them on the same size as the IHS has given AMD a chance to put more pads on the bottom of the processor and as a result retain the same package size as AM4 processors.
https://videocardz.com/newz/amd-am5-to-be-a-long-lived-platform-backward-compatibility-with-am4-coolers-confirmed

Wake

2022-01-07, 15:27:46

Die Frage im Interview ob die WP unter den IHS laufen wird war auch wieder mal... ;D
(Antwort: Nein, ist natürlich versiegelt)

Bezüglich der Mulden außen solle man halt wie üblich mit Wattestäbchen und Reinigungsalkohol ran, falls doch mal was drauf runter läuft.
Mutig vom AMD-Rep aber das so deutlich auszusprechen, da es sicher wieder paar Grobmotoriker da draußen geben wird welche das als Anlass nehmen werden auf Kondensatorenjagd zu gehen.

Solange es nicht gerade leitende WP oder halt LM (wo man eh mit Lack drüber pinseln sollte) ist wirds bis auf die Ästhetik eh egal sein.

Zossel

2022-01-07, 15:41:07

Bezüglich der Mulden außen solle man halt wie üblich mit Wattestäbchen und Reinigungsalkohol ran, falls doch mal was drauf runter läuft.
Mutig vom AMD-Rep aber das so deutlich auszusprechen, da es sicher wieder paar Grobmotoriker da draußen geben wird welche das als Anlass nehmen werden auf Kondensatorenjagd zu gehen.

Solange es nicht gerade leitende WP oder halt LM (wo man eh mit Lack drüber pinseln sollte) ist wirds bis auf die Ästhetik eh egal sein.

Mit ist schon mal Wärmeleitpaste mit Metallspänen drin auf ein Motherboard dorthin getropft wo Hühnerfutter in 201 verbaut war, die Paste war ziemlich dünnflüssig.

Wattestäbchen und Spiritus und eine anschließende optische Kontrolle haben das Problem beseitigt:

$ date; uptime
Fri Jan 7 15:42:23 CET 2022
15:42:23 up 146 days, 9:42, 1 user, load average: 0,67, 0,64, 0,55
$

Neurosphere

2022-01-08, 11:22:52

Irgendwo sind irgendwelche Daten von Zen 4 aufgetaucht:

https://abload.de/img/zen47sko5.jpg

Quelle:
https://wccftech.com/alleged-amd-ryzen-7000-zen-4-16-core-8-core-desktop-cpus-spotted/

robbitop

2022-01-08, 11:35:48

Soeht nach nem komischen Sonderfall aus. 5x so viel INT Durchsatz?

Neurosphere

2022-01-08, 11:47:42

Kenne die Software nicht, evtl. hilf da auch die GPU (iGPU?) mit?

Benutzername

2022-01-08, 17:46:07

So lange es DDR5 gibt. Heißt aber nicht, dass die ersten AM5 Boards noch kompatibel sind mit den Prozessoren in 4 Jahren.
Ich habe einen 1600X mit AM4 320er Board. Unterstüzt nur bis Ryzen 3xxx.

Ein neuerer Ryzen würde vermutlich auch darauf laufen, wenn das UEFI bzw. combopi passt. Ist ja dann doch meistens die Firmware, die fehlt. Es haben ja auch shcon Leute UEFIs zusammengehackt um zB neuere Ryzen-G in einen Asrock A300 zu stecken. Auf anderen boards haben andere auc hschon sowas gebastelt. Gehen ginge das schon, hat aber der Mobo-Hersteller natürlich kein Interesse daran, die Firmware nachzuliefern. War ja aber schon weiter oben geklärt.

Nakai

2022-01-08, 18:01:04

Caching Effekte?

iamthebear

2022-01-09, 14:00:27

Vielleicht auch einfach nur ein Mess/Auslesefehler. Die 16 Kern Variante hat auf einmal nur mehr 1/16 davon.
Der größere L2 kann das nicht erklären. So groß ist der Unterschied zwischen L2/3 Latenz nicht.

basix

2022-01-09, 14:11:41

Soeht nach nem komischen Sonderfall aus. 5x so viel INT Durchsatz?

AVX-512? Kenne mich mit dem Algo von MilkyWay@Home nicht aus.

Twodee

2022-01-09, 14:27:00

AVX-512? Kenne mich mit dem Algo von MilkyWay@Home nicht aus.
Das hat nichts mit dem Algo von MilkyWay@Home, sondern mit dem integrierten Benchmark im BOINC-Manager (welcher nichts mit dem zu rechnenden Projekt zu tun hat).
Tatsächliche Laufzeiten der Workunits (und wie viele davon zur gleichen Zeit) wären aussagekräftiger.
Btw.: Der Source vom BOINC-Manager ist opensource und somit ein leichtes diesen zu modifizieren (Hardware-Kennung und Bench-Ergebnisse wären leicht zu faken).

HOT

2022-01-11, 16:26:26

https://www.techpowerup.com/290798/amds-lisa-su-confirms-zen-4-is-using-optimised-tsmc-5-nm-node-2d-and-3d-chiplets

Damit ist die VCache-Variante von Zen4 indirekt bestätigt. Man scheint auch eine Art N5"e" zu nutzen, also einen angepassten N5 HPC.

Berniyh

2022-01-11, 16:29:47

Man scheint auch eine Art N5"e" zu nutzen, also einen angepassten N5 HPC.
Gab es die Info nicht schon mal vor Monaten? Stand das e nicht für enhanced o.ä.?

basix

2022-01-11, 17:23:04

Damit ist die VCache-Variante von Zen4 indirekt bestätigt.

Schau dir die Source von Anandtech an. Das liest sich dort ganz anders. Ebenso die Interpretation, dass es verschiedene Zen 4 Chiplets für 2D und 3D gibt, ist dämlich: 2D Chiplet = CCD; V-Cache = 3D-Chiplet. So einfach ist das. Und es ist N5HPC. Schreibt AMD sogar selbst auf ihre Folien. N5E gibt es nicht. Edit: Es gibt N3E, N4X usw.

Diese "News" von TPU kann man kübeln, die ist nichts wert.

y33H@

2022-01-11, 17:44:58

N5HPC mit Volume in Q2/2022 ist ggf ambitioniert.

78024

Und es ist N5HPC. Schreibt AMD sogar selbst auf ihre Folien.Auf welcher Slide steht das?

Nightspider

2022-01-11, 18:06:33

Also ich bin echt gespannt auf die Performance von Zen4.

Kann fast nur ein riesiger Sprung werden.

Sunrise

2022-01-11, 18:10:06

Dass AMD hier aggressiv einen verbesserten N5 (N5P bzw. HPC) mit TSMC entwickelt hat bzw. nutzen wird, war ja schon mehrfach hier im letzten Jahr mit diversen Quellen beschrieben worden.

AMD scheint dieses Mal auch besonderen Wert auf hohe sustained Taktraten zu legen um Single-Core noch weitere pushen zu können. Das geht natürlich nur dann, wenn sie die Wahl haben, nicht nur die hohe Dichte vom neuen Node zu nutzen, sondern zusätzlich auch noch mehr Spielraum bei Takt bzw. Power Consumption (7% bzw. 15% laut TSMC) zu haben.

War auch schon damals bekannt geworden, da Anandtech das mit einem entsprechenden Artikel schon Mitte 2019 beschrieben hat (https://www.anandtech.com/show/14687/tsmc-announces-performanceenhanced-7nm-5nm-process-technologies), der aber AMD hier noch nicht erwähnt. Das kam erst ein Jahr darauf von chinesischen Quellen (März) nach.

AMD hat es im Prinzip ja jetzt auch schon geteasert, Zen4 wird sehr hohe Takte (im Boost) fahren können, natürlich mit der entsprechenden TDP. Alternativ nutzt man eben niedrigere Takte aber nimmt die 15% bessere Power Consumption mit (siehe Zen4c).

Berniyh

2022-01-11, 18:26:32

N5E gibt es nicht.
N7E (und jetzt ggf. N5E) sind wohl interne Bezeichnungen für das was AMD bei N7 bzw. N5 verwendet, d.h. ein angepasster Prozess basierend auf der jeweiligen Node.
Ob jetzt TSMC-intern oder AMD-intern oder beides wissen wir aber natürlich nicht.
Das zumindest war die Info die schon vor Monaten mal rumgeisterte.

Dass AMD angepasste Prozessnodes verwendet gilt aber ja eigentlich als gesichert.

y33H@

2022-01-11, 20:25:22

N5P ungleich N5HPC.

HOT

2022-01-11, 21:08:40

N7E (und jetzt ggf. N5E) sind wohl interne Bezeichnungen für das was AMD bei N7 bzw. N5 verwendet, d.h. ein angepasster Prozess basierend auf der jeweiligen Node.
Ob jetzt TSMC-intern oder AMD-intern oder beides wissen wir aber natürlich nicht.
Das zumindest war die Info die schon vor Monaten mal rumgeisterte.

Dass AMD angepasste Prozessnodes verwendet gilt aber ja eigentlich als gesichert.
AMD sprach bei der XBox Vorstellung von N7e. Das ist einfach deren Name dafür.

N5P ungleich N5HPC.

Ich bin gespannt ob AMD wieder N5P für die GPUs verwendet. Ist N4 wieder kompatibel zu N5? Ja oder? Dann könnte man hinterher mit N4 wieder kostenoptimiert arbeiten.

iamthebear

2022-01-11, 22:49:38

HOT

2022-01-11, 23:09:06

Na jo, AMD wird ja schon länger am Zen5-Design arbeiten. Ob in N3 oder N4X weiss halt nur AMD. Die werden aber schon länger wissen, dass TSMC sowas ins Programm nehmen will, also kann das durchaus auch sein.

basix

2022-01-11, 23:14:03

Was ich mir jedoch gut vorstellen könnte ist dass AMD den Cache nur in 6/7nm statt 5nm fertigt da SRAM mit 5nm relativ schlecht skaliert. So könnte man Dual Sourcing betreiben denn 7nm Kapazitäten sollten ja genug frei werden.

Sowas würde ich eigentlich erwarten. Das ist ja einer der grossen Vorteile von Chiplets.

Zu Zen 5:
Der wird nicht vor 2024 erscheinen. N3E/X oder wie der dann auch heisst, wäre mMn naheliegender.

Auf welcher Slide steht das?

N5HPC steht so nicht direkt auf einer Folie. Aber "N5 High Performance Computing" oder "5nm HPC" findet man auf Bergamo/Epyc Folien:
https://www.anandtech.com/show/17055/amd-gives-details-on-epyc-zen4-genoa-and-bergamo-up-to-96-and-128-cores
https://images.anandtech.com/doci/17055/image_2021_11_08T15_13_50_667Z.png

Berniyh

2022-01-11, 23:19:53

davidzo

2022-01-11, 23:28:12

Dass es VCache mit Zen4 geben wird war ja ziemlich sicher. Wenn AMD mit Zen3 ein VCache Modell mit Epyc anbietet so muss der Nachfolger auch ein VCache Modell haben. Sonst ist das für einige Anwendungen ein Rückschritt.
Die Frage ist ob es in den Desktop schafft und hier war die Aussage von Frank Azor, dass es vom Erfolg des 5800X3D abhängt.

Bisher gibt s kein einzigen Hinweis auf Zen4X3D. Gab es aber von Zen3 X3D auch bis vor kurzem nicht, das muss also nichts heißen.
basix hat aber schon recht, dass die News mehr zu sein scheint als sie ist.
MD's Lisa Su Confirms Zen 4 is Using Optimised TSMC 5 nm Node, 2D and 3D chiplets
Statt dem Komma vor 2D und 3D sollte eher ein Punkt. Das bezieht sich kein Stück auf Zen4.

In dem Interview finde ich eher auffällig dass Lisa sehr betont dass man "die richtige Technologie für die richtige Anwendung" auswählt. Man hätte auf der einen Seite Prozesse wie 6nm die anscheinend günstig für consumer/mobile sind, dann hätte man neue cores wie Zen4 und Zen5, sowie 2D und 3D Chiplets und den N5e Prozess der auf high performance getunt ist.
Sie nennt das sehr vorsichtig getrennt voneinander dass ich mich wundern würde wenn das nicht Absicht ist.
X3D scheint ein Testballon zu sein, so wie damals Kabylake-G. Man will mal gucken ob die Zeit reif ist, vielleicht ist sie es, vielleicht auch nicht und dann verschwindet dass wieder aus dem consumermarkt wie HBM auch schon. Threadripper Gen1 war auch so ein Testballon, der es allerdings geschafft hat sich zu etablieren.

Dr. Su stated that AMD is continuing to innovate in all areas. For AMD it seems, leading the chiplet technology has helped to bring the package together. She went on to say that AMD has had strong delivery of 7nm, is introducing 6nm, followed by Zen 4 and 5nm, talking about 2D chiplets and 3D chiplets – AMD has all these things in the tool chest and are using the right technology for the right application. Dr Su reinforced that technology roadmaps are all about making the right choices and the right junctures, and explicitly stated that our 5nm technology is highly optimized for high-performance computing – it’s not necessarily the same as some other 5nm technologies out there.

Weil die Volumen CPUs mit Sicherheit nicht auf so etwas teures wie X3D setzen werden, rechne ich zum Zen4 Launch erstmal nicht mit X3D CPUs. Wenn der 5800X3D sehr erfolgreich ist, dann wird man eine Zen4 CPU mit 3dcache eventuell nachschieben, aber das wird sicher nicht von day1 verfügbar sein.

Sonst könnte man sich den 5800x3d ja sparen wenn zwei quartale später zen4x3d kommt.
Und wenn Vermeer X3D im labor schon so gut ist, wieso sind dann scheinbar alle anderen X3D Modelle erstmal gecancelt worden? Weil X3D nur die Gaming-Nische bedient, in anderen workloads langsamer ist und ein Dual-Die X3D dabei in Games nicht schneller aber viel teurer wäre?

basix

2022-01-11, 23:37:53

Zu Zen 4c evtl. ein paar Gedanken:
- Optimized Cache Hierarchy: 512kB L2 sowie 2 MByte L3 pro Core? Halbierung verglichen mit Zen 4. Dazu halbierte L1-Cache Bandbreiten, das ist vor allem für hohe AVX-Leistung nötig, welche aber bei Zen 4c reduziert wird (siehe nächsten Punkt)
- Optimized Zen 4 Core für Scale Out Performance: 1x AVX-512 Unit anstatt 2x. AVX-512 Crunching ist wohl eher nicht typisch für Cloud-Anwendungen.

Allein mit diesen Massnahmen würde die Fläche eines Cores drastisch sinken. Vermutlich nicht viel grösser als ein normaler Zen 3 Core (auf Anzahl Transistoren / Fläche bei iso Prozess bezogen). Und die Änderungen am Core halten sich in Grenzen, was bezüglich Designaufwand sehr vorteilhaft wäre. Ebenso identische Befehlssätze, selbe sonstige Features, sehr ähnliche IPC. Beim Herstellungsprozess ist allenfalls noch die Frage, ob man auf eine höhere Density und Low(er) Power Libraries geht. Das 8C Zen 4 CCD wird mit 72mm2 geschätzt. Zen 4c mit 16C dann evtl. ~90...95mm2?

Edit:
Bisher gibt s kein einzigen Hinweis auf Zen4X3D. Gab es aber von Zen3 X3D auch bis vor kurzem nicht, das muss also nichts heißen.
...
Weil die Volumen CPUs mit Sicherheit nicht auf so etwas teures wie X3D setzen werden, rechne ich zum Zen4 Launch erstmal nicht mit X3D CPUs. Wenn der 5800X3D sehr erfolgreich ist, dann wird man eine Zen4 CPU mit 3dcache eventuell nachschieben, aber das wird sicher nicht von day1 verfügbar sein.
Ich gehe eigentlich davon aus, dass es von Zen 4 eine X3D Variante geben wird. Zumindest im Rahmen von Epyc oder Supercomputer definitiv.

Sonst könnte man sich den 5800x3d ja sparen wenn zwei quartale später zen4x3d kommt.
Und wenn Vermeer X3D im labor schon so gut ist, wieso sind dann scheinbar alle anderen X3D Modelle erstmal gecancelt worden? Weil X3D nur die Gaming-Nische bedient, in anderen workloads langsamer ist und ein Dual-Die X3D dabei in Games nicht schneller aber viel teurer wäre?

Momentan hat man zu geringe Fertigungskapazitäten. Und ein 5800X3D macht gegen Alder Lake ebenfalls mehr Sinn. Das kann bei Zen 4 schon etwas anders aussehen.

Ich würde X3D bei Zen 4 hauptsächlich für zwei Dinge sehen:
- Refresh-Zyklus
- Konter, falls Intel mal noch mit was kommt

Am ersten Tag erwarte ich ebenfalls nicht X3D. Das kannibalisiert die Sales der 2-Chiplet SKUs ein wenig. Aber wer weiss. Hängt auch ein wenig von der Performance von Zen 4 und Raptor Lake ab.

Zossel

2022-01-12, 06:57:26

Man will mal gucken ob die Zeit reif ist, vielleicht ist sie es, vielleicht auch nicht und dann verschwindet dass wieder aus dem consumermarkt wie HBM auch schon.

GDDRx wird immer aufwendiger, das könnte wegen zu wenig "Vorteilen" auch irgendwann verschwinden.

Weil die Volumen CPUs mit Sicherheit nicht auf so etwas teures wie X3D setzen werden, rechne ich zum Zen4 Launch erstmal nicht mit X3D CPUs. Wenn der 5800X3D sehr erfolgreich ist, dann wird man eine Zen4 CPU mit 3dcache eventuell nachschieben, aber das wird sicher nicht von day1 verfügbar sein.

Je nach Anwendung könnte auch ein Zen4 ohne extra Cache langsamer sein als ein Zen3 mit extra Cache.

y33H@

2022-01-12, 09:36:22

N5HPC steht so nicht direkt auf einer Folie. Aber "N5 High Performance Computing" oder "5nm HPC" findet man auf Bergamo/Epyc FolienDanke, das hatte ich tatsächlich übersehen ;(

Tarkin

2022-01-12, 11:00:30

Igor sagt in seinem aktuellen AM5 Video btw... Raphael kommt in Q3

HOT

2022-01-12, 11:24:17

Das passt ja auch gut. Vorstellung bestimmt wieder 5.5., AMD liebt ja sowas, und Tests + Verkaufsstart dann Juli oder August.

amdfanuwe

2022-01-12, 11:40:18

@HOT
Vielleicht zu normalen Zeiten ohne Kapazitätsproblemen.
Ich rechne eher mit September Vorstellung und halbwegs Verfügbar ab November.

basix

2022-01-12, 11:58:34

Q3 Release wäre schon recht nice. Deutlich vor Raptor Lake. Wenn es gleichzeitig noch N33 gibt und in Q4 N32/N33 wäre das ziemlich cool.

Leonidas

2022-01-12, 13:36:41

Wäre ein Traum. Aber andere Leaker habe auch schon klar von Vorstellung Oktober, Marktstart November für Zen 4 Consumer gesprochen. Und wie früh AMD was ankündigt oder in den Server-Bereich schickt, steht da noch auf einem ganz anderen Blatt.

HOT

2022-01-12, 14:16:28

Wobei die "anderen Leute" dahingehend wohl kaum belastbare Aussagen getätigt haben. Das wird schon passen mit Q3. CPUs zu fertigen wird kein Problem sein, die Boards können ja nach AMDs AM5-Aussage relativ schnell starten. Lt. AMDs Aussage hier:
https://www.pcgameshardware.de/AMD-Zen-Architektur-261795/News/Ryzen-6000-Rembrandt-auf-AM5-fuer-Desktop-PCs-1386931/
kann AMD AM5 starten, sobald sich die DDR5-Situation entspannt. Es kommt also letztendlich auf 2 Faktoren an:
- Wann beginnt die Massenproduktion von Zen4
- Ist DDR5 in ausreichender Stückzahl am Markt
Interessant wird da eher die Preisentwicklung sein, wie teuer die Teile und vor allem die Boards werden, da mach ich mit ein bisschen mehr Sorgen. Immerhin scheint AMD jetzt alle Boards gleichzeitig starten zu können, da ja alles auf demselben Chipsatz basiert. Beim 670X gibts halt 2 davon.

davidzo

2022-01-16, 13:02:30

X3D ist doch gar nicht notwendig um Intel zu kontern. Bei der Cache hitrate hat AMD sowieso schon die Nase vorn und auch Raptorlake wird daran nicht viel ändern.

Zen4 reicht auch ohne X3D schon um Raptorlake in die Schranken zu weisen. Dazu ist Golden Cove einfach noch zu nahe an Zen3 bei der IPC und Raptor cove wird wohl kaum fundamentale veränderungen bringen abseits des größeren L2s, da man ja auch noch die Monts verdoppelt.

IPC-technisch ist Zen3 schon jetzt beinahe auf Augenhöhe mit Golden Cove, es ist im Wesentlichen das Taktdefizit und DDR5 Speicher welcher Zen3 fehlt.

Und dabei hat Alderlake schon 50% mehr execution ports und zum Teil 100% mehr oOo Ressourcen (2x ROB, 2x FPregister, 2x RegFlags, 1,8x store queue etc.). L1 und L2 sind bereits jetzt eine Dampfwalze, hohe Latenz, maximale Bandbreite und den riesigen ROB braucht man auch um die Latenzen zu kaschieren.
Dafür dass das an vielen Stellen gut doppelt so breit ist wie Zen3, und auch entsprechend Transistoren und Diefläche kostet, kommt am Ende erstaunlich wenig bei heraus. Und das säuft natürlich wie ein Loch wenn mal richtig Last anliegt. Respekt aber wie Intel das bei teillast clock gegated bekommt so dass der idleverbrauch nicht explodiert ist.
In wirklichen Lastzenarien trennt sich aber die Spreu vom Weizen und bei Epyc sieht man ja dass Zen3 mal eben die doppelte sustained performance bei gleicher TDP auf die Straße kriegt wie ein 3rd gen Xeon scalable/ Icelake SP.

Zen3 hat nicht nur den besseren Branch predictor, was hilft Energie zu sparen, sondern auch die geringeren Latenzen in allen cache Stufen, vor allem im L3. Dadurch brauch man keine so großen L1+2 caches und keinen so großen ROB.
Den größten Vorteil hat AMD im L3 cache. Der ist schon ohne X3D größer, hat die geringere Latenz trotz höherer Bandbreite (MT). Nur bei der ST Bandbreite hat Alderlake die Nase vorn und natürlich beim DRAM zugriff durch DDR5. Ich frage mich ob Alderlake überhaupt spürbar vor Zen3 liegen würde, wenn letzterer ebenfalls DDR5 hätte? Die DDR4 Tests von Alderlake zeigen ja dass der Vorteil dann im wesentlichen dem Taktunterschied entspricht.

Ich denke AMD hat es ausgehend von Zen3 wesentlich einfacher die Architektur aufzubohren, da sie noch sehr schlank ist und man mit 5nm ein gigantisches Transistorbudget zur Verfügung hat. Das ist einfach wünsch dir was, während intel bei raptorlake mit derselben 10nm+++ Fertigung und supplyabhängigen diesize constraints klar kommen muss.
- Größerer ROB macht bei dem großen L3 sowieso sinn und sollte direkt IPC bringen.
- Eventuell 1x bis 2x mehr execution ports, also ggf. gleichauf mit Golden Cove an der Int-execution front.
- gesteigerte L1 Bandbreite passend zum rob und execution port upgrade
- L2 vergrößert auf 1Mb.
- Aufgebohrte FP-units, multicycle AVX-512, mehr FP register, mehr execution ports. Eigentlich unnötig, da Zen3 hier ohnehin sehr gut gegenüber Golden Cove dasteht.

Und Zen4 stellt nicht nur den Vorsprung von 1x Fullnode Sprung gegenüber der Intel Fertigung wieder her den man mit Zen2 hatte, sondern nach all dem was wir über TSMC/AMDs N5 Prozess wissen, ist das sgar ein waschechter HPC node. Das heißt wir sehen erstmals seit 32nm SOI einen echten custom Prozessornode bei AMD. Die Taktraten werden steigen - ich würde nicht damit rechnen dass Intel bei Raptorlake noch irgendeinen Taktvorsprung vorweisen kann, eher umgekehrt.

MSABK

2022-01-16, 13:09:40

Ich denke den 3dcache wird sich AMD für Zen 4+ aufheben um evlt kontern zu können wenn Intel schneller wird.

Nightspider

2022-01-16, 13:18:18

davidzo

2022-01-16, 16:42:45

V-Cache ist auf jeden Fall keine Universallösung, sondern ein spezieller Anwendungsfall und wird deswegen auch nur auf bestimmten CPUs verbaut werden.

Chips and Cheese hat das mal simuliert und dabei in vielen Anwendungen Regressionen von 5-8% erhalten wenn man von 32mb@46cycles auf 96mb @52cycles geht.
https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2021/09/image-18.png?ssl=1

In der Realität sind es statt 6 cycles Penalty wohl nur 3-4 bei 3D V-cache wie C&C jüngst geteased haben: https://chipsandcheese.com/2022/01/14/amds-v-cache-tested-the-latency-teaser/
Aber da werden immer noch Regressionen von 3-5% bleiben. Wohlgemerkt bei gleichem Takt und der Takt bleibt ja eben nicht gleich sondern sinkt auch nochmal 5%.

Bei Spielen bringt das ganze dann wiederum simuliert biszu 20% mehr performance bzw. ein Average von 12-15%.
Btw, die haben das auch it zero cycle Latenzzuwachs getestet und die meisten Workloads zeigen dann überhaupt keinen Vorteil für Vcache an, während diejenigen die Zuwächse haben auch nur minimal über den werten liegen die auch mit größeren Latenzen schon zuwächse hatten.

Das ganze ist für Spezial usecases, nicht für den Average consumer.

robbitop

2022-01-16, 19:10:45

Eventuell bringt AMD V-Cache zuerst in Genoa-X. Dort kann man am meisten Geld verlangen für den V-Cache.

Zen4 wird auf jeden Fall eine mächtige Architektur.

Ich erinnere nochmal daran das letztes Jahr einige Gerüchte von 40% mehr Leistung bei Genoa pro Kern sprachen.
Davon könnten 10-15% durch N5 und höheren Takt kommen und die IPC soll ja sowieso einen großen Sprung machen.

Das ganze bei der geringen Leistungsaufnahme wie bei Zen3 und das werden super Prozessoren werden.

Ich glaube eher Zen 5 wird richtig mächtig. Erstens weil er Zen4C als little Cores betrachtet. Und außerdem hat in dem Interview mit Ian einer der Zen Väter auch gehintet, dass Zen 5 ein besonderer Meilenstein wird iirc in dem Zusammenhang dass man irgendwann mal breiter als 4 wide werden wird.

Nightspider

2022-01-17, 01:21:40

Ja gut, Zen5 kommt in N3 und ist nochmal 2 Jahre weiter entfernt.

Schön ist es sowieso das man gefühlt alle 2 Jahre einen größeren Sprung bekommt.

Wenn man sich überlegt das man bei Intel 6 Jahre lang 14nm CPUs bekommen hat die bei der IPC fast auf der Stelle standen.

robbitop

2022-01-18, 09:28:46

Eigentlich bis dato immer 5 Quartale - also nicht 2 Jahre weiter als Zen 4.

Ich habe da rausgelesen, dass Zen 4 den üblichen Sprung bringt und Zen 5 einen mehr als üblichen. Sozusagen AMDs "royal core".

basix

2022-01-18, 10:16:11

Ich tippe bei Zen 5 auf H1/2024, wenn wir Glück haben allenfalls auch Q1/2024.

Zen 5 könnte/sollte in N3(E) daherkommen. Daher wohl auch eine Abhängigkeit von N3 Verfügbarkeit bei TSMC.

robbitop

2022-01-18, 11:10:33

Wenn es N3 ist wird es aufgrund der Verfügbarkeit allein schwierig - das stimmt. Serienfertigung geht H2 2022 los. Je nach dem ob AMD entsprechende Kapazitäten (teuer) vorgebucht hat wäre aber auch H2 2023 möglich.

Aber ja: normalerweise sind die smartphone SoCs erstmal dran bevor die PC Chips kommen. In der Regel 1-1,5 Jahre Vorsprung. Dann wären wir bei H1 2024.

basix

2022-01-18, 11:44:19

H2/2023 wäre prinzipiell möglich, ja. Genau hier laufen die Mobile SoCs dann aber in Höchstvolumen. Ich glaube nicht, dass AMD hier so früh einsteigen will. Mit HPC-Beschleunigern wie MI300/400 evtl. ja aber die haben deutlich geringere Volumen.

Alternative wäre N4X. Der ist aber sogar später dran als N3E.

robbitop

2022-01-18, 12:10:17

Die Frage ist, was AMD dieser Vorteil (time to market und Prozessvorteil) wert ist und wie Reif für ein HPC Produkt der Prozess im gewünschten Timeframe ist.
Was dieser Vorteil bedeutet, sah man mMn sehr gut am 2020 M1 und A14. Die haben alles zertreten, was es an Wettbewerber SoCs gab in Bezug auf Perf/W. Das lag sicherlich nicht allein an N5 aber es war sicherlich ein guter Vorteil.

Wenn die Reservierung eines state of the Art Prozesses solche Vorteile ggü AMD's Wettbewerbern in 2023 bringen würde, könnte man gerade bei Epyc diese auch durch hohe Gewinnspannen monetarisieren und auch die Marke weiter deutlich stärken.

Aber anhand der Historie würde ich vermuten, dass Zen 5 kein N3 Erstkunde sein wird.