News Prozessorgerüchte: AMD Epyc 2 „Rome“ wird angeblich ein 9-Die-Chip

sieh dir die Adored TV Videon über Interposer an , da wird auf Latenzen eingegangen , nehmen wir die " missaligned Butter Donut " Verknüpfung beim aktiven Interposer , dann sind die Latenzen sogar geringer als die Intels beim monolithischen Design unter Verwendung von Mesh
 
Zuletzt bearbeitet:
Taxxor schrieb:
Wenn AM4 vorerst auch bei maximal 8C bleibt, dann bräuchte man es ja sowieso nicht, da man nur einen Die hätte.

Wenn dort aber 2 Dice eingesetzt werden, dann macht doch ein System Controller genau so viel Sinn, wie bei Threadripper und Epyc, da man hier dann auch so oder so Offdie Latenzen hat
Komische Gedankengänge. Wenn man dort ohne System-Controller + Chiplet arbeitet, dann natürlich nur mit einem Die. Auch 16C wären nicht größer als Zeppelin heute. Eher kleiner.
 
@bensen Wir hatten hier vor einer Weile schon mal das Thema, dass 16 Kerne pro Die, also 8 Kerne pro CCX, ein riesiger Aufwand wäre, der wohl nicht wirklich umsetzbar ist.
Vor allem die ganzen einzelnen Verbindungen der Kerne untereinander innerhalb solch eines CCX, mit einer Die zu Die Verbindung über den IF funktioniert das einfacher.
 
@bensen
so natürlich ist das nicht , erfordert ein komplett neues Design des 8C Chiplets , wird aber ein aktiver Interposer verwendet , sind die Nachteile mehrerer Chiplets überschaubar , eher gering , da wird von 27 - 28 ns Latenz gesprochen anstatt von 120 - 130 ns wie beim TR/EPYC von Die to Die
2018-10-30.png

2018-10-30 (1).png

2018-10-30 (2).png
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Ned Flanders
Taxxor schrieb:
@bensen Wir hatten hier vor einer Weile schon mal das Thema, dass 16 Kerne pro Die, also 8 Kerne pro CCX, ein riesiger Aufwand wäre, der wohl nicht wirklich umsetzbar ist.
Vor allem die ganzen einzelnen Verbindungen der Kerne untereinander innerhalb solch eines CCX, mit einer Die zu Die Verbindung über den IF funktioniert das einfacher.
Du wirfst alles durcheinander. Es hat niemand von 8 Kerne pro CCX geredet. Das wäre nur mit nem Ringbus machbar. Nicht unmöglich, das AMD das macht, aber glaub ich nicht. Vor allem, da anscheinend die Chiplets bei Epic nur 8 Kerne haben.

@bensen
Verstehe gerade nicht, was dein Post mit meinem zu tun hat. :confused
Wozu sollte ich 2 Dies nutzen, wenn ich eh nicht die Chiplets von Epic + Systemcontroller nehme?
 
Letzten Endes:
Viele Wege führen nach Rome (:D)
Diese Idee mit den 9 Dice ist eine mögliche Variante, wie es aber in der Praxis aussieht, bleibt soweit unklar. Obwohl es ein bisschen nach Wahrheit riecht: Die Gerüchte sind ja nicht gerade neu und trotzdem kommt gerade jetzt, knapp zwei Wochen vor der New Horizons Vorstellung ein Artikel über diese Gerüchte. Ob da vielleicht CB auch Infos unter NDA hat und daher diese Gerüchte aufgreift?

