News AMD Zen 2 und Rome – was wir bisher wissen

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Die kommende CPU-Architektur Zen 2 wird AMD zuerst im für 2019 geplanten Server-Prozessor Epyc “Rome” einführen. Das macht Sinn, da die Server-Plattform den Zwischenschritt “Zen+” übersprungen hat, der uns 2018 die in vielen Details verbesserten Ryzen 2000 CPUs beschert hat. Kürzlich hatte AMD ja, wie berichtet, offizielle Informationen zu Rome veröffentlicht, allerdings auch viele Details ausgespart.
(…)

» Artikel lesen
 
Zuletzt bearbeitet:
@ Nero24

Ist nicht gerade der Cache ein wichtiger "Profiteuer" von einem Shrink?
Macht es dann wirklich Sinn, den Cache weitehin in 14nm zu fertigen, falls er im I/O Chip platziert wurde?

M.M. spricht das etwas gegen die Spekulation der L3 wäre im I/O Chip.
 
Zuletzt bearbeitet:
Mhh kleiner Fehler im Artikel im dual sockel System wird nicht per pcie sonder per IF verbunden was schneller ist weiß aber die genauen Zahl jetzt nicht aus den Kopf

Schon, aber die darunterliegende Hardware für die Sockel-zu-Sockel-Kommunikation per IF sind doch die PCIe-Lanes?!
Anders als damals beim Opteron beschränkt sich AMD bei Epyc auf Ein- und Zweisockel-Systeme. In 2P-Konfiguration werden 64 der 128 PCIe-Lanes für die CPU-Direktverbindung umgewidmet, sodass insgesamt auch ein 2P-System 128 PCIe-Lanes für Geräte (NVMe-SSDs, RAID-Controller, 40 Gb-NICs, etc.) frei hat.
Sonst hätte ein 2P-System ja 256 PCIe-Lanes zur freien Verfügung.
Ist nicht gerade der Cache ein wichtiger Profiteuer von einem Shrink?
Macht es dann wirklich Sinn, den Cache weitehin in 14nm zu fertigen, falls er im I/O Chip platziert wurde?

M.M. spricht das etwas gegen die Spekulation der L3 wäre im I/O Chip.
Das ist korrekt, daher glaube ich persönlich auch nicht daran, dass der L3-Cache in den I/O-Chip ausgelagert wurde. Wollte es nur mal als MÖGLICHE Erklärung erwähnt haben.
 
Zuletzt bearbeitet:
Ja 64 if links werden pro CPU zur Verbindung genutzt die sonst für Pcie benutzt werden im singel System
Es ging nur um die Geschwindigkeit da if an sich schneller ist als pcie 3.0

152gb/s gegen die 64gb/s von pcie 3.0 also für alle 64 Lance wenn ich das richtig habe
 
Ach so, Du meinst, dass IF nicht von dem schnelleren PCIe 4.0 profitieren wird, weil sie die Lanes auch bisher schon mit einem anderen Protokoll nutzen als PCIe-3.0-Geräte? Ja, das kann natürlich sein.
 
Zur Sockelkompatibilität könnte man ja auch noch erwähnen, dass beim gezeigten Rome-Modell die Kerben genauso sind wie bei Epyc oder Threadripper. Jedenfalls ist die Anordnung dieselbe.

-----

Kennt wer die Maße des IO-Die?
Ich habe mal Pixel gezählt und käme auf 15,6 x 31mm, was 201 483mm² machen würde.

Kennt wer die Dichte der Lötpunkte von dem Prozess?
Wenn ich von EPYC ausgehe und ein ZEN-Die 189mm² hat, wären das 5,4 Lötpunkte pro mm²

Übertragen auf den IO-Die wären das ~2611 Lötpunkte, von denen allein mindestens 1600 für IF, PCI-E und DDR weggehen würden. Keine ahnung, was man da sonst noch so alles braucht.

Daher würde ich mal nicht zuviel in den IO-Die hineinspekulieren und eher vermuten, der ist wegen den vielen nötigen Kontakten so groß geworden.
 
Da AMD bei Epyc PCIe-Lanes dazu verwendet
Nein, PCIe-PHYs, die dann mit Infinity Fabric beschaltet werden.

