AMD Zen - 14nm, 8 Kerne, 95W TDP & DDR4?

Angeblicher Zen Wafer.
Sagt wer?
Grob nachgemessen, ich komme auf etwa 320-330 mm² fürs Die. Also ähnlich gross (minimal grösser) wie Orochi. Bei über 2-facher Transistordichte von 32nm auf 14nm dürften 16 Kerne realistisch sein. 32 Kerne werden dann vermutlich per MCM realisiert.

Grob angesehen erkenn ich da 6 Kerne und etwas L3 ... noch besser sieht mans auf dem High-Res-Bild hier:

http://www.fudzilla.com/images/stories/2009/November/General News/img_2238.jpg

Man beachte die Datumsangabe im Linkpfad :-)
 
Stimmt, ist wohl ein Istanbul Wafer. Fudo wieder mal. *chatt*
 
Nicht "Fudo mal wieder" ... einfach mal nachdenken, Symbol-Bild und so. Wäre es ein Zen-Wafer, würde er das schreiben.
 
Stimmt, ist wohl ein Istanbul Wafer. Fudo wieder mal. *chatt*

Ja, aber zu seiner Ehrenrettung muss man sagen, dass er das nirgends direkt behauptet hat :)
Halt nur ein Beispielbild .. sowas gibts öfters bei Chipnews.

Außerdem stellt sich auch die Frage, obs überhaupt schon ZEN-Wafer gibt. Und selbst wenn - dann sind die Dinger noch so super geheim, dass die sicher kein Fuad zu Gesicht bekäme ;)

Zur MCM-Theorie: Hmm, wieso nicht. Das ist bekanntlich billig und AMD muss billig sein. Spart schließlich ein Monster-Die-Design mit (bei AMD) geringer Stückzahl und die Yields in 14nm könnte man bei so nem Riesenteil ebenfalls vergessen.

Nur die 8 DDR4-Kanäle pro "G34-Zen-Sockel" wären etwas viel ... aber gut . .sind ja auch 32 Kerne/64 Threads. Intel verbaut bei ihrem aktuellem 15Kern/30Thread-Chip (37,5 MB L3) auch 4 Kanäle im Sockel 2011. Doppelt soviel Kanäle bei doppelt soviel Kernen käme also schon hin.

Aber wieviel Pins soll der G34-Zen-Sockel dann haben, 3000 aufwärts? Einerseits etwas viel, aber andererseits hat IBMs Power8 lockere 15.000 Pads .. von daher wohl auch nicht unmöglich. Sorgen mach ich mir dann nur noch über die Kopplung in 2P Systemen. Die ganzen Kerne erzeugen auch ein Vielfaches an Cohärenz-Traffic, da wird wohl wieder HT-Assist die Kohlen aus dem Feuer holen müssen, genug L3 dafür hat man ja. Mit nem gleichzeitigen Upgrade auf HT 4.0 mit ~PCIe3-Geschwindigkeit könnte es schnell genug sein, eventuell noch nen vollen 32-Bit-HT-Link statt bisher 16+8, dann wärs vermutlich schon ganz passabel.

Für uns könnte dann ein FX mit einem Die und Quad-Channel abfallen, quasi ein 2011-Gegenstück. Wenigstens die Sockel-Strategie sollte sich hoffentlich in ~2 Wochen auf der Analystenkonferenz klären. Da wird man zwar hauptsächlich für den Skybridge-Sockel werben, aber wenn der Zen-Opteron nächstes Jahr kommen soll, erkennt man hoffentlich irgendwas auf den Roadmaps.

Der Idealfall wär natürlich ein Skybridgesockel mit Quad-DDR4, dann wär alles klar, aber das ist wohl "etwas" unwahrscheinlich ;)
 
Ja, aber zu seiner Ehrenrettung muss man sagen, dass er das nirgends direkt behauptet hat
Aber sowas dann bei einem solchen Artikel zu bringen, ist trotzdem völlig daneben, weil man es eben leicht implizieren kann. Wenn es wenigstens Orochi gewesen wäre, also das bisherige Opteron-Design und der Vorgänger des Zen Opterons. Da wäre wenigstens noch ein logischer Zusammenhang dagewesen. Aber so ist es einfach nur deplatziert und inkompetent. Wie gesagt, halt Fudo wieder mal. *chatt* Am besten man setzt ihn wirklich komplett auf die Blacklist.

