News CPU-Gerüchte: Angaben zu Zen 5 und Zen 6 angeblich von AMD

[Rockstar85]

Was denn für GERÜCHTE, es gibt ganz offiziell keinen Zuwachs, weil man dieselben P Cores von Alder/Raptor Lake verwendet

Intel sagt selbst, dass Lunar anders werden soll. Und wie du schon sagtest, ist Meteor nur ein Tick und nicht mehr.
Dennoch wird Intel am Takt drehen um AMD zu schlagen.

 

[foofoobar]

Klar,

Sollten die IPC Gerüchte von Meteor stimmen, wird AMD nicht wirklich massiv an der Taktschraube drehen.. Sollte allerdings Intel mehr IPC zulegen, und die ~20-25% IPC bei AMD stimmen, wird AMD oberhalb der 125W rauskommen... Die Gretchenfrage ist halt, wie gut die Verdoppellung bei AMD in IPC fust.

Orientiert sich AMD wirklich an Intel?

Desktop ist bei AMD das was bei den Servern abfällt, und mobil ist lt. AMD Apple der Maßstab.

 

[stefan92x]

Orientiert sich AMD wirklich an Intel?

In Sachen Architektur sicher nicht, aber was TDP und Takt angeht (worum es dem Kommentar ja ging), kann man schon davon ausgehen, dass AMD die Marktsituation berücksichtigt.

 

[ETI1120]

Das würde ich jetzt nicht zwingend so sehen. Turin Dense/Breithorn Dense kann trotzdem durchaus ein 16 Core ZEN5c CCX nutzen.Strix ist mit der Mischung aus ZEN5c und ZEN5 wieder eine andere Gecshichte und vor allem ein Monolith. Das ist so oder so ein extra Tapeout.

Das hat AFAIK nichts mit den Dies zu tun. Der kritische Faktor ist viele Kerne mit niedriger Latenz und unter beibehalten der Cache-Kohärenz an den L3-Cache anzubinden. Wenn AMD das mit 16 Kernen gelingt, sehe ich keinen Grund warum AMD dies nicht auch mit 12 Kernen machen sollte.

Das Aufteilen auf 2 CCX bringt andere Herausforderungen.

Außerdem besagt die angebliche Roadmap, dass das Zen 5 CCD ein CCX mit 16 Cores haben soll. MLID selbst schreibt Zen 5 hat ein CCX mit 8 Kernen und Zen 5c hat ein CCX mit 16 Kernen. Wobei es gerade für Zen 5c IMO eher wenig bringt auf 16 Kerne im CCX zu gehen.

Orientiert sich AMD wirklich an Intel?

In Sachen Architektur sicher nicht, aber was TDP und Takt angeht (worum es dem Kommentar ja ging), kann man schon davon ausgehen, dass AMD die Marktsituation berücksichtigt.

Aber bei den Entscheidungen die für die Architectur getroffen werden ist doch auch die End-Freuquenz weitgehend festgelegt. Bei Ryzen 7000 wird doch ziemlich deutlich, dass das Hochprügeln der TDP nichts bringt. IMO hat es AMD massiv geschadet.

 

[Rockstar85]

Aber bei den Entscheidungen die für die Architectur getroffen werden ist doch auch die End-Freuquenz weitgehend festgelegt. Bei Ryzen 7000 wird doch ziemlich deutlich, dass das Hochprügeln der TDP nichts bringt. IMO hat es AMD massiv geschadet.

Wir Leben halt in einer Welt, des schneller , höher Weiter.. Und da braucht es dann am ende 50W für für vlt 5%
Weil Strom zahlen ja die Konsumenten.. Und genau darum geht es. Man sieht ja sehr deutlich, wo die Sweet Spots sind und wo nicht. AMD wird zu 99% sich mit dem Takt an Intels Generationen angleichen.. Reicht es halt nicht für einen Arrowlake mit berechneten 95W TDP, kommt die 125W Keule oder gar 150W.
Gut halte ich das alles nicht, da AMDs 7700X am Ende unter 65W Limit eindrucksvoll zeigt, wie gut Zen4 als Architektur ist.
Aber ich bin halt nicht der Markt.

 