dürfte damit auch die Geschwindigkeit der Sockel-zu-Sockel Kommunikation bei Rome danke PCIe Gen 4 doppelt so hoch ausfallen.
...Infinity Fabric, welches über die PCIe PHYs geschaltet wird.

dass der L3-Cache aus 16 Segmenten besteht, darauf hindeuten, dass jedes Zen-2-Die – so wie bei Zen 1 – aus zwei CCX bestehen wird. Also kein homogenes 8-Kern-Die mit gleichen Zugriffszeiten für alle Kerne, sondern weiterhin zwei CCX mit je 4 Kernen, die via Infinity Fabric zusammengeschaltet sind. Nur, dass jeder CCX dann 16 MB L3-Cache haben wird statt nur 8 MB wie bei Zen 1.
...wobei immer die Möglichkeit eines Auslehsefehlers gegeben ist, da es auch möglich ist, dass die Werte schlicht aus einer Datenbank ausgelesen werden...


Zum I/O Die:
Da könntest du noch anmerken, dass man eventuell gar den L3 Cach spiegelt und sowohl im I/O als auch dem Chiplet Dies koherent hält, da das die Chip-to-chip Kommunikation beschleunigen könnte und man sich auch einige Tatentransfers spart, auch könnte der L3 auch deswegen so groß werden, weil man auf Inklusive umsteigt (ie alles was im L1 und L2 ist, ist auch im L3), eben um die Latenz zu senken und unnötige Transfers vom I/O Dings zu den Chiplets zu vermeiden.
Preis dürfte eine untergeordnete Rolle spielen...

--- Update ---

Ach so, Du meinst, dass IF nicht von dem schnelleren PCIe 4.0 profitieren wird, weil sie die Lanes auch bisher schon mit einem anderen Protokoll nutzen als PCIe-3.0-Geräte? Ja, das kann natürlich sein.

Nein, dass die Lanes mit IF beschaltet werden und man das mit höherer Frequenz nutzt, die einerseits über PCIe 4.0 ist und andererseits das ganze auch noch effizienter übertragen werden kann.
Der Takt wird schon höher sein, da wird man die PHYs voll ausfahren (oder zumindest im Rahmen des technisch sinnvoll möglichem)...

--- Update ---

Daher würde ich mal nicht zuviel in den IO-Die hineinspekulieren und eher vermuten, der ist wegen den vielen nötigen Kontakten so groß geworden.
Schon, nur wenn du das Die eh aufgrund der Pins so groß machen musst, warum nicht den Platz auch nutzen??

Meine Idee wäre schlicht eine Kopie der Caches im I/O Die zu behalten, um so die Chip-to-Chip Kommunikation bisserl asynchroner zu gestalten...
 
Mehr oder weniger @nero

AMD bei Epyc PCIe-Lanes dazu ver*wen*det, um die bei*den Sockel auf Dual-Sockel-Sys*te*me zu kop*peln, könn*te auch die Geschwin*dig*keit der Sockel-zu-Sockel Kom*mu*ni*ka*ti*on bei Rome dan*ke PCIe Gen 4 dop*pelt so hoch aus*fal*len, da im 2P-Betrieb je 64 PCIe-Lanes dafür umge*wid*met wer*den.

Und das stimmt so erstmal ja nicht da eben das if Protokoll genutzt wird
 
Eine Kopie des L3? Dann dürfte Rome ziemlich viel unnütze Energie schlucken. Zumal ich bezweifeln würde, dass 256MB L3 mal eben in 200mm² @14nm reinpassen. Man brauch ja auch Platz für den komplexen IF-Switch samt einer optimalen Anbinung und Verteilung an I/O, PCI-E und RAM.
 
Eine Kopie des L3? Dann dürfte Rome ziemlich viel unnütze Energie schlucken. Zumal ich bezweifeln würde, dass 256MB L3 mal eben in 200mm² @14nm reinpassen. Man brauch ja auch Platz für den komplexen IF-Switch samt einer optimalen Anbinung und Verteilung an I/O, PCI-E und RAM.

Aehm, der IO-Die liegt eher in der Größenordnung 430mm², mit den CPU-Chiplets liegt man knapp unter 1000mm². Platz dürfte also reichlich sein.
 
Wer viel misst, misst viel mist. :]

Keine Ahnung, wie ich nur auf 200mm² gekommen bin.
 