Außerdem stellt sich auch die Frage, obs überhaupt schon ZEN-Wafer gibt.
Nachdem was so zu hören ist, soll das Tapeout bereits erfolgt sein. Und die 14nm Fertigung läuft bei Glofo ja auch schon seit einiger Zeit. Insofern könnte es Testwafer sicherlich schon geben. Wäre auch angebracht, wenn man Zen im kommenden Jahr und nicht erst am 31.12. launchen will.

Nur die 8 DDR4-Kanäle pro "G34-Zen-Sockel" wären etwas viel ... aber gut . .sind ja auch 32 Kerne/64 Threads.
Wenn ein Zen Chip 4 Speicherkanäle mitbringt, dann wären es bei 2 Chips eben 8 Speicherkanäle. Vorstellbar ist das durchaus. Fragt sich nur, ob man damit einen adäquaten Desktop Ableger basteln kann. MCM braucht man da sowieso nicht. Aber auch 16 Kerne und Quad-Channel wäre eigentlich noch zu viel des Guten. Ausser man will LGA2011 Konkurrenz machen. Attraktiver wären für die meisten Leute aber sicherlich 4-8 Kerne und Dual-Channel für FM4/Skybridge zu bezahlbaren Preisen.

Intel verbaut bei ihrem aktuellem 15Kern/30Thread-Chip (37,5 MB L3) auch 4 Kanäle im Sockel 2011.
18 Kerne / 36 Threads und 45 MB L3.

Sorgen mach ich mir dann nur noch über die Kopplung in 2P Systemen. Die ganzen Kerne erzeugen auch ein Vielfaches an Cohärenz-Traffic, da wird wohl wieder HT-Assist die Kohlen aus dem Feuer holen müssen, genug L3 dafür hat man ja. Mit nem gleichzeitigen Upgrade auf HT 4.0 mit ~PCIe3-Geschwindigkeit könnte es schnell genug sein, eventuell noch nen vollen 32-Bit-HT-Link statt bisher 16+8, dann wärs vermutlich schon ganz passabel.
Mit Magny Cours hatte man schon eine Lösung für bis zu 96 Kerne (8x 12). Und da musste Kohärenz für bis zu 16 L3 Caches sichergestellt werden. Da sollten 32 Zen Kerne / 64 Threads und lediglich 2 L3 Caches eigentlich nicht das Problem sein.
 
Skybridge ist ARM (A57) und Cat-Core (Puma+) in 20nm für FT4, nicht Zen und 14nmFF.

AMD-Skybridge-02.jpg AMD-Skybridge-03.jpg
 
Sorgen mach ich mir dann nur noch über die Kopplung in 2P Systemen. Die ganzen Kerne erzeugen auch ein Vielfaches an Cohärenz-Traffic, da wird wohl wieder HT-Assist die Kohlen aus dem Feuer holen müssen, genug L3 dafür hat man ja.

Wie wäre es mit HSA um den Cohärenz-Traffic zu reduzieren? Die Software müßte mitspielen, aber "alte" Software ohne HSA würde ja trotzdem laufen, allerdings langsamer als ohne HSA.

Die Frage ab wann 14 nm High-Performance Prozesse mit brauchbaren Yield für große Dies zur Verfügung stehen, bleibt offen.

--- Update ---

Einerseits etwas viel, aber andererseits hat IBMs Power8 lockere 15.000 Pads

DAS ist wirklich ne Menge Holz, aber der Preis wird nicht günstig sein. Auch die Platinen auf denen sowas verbaut werden kann sind nicht billig.
 
Aber sowas dann bei einem solchen Artikel zu bringen, ist trotzdem völlig daneben, weil man es eben leicht implizieren kann.
(...) Am besten man setzt ihn wirklich komplett auf die Blacklist.
Letzteres geht halt schlecht, da er dann doch ab und zu nette Schaubildchen postet. Da muss man nur die Goldwage im Hinterkopf haben und sich beherrschen ja keine voreiligen Schlüsse zu ziehen, eben weil man bei ihm so wenig wie möglich implizieren darf :)


