AMD EPYC Rome Server CPUs - Zen 2 in 7nm TSMC

Wenn der MC auf einem Extra-Die sein soll, und kein Interposer verwendet wird, dann kann man das praktisch garantiert in der Pfeife rauchen. Dann hat man auf allen Dies eine hohe Speicherlatenz, und dazu noch die zusätzliche Die-to-Die-Latenz durch noch mehr Verbindungen. Aktuell hat jeder Die drei Verbindungen zu den jeweils anderen Dies. Sollen die in Zukunft dann 7 Verbindungen haben?

Das sieht jetzt wohl schon so aus:

XVrlsiZ.png
 
Geh mal davon aus, das der Memmory Controler im I/O Chip sitzt. Dann brauchen die Chiplets je nur eine Verbindung zum I/O und keine Untereinander.
 
So oder so bräuchte man dann aber einen Switch mit 8x 50-100 GBit/s Ports plus mind. 2-4x 50-100 GBit/s Ports für eine Verbindung zu mindestens einem anderen Sockel, d.h. der müsste auch eine Backplane/Switching Capacity von mind. 1 TBit/s mitbringen der Chip. Da sehe ich wirklich nicht warum man das nicht gleich als Interposer oder Bridge Chiplet auslegen sollte.
 
Ein normaler Ryzen hat doch schon 4XIFOPs und IFOB over PCIe als Verbindung zum anderem Sockel. Versteh jetzt dein Problem nicht.
Der I/O Chip oder Bridge Chiplet bräuchte grad mal doppelt so viele IFOPs und wenn man am Sockel nichts ändert auch nur vier mal soviele PCIe wie Ryzen.
Kann mir vorstellen, dass bei einer 4 Sockel Lösung weniger Verbindungen zwischen den Sockeln haben, dafür über PCIe 4.0 doppelt so schnelle.

--- Update ---

Interposer benötigt man doch eigentlich nur, wenn viele Verbindungen zwischen den Chips bestehen.
 
Jeder CPU-Die braucht eine Verbindung zu den anderen CPU-Dies. Cache Coherent, usw. Dann hast Du immer noch mehrere Memory Controller auf dem Die, plus PCIe, etc. pp. Wie willst Du das ohne geswitchtes Netzwerk ordentlich hinbekommen?
 
Ich denke wir drehen uns im Kreis. Warten wir also ab, was AMD uns präsentieren wird. Sind ja nur noch ein paar Monate.
 
Für Gaming oder Anwendungen, die niedrige Latency benötigen, wäre das Konzept sicherlich nicht geeignet. Andererseits wäre es wohl sehr wünschenswert, wenn nur noch die Strukuren, die nur für die CPU selbst gebraucht werden, auf dem Chiplet sind, also die Cores, der Cache und eine einzige Anbindung an das System. Dann wäre das Chiplet genau auf das reduziert, was früher in eine CPU war, also ganz ohne North- und Southbridge. Packt man entsprechend viel L2-Cache mit drauf, wird das Chiplet nicht mehr ganz so klein ausfallen.

Zudem könnte dann ein solches Chiplet auch in einer zukünftigen APU Verwendung finden, die allerdings dann wohl auch nicht super für Games wäre. Aber AMD könnte argumentieren: für Gaming gibt es eine eigene CPU nach dem bisherigen Konzept. Den Rest (Server und APU: beide benötigen vor allem Effizienz!) könnte AMD aus den Chiplets zusammen mit einem IGP-IO-Chip je nach Bedarf aufbauen.
 
Zuletzt bearbeitet:
Schau dir die Chips ohne Memmory Anbindung beim Threadripper an. Nur Cores und IFOPs werden verwendet.

--- Update ---

Wäre mal interessant wie die Chips ohne Memmory Anbindung performen, wenn die Cores der Chips mit Memmory Anbindung abgeschaltet wären.
 
Wäre mal interessant wie die Chips ohne Memmory Anbindung performen, wenn die Cores der Chips mit Memmory Anbindung abgeschaltet wären.