[ETI1120]

Wir wissen nicht was Intel abliefert. Wir wissen nicht was AMD abliefert. Entschieden wird das ganze über Architektur und Fertigungsprozess.

Heizen kann sich nur Intel leisten. AMD hat das schon des öfteren getan, aber es hat AMD immer geschadet, besonders im Notebookmarkt.

Ich gebe die Hoffnung nicht auf, dass es AMD Mal kapiert.

Wir Leben halt in einer Welt, des schneller , höher Weiter

Ja das erzählt man sich so gerne. Stimmt aber so pauschal nicht.

Wie war das mit der Concorde?

Viel wichtiger als die Performance ist das Image. Und in der Technik gewinnt letztendlich immer die Effizienz.

Nur in den Luxusnischen funktioniert Performance um jeden Preis, aber eben nur wenn auch das Image stimmt.

Und da braucht es dann am ende 50W für für vlt 5%

Es sind 88 W für 5 % Performace mehr oder knapp mehr 62 % Power für 5 % mehr Performance.

Das ist die Definition von Verheizen.

Gut halte ich das alles nicht, da AMDs 7700X am Ende unter 65W Limit eindrucksvoll zeigt, wie gut Zen4 als Architektur ist.
Aber ich bin halt nicht der Markt.

Wir können festhalten, dass das Release nicht gut gelaufen ist. Spricht nicht unbedingt für den Erfolg der Strategie heizen ohne Performance Plus.

Es gab Herausforderungen durch den gesättigten Markt, teures RAM und teure Mainboards. Bei den Mainboard-Preisen hat natürlich die zusätzliche Power auch ihren Effekt.

Hauptkritikpunkt neben den Preis für die Plattform war beim Release die schlechte Effizienz. Und hier hat IMO AMD ziemlich leichtfertig ein Kernargument gegen Intel weggeschmissen.

 

[RKCPU]

Das Aufteilen auf 2 CCX bringt andere Herausforderungen.

Außerdem besagt die angebliche Roadmap, dass das Zen 5 CCD ein CCX mit 16 Cores haben soll. MLID selbst schreibt Zen 5 hat ein CCX mit 8 Kernen und Zen 5c hat ein CCX mit 16 Kernen. Wobei es gerade für Zen 5c IMO eher wenig bringt auf 16 Kerne im CCX zu gehen.

Im Mobilbereich max 16 Zen5, dafür aber auch 4x Zen5 plus 8x Zen5c nach aktuellen Spekulationen.
Sollte AMD beim Zen 5c erweiterte Modulbauweise nutzen, also shared L2, wie 1,5 MB und erweiterte shared FPU setzen dann würden 12 Cores am 8er CCX passen. Die FPU ist für die meisten Anwendungen der Zen 'c' nur selten genutztes Beiwerk.

Beim Zen5c Chiplet könnten dann 8 Module die 16 Cores ergeben, welche dann aber durchaus 64 MB L3 aufweisen könnten (L3 ist bei 'c' ja kompakter).

16 Core CCX beim Zen5 stellt die Frage welche Produkte dann kommen würden, denn auf 6-Core gestutzt macht dann wenig Sinn.

 

[RKCPU]

Fuer die meisten Desktop-Benutzer reichen die PCIe-Lanes aus, noch dazu wo die PCIe 5.0 sind. Fuer eine Anbindung von mehr NVMe-SSDs (auch nur eine Minderheit der Desktop-Nutzer) koennen sie ein Chipset mit mehr PCIe-Lanes bringen, ohne Sockelwechsel. Etwas groesseres ist fuer die meisten Desktop-User auch nicht noetig, und wenn Zen6 32 Cores pro CCX (und damit auch pro CCD) hat wie auf der Folie angekuendigt, waeren 2 CCDs eine Unmenge an Cores (ich vermute aber, von den grossen Cores, die man als Desktop-Nutzer haben will, gehen sich weniger auf einem CCD aus, der noch in AM5 passt).