Nachdem was so zu hören ist, soll das Tapeout bereits erfolgt sein. Und die 14nm Fertigung läuft bei Glofo ja auch schon seit einiger Zeit. Insofern könnte es Testwafer sicherlich schon geben. Wäre auch angebracht, wenn man Zen im kommenden Jahr und nicht erst am 31.12. launchen will.
Hoffen wirs mal .. :)

Wenn ein Zen Chip 4 Speicherkanäle mitbringt, dann wären es bei 2 Chips eben 8 Speicherkanäle. Vorstellbar ist das durchaus.
Jo sicherlich, erscheint für AMD halt nur etwas viel, d.h. ist ungewohnt, aber naja, das Core<>Kanalverhältnis würde passen.
Fragt sich nur, ob man damit einen adäquaten Desktop Ableger basteln kann. MCM braucht man da sowieso nicht. Aber auch 16 Kerne und Quad-Channel wäre eigentlich noch zu viel des Guten. Ausser man will LGA2011 Konkurrenz machen. Attraktiver wären für die meisten Leute aber sicherlich 4-8 Kerne und Dual-Channel für FM4/Skybridge zu bezahlbaren Preisen.
Ne MCM fällt natürlich weg. Aber wenn LGA2011-Konkurrenz muss fast sein, ansonsten rentierten sich die 8 Kanäle des Opteron nicht. So nen Sockel kann man auch für 1P-Opteronsysteme brauchen, quasi wie damals bei Sockel940. Eigentlich war AM3 vs. C32 auch Blödsinn, fast kein Unterschied. Wenn AMD jetzt PCIe und HTr-Pins dynamisch wechseln kann, macht ein einzelner Sockel auch Sinn, für die Desktopversion kann man dann einfach mehr PCIe-Lanes für 2x16 o.ä. anbieten.

18 Kerne / 36 Threads und 45 MB L3.
Danke fürs berichtigen, aber das macht das Kraut auch nicht fetter. Hab nur kurz in ner Intelübersicht geschaut, was gerade aktuell ist, war anscheinend nicht vollständig, aber die 3 Kerne ändern nichts viel der Kern/Kanalaussage.

Mit Magny Cours hatte man schon eine Lösung für bis zu 96 Kerne (8x 12). Und da musste Kohärenz für bis zu 16 L3 Caches sichergestellt werden. Da sollten 32 Zen Kerne / 64 Threads und lediglich 2 L3 Caches eigentlich nicht das Problem sein.
2 L3 Caches? Wie kommst Du auf zwei? In so nem 2P Zen-MCM-Setups gäbs 64 Kerne, das macht bei den 4er-Zen-Clustern ebenfalls wieder 16 L3s. Aber insofern stimmt Deine Aussage dann .. damals gabs auch nicht mehr ^^ Wobei - gabs 8P Systeme im G34 Sockel überhaupt? Bilde mir ein, dass es nur 4P gab, also nur 4x12. Logisch ist ein G34-Sockel für sich ja schon ein 2P-System ...

Skybridge ist ARM (A57) und Cat-Core (Puma+) in 20nm für FT4, nicht Zen und 14nmFF.
Schon klar, deswegen schrieb ich ja ""etwas" unwahrscheinlich" ;-) Ganz 100%ig ausschließen kann mans aber nicht, wir reden schließlich über AMD :)

Wie wäre es mit HSA um den Cohärenz-Traffic zu reduzieren? Die Software müßte mitspielen, aber "alte" Software ohne HSA würde ja trotzdem laufen, allerdings langsamer als ohne HSA.
Was sollte das bringen? Ein Kernelement von HSA ist hUMA, ein großer gemeinsamer Speicherbereich für CPU+GPU und bei nem gemeinsamen Speicherbereich muss man eben die Kohärenz sicherstellen...
DAS ist wirklich ne Menge Holz, aber der Preis wird nicht günstig sein. Auch die Platinen auf denen sowas verbaut werden kann sind nicht billig.
Jupp, aber bei 64 Kernen /128 threads und 16 DDR4 Kanälen kann man dann schon teuere Platinen einplanen. So gesehen wäre ein teurer Sockel auch nicht unwahrscheinlich.