Wenn Rome mit einen Interposer/Controller-Chip und 8 Dice gelöst wird, bleibt die Frage: Wird (bzw ist dann wohl schon) diese Aufteilung auch bei Ryzen mit einfließen oder gibt's dann doch einen weiteren Die, der im Mainstream eingesetzt wird?
Für gleiche Dice mit extra Controller-Die würde die kleinere Die-Fläche und die damit verbundene höhere Yield sprechen, der Controller dazu auch noch in 14/12nm.
Dagegen spricht allerdings der Aufwand und eventuell höhere Latenzen gerade im Konsumer-Umfeld. Immerhin muss ja eine Inter-Die-Kommunikation hergestellt werden. Dazu soll der Cache für Rome auch erhöht worden sein, nur geht es dabei um L3 innerhalb des CCX oder um Gesamt und damit ein möglicher L4 im Controller-Die? Wenn der L3 größer ist, in wie weit ist es im Kosten/Nutzen-Verhältnis ein Vorteil bei Konsumer-CPUs?

Oder gibt's dann für Ryzen ein eigenen Die mit zwei bis vier CCX. Wobei ich zwei als am Wahrscheinlichsten halte, man hält damit den Die klein um den Aufwand von 7nm entgegen zu wirken. Eine Lösung mit drei CCX (damit 12 Kerne) dürfte knapp 25% mehr Die-Fläche einnehmen (bei Summit und Pinnacle Ridge nehmen die beiden CCX etwas weniger als die Hälfte des Dice ein, der Uncore-Bereich sollte wohl nicht sonderlich größer werden).

Wenn 7nm tatsächlich eine Halbierung der Die-Fläche hinbekommt (immerhin sind die Angaben in erster Linie eine Marketingbezeichnung als eine Größenangabe) oder zumindest annähernd, sollte selbst ein 16-Kern-Die für Ryzen sogar kleiner ausfallen, als zur Zeit Pinnacle Ridge. Damit wäre auch ein 4-Die-Verbund wie bisher im Bereich des Möglichen.

Vielleicht ist das Gerücht auch nur ein Teil der Wahrheit und es werden dort Dice eingesetzt, die auch weiterhin einen Uncore-Bereich haben sodass sie wie bisher alleine funktionieren. Bei Epyc und dann wohl auch bei Threadripper ist der Interposer-Die dann nur ein extra Bindeglied, sodass Speicher und I/O quasi geroutet werden und damit Konstanz erreicht wird, statt gegebenfalls Umwege über die anderen Dice zu gehen. Dadurch hat man auch wieder den gleichen Die für Ryzen, Threadripper und Epyc aber benötigt für Ryzen keinen extra Die für Uncore. Dieser Die würde ja trotzdem deutlich kleiner werden, auch wenn diverse Zusätze und Eigenheiten von Zen2 Platz benötigen. 120mm² klingt beispielsweise nicht unrealistisch für einen 8-Kerner in 7nm.

Viel Spekulatius für die Vorweihnachtszeit, die mittlerweile bereits Anfang September beginnt (mit Erscheinen von Lebkuchen, Dominosteinen und natürlich Spekulatius)
 
abwarten , kommt drauf an wie gut der Interposer funktioniert , wenn es denn einen gibt , jedenfalls sollen einige Interposer Konfigurationen weniger Latenz haben als Intel mit Mesh im monolithischen Die .... , siehe Grafik oben , falls das tatsächlich so gut funktionieren würde , sehe ich keinen Sinn darin den Uncore wieder in die CPU zu integrieren : Es wäre das perfekte Baukastensysten , man bräuchte nur 3 IO Chiplet Varianten , Desktop , HEDT und Server zu entwickeln und könnte von 4 bis 64 Kerne alles abdecken damit
 
cookie_dent schrieb:
... niemand genau weis was ein 12 nm Chip tatsächlich kostet und wieviel der 7nm Chip dann kosten wird. Theorethisch müssten die 7nm Chips doch kleiner ausfallen, was die Ausbeute pro Wafer erhöht und den höheren Produktionspreis egalisieren könnte.
Oder habe ich da einen Denkfehler?