Ein Ryzen 9000 mit 32 Cores je Chiplet ergibt keinen Sinn, er ersäuft in der Abwärme des DIE - selbst in 2nm Technik.

Viel Platz benötigt weiterhin der L3-Cache, da wäre eher 8er CCX mit nativ 24 MB, dazu 1-2 3D Lagen mit dann 24+48 MB bzw. 24+96 MByte sinnvoll. Der Ryzen 9600 hätte dann eben nur 24 MB, ein 9700X3D dann 8-Core 72 MB.

Beim Zen6c ist das anders, wobei Intel ja jeweils ein Cluster mit 4 Cores bildet, je 4 ähnliche an ein 8er CCX und fertig wäre ein 32-Core.
Der 'c' schleppt viel FPU und L2 mit sich rum, eigentlich zuviel Fläche, die selten benötigt wird.
Ich tippe mal, dass Zen 5c Modulbauweise bekommt, also 4-fach SMT FPU, 2x Integer und shared 1,5M L2 je Modul bei 2/4 Threads. Zen 6c würde dann 'nur' SMT im Vollausbau verlieren, die FPU bliebe gleich, L2 dann 2M. Teildeaktiviert wieder 2/4 SMT.
Ein 8er CCX hätte dann 4x Zen 6 plus 4x 4 Zen 6c am gleichen L3 und als APU's. Die Zen 5c und 6c DIE's dürften einen L3 bekommen, der auch via 3D Chip erweiterbar ist, wie 48 MB plus 48 MB on Top.
Viel Spekulation, aber AMD muss die teuren Wafer ab 5nm auch effizient nutzen.

 

[mae]

Ein Ryzen 9000 mit 32 Cores je Chiplet ergibt keinen Sinn, er ersäuft in der Abwärme des DIE - selbst in 2nm Technik.

Es gibt 96-Core-Threadripper mit 350W TDP, warum sollte da ein 32-Core Ryzen mit 170W TDP in Abwaerme ersaufen? Wenn ich mich recht an die Tests erinnere, laufen die 16-Kerner gut mit 88W power target (65W TDP bei AMD). Also braucht AMD dafuer nicht einmal einen stromsparenderen Prozess.

Wenn Du jetzt darauf hinaus willst, dass die 96 Cores sich ja auf 12 dies verteilen. Stimmt schon, aber ein die mit 32 Kernen ist 4 mal so gross wie eins mit 8 Kernen, die Abwaerme verteilt sich entsprechend auf eine groessere Flaeche.

 

[stefan92x]

Es gibt 96-Core-Threadripper mit 350W TDP, warum sollte da ein 32-Core Ryzen mit 170W TDP in Abwaerme ersaufen?

Der TR verteilt die 350W auf 12 CCD und einen großen IOD. Die 170W für einen Ryzen mit einem CCD würden komplett auf diesem anfallen. Das ist also ganz grob die vierfache Wärmemenge pro CCD verglichen mit dem TR und würde daher verdammt schwer bis unmöglich zu kühlen sein.

 

[PS828]

kühlung ist bei TR kein problem. die geht gut weg durch den großen IO die und die vielen chiplets zusammen mit dem riesen IHS. kann man locker 800W+ abführen.

wichtig ist hier inwiefern AMD möglichkeiten zur leistungsanpassung gibt. epyc geht auch bis 420W für SP5 da wirds bei TR doch sicherlich möglicheiten zum tunen geben, selbst für den Pro

 

[ETI1120]

Im Mobilbereich max 16 Zen5, dafür aber auch 4x Zen5 plus 8x Zen5c nach aktuellen Spekulationen.

Das Problem liegt im Wort Spekulationen.