Als AMD-Fan könnte man jetzt auch mutmaßen, dass AMD von ner (sehr) guten Zen-Leistung ausgeht, sodass selbst solch teure Klotzereien Abnehmer finden werden. Aber zum Thema implizieren: Siehe oben ;)
 
Als AMD-Fan könnte man jetzt auch mutmaßen, dass AMD von ner (sehr) guten Zen-Leistung ausgeht,

Sicher wird ZEN nicht schlecht sein. Für uns stellt sich nur die Frage, wie gut er in Games und normaluser Homeanwendungen abschneidet.
Selbst bei verbesserter IPC und mit 16 Kernen wird ZEN für uns uninteressant, wenn er Taktmäßig nicht in die puschen kommt.
Könnte dann wieder ausgehen wie bei Bulldozer: Multithreaded ganz gut dabei, für Zocker langsamer als ein guter Intel Quadcore.
Schon sind alle wieder entäuscht, dass ein alter i3 in Games besser ist wie ein 16 Kern ZEN.
 
Was sollte das bringen? Ein Kernelement von HSA ist hUMA, ein großer gemeinsamer Speicherbereich für CPU+GPU und bei nem gemeinsamen Speicherbereich muss man eben die Kohärenz sicherstellen...

Ein Trick an HSA ist das man die Kohärenz steuern kann bzw. nicht kohärente Pages Faults werfen können, ansonsten würden die ganzen (GPU)Cores am Kohärenztraffix ersticken. Blätter mal in meinen Postings ein wenig zurück.
 
Zuletzt bearbeitet:
Ab 2016 dürfte das kein so großes Problem mehr sein aufgrund der neuen Grafik-APIs. Sicher lässt sich nicht alles parallelisieren, aber wenn die pro-Kern/Thread Leistung nicht erheblich schrumpft, dann dürfte dank 14nm einiges drin sein.
Ein Hochtaktdesign ist allerdings mMn recht sicher auszuschließen und damit wird ein breiter Kern (damit meine ich sowas wie Cyclone) wahrscheinlicher als ein schlanker. AMD wird sich nicht nur wegen der Design-Einspraungen für seine x86-Kerne zukünftig stärker an ARM orientieren. Schließlich muss die Fertigung verfügbar sein und das ist sichergestellt wenn man sich an die Vorgaben der Standard-ARM-Kerne hält. Das dürfte auch dem APU-Konzept entgegenkommen.
 
Sorgen mach ich mir dann nur noch über die Kopplung in 2P Systemen. Die ganzen Kerne erzeugen auch ein Vielfaches an Cohärenz-Traffic, da wird wohl wieder HT-Assist die Kohlen aus dem Feuer holen müssen, genug L3 dafür hat man ja. Mit nem gleichzeitigen Upgrade auf HT 4.0 mit ~PCIe3-Geschwindigkeit könnte es schnell genug sein, eventuell noch nen vollen 32-Bit-HT-Link statt bisher 16+8, dann wärs vermutlich schon ganz passabel.
Wird es überhaupt 2P Systeme geben? Ich bin mir da nicht sicher. Wie ich das verstehe, wäre der in den Medien herumspukende 16 Kern-Zen-Prozessor ja schon ein 4x4 System mit einem Kohärenznetzwerk zwischen den Clustern "on chip".
 
Ein Trick an HSA ist das man die Kohärenz steuern kann bzw. nicht kohärente Pages Faults werfen können, ansonsten würden die ganzen (GPU)Cores am Kohärenztraffix ersticken. Blätter mal in meinen Postings ein wenig zurück.
AH ok Danke, das muss ich dann übersehen haben. Wär das dann ne Art Kohärenz nur bei Bedarf? Das wär dann sicherlich nett, aber unterscheiden müsste man das dann auch irgendwie ... das wär ein ziemlich tiefer Eingriff in die Logik. Ich schaus mir die Tage mal an, Danke für den Tipp.