Könnte es sein, daß die I/O-Die schon 10 RAM-Channel und mehr PCIe Lanes integriert hat?
ES soll in Zukunft laut Gerücht ja ein Sockel mit 10 Channel kommen, vielleicht hat diese I/O-Die das alles schon integriert.

Da könntest du noch anmerken, dass man eventuell gar den L3 Cach spiegelt und sowohl im I/O als auch dem Chiplet Dies koherent hält
Das wäre aber ein gewaltiger Energiefresser.
 
Beim Zeppelin Die benötigen 8MB L3 16mm². Bräuchte man für 256MB L3 512mm² in 14nm. Ergo: keine L3 Kopie im I/O Die.
Ein CCX mit 8MB Cache ist beim Zeppelin 44mm² groß. Mit 16MB L3 wären es 60mm². Dazu noch was Platz für die Verbesserungen ~70mm² bei 14nm für EINEN CCX. Also ~75mm² für 2 CCX + IF Link in 7nm scheinen mir nicht zu groß.

Der SP3 Sockel hat 4094 Kontakte, die der I/O Chip zu bedienen hat. Dazu noch die 8 IF Links. Wie klein könnte der I/O Chip denn sein um alle diese Kontakte bereit zu stellen? Sind ja keine µBumps wie bei HBM.

Um die Cache Kohärenz zu gewährleisten ist ja auch was an Aufwand zu treiben. Ich denke mal, AMD wird ein Verzeichnisbasiertes Verfahren für die vielen Kerne nutzen. Zudem geisterte letztens ein Patent durch das Netz in dem AMD beschreibt wie durch speichern der Sockelübergreifenden Latenzen für die einzelnen Cachelines der Zugriff auf Daten beschleunigt werden kann, indem die Daten mit der niedrigsten Latenz gelesen werden. Dürfte zwar erst ein Thema für ZEN3 werden aber das würde zu einem Verzeichnisbasiertem Cache Kohärenz System passen.
 
Der SP3 Sockel hat 4094 Kontakte, die der I/O Chip zu bedienen hat. Dazu noch die 8 IF Links. Wie klein könnte der I/O Chip denn sein um alle diese Kontakte bereit zu stellen? Sind ja keine µBumps wie bei HBM.

Alle Kontakte wird der IO-Die nicht bekommen, viele sind ja zur Stromversorgung da. Ich hatte ja schonmal weiter ogben die theoretische Dichte an Kontakten von Zen 1 angenommen und würde beim IO-Die mit selber Dichte auf 2611 Kontakte kommen.
 
Vielleicht ist der L3-Cache auf Chiplets und I/O verteilt, so dass die Daten sowohl im Chiplet als auch im I/O geladen werden und so schneller zwischen den Chiplets ausgetauscht werden können. Also 100% Victim Cache.
 
Allein aus effizienzgründen würde der L3 in 7nm mehr Sinn machen. Zumal ist die Frage, ob der L3 in 14nm die Taktraten des 7nm-L3 schafft, nicht das so wieder Diskrepanzen entstehen.

Aber ein wenig Cache für den IF-Switch macht dagegen tatsächlich etwas Sinn. (Bei Hyper Transport 3.0 wurde ja aus Latenzgründen etwas L3 vom Prozessor dafür reserviert)
 
Aber ein wenig Cache für den IF-Switch macht dagegen tatsächlich etwas Sinn. (Bei Hyper Transport 3.0 wurde ja aus Latenzgründen etwas L3 vom Prozessor dafür reserviert)
So siehts aus. Es gab ja auch Gerüchte, dass es wieder 4P und 8P Systeme geben soll. Dazu braucht man wieder ne Pufferstufe zur besseren Koherenzverwaltung.
Ein Epyc-Rome-Chiplet sähe dann nach außen wie ein einzelner Rechenknoten aus. Die alten Cray-Systeme auf K10-Basis waren nichts anderes, jeder Cray-Chip band dort 2 K10-CPUs mit je 4 Kernen an.

Jetzt bietet es sich halt an die ganze Sache selbst in einem Gehäuse zu machen, erstens, weil mans kann, zweitens weil Cray mittlerweile zu Intel gehört, man es also machen muss, wenn man bei ganz großen Dickschiffen noch mithalten will.

Bleibt zu hoffen, dass es bei der TR-Version die Möglichkeit gibt, das Ganze als L4-freizuschalten ;)
 
Zurück
Oben Unten