Ich halte es für sehr wahrscheinlich, dass sowohl Dragon Range als auch die beiden Phoenix Zen 5 Nachfolger bekommen. Ob Strix Point in der genannten 4 P und 8 E Konfiguration kommt, werden wir sehen. 2 P und 4 E wie bei Phoenix 2 wäre dann aber ein großer Abstand zwischen Strix Point und Strix Point 2.

Heute hat Harakuze5719 ein paar SKUs von 7000G und 8000U veröffentlicht. Es sind nur Phoenix 2 bzw. der Refresh enthalten. Die Grafiken enthalten aber offensichtliche Fehler. Eine Quelle nennt Harakuze5719 nicht.

Sollte AMD beim Zen 5c erweiterte Modulbauweise nutzen, also shared L2, wie 1,5 MB und erweiterte shared FPU setzen dann würden 12 Cores am 8er CCX passen.

Auch hier gilt, man kann sich viel vorstellen.

Zum shared L2 für die E-Cores bei Strix Point gibt es sich widersprechende Leaks. Auch wenn mich die Idee sehr reizt, ist das Leak aus dem es stammt nicht vertrauenswürdig. Dieses Leak besteht aus 2 Screens und zeigt auf beiden Screens verschiedene Werte für die Größe des L3-Caches. Von den unsinnigen Taktraten Mal abgesehen.

Die Modulbauweise wäre ein tiefgreifender Unterschied zwischen Zen 5 und Zen 5c. AMD hat bei Zen 4c die FPU unverändert übernommen, deshalb ergibt ein so tiefgreifender Wandel für mich keinen Sinn.

Die FPU ist für die meisten Anwendungen der Zen 'c' nur selten genutztes Beiwerk. Beim Zen5c Chiplet könnten dann 8 Module die 16 Cores ergeben, welche dann aber durchaus 64 MB L3 aufweisen könnten (L3 ist bei 'c' ja kompakter).

Zen 4c hatte weniger Cache je Kern als Zen 4. Der Performance hat es, wie die Benchmarks von Phoronix für Bergamo und Siena zeigen, nur wenig geschadet. Deshalb gibt es keinen Grund für AMD den L3-Cache bei Zen 5c zu vergrößern. Ich sehe auch keinen Grund für eine Zen 5c Variante mit 3D V-Cache.




Bei allen Überlegungen zu einem größeren On-Die Cache muss berücksichtig werden:

1. Wenn man den Cache größer macht, leidet immer auch die Latenz. Wichtig dabei ist, dass die "Latenz-Strafe" klein ausfällt.
2. AMD hat 3D V-Cache um SKUs zu fertigen, die sehr stark von mehr Cache profitieren. Es ist übrigens der Clou, dass beim 3D V-Cache die Latenz nur ein kleines bisschen leidet. Es gibt die Anmerkung von Sam Naffziger, dass 96 MByte in einer Ebene nicht möglich gewesen wäre, weil die Latenz zu schlecht geworden wäre.
3. Der L3-Cache wird zwischen 5 nm und 3 nm nicht skalieren.
4. Hybrid Bonding, das Verfahren mit dem der 3D V-Cache "montiert" wird, ist relativ neu und entsprechend teuer.

16 Core CCX beim Zen5 stellt die Frage welche Produkte dann kommen würden, denn auf 6-Core gestutzt macht dann wenig Sinn.

Dass ich dieses Gerücht sehr skeptisch sehe, liegt vor allem an der Spekulation über die 16 Kern CCX für Zen 5 und die 32 Kern CCX für Zen 6. Und dann sagt MLID im selben Video, dass Zen 5 hat ein 8 Kern CCD und Zen 5c ein 16 Kern CCD haben soll.

Wie gesagt entweder man vertraut seinen Quellen oder man vertraut Ihnen nicht. Die Folie sagt explizit Zen 5 mit einem 16 Kern CCX und Zen 6 mit einem 32 Kern CCX. Da steht kein "up to" aus dem man interpretieren könnte, dass es Varianten gibt.