Weniger gut, vor allem wenn der Scheduler nichts davon weiß: https://www.anandtech.com/show/1344...-scheduler-wars-with-amds-threadripper-2990wx

Edit: Angeblich soll heute auch der "Dynamic Local Mode" für die Threatripper WX veröffentlicht werden. Da dürfte ein On/Off-Vergleich schon gute Hinweise liefern.

Edit: Bei PC Perspective haben sie das DLM getestet, den deutlichsten Unterschied sieht man bei IOMeter auf einer RAMdisk (logisch), macht immerhin 22% Unterschied.
 
Zuletzt bearbeitet:
Also realistisch betrachtet müsste der Controller Die sogar ein 3.2 TBit/s Switch sein (ist technisch machbar, siehe zum Beispiel Broadcom, aber aufwendig). 100 GBit/s pro CPU-Die (8x), 100 GBit/s pro MC (DDR5 Dual Channel, 4x), 50 GBit/s pro PCIe 4.0 x16/xGMI (8x), und das Full Duplex. Eventuell auch noch mehr wenn z.B. ein L4-Cache drauf ist.
 
Also realistisch betrachtet müsste der Controller Die sogar ein 3.2 TBit/s Switch sein (ist technisch machbar, siehe zum Beispiel Broadcom, aber aufwendig). 100 GBit/s pro CPU-Die (8x), 100 GBit/s pro MC (DDR5 Dual Channel, 4x), 50 GBit/s pro PCIe 4.0 x16/xGMI (8x), und das Full Duplex. Eventuell auch noch mehr wenn z.B. ein L4-Cache drauf ist.

Nicht wirklich denn ich könnte mir auch vorstellen das einfach nur ein BUS System dahinter stehen könnte denn wann benötigt man schon von allen DIE die volle Bandbreite? Die Speicherbandbreite hält sich in Grenzen und bei DMA Zugriffen der Geräte sind die CPU Kerne weitestgehend raus. Da spielt sich die Kommunikation dann weitestgehend im IO Chip statt. Die Kommunikation zwischen den Kernen sollte man per OS eingrenzen können, erste Schritte sieht man ja bereits beim "Dynamic Local Mode". Ja man könnte es sich einfach machen und alle Kerne gleichrangig behandeln aber man könnte sie auch in Blöcke aufteilen und dafür sorgen das die Kerne des Blocks vorrangig genutzt werden, ähnlich dem wie es heute bei SMT gehandhabt wird um die einhergehenden Leistungseinbrüche abzufangen. Da bis heute nur wenige Alltagsprogramme mehr als 8 Kerne nutzen und der Allcore Leistungsgewinn mit den zusätzlichen DIE erheblich größer ausfallen dürfte sollten die Vorteile die Nachteile überwiegen.
 
Man könnte vielleicht, aber, das ist relativ sicher alles fully-switched Netzwerk basiert. Der ganze Kram (Infinity Fabric) basiert ziemlich sicher auf Ethernet-PHY-Technologie. Der Sinn ist die Skalierbarkeit on- und off-chip. Intern wie extern. Vega und Ryzen setzen bereits intern voll da drauf. Das ganze ist z.B. auch QoS-fähig etc. Siehe auch die ganzen Exascale Papers, etc.
 
Das Problem, welches du anscheinend übersiehst ist, dass 7nm sau teuer ist.
Und für den I/O Bereich ists einfach verschwendet.

Das heißt also dass man entweder eine Hybridbelichtung bräuchte, ie 16nm oder whatever für I/O und eben 7nm für die Cores. Hat bisher niemand vorgestellt.
Oder man schmeißt den I/O Teil aus dem CPU die raus und macht nur einfache IF on Chip Verbindungen, die sich auch noch schrinken lassen.


Punkt ist, dass das ganze eine loose/loose Situation ist!
Man kann also einerseits die Yieldraten erhöhen und kosten senken, indem man CPU und I/O Die trennt.
Oder man könnte das aktuelle Design beibehalten und den I/O Teil im CPU Die behalten, dann hätte man aber deutlich schlechtere Yields, würde die Kosten deutlich steigern...