Ein Hochtaktdesign ist allerdings mMn recht sicher auszuschließen und damit wird ein breiter Kern (damit meine ich sowas wie Cyclone) wahrscheinlicher als ein schlanker. AMD wird sich nicht nur wegen der Design-Einspraungen für seine x86-Kerne zukünftig stärker an ARM orientieren. Schließlich muss die Fertigung verfügbar sein und das ist sichergestellt wenn man sich an die Vorgaben der Standard-ARM-Kerne hält. Das dürfte auch dem APU-Konzept entgegenkommen.
Na das ist alles klar, die Frage ist nur: Wie breit wird es. Eher mehr Puma oder mehr EV8? ;-)
Im Moment hab ich Angst, dass es zuviel Puma wird, aber mal schauen.

Wird es überhaupt 2P Systeme geben? Ich bin mir da nicht sicher. Wie ich das verstehe, wäre der in den Medien herumspukende 16 Kern-Zen-Prozessor ja schon ein 4x4 System mit einem Kohärenznetzwerk zwischen den Clustern "on chip".
Nee der 16core ist doch nur ein 2P-System, kein 4x4, oder meinst Du mit 4x4 die ehemaligen 2P-Boards der FX-CPUs? Ja dann passt es, aber man könnte dann auch noch zwei dieser "2P-CPUs" zusammenschaltet. Fuad sprach davon, aber obs wirklich kommt .. muss man natürlich abwarten.
 
Naja, ich hoffe die vergessen die Single-Core-Leistung nicht komplett über Vulkan/DX12. Aber ich schätze die werden verschiedene Versionen raus bringen, mit 4/8/12/16 Kernen für Desktop, und je weniger Kerne desto höher der Takt. Dann muss man sich halt das Beste für sich raus suchen, oder besser kühlen und übertakten.
 
@Opteron
Inwiefern ist Puma breit, der ist doch nur zweifach superskalar? Ich denke schon eher sowas wie Cyclone, das scheint Keller ja zu liegen (siehe auch A64); falls SMT kommt könnte ja es tatsächlich sogar in Richtung EV8 gehen (hoffentlich übernehmen sie nicht zu viel vom EV8, vor allem was die Veröffentlichung angeht), aber das glaube ich irgendwie nicht (Ohne dass ich von Prozessordesign Ahnung habe :D)

Etwas anderes:
Die Trennung von CPU und GPU macht zukünftig Sinn, weil man damit ohne Aufwand diversifizieren kann. z.B. ein Dicker Server Zen für CPU-lastige Aufgaben -> Fette CPU + keine GPU oder Mini-GPU + normal HBM; ein HPC-Zen -> mittlere CPU-Einheit + fette GPU + ordentlich HBM; Consumer-Version -> Mittlere CPU-Einheit + mittlere GPU + normal HBM etc.
Gleichzeitig könnte man dann bei den CPU-Einheiten zwischen ARM und x86 austauschen.

Dadurch kann AMD ohne zusätzlichen Fertigungsaufwand "nur" durch das Packaging sein Portfolio immens verbreitern.
 
Zuletzt bearbeitet:
Nee der 16core ist doch nur ein 2P-System, kein 4x4, oder meinst Du mit 4x4 die ehemaligen 2P-Boards der FX-CPUs? Ja dann passt es, aber man könnte dann auch noch zwei dieser "2P-CPUs" zusammenschaltet. Fuad sprach davon, aber obs wirklich kommt .. muss man natürlich abwarten.
Habe ich das falsch verstanden?
Ich dachte der kolportierte Server-Zen wäre ein monolithischer 16-Kern Chip (+ Hyperthreading). Zur Kostensenkung (?) würde man den jedoch modular aufbauen: Vier Zen-Kerne teilen sich einen L3-Cache und bilden ein Cluster (analog zu den Jaguars in den Spielconsolen, dort jedoch nur mit 2 Cache-Ebenen). Mit vier solchen Zen-Clustern kommt man auf 16-Kerne.

Spekulativ: Die Cluster müssen die Cache-Kohärenz sicher stellen, also analog zu den alten Hyperthreading-Opterons miteinander reden. Nur kann man jetzt das Protokoll dafür direkt auf dem Chip umsetzen, das spart Latenz und Energie und man kann die Bandbreite hochskalieren. Für die Consolen müssen sie das ja schon fertig entwickelt und umgesetzt haben.