Ein Ryzen 9000 mit 32 Cores je Chiplet ergibt keinen Sinn, er ersäuft in der Abwärme des DIE - selbst in 2nm Technik.

Kannst Du mir bitte Mal die Logik dahinter erklären? 32 Cores haben die 4 fache Fläche wie 8 Cores. Wenn 32 Cores mit der 4-fachen Fläche die Wärme nicht abführen können dann klappt es auch bei 8 Cores nicht.

Auch die monolithischen Dies nehmen nur eine kleine Fläche unter dem Heat Spreader ein. Das Problem, das sich bei den Ryzen gezeigt hat, ist IMO, dass die CCDs als größte Wärmequelle nicht in der Mitte sondern eher am Rand und bei Ryzen 7000 ganz am Rand des Heat Spreaders sitzen. Dadurch werden Heats Spreader und Kontaktfläche des Kühlers asymmetrisch belastet und können deshalb nicht so effektiv wirken, als wenn die Wärmequelle im Zentrum wäre.

Viel Platz benötigt weiterhin der L3-Cache, da wäre eher 8er CCX mit nativ 24 MB, dazu 1-2 3D Lagen mit dann 24+48 MB bzw. 24+96 MByte sinnvoll. Der Ryzen 9600 hätte dann eben nur 24 MB, ein 9700X3D dann 8-Core 72 MB.

Ich halte es für sehr verfrüht sich über Zen 6 Gedanken zu machen. Zuerst will ich Zen 5 und Zen 5c sehen.

Warum sollte AMD den L3-Cache bei Zen 6 zurückfahren? AMD müsste für sehr viel mehr SKU 3D V-Cache anbieten. Im anderen Post willst Du den L3-Cache bei Zen 5c vergrößern, wo ist da die Logik?

Ich denke es ist nur eine Frage der Zeit bis 3D V-Cache mit mehr als einer Lage auftauscht. Aber im Desktop erst sehr viel später als im Server.

Beim Zen6c ist das anders, wobei Intel ja jeweils ein Cluster mit 4 Cores bildet, je 4 ähnliche an ein 8er CCX und fertig wäre ein 32-Core.

Die Idee mit den Clustern hat mir bei den Mobilprozessoren gefallen. Bei den Servern sind die Cluster IMO eine sehr schlechte Idee.

Der 'c' schleppt viel FPU und L2 mit sich rum, eigentlich zuviel Fläche, die selten benötigt wird.

Das war auch meine erste Idee.

Allerdings sehe ich inzwischen bei der Verwendung von Zen 4c in Siena einen Nutzen in einer starken FPU. Bei Bergamo je nach Anwendung*) ebenfalls. Und AMD hat die Fläche des Kerns massiv reduziert ohne die Funktion der FPU zu beschneiden. Passt doch.

*) Die Benchmarks zeigen dass Bergamo auch für massiv parallele Anwendungen funktioniert, d. h. die Cloudanbieter mit ihren single CPU Instanzen sind nicht die einzigen Anwender von Bergamo.

Das mit AVX-512 aufbohren sehe ich sehr kritisch. Was ist das Problem mit der aktuellen Implementierung? Wie viele Anwendungsfälle profitieren davon? Lohnt es sich dafür den Durchsatz durch das Front end zu verdoppeln?

Beim L2 Cache bin ich ziemlich unschlüssig. Intel braucht einen großen L2 Cache, AMD eigentlich nicht, da der L3 Cache bei Zen 4 hervorragende Latenzen hat. Dementsprechend klein war der Zuwachs an IPC durch das Verdoppeln des L2 Caches.

Ich tippe mal, dass Zen 5c Modulbauweise bekommt, also 4-fach SMT FPU, 2x Integer und shared 1,5M L2 je Modul bei 2/4 Threads. Zen 6c würde dann 'nur' SMT im Vollausbau verlieren, die FPU bliebe gleich, L2 dann 2M. Teildeaktiviert wieder 2/4 SMT.