Da kann man nur eines sagen:
Müll ist beides.
und eine "beste Lösung" gibt es hier nicht.
 
Das heißt also dass man entweder eine Hybridbelichtung bräuchte, ie 16nm oder whatever für I/O und eben 7nm für die Cores. Hat bisher niemand vorgestellt.
Oder man schmeißt den I/O Teil aus dem CPU die raus und macht nur einfache IF on Chip Verbindungen, die sich auch noch schrinken lassen.
Hybridbelichtung stelle ich mir ziemlich unpraktisch vor.
Dadurch wirds nicht billiger und der teure Platz auf dem Wafer wird noch mehr verschwendet als wenn man I/O dann gleich ebenfalls mit 7nm macht, wenn man schon mal dabei ist.
 
@ Stefan Payne
Sofern es korrekt ist das der IO Part wegen der benötigten Treiber Bausteine nur schlecht bei Shrinks skaliert dürfte der größte Vorteil im getrennten Aufbau darin liegen dass man mehr CPUs auf den teuren 7 nm Wafer bekommt und den IO Part mit bestehenden, billigeren Fertigungsprozessen fahren und damit auch diese Fertigungskapazitäten nutzen kann. Bei den großen IO lastigen Multicores wie Threadripper und Epyc dürfte das durchaus sinnvoll sein, bei den kleinen IO armen Modellen für den AM Sockel halte ich einen Multichip Aufbau hingegen für fraglich. Zum einen hat der Sockel eine erheblich kleinere Fläche, zum anderen könnte sich die Platzersparnis so gering sein das der Multichip Aufbau mehr kostet als man dadurch einspart.
An der Stelle sollte man aber auch nicht vergessen das jeder zusätzliche Arbeitsschritt auch eine zusätzliche Fehlerquelle sein kann, weshalb ich so meine Probleme mit der aktuellen Spekulation habe. Ein 9 Chip MCM Package halte ich ganz einfach für den absoluten Overkill. Da muss die 7 nm Ausbeute schon verdammt lausig sein, was wiederum ein sehr schlechtes Zeichen für entsprechende GPUs wäre. Wie dem auch sei, ich bin gespannt was am Ende dabei raus kommt. :)
 
Unter Umständen könnte es sich auch anbieten für einen IO-Chip auf einen Prozess wie 22FDX oder 12FDX zu setzen. Ansonsten würde sich natürlich auch 14LPP oder 12LP anbieten. Jedenfalls würde ich es für wahrscheinlich halten, dass man so einen IO-Chip (sollte es einen geben) bei GloFo fertigt, um möglichst viel vom WSA zu erfüllen.
 
Aus dem Wiki Artikel zur Cache Kohärenz:
Die Wahl zwischen verzeichnis- und snoopingbasiert hängt u. a. auch von der Anzahl der beteiligten Prozessoren (Cache Controller) ab. Spätestens ab 64 Prozessoren müssen üblicherweise verzeichnisbasierte Protokolle benutzt werden, da die Bandbreite des Busses nicht ausreichend skaliert. Bei kleineren Installationen ist der snoopingbasierte Ansatz aufgrund der fehlenden zentralen Instanz etwas performanter.[2]
Ob da AMD auf Verzeichnisbasierter Kohärenz geht mit dem IOX?
 
Das ist doch schon mit HBCC umgesetzt wenn ich das richtig interpretiert habe. Oder meint ihr etwas anderes? Ich denke hier muss man sich CCIX und GenZ anschauen wo AMD hin will mit den Interconnects.
 
Mir gehts nur um die Cache Kohärenz. Hab da bisher nur etwas von "snooping" gelesen. War deshalb überrascht wegen der Tabellenlösung. Mit dem Patent, Latenzen über mehrere Sockel in einer Tabelle zu verwalten, macht die 9 Chip Lösung für Rome noch mehr Sinn. Im IOX eben auch die ganze Latenz und Kohärenz Geschichten für einen Sockel abzuhandeln.
 
Zurück
Oben Unten