Interessant wird die Speicheranbindung. Gibt man jedem der vier Cluster einen separaten DDR4-Kontroller mit auf den Weg (führt zu einer Art NUMA-System, jedoch mit sehr kleinen Latenzunterschieden zwischen den Speicherbereichen) oder baut man einen gemeinsamen Speicherkontroller ein (ist latenztechnisch langsamer, aber der gesamte Speicher kann gleich schnell angebunden werden)?
Die NUMA-Variante wäre dann eine Art 4-Sockel-F-Quadcore-Opteron-System. Nur eben alles auf einem Chip. Will man etwas kleineres, lässt man zwei oder drei der vier Cluster weg und hätte etwas für den Desktop und Mobilmarkt.

Deshalb meine Frage, ob man dann wirklich noch einen zweiten Sockel auf dem Mainboard anbringt und die Kosten und die langen Leiterbahnen in Kauf nehmen soll?
Will man in die Leistungsregion, könnte man auch den Prozessor-Träger/Sockel etwas größer machen und statt einem 16-Kern Zen-Die derer zweier einsetzen, bei jedem aber nur zwei der vier Speicherkanäle nach draußen führen und die zwei Chips über den eher kurzen Weg auf dem Chip-Träger miteinander kommunizieren lassen. Die Erfahrung dafür müsste ja von Magny-Cours noch vorhanden sein, bzw. kann man in dem Fall sogar die zwei brachliegenden Speicherkontroller pro Die oder zumindest deren "Endstufen" verwenden. Da die Verbindung zwischen den Dies dann sehr kurz ist, geht das latenztechnisch noch.
Der Nachteil wäre die gesunkene Speicherbandbreite pro Kern, der Vorteil die Kostenersparnis bzw. das die Wertschöpfung bei AMD und nicht beim Boardhersteller liegt.
Das ist aber alles hochspekulativ. :D
 
NUMA ist ja das Gegenteil von HSA mit hUMA. Daher ist es doch recht unwahrscheinlich, dass AMD NUMA on Chip verbaut. Unified Memory ist der Weg der gegangen wird, vor allem mit HBM Stacks, die mit völlig unterschiedlichen Taktraten angesprochen werden können je Speicherchannel.
 
Stimmt. NUMA würde das HSA ein Stück weit erschweren. Dann wohl eher mit einem gemeinsamen Speicherkontroller und dem Kohärenznetzwerk zwischen den L3-Caches.
 
@Opteron
Inwiefern ist Puma breit, der ist doch nur zweifach superskalar?
Ja, eben nur 2fach "breit", also "wenig breit". Die 2 Chips waren als Gegenpole gedacht, Puma für wenig, EV8 für viel. Irgendwo dazwischen wird ZEN landen, fragt sich nur wohin die Tendenz geht. Mit sowas wie Cyclone wär man sicherlich schon zufrieden.

Etwas anderes:
Die Trennung von CPU und GPU macht zukünftig Sinn, weil man damit ohne Aufwand diversifizieren kann. z.B. ein Dicker Server Zen für CPU-lastige Aufgaben -> Fette CPU + keine GPU oder Mini-GPU + normal HBM; ein HPC-Zen -> mittlere CPU-Einheit + fette GPU + ordentlich HBM; Consumer-Version -> Mittlere CPU-Einheit + mittlere GPU + normal HBM etc.
Gleichzeitig könnte man dann bei den CPU-Einheiten zwischen ARM und x86 austauschen.
Naja, und wozu hat man dann seit Llano versucht das Ganze auf einem Die unterzubringen? Die ganze Idee steht und fällt mit dem Interconnect zw. GPU und CPU, da kann man on-die normalerweise immer mehr Bandbreite bereitstellen. Aber mal schauen ... TSVs könnten auch für den Fall ne Lösung sein.
Habe ich das falsch verstanden?
Ich dachte der kolportierte Server-Zen wäre ein monolithischer 16-Kern Chip (+ Hyperthreading). Zur Kostensenkung (?) würde man den jedoch modular aufbauen: Vier Zen-Kerne teilen sich einen L3-Cache und bilden ein Cluster (analog zu den Jaguars in den Spielconsolen, dort jedoch nur mit 2 Cache-Ebenen). Mit vier solchen Zen-Clustern kommt man auf 16-Kerne.
Wieso sollen die 4er Cluster die Kosten senken? Solange das ein monolitisches Die ist, ists ein Riesendie, dass teuer ist. Deshalb die Überlegung, dass der 16-Kerner wie die Sockel-G34-Opterons aus 2 Dies je 8 Kernen /16 Threads besteht. Wäre ja schon ne Verdopplung der aktuellen BD-Dies mit 8 Threads. Wenn man davon ausgeht, dass die Kerne gleich groß wären könnte man die doppelte Anzahl grob durch den Shrink aufsummieren. Auch aus Yieldgründen sollte man das so machen. 14nm ist anfangs sicherlich schlecht, da kann man nicht mit nem großen Die ankommen, Intel fertigt seine Riesen-Xeons auch immer im älteren Prozess.