Eigentlich schon, aber die Fertigungskosten (nicht nur laufende Kosten, aber auch immer hoehere Investitionskosten in die neuesten ASML Anlagen, Fabrikumbauten/-neubauten, usw.) werden ja im Falle von Autragsfertigern an den Chipentwickler (und danach die Konsumenten) direkt weitergereicht und ich vermute dass trotz der Architekturverkleinerung in mindestens gleichem Masse mittlerweile die Investitionskosten und laufenden Kosten den Vorteil der kleineren Strukturen und damit quantitativ groesseren Ausbeute pro Wafer wieder aufwiegen und bei 7nm evt. gar ueberragen (so dass die 7nm (bzw. 10nm) Node dann teurer als die Fertigung in 12 und 14nm wird).

Des Weiteren duerfte die 7nm Fertigung mit mehr Erfahrungswerten und Optimierung mittelfristig (aehnlich wie bei 14nm etwa) wieder guenstiger werden, auch wenn das beim Konsumenten evt. nicht ankommen duerfte (denn dem reicht oft schon das Mehr an Leistung und/oder Effizienz), es sei denn die Ausbeute steigt massiv an und der Konkurrenzdruck ist gross (zwischen AMD und Intel gibt es in einigen Feldern/bei CPU-Produkten zum Glueck wieder solch einen Druck; zwischen AMD und nVidia leider nur in geringerem Masse, oberhalb einer GTX1080/RXVega64 bzw. ab einer GTX1080Ti/RTX2080 leider aktuell nicht).

Bei Intel kommt dann noch hinzu, dass man ueber Jahre den 10nm Fertigungsprozess nicht gut genug in den Griff bekommen hat und somit eben auch den technologischen Vorsprung vor der Konkurrenz eingebuesst hat, was man z.T. auch an den Kunden weiter reichen koennte, abhaengig davon wieviel besser die Intel 10nm Fertigung als die TSMC (oder Samsung) 7nm Fertigung sein wird und ob/wieviel die Kundschaft bereit ist dafuer mehr Geld auf den Tisch zu legen.

Eigentlich kann man schon froh sein, dass es gerade Intel (und nicht das deutlich finanzschwaechere TSMC) mit den argen Fertigungsschwierigkeiten erwischt hat, denn andere Unternehmen haette es bei so einer Belastung evt. dahingerafft; GloFo hat die Kosten ja auch ueber Jahre nicht mehr einspielen koennen und ist jetzt als Konsequenz daraus abgehaengt worden.

Moeglicherweise wird Intel aus den ueber Jahre gemachten Negativerfahrungen Lehren ziehen, die langfristig/zukuenftig in einen Vorteil gewandelt werden koennten und durch das angesammelte Wissen wuerde Intel noch konkurrenzfaehiger werden (auch wenn sie dafuer kurzfristig tief in die Tasche greifen mussten bzw. Gewinneneinbussen und Marktanteile in dem Bereich gelassen haben), wohingegen die Konkurrenz so etwas evt. erst noch vor sich hat, wer weiss?
 
Zuletzt bearbeitet:
bensen schrieb:
Du wirfst alles durcheinander. Es hat niemand von 8 Kerne pro CCX geredet. Das wäre nur mit nem Ringbus machbar. Nicht unmöglich, das AMD das macht, aber glaub ich nicht. Vor allem, da anscheinend die Chiplets bei Epic nur 8 Kerne haben.
Du sagtest dass AMD auch einen 16C Die machen könnte. Wie sollen sie das denn anders machen als mit 2 CCX á 8 Kerne?

Und wie du selbst sagtest da die chiplets nur 8 Kerne haben würde das für einen 16C Ryzen 2 Dice bedeuten
 
Zuletzt bearbeitet:
@Taxxor Na wie bisher. Also 4 CCX à 4 Kerne, aber diesmal nicht auf 2 Dies, sondern auf einem. Oder man vergrößert auf 19 Kerne und geht auf 3 CCX à 6 Dies. Es gibt da schon einige Varianten... Klar, die Gerüchteküche sagt was anderes, keine Frage ;)
 
  • Gefällt mir
Reaktionen: bensen
@Taxxor
4x4 sind? Nenn mir doch mal einen Grund warum man nur 2 CCX verbauen kann?

Desweiteren lies doch meine Posts bevor du sie kommentierst.
Ich schrieb, dass wenn sie nicht auf das Chiplet-Design gehen, ein 16 Kerner aus einem Die bestehen würde.
 