Bei Bulldozer hat sich AMD entschieden auf SMT zu verzichten und hat statt dessen 2 Integer-Module verbaut. SMD und Integer-Module wäre was neues.

Der Unterschied im Verhalten zwischen Zen 5 und Zen 5c wäre sehr groß, was wiederum erheblich höheren Aufwand bei der Validierung auslöst und für nette Probleme sorgen kann, d. h. dass sich Software auf den Zen 5 und Zen 5c unterschiedlich verhält.

Ich denke das Thema Module hat sich für Zen erledigt. Wenn AMD wieder auf sowas zurück wollte, wird es eine komplett neue Architektur geben und Zen wird beerdigt. Als Teillösung für "c"-Kerne halte ich es für extrem unwahrscheinlich.

Ein 8er CCX hätte dann 4x Zen 6 plus 4x 4 Zen 6c am gleichen L3 und als APU's.

Ein CCD mit P und E Cores ergibt IMO keinen Sinn.

Die Lösung von Intel funktioniert nur, weil AMD bei der Anzahl der Kerne nicht variabel reagieren kann. Für das obere Ende des Desktops funktioniert Zen 4c nicht. AMD müsste das Konzept der "c"-Cores grundsätzlich über den Haufen werfen, wenn "c"-Kerne im High End Desktop eingesetzt werden sollen.

Phoenix 2 hat die doppelte Anzahl von E Cores. Bei Strix Point soll es mit 4 P + 8 E genauso sein. Das ist zwar anders als bei den anderen Hybrid CPUs, aber es könnte das Markenzeichen von AMD Hybrid CPUs sein. Denn da die E-Cores dieselbe IPC haben, kann die Lastverteilung zwischen P und E Cores ganz anders aussehen. Je kleiner das Power Budget ist und je geringer die Frequenz ist, desto attraktiver ist Zen 4c.

Die Zen 5c und 6c DIE's dürften einen L3 bekommen, der auch via 3D Chip erweiterbar ist, wie 48 MB plus 48 MB on Top.

Dafür gibt es keinen Grund. Die TSV kosten Die-Fläche und erhöhen die Fertigungskosten. Für die Applikationen, die vom großen L3-Cache profitieren, gibt es als Basis die klassischen Kerne.

Man modularisiert, um mit wenigen Bausteinen viele Anwendungen abzudecken. Mit mehreren Kombinationen von Dies dieselbe Anwendung abzudecken, ergibt keinen Sinn und ist Resourcenverschwendung.

Nimm doch bitte das Beispiel IOD. Auch ich hätte für Siena einen eigenen IOD erwartet. Aber es kam ganz anders. Und es ist auch nachvollziehbar warum. Wir Laien schauen viel zu sehr auf die Die-Fläche. Und übersehen dabei die vielen anderen Kostenfaktoren. Einen Die für vier Plattformen zu verwenden bringt eine enorme Kostenersparnis bei der Entwicklung und Validierung dieser Plattformen. Die größere Die-Fläche wird außerdem relativiert, weil auch teildefekte Dies verwendet werden können.

Viel Spekulation,

Wenn Du mich fragst viel zu viel Spekulation und das auch noch bei meist ziemlich langweiligen Fragen.
Das winzige was mich wirklich interessiert ist, wie organisiert AMD die Kerne bei Strix Point.

aber AMD muss die teuren Wafer ab 5nm auch effizient nutzen.

Das tut AMD.

Im übrigen hätte ich erwartet, dass AMD erst mit Zen 6 auf 3 nm wechselt, aber AMD selbst hat gesagt dass Zen 5 in 4 nm und 3 nm kommt.

Bei den APUs spricht viel dafür, dass sie in 4 nm kommen. Das IOD soll ja angeblich nicht verändert werden. AMD wird aller Voraussicht nach den N3E-Prozess verwenden und hier ergibt sich für SRAM keine Verkleinerung.