Weiterer Vorteil: Das einzelne 8Kern-Die lässt sich prima als FX vermarkten. Auch wenn der Markt immer kleiner wird, schadet das sicherlich nicht.

Interessant wird die Speicheranbindung. Gibt man jedem der vier Cluster einen separaten DDR4-Kontroller mit auf den Weg (führt zu einer Art NUMA-System, jedoch mit sehr kleinen Latenzunterschieden zwischen den Speicherbereichen) oder baut man einen gemeinsamen Speicherkontroller ein (ist latenztechnisch langsamer, aber der gesamte Speicher kann gleich schnell angebunden werden)?
Die NUMA-Variante wäre dann eine Art 4-Sockel-F-Quadcore-Opteron-System. Nur eben alles auf einem Chip. Will man etwas kleineres, lässt man zwei oder drei der vier Cluster weg und hätte etwas für den Desktop und Mobilmarkt.
Na ne, auf einem Die rentiert sich kein NUMA, das werden 4 Kanäle (oder wie viel auch immer) und die sind für alle Kerne da. Glaub auch nicht, dass der dann höhere Latenzen hätte. Ein 4er Cluster muss immer nen Speicherkontroller ansprechen. Ob an dem nun ein DRAM-Kontroller hängt, oder 4 .. ist egal.

Deshalb meine Frage, ob man dann wirklich noch einen zweiten Sockel auf dem Mainboard anbringt und die Kosten und die langen Leiterbahnen in Kauf nehmen soll?
Es spräche sicherlich nichts dagegen, beim den aktuellen Opterons gehts ja auch...

NUMA ist ja das Gegenteil von HSA mit hUMA.
Gegenteil würde ichs nicht unbedingt nennen, denn beides schafft einen zusammenhängenden Adressraum.
Daher ist es doch recht unwahrscheinlich, dass AMD NUMA on Chip verbaut. Unified Memory ist der Weg der gegangen wird, vor allem mit HBM Stacks, die mit völlig unterschiedlichen Taktraten angesprochen werden können je Speicherchannel.
Naja, die kolportierte Riesen-APU könnte ne NUMA-Architektur sein, wenn es wirklich aus einem Zen Die und einem Arktik-Insel-Die bestünde. Da hingen die 16GB HBM-Speicher ganz sicher direkt an der GPU und die DDR4-Kontroller am Zen-Die hängt.

Wenns ein Riesendie werden würde, wärs sicherlich was anderes .. aber wirds das? Da gilt wieder die obige 14nm Regel, nach der sich solche Riesendies (noch) nicht rentieren dürften. Ergo muss man eher mit nem MCM rechnen.
 
NUMA= Non-Uniform Memory Architektur

Also da sollten wir uns schon klar einig sein was das bedeutet:
Non-Uniform Memory Access oder kurz NUMA ist eine Computer-Speicher-Architektur für Multiprozessorsysteme, bei denen jeder Prozessor einen eigenen, lokalen Speicher hat, aber anderen Prozessoren über einen gemeinsamen Adressraum direkten Zugriff darauf gewährt (Distributed Shared Memory). Die Speicherzugriffszeiten in einem solchen Verbund hängen daher davon ab, ob sich eine Speicheradresse im lokalen oder im fremden Speicher befindet.

Im Gegensatz dazu stehen

Uniform-Memory-Access (UMA), bei dem es einen zentralen Speicher gibt, auf den Zugriffszeiten immer gleich sind.
hUMA=UMA mit heterogenen Geräte wie CPU+GPU