Es ist mit Sicherheit einfacher, mehr CCX am IF zu hängen als den CCX auszuweiten. Ich denke, dass der CCX bewusst 4 Kerne besitzt und dass es auch noch lange so bleibt, wohl so lange wie Zen-Iterationen verwendet werden.
 
bensen schrieb:
4x4 sind? Nenn mir doch mal einen Grund warum man nur 2 CCX verbauen kann?
Weil man dafür eben den Die ändern müsste und dann neben einer Maske für Epyc und einer Maske für die APUs noch eine zusätzliche Maske für Ryzen haben müsste.

Man kann alles machen, man kann auch für Ryzen einen monolithischen 16C Die entwerfen, ob das letztendlich Sinn macht ist die Frage
 
Zuletzt bearbeitet:
Ozmog schrieb:
Es ist mit Sicherheit einfacher, mehr CCX am IF zu hängen als den CCX auszuweiten. Ich denke, dass der CCX bewusst 4 Kerne besitzt und dass es auch noch lange so bleibt, wohl so lange wie Zen-Iterationen verwendet werden.
sehe ich nicht so , letzlich ist es nur ein neuverdrahten der Verbindungen innerhalb des CCX Die intern , da wenn der Uncore incl Speichercontroller ausgelagert wird , man darauf keine Rücksicht mehr zu nehmen braucht , ich denke man hat beim 8 Kern Die 2 CCX genommen weil jeder CCX für einen Speicherkanal zuständig war bzw Zugriff hatte . Ansonsten kann man die Crossbar soweit erweitern das man auch bei 8 Kernen direkte Verbindungen hat , was bei einem aktiven Interposer mit Routerfunktion jedoch überflüssig wäre , da der Interposer Router die Verbindung schalten würde und das nicht nur zu Kernen in demselben Die . Das würde die Latenzen homogenisieren und im Grunde dafür sorgen das die Chiplets wie ein zusammenhängendes Stück Silizium agieren , die Probleme mit dem Windows Scheduler wären weg , es wäre egal welcher Kern eines CCX eine Aufgabe erhält , er könnte genausogut mit einem benachbarten wie mit einem Kern eines anderen Die s zusammenarbeiten , nimmt man die og. Tabelle sind es 2,32 Hops im Schnitt ( bei 64 Kernen )
 
MK one schrieb:
sehe ich nicht so , letzlich ist es nur ein neuverdrahten der Verbindungen innerhalb des CCX Die intern , da wenn der Uncore incl Speichercontroller ausgelagert wird , man darauf keine Rücksicht mehr zu nehmen braucht

Braucht man bereits schon nicht, die Kommunikation läuft über den IF auch zum Speicherkontroller und den restlichen Uncore, der IF ist nicht nur zur Anbindung der CCX untereinander da. Dadurch wird praktisch nur ein/zwei weitere CCX an den IF gehängt, und schon ist ein 12/16-Kerner fertig. Grob gesehen.
Während die Erhöhung der Kernzahl innerhalb eines CCX zunehmend komplexer wird.

Es hat kein CCX eine besondere Kontrolle über einen expliziten Speicherkanal, sondern beide CCX sind über den IF mit den Speicherkontroller verbunden. Der IF wurde gerade für eine Skalierung entwickelt, wodurch er CCX und/oder CUs in fast beliebiger Anzahl mit anderen Parts verbinden kann. Bei Raven Ridge verbindet der IF den CCX und 11 CUs, bei Vega bis zu 64 CUs.
 
Glaube ich nicht , ist vermutlich auch nicht Bestandteil des Cross Lizensierungsvertrags von 2009 /2010 in dem AMD Intel erlaubte AMD64 Instruktionen zu nutzen , im Gegenzug dürfte AMD AVX nutzen , in dem Vertrag wurden auch noch andere Dinge geregelt , Intel zahlte 1 Milliarde an AMD .
 
Zurück
Oben