Meine Erwartung ist, dass AMD mit beiden CCDs auf 3 nm wechselt. Nur mit der "c"-Variante auf 3 nm zu wechseln, ergibt für mich keinen Sinn, da man dann für die klassischen Kerne auf die Verbesserungen mit Performance bzw. Power von 3 nm verzichtet .

Was es bringen soll, die CCD zuerst in 4 nm und dann nochmal in 3 nm zu designen, erschließt sich mir nicht. Es bindet Resourcen, die in anderen Projekten fehlen. In diesem Punkt ist MLID auch ganz gewaltig von "3 nm erst 2025" abgerückt.

Die eigentlich für mich interessanten Fragen sind:

• Werden die TSV bei allen Zen 3 und Zen 4 CCD tatsächlich auf die volle Tiefe (ca. 20 µm) hergestellt, oder nur bei den Wafern die für den Einsatz mit 3D V-Cache vorgesehen sind?
  Hintergrund: Das Ätzen ist ein langsamer Vorgang.
• Was bringt Zen 5 in Bezug auf Performance und Power?
• Wann kommen die einzelnen Zen 5 Produkte?
  Zen 4 brachte nicht nur den Umstieg von 7 nm auf 5 nm, sondern auch die Einführung von DDR5 und PCIe 5.0 und deswegen neue Plattformen: AM5, SP5, SP6, TRX40 und WRX90. Das erforderte einen großen Aufwand bei der Validierung. Die Einführung von Zen 5 wird viel einfacher, das die Plattformen bereit sind.
• Wie wird in Zukunft der Releasezyklus bei Zen sein?
  24 Monate wie hier einige meinen, wird IMO auf Dauer nicht funktionieren.
• Wie wird die AIE bei den Chiplet Ryzen und EPYC eingebunden?
  • Auf dem IOD?
  • Auf dem CCD?
  • Als eigenes Chiplet?
• Bleibt AMD mit Zen 5 komplett auf MCM oder wechselt AMD zumindest bei einigen SKUs auf Fanout?
  Mit Fanout können erheblich feinere Leiterbahnen realisiert werden. Im Umkehrschluss bedeutet es, dass eine erheblich höhere Verbindungsdichte möglich ist. Bei derselben Anzahl von Verbindungen ist das Routing erheblich einfacher. Ein Nebeneffekt wäre, dass die Chiplets mit geringerem Abstand positioniert werden könnten.
• Bleibt AMD beim einem classic CCD von Desktop bis Server oder wird es classic CCDs mit unterschiedlicher Anzahl von Kernen geben?
  16 Kerne je CCD sind im Desktop unpraktisch. 6 und 8 Kerne auf dieser Bais wäre zu teuer. Eine APU mit 4 P und 8 E wird die Lücke nach unten nicht schließen. Hier wäre eine APU mit 8 P Kernen erforderlich. Oder eben ein zweites CCD.
• Wann verwendet AMD Hybrid Bonding für andere Chiplet als das Cache Chiplet

Das ist also ganz grob die vierfache Wärmemenge pro CCD verglichen mit dem TR und würde daher verdammt schwer bis unmöglich zu kühlen sein.

Dazu gibt es drei Dinge zu sagen:

1. Die 170 W TDP bei Ryzen 7000 sind komplett unnötig.
2. Die Threadripper werden beschränkt, um sie von den EPYC besser abzugrenzen
3. Nvidia bekommt bei GH100 700 Watt an Wärme abgeführt.

Das Problem ist nicht das Silizium, sondern die sehr ineffizienten Kühlungsmethoden im PC. Anstatt die Wärme gleich auch dem Gehäuse abzuführen wird sie zuerst im Gehäuse verteilt und erst dann abgeführt. Es soll ja schön leise sein.

wichtig ist hier inwiefern AMD möglichkeiten zur leistungsanpassung gibt. epyc geht auch bis 420W für SP5 da wirds bei TR doch sicherlich möglicheiten zum tunen geben, selbst für den Pro