hUMA beinhaltet ja schon lokalen und remote Speicher der einzelnen Compute Units. Das ganze jetzt noch innerhalb der CPU auf Cluster anzuwenden macht IMHO überhaupt keinen Sinn mehr. Es macht auch nur in Multisockelsystemen Sinn, wobei auch hier immer bessere Anbindungen stattfinden. Mit einer Fabric sind NUMA-Konfigurationen vieleicht wieder am kommen, je nach Throughput, doch sicher nicht auf Die-Ebene, wo ja alles lokal und schnell anbindbar ist.
 
Zuletzt bearbeitet:
Opteron schrieb:
Naja, und wozu hat man dann seit Llano versucht das Ganze auf einem Die unterzubringen? Die ganze Idee steht und fällt mit dem Interconnect zw. GPU und CPU, da kann man on-die normalerweise immer mehr Bandbreite bereitstellen. Aber mal schauen ... TSVs könnten auch für den Fall ne Lösung sein.
Ich denke, dass HBM der Schlüssel dazu ist. Vorher musste man die Daten abgleichen, damit man die Speicheranbindung nicht übermäßig belastet, weil da die Engstelle war. Daher ist das Fusion-Konzept für die Zeit eines externen Arbeitsspeichers durchaus sinnvoll. Auch weil man bei der größe der integrierten GPU durch die Speicheranbindung sowieso ziemlich beschränkt war. Jetzt kann man aber die Daten in den und aus dem HBM schubsen, auf den alle Einheiten mit der gleichen Geschwindigkeit zugreifen können ohne dass Bandbreitenprobleme entstehen.
Gleichzeitig macht es aber auch keinen Sinn ultrafette Dies zu produzieren und dann Teile zu deaktivieren.


Ich sehe bei AMD momentan das Problem, dass man enorm viel Potential aufgrund des breiten Portfolios hat, das man nicht ausspielen kann/ausspielt, weil offensichtlich die jeweilige Fertigung mit den jeweils eigenen Masken/Debugging etc. zu teuer ist. Wie soll das weitergehen bei den kommenden GPUs, ARM-APUs, ARM-CPUs, x86-APUs, x86-CPUs... Dann kommen mal Schwankungen im Absatz und zack ist der Gewinn futsch und man hat die Lager voll.

Das könnte man beheben, wenn man es schafft, das Design stärker zu modularisieren. Wenn ich ein GPU-Die gleichzeitig diskret oder als iGPU verwenden kann, dann habe ich da schon mal kaum Kostenprobleme. Wenn ich gleichzeitig entweder Zen oder K10 mit der jeweiligen GPU kombinieren kann, dann hab ich tatsächlich fast alle Schwierigkeiten ausgeräumt. Vor allem muss ich nicht jeden Chip einzeln debuggen. Und schneller als eine Anbindung über PCI-Express ist es allemal.

Und möglicherweise könnte man sogar mehrere GPUs auf einem Carrier unterbringen und mehrere CPU-Cluster (keine Ahnung wie kompliziert und energieintensiv das Verdrahten dann wird). Dann kann man recht kleine Dies fertigen und sie beliebig kombinieren. Das wäre dann allerdings ein SoC im Sinne von System-on-Carrier. Gerade für HPC erscheint mir das beinahe unumgänglich, für den Ultramobilbereich wäre wohl eine APU besser.
 
Zuletzt bearbeitet:
Bisher sieht es nach 2 verschiedenen ZENs aus:

8M/16C Zen mit GPU für Desktop
16M/32C Zen Opteron mit neuen Interconnect zw. den CPUs welches aber irgendwie nach HT3 aussieht mit neuem Namen und Takt ... "HT4" also doch irgendwie

Die Optis sollen auch "nur" Quad-DDR4-2xxx haben (REG ECC) - Desktop halt ohne REG ECC

Leider find ich's grade nicht:
Es soll auch HUMA+NUMA kommen
Opterons untereinander NUMA
Opteron zur per PCIe angeflanschten FirePro HUMA
für "fettes" HPC
 
HSA Software ist ja darauf ausgelegt mit solchen unterschiedlichen Speicherpools umzugehen. Bin echt gespannt was da weiter kommt.
 
Zurück
Oben Unten