⁵ Overclocking and/or Undervolting AMD processors and memory, including without limitation, altering clock frequencies / multipliers or memory timing / voltage, to operate outside of AMD’s published specifications will void any applicable AMD product warranty, even when enabled by AMD hardware and/or software. This may also void warranties offered by the system manufacturer or retailer. Users assume all risks and liabilities that may arise out of overclocking / undervolting AMD processors, including, without limitation, failure of or damage to hardware, reduced system performance and/or data loss, corruption, or vulnerability. GD-106

Overclocking wird auch bei Ryzen Threadripper PRO 7000 unterstützt. Nur die fertig konfigurierten Systeme werden es nicht unterstützen. Man wird sehen was die Boards auffahren.

IMO reichen 350 W bis 32 Kerne dicke. Bei 64 und vor allem 96 Kernen wird's dann schon dünn. Ich denke man sollte ganz gut rechnen, ob sich die 96 Kerne für die eigenen Anwendungen wirklich lohnen.

 

[ETI1120]

Gestern machte die Runde dass AMD den ersten Zen 5 Patch bei GCC eingelastet hat.
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20240210/b2991675/attachment-0001.obj

Wie üblich ist Phoronix darauf gestoßen:
https://www.phoronix.com/news/AMD-Zen-5-Znver-5-GCC

Der Patch passt zu dem in diesem Artikel gezeigten Leak.

Zen 5 hat 6 anstatt 4 Integer ALU, 4 anstatt 3 AGU, nach wie vor 4 FPU und 2 FP Store Pipes die zusammen geschaltet werden können, um einen 512 bit Wert zu speichern. Damit verdoppelt sich der Durchsatz beim Speichern von FP im Vergleich zu Zen 4.

Massiv verwundert, dass nach wie vor nur 4 Decoder enthalten sein sollen.


Aus dem Patch und Github jeweils ein Auszug aus znver4.md und znver.5md.

InstLatX64 meint dass alles darauf hindeutet, dass AMD die FPUs 512 bit breit gemacht hat.
https://twitter.com/InstLatX64/status/1756450975496183820

 

[RKCPU]

Gestern machte die Runde dass AMD den ersten Zen 5 Patch bei GCC eingelastet hat.
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20240210/b2991675/attachment-0001.obj

Wie üblich ist Phoronix darauf gestoßen:
https://www.phoronix.com/news/AMD-Zen-5-Znver-5-GCC

Der Patch passt zu dem in diesem Artikel gezeigten Leak.

Zen 5 hat 6 anstatt 4 Integer ALU, 4 anstatt 3 AGU, nach wie vor 4 FPU und 2 FP Store Pipes die zusammen geschaltet werden können, um einen 512 bit Wert zu speichern. Damit verdoppelt sich der Durchsatz beim Speichern von FP im Vergleich zu Zen 4.

Massiv verwundert, dass nach wie vor nur 4 Decoder enthalten sein sollen.
InstLatX64 meint dass alles darauf hindeutet, dass AMD die FPUs 512 bit breit gemacht hat.
https://twitter.com/InstLatX64/status/1756450975496183820

Wird dann beim Zen5 auch so ein 'geschrumpftes' Monster verbaut oder die bisherige FPU oder shared eine vergrößerte FPU für je zwei Zen5c Cores wie bei der früheren Modulbauweise?

 

[stefan92x]

Da es auf Software-Ebene keinen Unterschied zwischen Zen 4 und 4c gibt und das hier für Zen 5 dem gleichen Aufbau folgt, würde ich davon ausgehen, dass auch Zen 5 und 5c logisch gleich aufgebaut sind.

 

[ETI1120]

Wird dann beim Zen5 auch so ein 'geschrumpftes' Monster verbaut oder die bisherige FPU oder shared eine vergrößerte FPU für je zwei Zen5c Cores wie bei der früheren Modulbauweise?

Welchen Grund hätte AMD die AI-Leistung der Zen 5c Kerne zu verkleinern?