Zen 2, 7nm, PCIe 4.0, 2019 (Matisse, Renoir, Castle Peak, Rome), Matisse-Refresh 2020

[fondness]

Ich gehe mittlerweile auch von 16 Kernen im Matisse-Die aus und unveränderter Strategie zu Zen was die einzelnen Produkte betrifft. Die chinesische Quelle, die schon bei Vega richtig lag, ist bis auf weiteres mit Sicherheit die ernstzunehmenste Quelle. Charlie bläst ins selbe Horn, und auch der hat meistens gute Quellen. Auch der mittlerweile bestätigte 32 Core Threadripper spricht für mich klar für 16 Kerne im AM4, ansonsten wäre die Lücke IMO zu groß.

Matisse-Die:
- 16C Zen2 CPU (CCX Aufteilung sei mal dahingestellt)
- Infinity Fabric für bis zu 4 Dies per Socket
- 32x PCIe4.0 (bestätigt für EPYC)
- xGMI
- TSMC 7nm
- Ende 2018 als 64C EPYC "Rome"
- H1/2019 als 16- und 12 Kerner im AM4.
- H2/2019 als 32C TR4 Threadripper "Castle Peak" plus als High-End APU mit Vega20.


Renoir-Die:
- 8C Zen2 APU
- keine externe Infinity Fabric
- 16x PCIe3.0
- Navi iGPU
- GF 7nm
- Ende 2019 als AM4 Mainstream bzw. mobile BGA.


Zusammen mit den vom Chinesen genannten 10-15% mehr IPC ggü. Zen+ und vermutlich mehr Takt wären das höchst potenten Produkte. Man deckt auch wieder mit nur 2 Dies den Markt weitgehend ab. Was höchstens noch fehlt wäre eine Lowend-APU. Hier Skrink man vielleicht noch einen RavenRidge auf 7nm (sollte auf knapp über 100mm² raus kommen) oder man entwickelt was eigenes. Man hätte dann auch wieder die Option Threadripper ein Jahr später auf bis zu 64C zu erhöhen.





Aktuelle Roadmap:
https://s9.postimg.cc/gpzsho0dr/amd-roadmap2020-1.jpg (https://postimages.org/)

https://www.hartware.de/wp-content/uploads/2017/09/AMD-Roadmap-2017-mit-Vega-20.jpg

https://6images.cgames.de/images/gamestar/226/amd-cpu-roadmap-2020-quelle-informatica-cero_6025105.jpg

[Ravenhearth]

Warum steigt man bei den Codenamen eigentlich auf Künstler um? "Meridian Ridge" find ich schöner ;D

[BoMbY]

Sehr wahrscheinlich 4-core CCX und 3x CCX pro Die. Die Server CPU soll bekanntermaßen bis zu 48 Kerne haben, und an dem 4x Die Layout bei SP3/AM4 werden die kaum etwas ändern. Eine Verdoppelung des Cache ist auch wahrscheinlich, wenn die bekannten Packdichte-Werte für 7LP stimmen. Und im "Product Brief" zu 7LP spricht GloFo von "5 Ghz operation", währen im 14LPP "Product Brief" von ">3 GHz operation" gesprochen wurde - man scheint sich auf jeden Fall sicher zu sein höhere Frequenzen erreichen zu können.

[HOT]

Da Rome 64 Kerne hat, hat ein Die zwangsläufig 2 oder 4 CCX. Es können auch 8-Kerne-Komplexe sein mit 64MB L3$ pro Komplex. Da gabs ja entsprechende Gerüchte. Man wird damit PR nach oben hin ergänzen würd ich sagen, also 4-8 Kerne bleibt PR und 8-16 Kerne dann Matisse, alles AM4. Matisse wird zwar PCIe 4.0 können, jedoch glaube ich nicht, dass die AM4-Variante das auch mitbringen wird. Die 48 Kerne war das frühe Starship-Gerücht, das was obsolet.

[maguumo]

Warum nicht? Müsste man doch einfach nur an den Slot führen, sollte für neue Boards kein Problem sein.

[HOT]

Das alles immer theoritisch so einfach, aber da es keinen AM4+ gibt wird man wohl die AM4-Spec einhalten.

[maguumo]

Mit AM3+ gab es auch neue Chipsätze, die müsste man hier nicht anfassen.

[Pirx]

Da Rome 64 Kerne hat, ...
ist das wirklich bestätigt?

[robbitop]

Die Frage ist, ob sie den L3 pro CCX einfach vergrößern (das hat ja idR negativen Einfluss auf die Latency) oder einen L4 als LLC hinzufügen. Das ginge in 7nm mit 64 MiB mit ~16mm² Fläche. Würde die durch den IF bedingte relativ langsame Memorylatency in Games gut kompensieren (siehe Broadwell-H mit Crystalwell) und für eine APU würde es den Bandbreitenflaschenhals ein Stück weit entschärfen (sofern die GPU Zugriff auf den L4 hätte).
Ich vermute aber mal, dass der L3 dann kein Victim Cache sein dürfte, damit das funktioniert - ergo Umbauten...

[HOT]

ist das wirklich bestätigt?


https://hothardware.com/news/amd-epyc-2-64-cores-128-threads-and-256mb-l3-cache
Bestätigt ist gut, offizell ist wie immer kaum was.
Demnach hätte ein Zen2-Die eben 16 Kerne und 128MiB L3$, was eben 2 Zen2 CCX bedeuten würde mit je 64MiB L3$, also 8 Pro Kern, nicht wie bislang 2. So ein bisschen erinnert das an Phenom -> Phenom II mit dem Cache. Ich denke, wenn man davon ausgeht wird mal letztendlich nicht großartig falsch liegen.

Große Umbauten im Kern selbst halte ich eher für Unwahrscheinlich, der wird immer noch 128Bit FPUs haben und den Zen-Aufbau ziemlich übernehmen. Man wird sich in erster Line auf die Weiterentwicklung der CCX konzentriert haben. Bei Zen3 sind dann die Kerne dran.

(Demnach ist dann auch eine passende APU denkbar mit einem Zen2 CCX mit weniger Cache und Navi-Grafik oder schon die post-GCN-IP. Das wird sicherlich ein interessantes Produkt)

[Der_Korken]

Welche Möglichkeiten hätte man eigentlich, wenn man wirklich einen L4-Cache einbauen wollte? Der einzige Grund für einen solchen Cache wäre es, den Datenaustausch zwischen mehreren CCX zu erleichtern, denn ansonsten könnte man einfach den L3 pro CCX vergrößern.

Der L3 ist ein Victim-Cache, d.h. er enthält nur Sachen, die aus dem L2 geworfen wurden. Wie sind L2 und L1 miteinander verbunden? Eine Inklusiv-Beziehung wie bei Intel ist es afaik nicht. Ist der L2 dann auch ein Victim-Cache aus Sicht des L2?

Und eine Frage noch zu den Latenzen: Die sehen bei SR etwa so aus:
L1 = 4 Takte
L2 = 17 Take
L3 = 40 Takte

Hat der L2 dann tatsächlich eine Latenz von 17 Takten oder sind es in Wirklichkeit nur 13, weil der Zugriff erst erfolgt, sobald man weiß, dass man einen L1 miss hat? Falls ja, würde eine zusätzliche Cache-Stufe dann nicht auch implizit die Speicherlatenzen erhöhen, weil es länger dauert alle Caches durchzuchecken, bevor der Zugriff nach draußen geht?

[BoMbY]

Naja, ein Tweet von Canard vs. eine alte Folie von AMD. Klar, AMD könnte natürlich die Pläne geändert haben mit der Zeit.

Als das Gerücht von Canard kam, hatte ich dieses Bild gebastelt, was ganz grob 50% Area Reduction entsprechen müsste:

https://i.imgur.com/6eK2zIh.jpg

Wäre also nicht vollkommen unmöglich, ohne die aktuellen Dimensionen zu verlassen.

[Hübie]

Jetzt muss ich mal doof fragen, warum die Latenz bei einem mesh größer wird, wenn der L3 pro Kern vergrößert wird? :|

[Nightspider]

Mal eine blöde Frage:

Damals hatte Intel den eDRAM (L4 Cache) in 22nm gefertigt und dieser führte zu starken Performance-Zuwächsen bei geringem Stromverbrauch.

Könnte AMD nicht auch bei GloFo oder TSMC im alten 14nm Prozess einfach etwas größere und schnellere eDRAM Chips produzieren lassen und die mit auf ihre CPUs setzen?

5-10 Watt mehr Verbrauch für teils 10-20% mehr Leistung in Anwendungsfällen bei geringen Mehrkosten von ~~50 Dollar? (Der eDRAM kostete damals laut Intel auch nur 40-50 USD im brandneuen 22nm FF Prozess)

Gerade im Server-Bereich wo bestimmt nicht die schnellsten RAM-Riegel zum Einsatz kommen könnte sowas doch ordentlich durchschlagen in der Leistung pro Watt oder sind die meisten Anwendungen im Server und HPC Bereich nicht so Speicher sensitiv?

Gerade in 14nm würde so ein eDRAM ja gar nicht mal so viel kosten wenn die CPUs schon in 7nm gefertigt werden.

Ja gut, die 50 USD wären gemessen an den Herstellungskosten der CPU Chips auch teuer aber wenn man durch den eDRAM dann sogar schneller und effizienter ist als Intel könnte man auch höhere Preise verlangen und Prestige würde das auch ordentlich bringen.

[BoMbY]

Da kann man auch gleich einen Interposer und HBM nehmen - was AMD früher oder später sicher in Erwägung zieht.

Durch das Infinity Fabric sind alle Controller ehh bereits alle Dinge (inkl. Memory Controller) praktisch mit einem geswitchten Netzwerk verbunden, und wenn man jetzt mal an das Chiplet-Patent denkt, könnte man auch gut einen separaten MC+Speicher in das Netzwerk hängen.

Wenn man das vernünftig durchzieht, könnte man mit einem CPU-Die und einem GPU-Die eine komplette Produktfamilie mit Server, Desktop, Mobile CPUs, APUs und GPUs auf den Markt bringen, sofern die halt im Verband über einen Interposer (oder mit Abzügen über weitere Wege, wie bei EPYC) ordentlich zusammen spielen.

[HOT]

Naja, ein Tweet von Canard vs. eine alte Folie von AMD. Klar, AMD könnte natürlich die Pläne geändert haben mit der Zeit.

Als das Gerücht von Canard kam, hatte ich dieses Bild gebastelt, was ganz grob 50% Area Reduction entsprechen müsste:

https://i.imgur.com/6eK2zIh.jpg

Wäre also nicht vollkommen unmöglich, ohne die aktuellen Dimensionen zu verlassen.
So ungefähr könnte der neue CCX aussehen. Die Cache-Organisation wird natürlich grundlegend anders sein als das. Aber die Geometrie mit den 4 Cores pro Seite dürfte schon gut hinhauen.

eDRAM und zusätzliche Dies sind keine Option, viel zuviel Aufwand. In 7nm ist eine SRAM-Zelle so klein, zumal die ja stark optimiert wurde ggü. 14nm, und die war schon klein.

[robbitop]

https://hothardware.com/news/amd-epyc-2-64-cores-128-threads-and-256mb-l3-cache
Bestätigt ist gut, offizell ist wie immer kaum was.
Demnach hätte ein Zen2-Die eben 16 Kerne und 128MiB L3$, was eben 2 Zen2 CCX bedeuten würde mit je 64MiB L3$, also 8 Pro Kern, nicht wie bislang 2. So ein bisschen erinnert das an Phenom -> Phenom II mit dem Cache. Ich denke, wenn man davon ausgeht wird mal letztendlich nicht großartig falsch liegen.

Große Umbauten im Kern selbst halte ich eher für Unwahrscheinlich, der wird immer noch 128Bit FPUs haben und den Zen-Aufbau ziemlich übernehmen. Man wird sich in erster Line auf die Weiterentwicklung der CCX konzentriert haben. Bei Zen3 sind dann die Kerne dran.

(Demnach ist dann auch eine passende APU denkbar mit einem Zen2 CCX mit weniger Cache und Navi-Grafik oder schon die post-GCN-IP. Das wird sicherlich ein interessantes Produkt)

96 Kerne - 256 MiB L3 -> 4 Dice
16 Kerne - 64 MiB L3 pro Die
4x CCX pro Die -> 16 MiB pro CCX

Warum denkst du, dass Zen 2 keine Umbauten hat? Keine Umbauten haben wir schon mit Zen+ (am eigentlichen Core).
Gerade 256 bit AVX2 ist für einige Anwendungen schon heute sinnvoll und von Nachteil es nicht zu haben (z.B. Videoencoding).

Auch Caches wären in Bezug auf Umbauten extrem sinnvoll. Zens inhomogene Spieleperformance (idR taktnormiert schlechter als er in Anwendungen ggü Intels CPUs dasteht) ist zu einem nicht unwesentlichen Teil durch die Memorylatency bedingt. Die IF deutlich schneller zu machen, ohne dass die Leistungsaufnahme durch die Decke geht, ist vermutlich auch nicht so einfach. Ein großer LLC würde sofort helfen.

Welche Möglichkeiten hätte man eigentlich, wenn man wirklich einen L4-Cache einbauen wollte? Der einzige Grund für einen solchen Cache wäre es, den Datenaustausch zwischen mehreren CCX zu erleichtern, denn ansonsten könnte man einfach den L3 pro CCX vergrößern.

Je größer ein Cache, desto langsamer ist er. Den L3 einfach aufzublähen würde in nicht wenigen Anwendungen (mit Instruction Sets die in den L3 passen) zu einer Performancedegression führen.
Auch würde ein L4 außerhalb der CCX sicherlich einfacher für den GPU Teil einer APU zugänglich sein.


Hat der L2 dann tatsächlich eine Latenz von 17 Takten oder sind es in Wirklichkeit nur 13, weil der Zugriff erst erfolgt, sobald man weiß, dass man einen L1 miss hat? Falls ja, würde eine zusätzliche Cache-Stufe dann nicht auch implizit die Speicherlatenzen erhöhen, weil es länger dauert alle Caches durchzuchecken, bevor der Zugriff nach draußen geht?
Das ist exakt der Nachteil einer jeglichen Cache Hirarchie. Cache Misses werden teurer je tiefer die Hierarchie bzw die Summe der Zugriffszeiten. Je größer der Cache und je schlauer das Prefetching desto seltener sind Misses.

Intel hat bei CFL eine insgesamt so niedrige RAM Latency, dass ein externer L4 eDRAM Cache nichts mehr bringen würde. Ein interner SRAM L4 ggf schon - aber der Nutzwert wäre relativ zu Zen geringer.

Jetzt muss ich mal doof fragen, warum die Latenz bei einem mesh größer wird, wenn der L3 pro Kern vergrößert wird? :|
Welche Latenz meinst du? Und wie steht das Mesh im Zusammenhang mit dem L3 in deiner Frage? Ich finde der Satz / die Frage ergibt so wie sie ist mMn wenig Sinn.

Mal eine blöde Frage:

Damals hatte Intel den eDRAM (L4 Cache) in 22nm gefertigt und dieser führte zu starken Performance-Zuwächsen bei geringem Stromverbrauch.

Könnte AMD nicht auch bei GloFo oder TSMC im alten 14nm Prozess einfach etwas größere und schnellere eDRAM Chips produzieren lassen und die mit auf ihre CPUs setzen?

5-10 Watt mehr Verbrauch für teils 10-20% mehr Leistung in Anwendungsfällen bei geringen Mehrkosten von ~~50 Dollar? (Der eDRAM kostete damals laut Intel auch nur 40-50 USD im brandneuen 22nm FF Prozess)

Gerade im Server-Bereich wo bestimmt nicht die schnellsten RAM-Riegel zum Einsatz kommen könnte sowas doch ordentlich durchschlagen in der Leistung pro Watt oder sind die meisten Anwendungen im Server und HPC Bereich nicht so Speicher sensitiv?

Gerade in 14nm würde so ein eDRAM ja gar nicht mal so viel kosten wenn die CPUs schon in 7nm gefertigt werden.

Ja gut, die 50 USD wären gemessen an den Herstellungskosten der CPU Chips auch teuer aber wenn man durch den eDRAM dann sogar schneller und effizienter ist als Intel könnte man auch höhere Preise verlangen und Prestige würde das auch ordentlich bringen.

Ein L4 SRAM Cache wäre erheblich schneller und würde nur ~16mm² kosten (64 MiB). Wozu einen teuren und relativ langsamen externen eDRAM? Zumal die Zugriffszeit auf den L4 eDRAM bei 40 ns lag. Im Vergleich mit damals aktuellem DDR3-1600 (führte idR zu gemessenen Zugriffszeiten von ~60 ns) sicherlich relativ schnell. Aber CFL liegt mit DDR4-3200 bereits bei 40 ns Zugriffszeit beim RAM. Er hätte dort also keinen Effekt mehr. (eine schnelle I/O / Fabric und ein hochtaktender IMC machen offenbar den größten Teil der Gesamtzugriffszeit aus)

Zen hingegen dümpelt beim RAM bei ~70-80ns rum (dank relativ langsamer IF). Hier würde eDRAM helfen. SRAM wäre aber noch besser.

Da kann man auch gleich einen Interposer und HBM nehmen - was AMD früher oder später sicher in Erwägung zieht.

Nicht gerade günstig und von der Zugriffszeit soll HBM auch nicht so toll sein. Bandbreite ist in CPU Tasks ja relativ selten der Flaschenhals. Für eine APU/IGP sicher eine gute Idee. Aber teuer. Ein SRAM LLC wäre sicherlich günstiger. Dank 7nm wäre ein L4 SRAM Cache auch gar nicht so flächenhungrig. In Bezug auf SRAM ist 7 nm ein richtig guter Sprung...

[Nightspider]

Da kann man auch gleich einen Interposer und HBM nehmen - was AMD früher oder später sicher in Erwägung zieht.

Durch das Infinity Fabric sind alle Controller ehh bereits alle Dinge (inkl. Memory Controller) praktisch mit einem geswitchten Netzwerk verbunden, und wenn man jetzt mal an das Chiplet-Patent denkt, könnte man auch gut einen separaten MC+Speicher in das Netzwerk hängen.

Wenn man das vernünftig durchzieht, könnte man mit einem CPU-Die und einem GPU-Die eine komplette Produktfamilie mit Server, Desktop, Mobile CPUs, APUs und GPUs auf den Markt bringen, sofern die halt im Verband über einen Interposer (oder mit Abzügen über weitere Wege, wie bei EPYC) ordentlich zusammen spielen.

Ich glaube HBM hat eine höhere Latenz, die ja besonders wichtig ist.

Der eDRAM bestand ja glaube aus einer SRAM Variante.

[Hübie]

@robbitop: Ich spreche vom OCN das die Cores mit den L3-slices verbindet. Bei Intel ist das ja bis auf die neue Skylake-E Gen ein Ringbus. Bei AMD (iirc) ein Gitter-Netzwerk. Du hast oben geschrieben, dass die Latenz steigt "(das hat ja idR negativen Einfluss auf die Latency)", wenn man mehr L3-Cache verbaut. Oder habe ich dich da falsch verstanden?

[basix]

Mehr Cache bedeutet mehr Organisationsaufwand und deswegen höhere Latenzen, ausser man strukturiert den Cache anders. Zen 2 (und auch Raven Ridge) haben 12 Zyklen L2 Latenz. Intel ebenfalls aber mit nur der Hälfte L2. Wie du siehst ist es nicht so einfach. Ob die Assoziativität auch noch reinspuelt weiss ich nicht.

Bei HSW-E ist die L3 Latenz auch höher als bei den 4-Kernern. So auch die RAM Latenz. Wirklich weh tut es aber nicht bei der Performance. Ich würde sagen, mehr Cache ist immer besser, egal ob die Latenz leicht steigt.

[mczak]

Warum denkst du, dass Zen 2 keine Umbauten hat? Keine Umbauten haben wir schon mit Zen+ (am eigentlichen Core).
Gerade 256 bit AVX2 ist für einige Anwendungen schon heute sinnvoll und von Nachteil es nicht zu haben (z.B. Videoencoding).

Hat sicher Umbauten, fragt sich halt bloss wieviel.
AVX2 mit 256bit SIMD-Einheiten, da bin ich noch nicht so sicher. Sinnvoll wäre das schon, allerdings kostet das richtig Fläche. Ausserdem ist es mit Erweitern der SIMD-Einheiten auf 256bit nicht getan, das benötigt zwingend auch 256bit load / store Pfade zum Cache. (Also theoretisch könnte man natürlich auch die loads/stores aufsplitten, aber da Zen mit den 2 AGU da eh schon sehr knapp dimensioniert ist, Stack-Engine hin oder her, ist das absolut keine Option - es sei denn Zen2 kann eben mehr als 1 Load / 1 Store (oder 2 Loads) pro Takt, was imho durchaus nicht ausgeschlossen ist). Will man allerdings AVX512 unterstützen sind 256bit SIMD-Einheiten wohl ein Muss, weil ein Split in 4x128bit vermutlich nicht wirklich sinnvoll ist.
Wieviele Kerne pro CCX ist eine interessante Frage. 6 wären schon ganz nett, wenn man die prinzipiell identische Organisation für die APUs beibehalten will.

[BoMbY]

Mit Cache ist das halt immer ein Hit und Miss. Eigentlich sind die CPU-Caches für die heutige Zeit viel zu klein. Ich denke schon, dass auch z.B. ein 512 MB HBM2-basierter L4 Cache der CPU einen Vorteil bringen würde, vor allem wenn noch mehr als ein CPU-Die am Werke ist.

Zum Beispiel einmal 512 MB HBM2 in der Mitte zwischen vier SR-Modulen bei einem EPYC-Package, mit einem zentralen Cache Controller, der mit allen SR-Modulen mit einer dedizierten Leitung verbunden ist. Also als quasi als Shared L4 Cache.

[ndrs]

Ich denke schon, dass auch z.B. ein 512 MB HBM2-basierter L4 Cache der CPU einen Vorteil bringen würde, vor allem wenn noch mehr als ein CPU-Die am Werke ist.
Wie von Robbitop schon erwähnt hat HBM die gleichen Latenzen, wie DRAM. Durch den geringeren Takt vielleicht sogar minimal höhere. Du würdest also bei einem L4-Hit nur Bandbreite gewinnen. Bei einem Miss allerdings ist deine Latenz total im Eimer, weil du dann irgendwo bei 130ms landest. Der gesharte Cache-Controller, würde es vermutlich nochmals schlimmer machen.

Ein solches Szenario könnte eventuell dann sinnvoll werden, wenn man einen Teil des On-Die-Caches nutzt um die entsprechenden Tables des L4 zu verwalten, so dass schon vor einem Zugriffsversuch bekannt ist, ob die Daten im L4 liegen. Da kenne ich mich aber zu wenig in den Details aus.

[BoMbY]

Soso. Nur, was ist wenn der benötigte Speicher wie in meinem Beispiel an dem MC des weit entferntesten Dies hängt, oder an der zweiten EYPC-CPU im anderen Sockel?

[robbitop]

@robbitop: Ich spreche vom OCN das die Cores mit den L3-slices verbindet. Bei Intel ist das ja bis auf die neue Skylake-E Gen ein Ringbus. Bei AMD (iirc) ein Gitter-Netzwerk. Du hast oben geschrieben, dass die Latenz steigt "(das hat ja idR negativen Einfluss auf die Latency)", wenn man mehr L3-Cache verbaut. Oder habe ich dich da falsch verstanden?
Du hast mich falsch verstanden. Das war unabhängig vom I/O gemeint. Je größer ein Cache desto langsamer. Dagegensteuern kann man mit mehr Assoziatität. Kostet aber Leistungsaufnahme und Fläche.

Zum I/O
Bei Intels Skylake-X ist es ein Mesh.

Ich glaube HBM hat eine höhere Latenz, die ja besonders wichtig ist.

Der eDRAM bestand ja glaube aus einer SRAM Variante.
DRAM =! SRAM. eDRAM ist (in einen IC) eingebetteter DRAM. Ein Bit braucht nur 1 Zelle. SRAM je nach Typ 6 Zellen. Manche Foundrys bezeichnen eDRAM aber als 1T-SRAM. Ist aber kein SRAM. :)


--------------------------
Ich sehe jedenfalls keinen Grund, bei 7 nm nicht einfach in mehr SRAM zu "investieren". Ob nun als L3 oder L4. Extern ist IMO teurer und langsamer. Für Serveranwendungen mit besonders großem Bandbreitenhunger oder Instructionset wäre HBM sicherlich eine gute Option.

[Thunder99]

Und wieso hat Intel nach Broadwell kein L4 mehr? Wenn es so gut wäre würden es auch die nachfolgenden Generationen haben

[aceCrasher]

Wie warscheinlich ist es eigentlich, dass in Zen 2 AVX512 implementiert wird? Ist für mich ein absolutes Killerargument, wegen dem enormen Leistungssprung in meinem Anwendungsfall. Ich encode mit x265.

http://x265.org/x265-receives-significant-boost-intel-xeon-scalable-processor-family/

"Our initial results with the latest build of x265 show a 67% average per-core gain for encoding using HEVC Main profile"

Der Leistungssprung durch AVX512 beim h265 encoding scheint durchaus enorm zu sein. Aktuell ist es noch in keinem Branch implentiert schreiben die Entwickler, sie haben es aber auf dem Radar.

Ohne AVX512 wäre man in Zukunft in Sachen HVEC Encoding wohl kaum konkurrenzfähig.

[Pirx]

SRAM war doch immer relativ teuer (bzw. wurde es nie im Überschwang verwendet, sondern eher andere Dinge mit den Transistoren gemacht). Warum sollte das bei 7 LP anders sein?

[Nightspider]

Ein fetter L4 eDRAM wäre halt im "zweitneuesten" Fertigungsprozess deutlich günstiger als wenn man jetzt großen SRAM in 7nm bringt und könnte wie bei Intel dann auch bei den APUs Vorteile bringen.
Intel hatte den eDRAM eben auch massiv auf kurze Latenzen und enorme Bandbreite (~100GB/s) optimiert.
HBM hätte da auch wieder höhere Latenzen weil er nicht direkt angesprochen wird sondern über den HBM Controller.

[BoMbY]

Wie warscheinlich ist es eigentlich, dass in Zen 2 AVX512 implementiert wird?

Ja, sieht im Moment so aus als würde der erste K18 kein AVX512 haben - wobei ich aber auch nicht verstehe warum Zen2 schon eine neue Familie rechtfertigt. Weil Zen3 im Moment scheinbar auch unter K18 läuft, aber dann AVX512 mitbringen soll.

[gravitationsfeld]

Wie warscheinlich ist es eigentlich, dass in Zen 2 AVX512 implementiert wird?
Meiner Meinung nach ist es nicht mal gesichert, dass wir full rate AVX256 sehen. Wenn AVX512, dann wahrscheinlich mit full rate AVX256 und half rate AVX512.

Ich bin immer noch der Meinung, dass man solche Workloads besser die GPU machen laesst.

[basix]

SRAM ist nich nur teuer, sonder verbraucht auch viel Energie. Nicht ohne Grund hat RR nur 4MB L3$. Und eDRAM kann anscheinend nur in speziellen Prozessen hergestellt werden. Das geht nicht mit jedem beliebigen.

[fondness]

Ich sehe jedenfalls keinen Grund, bei 7 nm nicht einfach in mehr SRAM zu "investieren".

Das Argument könnte man bei jedem Fertigungswechsel bringen. Die Antwort ist immer die gleiche: Nämlich das mehr Kerne in der Regel mehr bringen als überproportional mehr Cache.

[basix]

Es gibt ja etliche Studien dazu die belegen, dass man überhalb 1-2MB Last-Level-$ pro Core die Hitrate nur noch marginal steigern kann (sind schon >90%) und man deshalb 2MB pro Core als "Sweet Spot" gewählt hat. Es ist immer ein Tradeoff zwischen Kosten und Leistungssteigerung. Ich denke die grosse Ausnahme sind hier Spiele, da sie am meisten von einer niedrigen Latenz profitieren. Wahrscheinlich profitieren auch andere Real-Time Anwendungen stärker davon als "normale" Anwendungen.

Links zu dem Thema Hitrate vs. Cache Grössen:
https://www.extremetech.com/extreme/188776-how-l1-and-l2-cpu-caches-work-and-why-theyre-an-essential-part-of-modern-chips
http://slideplayer.com/slide/9710585/
http://schools-wikipedia.org/wp/c/CPU_cache.htm

[robbitop]

Und wieso hat Intel nach Broadwell kein L4 mehr? Wenn es so gut wäre würden es auch die nachfolgenden Generationen haben

Weil es nichts mehr bringen würde. Memory Latency bei Haswell/Broadwell lag bei damaligem ddr3 bei insgesamt ~ 60 ns.
Der eDRAM lag bei 40 ns und war somit deutlich schneller. Die Fabric und der IMC haben beide ein sehr großen Einfluss auf die Latency. Hoch taktende Fabric (Ringbus) und ein hochtaltender IMC (läuft logischerweise mit ram Takt) reduzieren hier die Latency deutlich. CFL mit ddr4 mit relativ guten frequenzen liegt bei ~40ns für den RAM. Ein eDRAM LLC hätte also keinen Effekt mehr.

SRAM war doch immer relativ teuer (bzw. wurde es nie im Überschwang verwendet, sondern eher andere Dinge mit den Transistoren gemacht). Warum sollte das bei 7 LP anders sein?
Ein externer Cache ist immer langsamer und teuer. Was soll an SRAM teuer sein? Frisst halt Fläche. Je kleiner der Fertungungsprozess desto weniger. 16 qmm für 64 MiB ist vergleichsweise wenig Fläche.

SRAM ist nich nur teuer, sonder verbraucht auch viel Energie. Nicht ohne Grund hat RR nur 4MB L3$. Und eDRAM kann anscheinend nur in speziellen Prozessen hergestellt werden. Das geht nicht mit jedem beliebigen.
Was Energie kostet ist jeder Zugriff. Je weiter die Strecke desto mehr Energie. Ein Cachehit kostet weniger Energie als ein RAM Zugriff. Mehr Cache erhöht die Hitrate. Ein Zugriff auf einen externen edram oder hbm kostet mehr Energie als auf einem internen Cache.


Das Argument könnte man bei jedem Fertigungswechsel bringen. Die Antwort ist immer die gleiche: Nämlich das mehr Kerne in der Regel mehr bringen als überproportional mehr Cache.

Prinzipiell schon - aber die Randbedingungen ändern sich. Für viele Anwendungen bringen mehr Kerne immer weniger. Auch bringt 64 MiB richtig viel. Mit 7 nm wären 64 MiB LLC (wen er niedrige latency hat) in Spielen (sofern der Workload für den ihv relevant ist) erstmalig relativ vertretbar. 16 sqmm sind 5% der Fläche.


————————

Das alles gilt insbesondere für Spiele (und für die Bandbreitenentlasung einer IGP). Die meisten anderen Workloads profitieren davon kaum.

[Nightspider]

Liegen nicht gerade mal die highend DDR4 Kits + subtiming optimierung im Bereich von 40ns?

Der damalige eDRAM ist ja noch von 2014 wenn ich mich nicht irre. Mittlerweile könnte man bestimmt auch eDRAM mit niedrigeren Latenzen fertigen oder?

Und es bliebt auch immer noch der Punkt das ein eDRAM Chip günstiger ist als arschteurer DDR RAM mit hohen Taktraten.

Und gerade im Server-Bereich findest du keine hochtaktenden RAM und damit hättest du einen enormen Vorteil mit eDRAM.

[robbitop]

Es wurden hier schon 36 ns bei cfl erzielt.
Mein 4790K liegt mit ddr3-2400 sogar schon bei 42ns.

Ob es viele Serverworkloads gibt, die davon profitieren, weiss ich nicht. SRAM wäre schneller und mMn bis zu einer gewissen Größe billiger. Aber wenn das Instructionset der Anwendung sehr groß ist, wäre eDRAM ab einem gewissen Punkt sicher sinnvoll.

Der eDRAM Takt selbst ist analog zur Memory Latency kaum der Flaschenhals. Es ist der Controller und die Anbindung. Die können auch höher takten. Das kostet aber Energie. Gerade wenn man off chip muss.

[BoMbY]

Da ich gerade ehh mit den PMC auf Ryzen rumspiele hab ich das mal ausprobiert:

https://i.imgur.com/XofKW22.png

Das ist mit Linpack auf allen Threads. Bin mir noch nicht sicher wie akkurat das ist, die Performance Counter sind alle irgendwie ziemlich durcheinander.

[robbitop]

Aida64 ist das verbreitetste Tool zum Messen. Ich bekomme dort reproduzierbare Latencys raus. Somit auch vergleichbar mit Messwerten von anderen. :)

[BoMbY]

Das ist nicht die Latency, das sind die Hits/Miss in Prozent in der letzten Sekunde.

[robbitop]

Achso. Kannst du das auch für Spiele messen?

[Thunder99]

Das ist nicht die Latency, das sind die Hits/Miss in Prozent in der letzten Sekunde.

Und wieso wird ein ns Wert angegeben bei Aida?

[BoMbY]

Achso. Kannst du das auch für Spiele messen?

So sieht es mit SC im Arena Commander Modus aus:

https://i.imgur.com/T6LkfIF.png

Den L3 kann man scheinbar nur ordentlich pro CCX messen, da die Counter geshared sind.

[robbitop]

Und wieso wird ein ns Wert angegeben bei Aida?

Das hat mit Aida nichts zu tun.

[Setsul]

Jetzt muss ich mal doof fragen, warum die Latenz bei einem mesh größer wird, wenn der L3 pro Kern vergrößert wird? :|
Jede Cache slice ist ja auch nur ein Cache. Das Ding muss irgendwie die Daten holen und das dauert Zeit. Je größer der Cache desto langsamer. Wenn man den Cache unterteilt hat dann wird dadurch natürlich erstmal nur die Zeit von "richtige slice bekommt die Adresse" zu "slice hat die Daten gefunden und schickt sie jetzt zurück" länger.
Aber dann kommt noch dazu dass der Cache insgesamt auch größer ist. Egal ob das pro slice oder die Anzahl größer wird, die durchschnittliche Entfernung wird größer und dadurch steigt die durchschnittliche Latenz.
Alles in der eigenen slice des Kerns wird nur durch die Größer der slice beeinflusst, also etwas weniger, aber die Latenz steigt trotzdem an.

Weil es nichts mehr bringen würde. Memory Latency bei Haswell/Broadwell lag bei damaligem ddr3 bei insgesamt ~ 60 ns.
Der eDRAM lag bei 40 ns und war somit deutlich schneller. Die Fabric und der IMC haben beide ein sehr großen Einfluss auf die Latency. Hoch taktende Fabric (Ringbus) und ein hochtaltender IMC (läuft logischerweise mit ram Takt) reduzieren hier die Latency deutlich. CFL mit ddr4 mit relativ guten frequenzen liegt bei ~40ns für den RAM. Ein eDRAM LLC hätte also keinen Effekt mehr.

Das ist einfach falsch. Coffee Lake halbiert die Latenz von Skylake nicht einfach mal eben so.

Hier sieht man schön wo externer eDRAM ungefähr landet. Ist ganz nett wenn man 128-256MB gebrauchen kann (IGP) aber ansonsten die Kosten nicht wert. Deshalb gibt es seit dem fehlgeschlagenen Versuch mit Broadwell auch keinen GT3e Die mehr für Desktop.
https://images.anandtech.com/doci/9483/6700K%20CPU%20Memory%20Latency.png


Ein externer Cache ist immer langsamer und teuer. Was soll an SRAM teuer sein? Frisst halt Fläche. Je kleiner der Fertungungsprozess desto weniger. 16 qmm für 64 MiB ist vergleichsweise wenig Fläche.
[...]
Prinzipiell schon - aber die Randbedingungen ändern sich. Für viele Anwendungen bringen mehr Kerne immer weniger. Auch bringt 64 MiB richtig viel. Mit 7 nm wären 64 MiB LLC (wen er niedrige latency hat) in Spielen (sofern der Workload für den ihv relevant ist) erstmalig relativ vertretbar. 16 sqmm sind 5% der Fläche.
[...]
Das alles gilt insbesondere für Spiele (und für die Bandbreitenentlasung einer IGP). Die meisten anderen Workloads profitieren davon kaum.

Wenn du einfach von einer Halbierung ausgehst dann kann man entweder den L3 verdoppeln oder 36% mehr Kerne draufpacken. Selbst wenn die Kerne etwas größer werden, so viel bringt dir etwas mehr L3 nie.
IGP haben Serverchips auch nicht, also irrelevant.
Man hätte schon Zen1 sehr viel besser für Spiele designen können oder eben Skalierbarkeit für Server priorisieren, so wie es dann auch gemacht wurde. Was denkst du wird bei Zen2 wichtiger sein? Wieder Server oder auf einmal Spiele?


Die IF deutlich schneller zu machen, ohne dass die Leistungsaufnahme durch die Decke geht, ist vermutlich auch nicht so einfach. Ein großer LLC würde sofort helfen.
Überleg doch mal, wie kommen die Daten von einem CCX zum anderen? IF.

Doppelter L3 pro CCX beschleunigt wieviel an Daten? 8MB.
Schnelleres IF beschleunigt wieviel? x*8MB aus anderen CCX und alles was aus dem RAM kommt.
Welches von beiden kostet massiv Fläche? Mehr Cache.

Wenn das Problem ist, dass das IF zu langsam ist im Vergleich zur Konkurrenz dann klebt man nicht eine Menge Cache dran und bläst den Die auf nachdem man 5 Jahre daran gearbeitet hat vergleichbare Leistung mit kleinerem oder zumindest gleich großem Die zu bekommen. Man macht das IF schneller.

[BoMbY]

Könnt ihr auch mal selber ausprobieren:

62618

Grundsätzlich natürlich auch: Keinerlei Garantie

Das Ding geht nur auf Ryzen, unter Windows x64, mit .NET Framework 4.5.2, und das ist nicht NUMA-Aware (keine Ahnung was da passiert, oder nicht). Und beenden sollte man das am besten nicht über das X, sondern in der Konsole irgendeine Taste drücken und zwei Sekunden warten, ansonsten werden die Performance-Counter auf der CPU nicht gestoppt und laufen für dumme Nüsse weiter bis zum Neustart.

[robbitop]

@setsul
Ich habe Daten aus Aida. Auch von Crystalwell. Wenn ich sehe, was ich von 60 ns auf 42 ns für einen Boost in Spielen damit hole, entspricht das der Wirkung von Crystallwell im i7 5775c.

Die Zugriffszeiten in deinem Diagramm passen etwa. Sind aber massiv abhängig vom Ramtakt und vom Ringbustakt. Ich habe mit ddr2400 ggü ddr1600 15 ns rausgeholt. Die 6700k haben sicherlich relativ langsam getakteten ddr4 gehabt. Mit ddr4 4000 kommt man unter 40 ns. Der Vorteil im Spielen ist reproduzierbar messbar und auch (im cpu limit) stark ausgeprägt.

Letzteres sehe ich anders. Ein L4 Cache wäre trotz CCX deutlich unter 40 ns. Und kostet nur 5% mehr Fläche.

[Pirx]

Jetzt solltest du mal überlegen, warum es so nicht, afaik noch nie(?), so gemacht wurde.

[Grabhopser]

naja mit 7nm, quasi 2 Full-Nodes kann man schon einiges anfangen…
Ein sehr großer LLC, wie auch immer er strukturiert sein mag, kann sich da schon als „most bang for the bug“ herausstellen. Speziell wenn man den core count nicht verdoppelt.
Bei früheren Nodes war Cache einfach wesentlich flächenintensiver, da der Core prozentual noch mehr Die-space beansprucht hat.
Mangelndes Core Wachstum macht Raum frei, speziell wenn man sich zusätzlich die GPU im Vergleich zum Mitbewerber spart :wink:

SRAM lässt sich zudem gut abschalten, sollte doch mal ein Partikel drauf fallen ;D

[Der_Korken]

Es müssen ja nicht gleich 64MB für den L4 sein. Eventuell belässt AMD den L3 bei 4MB, so wie bei Raven Ridge und setzt dafür noch einen L4 drüber. 4 CCX mit je 8MB L3 wären zusammen 32MB, mit je 4MB L3 und einem 32MB L4 wären es in Summe 48MB, also nur 16MB mehr. Das entspräche nach robbitops Rechnung einer Fläche von 4mm². Je mehr CCX der Chip hat, desto eher könnte ich mir vorstellen, dass sich so eine Aufteilung lohnt.

Btw: Guckt euch mal Dieshots von Intels Core 2 Quad an. Der bestand quasi zur Hälfte nur aus Cache. Damals waren es 12MB L2 für vier Kerne. Auf 16 Kerne hochgerechnet wären das 48MB, wobei die heutigen Kerne viel leistungsfähiger sind als die alten (SMT, AVX, mehr IPC, usw.). Insofern ist an der These, dass heutige CPUs vergleichsweise wenig Cache haben, imho durchaus was dran.

[Setsul]

@robbitop:
Natürlich ist das vom Takt abhängig. In dem Fall war es 2133.
EDRAM ist trotzdem nicht langsamer als DDR4. DDR4 hat an sich erstmal höhere Latenz als DDR3. Klar kann man den hochprügeln mit ring multi auf 40x, aber dann müsstest du auch mit eDRAM auf 4 GHz rechnen. Ein off-chip eDRAM L4 hätte niedrigere Latenz als DDR4 und ein on-chip SRAM L4 erst recht. Trotzdem macht es keiner.

Gerade für Zen2 hast du dir die Antwort selbst gegeben. Ein bisschen niedrigere Speicherlatenz bringt genauso viel 128MB L4 für 4 Kerne. Man kann diskutieren wieviel dann 8MB L4 mit niedrigerer Latenz weil on-chip bringen. Aber wieso sollte man anstatt besserem IMC und schnellerem IF, was offensichtlich möglich ist, sonst könnte Intel es nicht, mehr Cache verbauen?
Das eine kostet keine Fläche, das andere schon.
Das eine erfordert kein Cache redesign, das andere schon. Ganz abgesehen von Victim Cache usw. geht bei Zen soweit ich weiß die Anfrage erstmal an den Snoop Filter um nicht IF zum anderen CCX auf dem selben Die und zu allen anderen Dies vollzuspammen. Rate mal wo der Snoop Filter dranhängt? Am IF. Und damit darf auch der L4 aufs IF warten. Das sieht dann wieder genauso aus wie Latenz zum L3 im anderen CCX oder eher noch schlimmer.
https://www.pcper.com/files/review/2017-03-10/ping-amd.png

5% von was auch immer du meinst sind Verschwendung wenn es fast kostenlos geht.
Raven Ridge hat keine großartigen Veränderungen und zeigt schon leichte Verbesserungen.
https://techreport.com/r.x/2018_02_12_AMD_s_Ryzen_3_2200G_and_Ryzen_5_2400G_processors_reviewed/memlatency.png
Bei Zen2 wird AMD sicher etwas umfassender Änderungen vornehmen und es sich dafür sparen den Cache zu verdoppeln.

[gravitationsfeld]

Ich bin mir auch nich so sicher dass sie mehr Cache einbauen werden. Die Signallaufzeiten sind primaer von der Distanz abhaengig und mehr Cache zwischen den Cores macht die nicht kuerzer.

Bei Intel ist seit Jahren ja auch 8MB bei vier Kernen Standard.

[robbitop]

Jetzt solltest du mal überlegen, warum es so nicht, afaik noch nie(?), so gemacht wurde.

A) was für ein Argument (ist keines) :D
B) bis dato wären 64 mib einfach zu groß gewesen und man konnte den Platz besser für Kerne investieren. Aber ab einem bestimmten Punkt bringen mehr Kerne nur begrenzten Mehrwert für die meisten Consumerworkloads

@setsul

Sehr hoch getakteter ddr4 mit optimierten Timings ist @cfl wie gesagt bei 36ns. Crystalwell liegt bei 40ns. Da gibt es nichts zu diskutieren. Das sind Messwerte. Aber sicherlich könnte man mit höher getakteten eDRAM bei gleicher Fabric (Ringbus) nochmal schneller sein. Mit der IF (zumindest der aktuellen Version) kannst noch nochmal 20ns draufpacken.

Die 6x ns bei RR sind sicherlich mit ziemlich schnellem Speicher. Die Notebookableger liegen bei 1xx ns bei ddr4 2400. Bei sehr schnellen Speicher schafft auch sr die 6x ns. Ich sehe hier keine Verbesserung bei RR. Bei gleich schnellem Speicher ist CFL mind 20ns schneller. (60 auf 42ns brachten im GTA5 Benchmark im CPU Limit bei mir 20% avg).

16 sqmm kosten 64mib @7nm (0.03um pro bit). Sind bei ~300 sqmm (SR) rund 5%.

Die IF schneller zu machen wäre natürlich ebenso zielführend. Ich fürchte aber, dass Skalierbarkei, Negieverbrauch und Performance diametale Kriterien sind. Intels Mesh in SKL-X hat das gleiche Problem. Auch dort ging es um bessere Skalierbarkeit.

@gravitationsfeld
Ein L4 müsste ja nicht zwangsläufig in die Mitte der Kerne im Layout

[Pirx]

ein gewissen Gewicht hat das schon, wenn sich diejenigen, die sich wirklich auskennen, wieder und wieder bei jedem Shrink dagegen entschieden haben, einen SRAM-L4 einzubauen
Deswegen sollte man als Halblaie auch mal dem folgen und sich überlegen, warum.

Mögl. sind es wirklich erstmal genug Kerne und man hat genau jetzt Platz für solche Spielchen. Andererseits bleiben auch bspw. Kerne nicht gleich...

[robbitop]

Es sind eben nur eine Teilmenge der Workloads mit einem so großen Instructionset, die von einem großen L4 profitieren. Die Power CPUs von IBM haben idR auch große L4. Deren Anwendungsgebiete scheinen zu profitieren. Spiele auch.
Ist aber beides nicht der Nabel der Welt und ggf. dann für AMD/Intel nicht sinnvoll.

Qualcomm hat im 845 btw auch einen (kleinen L4 eingebaut)

[HOT]

Ich bin mir auch nich so sicher dass sie mehr Cache einbauen werden. Die Signallaufzeiten sind primaer von der Distanz abhaengig und mehr Cache zwischen den Cores macht die nicht kuerzer.

Bei Intel ist seit Jahren ja auch 8MB bei vier Kernen Standard.
Das mag ja alles sein, aber das wären dann 16 Kerne, die an 2 Speicherkanälen hängen. Ich glaube mehr LL-Cache ist einfach unvermeidlich.

[Der_Korken]

ein gewissen Gewicht hat das schon, wenn sich diejenigen, die sich wirklich auskennen, wieder und wieder bei jedem Shrink dagegen entschieden haben, einen SRAM-L4 einzubauen
Deswegen sollte man als Halblaie auch mal dem folgen und sich überlegen, warum.

Die Kernzahl ist seitdem aber auch wieder gestiegen und wird mit Zen 2 weiter steigen. Nur weil der L4 bei einem Broadwell-Quadcore außerhalb von Spielen kaum was gebracht hat, heißt es nicht, dass es bei einem möglichen 16-Kerner mit CCX-Architektur nichts bringt. Von 2009 bis 2017 hatten sämtliche Intel-Designs einen L3-Cache mit Ringbus als LLC für alle Kerne. Da war ein L4 also nur ein zusätzlicher Puffer für den L3. Zen sieht hier ganz anders aus. Hier wäre es für mich konsequent, wenn AMD die vier Kerne pro CCX beibehält und nur noch deren Anzahl erhöht. Allerdings wird natürlich der Impact durch höhere Inter-CCX-Latenzen immer größer, je mehr es von diesen gibt, weil die Wahrscheinlichkeit steigt, dass der Austausch zweier zufälliger Kerne über CCX-Grenzen hinweg passiert. Und da könnte ein L4 durchaus mehr bringen als er Fläche kostet.

[basix]

Meiner Meinung liegt es auch daran, das die Applikationen explizit darauf designed werden um mit 256kB L2 und 2MB L3$. Dies ist bei Intel seit 10 Jahren der Standard. Dass man bei Änderungen dann weniger konsistente Performance erhält sieht man ja bestens an Skylake-X. Das ist meiner Meinung nach der Hautpgrund, wieso mehr Cache nur begrenzt etwas bringt, reduzierte Speicherlatenz zum DRAM aber enorm was.

[HOT]

So kann man das nicht sehen. Bei P4 war der L1$ zu klein, bei BD auch. Aber ansonsten reagiert die Software nicht so krass auf die $-Größe. Also keiner designt i.d.R. Software für so-und-so-viel Kerne oder Caches.
Ich denke, dass die L4-Annahmen einfach am Thema vorbeigehen. Ich denke, man wird einfach der L3 pro Kern vervierfachen, einfach, weil es der Prozess mit annehmbaren Latenzen zulässt und weil die Speicherbandbreite knapp wird und zusätzlich die Latenzen steigen werden. Intel mesht halt Kerne und AMD CCX, das hat alles Vor- und Nachteile. AMD sieht halt offenbar einen Vorteil darin, die Knoten fetter zu machen ohne das Netz zu vergrößern.

Wenn man jetzt an PhenomII zurückdenkt, brachte die Verdreifachung des L3 auch erhebliche Vorteile mit sich und das wurde auch erst durch den 45nm-Prozess überhaupt möglich.

[Der_Korken]

Können bei Zen eigentlich die Kerne auf den L3 eines anderes CCX zugreifen oder geht der Zugriff dann über den RAM? Ich war bisher von letzterem ausgegangen.

[Hübie]

Wie viel mehr Kerne bringen sehen wir doch beim Threadripper. Wir müssten in der Diskussion also mal auseinander halten ob Server- oder Gamingbereich betrachtet wird.

[YfOrU]

Können bei Zen eigentlich die Kerne auf den L3 eines anderes CCX zugreifen oder geht der Zugriff dann über den RAM? Ich war bisher von letzterem ausgegangen.

https://www.techpowerup.com/231268/amds-ryzen-cache-analyzed-improvements-improveable-ccx-compromises
However, on AMD's Ryzen 1800X, latency times are a wholly different beast. Everything is fine in the L1 and L2 caches (32 KB and 512 KB, respectively). However, when moving towards the 1800X's 16 MB L3 cache, the behavior is completely different. Up to 4 MB cache utilization, we see an expected increase in latency; however, latency goes through the roof way before the chip's 16 MB of L3 cache is completely filled. This clearly derives from AMD's Ryzen modularity, with each CCX complex (made up of 4 cores and 8 MB L3 cache, besides all the other duplicated logic) being able to access only 8 MB of L3 cache at any point in time.

Nach meinem Verständnis und den Werten (für größer 8MB) nicht und wenn doch macht es keinen Unterschied da der Weg über die IF nicht schneller als DRAM ist.

[basix]

IF bringt doch Cache-Kohärenz mit. Wieso sollte das also nicht gehen? Die Zugriffe sind dementsprechend einfach langsamer.

[Setsul]

Sehr hoch getakteter ddr4 mit optimierten Timings ist @cfl wie gesagt bei 36ns. Crystalwell liegt bei 40ns. Da gibt es nichts zu diskutieren. Das sind Messwerte. Aber sicherlich könnte man mit höher getakteten eDRAM bei gleicher Fabric (Ringbus) nochmal schneller sein. Mit der IF (zumindest der aktuellen Version) kannst noch nochmal 20ns draufpacken.

Du verstehst es immernoch nicht.
Du argumentierst dass sehr hoch getakteter DDR4 mit hoch getaktetem Ring schneller ist als niedrig getakteter eDRAM.
Das ist richtig aber völlig belanglos. Hoch getakteter DDR3 hat auch mehr Bandbreite als niedrig getakteter DDR4.

Und nochmal: Wenn du einen L4 anhängst dann läuft der auch über IF. Schon L3 zu L3 läuft über IF. Der L4 kann keine niedrigere Latenz haben als der L3 im anderen CCX. Außer man macht den L4 an sich schneller als den L3 und das ist völliger Schwachsinn.



Die 6x ns bei RR sind sicherlich mit ziemlich schnellem Speicher. Die Notebookableger liegen bei 1xx ns bei ddr4 2400. Bei sehr schnellen Speicher schafft auch sr die 6x ns. Ich sehe hier keine Verbesserung bei RR. Bei gleich schnellem Speicher ist CFL mind 20ns schneller. (60 auf 42ns brachten im GTA5 Benchmark im CPU Limit bei mir 20% avg).

Es geht hier nicht um absolute Werte sondern um relative. CFL, SR und RR laufen bei dem Test alle mit dem selben Speicher. RR hat niedrigere Latenz als SR. Das ist eine Verbesserung.


16 sqmm kosten 64mib @7nm (0.03um pro bit). Sind bei ~300 sqmm (SR) rund 5%.

Die Rechnung stimmt hinten und vorne nicht.
SR hat ~200mm².
Man baut nicht den Cache in 7nm und den Rest in 14nm. Also entweder mit 14nm Größen für beides rechnen oder mit ~100mm² für SR, wobei das auch nicht ganz stimmt weil die Interfaces wie IMC bei Weitem nicht so stark schrumpfen.
16 mm² für 64 MiB sind auch Schwachsinn. 8 MiB L3 kosten 16 mm² auf 14nm. Also 128 mm² für 64 MiB. Selbst wenn man annimmt, dass L4 dichter ist, werden da bei 7nm beim besten Willen keine 16 mm² draus.



Die IF schneller zu machen wäre natürlich ebenso zielführend. Ich fürchte aber, dass Skalierbarkei, Negieverbrauch und Performance diametale Kriterien sind. Intels Mesh in SKL-X hat das gleiche Problem. Auch dort ging es um bessere Skalierbarkeit.

Aber L4 der auch am IF hängt kostet keine Energie?

[mksn7]

IF bringt doch Cache-Kohärenz mit. Wieso sollte das also nicht gehen? Die Zugriffe sind dementsprechend einfach langsamer.

Die Cachelines die aus dem L2 eines Kerns evicted werden, werden nur im L3 des eigenen CCX platziert. Bei einem single core workload hat der Kern also effektiv nur die eigenen 4MB als L3 zur Verfügung.

Wenn ein Datum im L3 eines anderen CCX liegt, wird das Datum von dort transferriert, und muss nicht vom DRAM geladen werden. Wenn zwei Kerne in unterschiedlichen CCX also mit den gleichen Datum arbeiten, können sie das aus dem jeweils anderen Cache laden. Wird dann aber wahrscheinlich dupliziert.

[Der_Korken]

Die Cachelines die aus dem L2 eines Kerns evicted werden, werden nur im L3 des eigenen CCX platziert. Bei einem single core workload hat der Kern also effektiv nur die eigenen 4MB als L3 zur Verfügung.

Wenn ein Datum im L3 eines anderen CCX liegt, wird das Datum von dort transferriert, und muss nicht vom DRAM geladen werden. Wenn zwei Kerne in unterschiedlichen CCX also mit den gleichen Datum arbeiten, können sie das aus dem jeweils anderen Cache laden. Wird dann aber wahrscheinlich dupliziert.

Das passt gut zum obigen Test, wo die Zugriffszeiten ab 8MB durch die Decke gehen. Ist allerdings insgesamt etwas unschön, da es für einen Scheduler nicht einfach zu entscheiden ist, ob man z.B. vier Threads in den gleichen CCX packt (=geringe Latenz untereinander) oder in zwei unterschiedliche (=hohe Latenz untereinander, dafür doppelter L3 Cache).


Und nochmal: Wenn du einen L4 anhängst dann läuft der auch über IF. Schon L3 zu L3 läuft über IF. Der L4 kann keine niedrigere Latenz haben als der L3 im anderen CCX. Außer man macht den L4 an sich schneller als den L3 und das ist völliger Schwachsinn.


Was aber wäre, wenn es vier CCX gäbe? Bei einem L3 miss müssten dann drei andere L3-Caches angefragt werden. Das könnte man natürlich parallel durchführen und würde so effektiv nicht langsamer werden als mit nur zwei CCX, aber es würde doch sicher deutlich mehr Energie kosten. Wäre ein L4-LLC in diesem Fall nicht besser, trotz etwas mehr Latenz?

[fondness]

https://www.techpowerup.com/231268/amds-ryzen-cache-analyzed-improvements-improveable-ccx-compromises


Nach meinem Verständnis und den Werten (für größer 8MB) nicht und wenn doch macht es keinen Unterschied da der Weg über die IF nicht schneller als DRAM ist.

Das ist natürlich Blödsinn. Der Stromverbrauch wäre ein Wahnsinn, wenn man da jedesmal über den RAM gehen müsste.

Die interne Kommunikation ist hier ganz gut dargestellt:

https://s14.postimg.org/aqy1pxpsx/AMD-_ISSCC-_Zeppelin-_Zen-_EPYC-_Threadripper-_Ryzen_5-1480x823.png (https://postimg.org/image/651xhl49p/)

https://s14.postimg.org/dl173dzox/AMD-_ISSCC-_Zeppelin-_Zen-_EPYC-_Threadripper-_Ryzen_8-1480x823.png (https://postimg.org/image/8z52v1e5p/)

https://s14.postimg.org/ua2myt3up/AMD-_ISSCC-_Zeppelin-_Zen-_EPYC-_Threadripper-_Ryzen_9-1480x823.png (https://postimg.org/image/41ri9fjr1/)

https://s14.postimg.org/tkjumgb0x/AMD-_ISSCC-_Zeppelin-_Zen-_EPYC-_Threadripper-_Ryzen_10-1480x823.png (https://postimg.org/image/x45sc9dql/)

https://wccftech.com/amd-zeppelin-soc-isscc-detailed-7nm-epyc-64-cores-rumor/

[Setsul]

@Der_Korken:
Soweit ich weiß geht das so oder so an den zentralen Snoop Filter, deshalb ist der Zugriff auf einen anderen CCX ja so langsam.
Man könnte natürlich erst im L4 suchen aber dann wären alle L3s in anderen CCX und der RAM noch langsamer und man verliert mehr als man gewinnt.
Wenn man auf den L4 genauso zugreift wie auf andere L3s dann sieht das Ding effektiv wieder aus wie ein zusätzlicher CCX, also wieso nicht gleich ein paar CCX mehr ingesamt, dann hat man auch noch extra Kerne für die Fläche bekommen.

[Hübie]

Das ist natürlich Blödsinn. Der Stromverbrauch wäre ein Wahnsinn, wenn man da jedesmal über den RAM gehen müsste.

Die interne Kommunikation ist hier ganz gut dargestellt:

https://s14.postimg.org/aqy1pxpsx/AMD-_ISSCC-_Zeppelin-_Zen-_EPYC-_Threadripper-_Ryzen_5-1480x823.png (https://postimg.org/image/651xhl49p/)

https://s14.postimg.org/dl173dzox/AMD-_ISSCC-_Zeppelin-_Zen-_EPYC-_Threadripper-_Ryzen_8-1480x823.png (https://postimg.org/image/8z52v1e5p/)

https://s14.postimg.org/ua2myt3up/AMD-_ISSCC-_Zeppelin-_Zen-_EPYC-_Threadripper-_Ryzen_9-1480x823.png (https://postimg.org/image/41ri9fjr1/)

https://s14.postimg.org/tkjumgb0x/AMD-_ISSCC-_Zeppelin-_Zen-_EPYC-_Threadripper-_Ryzen_10-1480x823.png (https://postimg.org/image/x45sc9dql/)

https://wccftech.com/amd-zeppelin-soc-isscc-detailed-7nm-epyc-64-cores-rumor/

Gibt es zu diesen Folien auch Bandbreitenangaben (CCX->CCM->SDF->UMC->DDR4)? Sind die 90 ns vom Core zum DRAM und zurück zum Core (so interpretiere ich das)? Das erscheint mir ganz schön viel. :|

[BoMbY]

Ist die Frage was man genau misst? Vom Core bis L1 Miss, über L2 Miss, über L3 Miss, zum RAM-Fetch können das problemlos 90ns sein.

[basix]

Ich komme immer mehr zur Überzeugung, dass ein 6C oder 8C CCX mehr bringen würden als eine 3x / 4x CCX Konfiguration. Einfach mehr CCX in den Chip zu klatschen ist aber wesentlich einfacher und mit weniger Designaufwand zu lösen. Bei 8C CCX und verringerter DRAM Latenz wird man auch bei Spielen gut dahstehen. Verdoppelter L3 pro Core wäre nice, lohnt aber wahrscheinlich den Aufwand nicht. Vielleicht gehen sie aber auf verdoppelten L2, um im Zweifelsfall gegenüber Intel Skylake-X nicht das nachsehen zu haben.

[reaperrr]

Ich komme immer mehr zur Überzeugung, dass ein 6C oder 8C CCX mehr bringen würden als eine 3x / 4x CCX Konfiguration. Einfach mehr CCX in den Chip zu klatschen ist aber wesentlich einfacher und mit weniger Designaufwand zu lösen. Bei 8C CCX und verringerter DRAM Latenz wird man auch bei Spielen gut dahstehen. Verdoppelter L3 pro Core wäre nice, lohnt aber wahrscheinlich den Aufwand nicht. Vielleicht gehen sie aber auf verdoppelten L2, um im Zweifelsfall gegenüber Intel Skylake-X nicht das nachsehen zu haben.
SKL-X hat dafür wesentlich weniger L3, und die "angetackerten" 512KB L2 scheinen den Verbrauch auch ganz schön mit hochzutreiben.


Übrigens, versteht hier jemand genug von der Materie um einschätzen zu können, ob der Samsung-M3/Apple-Cores-Ansatz von 6-wide auch mit x86 funktionieren könnte?
7nm (und wenn er mal ausgereift ist, wohl auch Intels 10nm) sollte den Verbrauch pro Transistor doch theoretisch weit genug senken, um den komplexeren Decoder und die zusätzlichen Pipes kompensieren zu können, bei ~50% mehr IPC kann man zur Not in der ersten Generation auch Takt und Spannung etwas niedriger ansetzen.

Ich vermute zwar, dass AMD bei Zen2 "nur" auf Optimierungen und (wesentlich) mehr Takt setzen wird (wenn selbst GloFo von "5 GHz" für 7LP sprechen vs. "> 3 GHz" für 14LPP, wäre alles unter 4.5 GHz base und 5 GHz Turbo für Zen2 schon eine kleine Enttäuschung), aber es gibt durchaus Einsatzgebiete, wo weniger Kerne mit dafür wesentlich höherer IPC zweckmäßiger wären (u.a. Gaming, aber wegen der pro-Kern-Lizenzkosten auch in manchen Server-Bereichen).

[basix]

SKL-X ging von 256kB L2 auf 1MB ;) Aber bei SKL-X vermute ich das Mesh als Haupttreiber für den hohen Energieverbrauch. Gleich wie bei Vega und IF. Da werden einfach zu viele Daten herumgeschaufelt.

Ob 6-Wide was bringt: Wahrscheinlich schon, ist einfach aufwändig und komplex. Man ist heute bei 4-Wide und Intel bei 5-Wide. Wie viel das am Schluss bringt, keine Ahnung. Den µOP Cache deutlich zu vergrössern würde evtl. mehr bringen bei deutlich weniger Energieverbrauch gegenüber zusätzlichen Decodern. µOP Cache zusammen mit dem Ringbus L3 sind der Grund, wieso Sandy Bridge so schnell und Energieeffizient war.

Auszug aus wikichip:
"Decoding is the biggest weakness of x86, with decoders being one of the most expensive and complicated aspect of the entire microarchitecture. Instructions can vary from a single byte up to fifteen. Determining instruction boundaries is a complex task in itself. The best way to avoid the x86 decoding tax is to not decode instructions at all. Ideally, most instructions get a hit from the BP and acquire a µOP tag, sending them directly to be retrieved from the µOP cache which are then sent to the µOP Queue. This bypasses most of the expensive fetching and decoding that would otherwise be needed to be done. This caching mechanism is also a considerable power saving feature."
https://en.wikichip.org/wiki/amd/microarchitectures/zen#.C2.B5OP_cache_.26_x86_tax

[fondness]

Mit sehr hoher Wahrscheinlichkeit zähen hier Samsung/Apple einfach nur kreativer. So ein mobile Core ist sicher nicht "breiter" und erreicht auch nicht die IPC einer aktuellen x86 High-End-CPU.

[Setsul]

@basix:
Nicht vergessen der L3 ist zwar nur ein Victim cache aber shared. Den L3 zu verdoppeln kostet schon Latenz aber wenn man 6 oder 8 Kerne dranhängen will dann zieht das das Ding einfach aus geometrischer Notwendigkeit in die Länge. Bei 4 Kernen ist das L3-Viertel schräg gegenüber nicht viel weiter weg es der direkt gegenüber oder seitlich daneben. Bei 8 Kernen ist der Unterschied recht deutlich.

Dann kommt noch dazu dass jetzt der CCX alle Anfragen von 8 Kernen dirigieren muss. Die Daten vom RAM oder anderen L3 gehen ja direkt an den L2 und alles was aus den L1/L2s wieder rausfällt könnte irgendwo im ganzen L3 landen. Bei 8 Kernen (also 8 L2s + 16 L1s) und 16 MiB L3 könnte das ziemlich unangenehm werden.

Verdoppelter L2 kostet einiges. Intel leistet sich das nur weil sonst AVX-512 ziemlich sinnlos wird. Ohne höhere Bandbreite und größeren L2 wäre es kaum schneller als 256 bit.
Das ist außerdem alles Äpfel zu Birnen. Bei Zen sind die Caches deutlich anders strukturiert also ergeben die selben Größen wie bei SKL nicht unbedingt Sinn.

@reaperrr:
M1/M2/M3 sind kein gutes Beispiel weil M1/M2 zwar 4-wide decode haben aber damit nicht an einem 2-wide A73 vorbei kommen. Breite kostet, da muss auch entsprechend viel herauskommen sonst lohnt es sich nicht.
Es gibt einfach 2 Probleme:
1. x86 hat variable Längen und das wird sehr schnell sehr ekelhaft während ARM bei 64 bit immer exakt 4 Byte pro instruction hat (Thumb gibts nur bei 32 bit). 2 Decoder mehr sind bei ARM einfach 2 Decoder mehr, das ist billig. Bei x86 ist es wesentlich komplizierter. Über macro-op fusion kann man zwei instructions durch einen decoder drücken also kann Skylake unter bestimmter Umständen sogar schon 6. Außerdem kommen vom µop cache maximal 6, bei Zen sogar 8 mops.
2. Das zweite Problem ist was fängt man dann damit an? 6 instructions pro Takt sind schön und gut, bringen aber überhaupt nichts wenn man durch den renamer nur 4 durchkriegt. Dann sind 4 oder 5 decoder (evtl. + fusion) und/oder ein µop cache die einen Schnitt von 4 halten können auch nicht schlechter, aber billiger. Wenn man >=4 GHz will und 6 wide rename eben nur bei der Hälfte geht dann ist grob betrachtet klar was gewinnt. 50% mehr Breite kompensieren nicht 100% mehr Takt. Man kann dann anfangen mit Spielereien wie rename auf mehr Takte strecken, aber man muss auch erstmal genug finden dass parallel ausgeführt werden kann und dann auch ein entsprechend breites Backend haben, damit man auch so viel gleichzeitig ausführen kann.
Intel und AMD haben kein Problem damit viel mehr Strom zu verbrennen als ein M3, aber das Ding so breit zu machen, dass es den niedrigeren Takt ausgleicht, kostet Fläche und das heißt weniger Kerne.
Intel und AMD holen schon so viel raus wie sie können. Bei SKL sind es 4 fused µops, davon können aber 2 über macro-op fusion aus 2 instructions bestehen und die anderen 2 können micro-fused sein also im scheduler dann in 2 aufgeteilt werden. Rein theoretisch können als 8 µops im Backend landen, meistens natürlich weniger.
Bei Zen gehen anscheinend 6 mops aber nur 5 instructions (aber die decoder haben kein problem sogar 4 instructions mit je 2 mops zu decoden). Mops können auch wieder in 2 µops aufgeteilt werden also auch hier landet schon einiges im Backend. Zum Beispiel 256 bit ops werden zu je 2 128 bit µops, dann ist mit 2 mops der ganze FP Teil schon voll. 4 mops zur Integerseite die nur maximal 6 µops schafft da ist dann bei 2 mops die sich spalten schon Schluss. Und das erfordert natürlich eine Mischung von int und fp (ob jetzt über SMT oder im selben Programm). Man sieht auf jeden Fall ohne breiteres Backend bringt es nichts das Frontend jetzt noch großartig aufzubohren.

Also nochmal kurz zusammengefasst:
-Der M1/M2 sind ziemlich schlecht für ihre Breite, sonst bekäme Samsung nicht 50% mehr IPC bei 50% mehr Breite.
-Kein Nutzen ohne breiteres rename, breiteres rename kostet Takt, evtl. Nullsummenspiel.
-Wenig Nutzen ohne breiteres Backend, breiteres Backend kostet Fläche, Fläche kostet Kerne.

@basix:
Richtig, genau deshalb hat Zen ja CCX. Darunter ist Zen fast genauso verbunden wie SKL-SP. 4 Verbindungen pro Knotenpunkt, bei Zen eben je eine zu jedem anderen Die auf dem Package und eine zum anderen Socket, bei SKL-X links, rechts, oben und unten. Der Unterschied ist, dass Zen nur ein Viertel der Endpunkte hat.

EDIT:
@fondness:
Nein, das stimmt schon. Aber Apple hat diese Breite einfach bei halbem Takt und Samsung hat zwar die Breite, steht aber bei den IPC nicht besser da als schmälere Kerne.
Das sind auch einfach andere Designziele. Was scheren mich ein paar etwas größerere Kerne wenn 3/4 des Chips sowieso GPU, Cache und Sonstiges sind. 100 oder 120mm² interessieren keinen, der Stromverbrauch muss stimmen.
AMD und Intel sind mit deutlich höherem Vebrauch pro Kern noch glücklich, aber größere Kerne die dann so viel Platz kosten und auch noch niedriger takten weil die bei 4-5 wide rename schon hart an der Grenze liefen, sodass die Leistung pro Fläche um 50% sinkt sind einfach keine Option.

[BoMbY]

Wird nicht jeder Slice des L3 von seinem benachbarten Kern verwaltet? Abgesehen davon sinken die Entfernungen und Signallaufzeiten mit dem neuen Prozess, und es ist immer noch besser einen L3-Zugriff lokal zu machen, auch bei 8 Kernen pro CCX, als den L3 Cache im benachbarten CCX aufzurufen.

[basix]

Bei 7nm nimmt die SRAM Density um 2-2.5x zu gegenüber 14nm (je nach dem, ob High Density oder nicht). Bei einem 8C CCX wären die Entfernungen und Signallaufzeiten in etwa ähnlich wie heute. Die grosse Frage ist, wie sie das untereinander verbinden würden. Punkt-zu-Punkt wie heute zwischen den Slices oder per Ring. Bei mehr als 4 Cores beginnt sich der Ring schon zu lohnen, da viel weniger Verbindungen zischen den Cores. Beispiel 8C:

Heute 4C: maximal 1 Hop, Verbindungen zwischen den Cache Slices = 6
ohne Ring und max. 2 Hops zu allen Kernen = 14
ohne Ring und max. 1 Hop zu allen Kernen = 26
mit Ring und max. 4 Hops zu allen Kernen = 8


Nachteil ist einfach die höhere Latenz des Rings. Intel hat aber gezeigt, dass dies geht. Bei zwei Hops halten sich die Latenz sowie Anzahl Verbindungen noch im Rahmen.

[Setsul]

@BoMbY:
Nein, die slices sind "low order adress interleaved". Wie gesagt Zen und SKL sind sehr unterschiedlich organisiert, ich sollte das mal aufmalen.

Signallaufzeiten sind auch nicht mehr das was sie mal waren. Widerstand hängt von Länge*Querschnittsfläche ab, parasitäre Kapazität von Länge*Breite/Abstand zwischen den Schichten. Breite und Abstand werden beide kleiner, das hebt sich bestenfalls auf. Widerstand wird quadratisch größer. Das heißt bei gleicher Länge wird RC quadratisch größer, bei genauso geschrumpfter Länge bleibt es gleich. Also davon wurde ich mir keine Rettung erhoffen.

@basix:
Siehe BoMbY. Das sind keine unabhängigen slices. AMD ist nicht Intel. Zen ist nicht SKL.

Gleiche Signallaufzeit bedeutet entweder höhere Latenz für den L3 und die ist jetzt schon nicht überragend oder man gibt alles Taktgewinn durch 7nm auf. Beides keine gute Idee.

Vergiss Ringe, Intel hat Ringe aufgegeben weil mehrere Ringe zu verbinden nicht gut funktioniert.
Die L2 direkt zu verbinden aber dann L3 slices über Ringe ist schwachsinnige Duplizierung. Wenn man alles über Ringe macht verhungern die Kerne am anderen Ende des Rings. Noch höhere Latenz zum RAM hilft wirklich nicht. Intel hat gezeigt dass sie das selbst nicht mehr tolerieren können.

[gravitationsfeld]

Coffee Lake hat immer noch einen Ring, oder?

Edit: Skylake-EP scheint ein Mesh zu haben.

[Setsul]

Ja, die kleinen Dies haben noch einen Ring. Bei 6 Kernen stört das auch nicht, ist nur ein einzelner Ring. Am entferntesten vom RAM sitzt dann die iGPU, die stört das bisschen extra Latenz auch nicht.

[BoMbY]

@BoMbY:
Nein, die slices sind "low order adress interleaved". Wie gesagt Zen und SKL sind sehr unterschiedlich organisiert, ich sollte das mal aufmalen.


Du solltest das nicht aufmalen, Du solltest besser die Quellen für Dein Wissen zitieren. Das hört sich alles toll an, nur ob es stimmt, oder totaler Quatsch ist, kann man so leider nicht beurteilen.

[Setsul]

Aber es wäre künstlerisch wertvoll!

https://pics.computerbase.de/7/4/1/5/4/14-1080.3338864818.png
Also man weiß das jetzt seit 1,5 Jahren und es war kein großes Geheimnis oder schwer zu finden, deshalb hab ich das nicht zitiert. Das steht selbst hier http://www.7-cpu.com/cpu/Zen.html oder in jedem Artikel der sich mit Zen beschäftigt.

[bbott]

Du solltest das nicht aufmalen, Du solltest besser die Quellen für Dein Wissen zitieren. Das hört sich alles toll an, nur ob es stimmt, oder totaler Quatsch ist, kann man so leider nicht beurteilen.

Wie wäre es mit beidem ;-)

[BoMbY]

Übrigens hat GloFo bei 7LP angefangen Kupfer durch Kobalt zu ersetzen (https://fuse.wikichip.org/news/641/iedm-2017-globalfoundries-7nm-process-cobalt-euv/4/), in bestimmten Layern. Und Intel scheint für 10nm auf den gleichen Trichter gekommen zu sein (https://fuse.wikichip.org/news/525/iedm-2017-isscc-2018-intels-10nm-switching-to-cobalt-interconnects/2/). Das dürfte einiges am bisher bekannten ändern.

[Gipsel]

Übrigens hat GloFo bei 7LP angefangen Kupfer durch Kobalt zu ersetzen (https://fuse.wikichip.org/news/641/iedm-2017-globalfoundries-7nm-process-cobalt-euv/4/), in bestimmten Layern. Und Intel scheint für 10nm auf den gleichen Trichter gekommen zu sein (https://fuse.wikichip.org/news/525/iedm-2017-isscc-2018-intels-10nm-switching-to-cobalt-interconnects/2/). Das dürfte einiges am bisher bekannten ändern.Eher wird da das bisher bei den Local Interconnects benutzte Wolfram ersetzt. ;)

[BoMbY]

Naja, erstmal bzw. auch.

Aber bei Intel werden scheinbar definitiv in den ersten beiden Layern Kobalt genutzt:


It’s worth noting that cobalt isn’t used for everything. It’s only used for the first two metal layers (i.e., M0 and M1) where you have your local interconnect that have very narrow pitches (e.g., 36nm) and where cobalt does benefit them.



Und GloFo hat es, jedenfalls vor Kurzem noch, in Betracht gezogen (http://semimd.com/blog/2017/12/21/companies-ready-cobalt-for-mol-gate-fill/):


John Pellerin, a vice president at GlobalFoundries who directs global research and development, said GlobalFoundries decided that for its 7nm logic technology, ramping in mid-2018, it would replace tungsten with cobalt at the trench contact level, which is considered the first level of the middle-of-the-line (MOL).

“We are evaluating it for implementation into the next level of contact above that. Cobalt trench level contacts are process of record (POR) for the 7nm technology,” Pellerin said in an interview at the 2017 IEDM, held Dec. 2-6 in San Francisco.

[OC_Burner]

Mir ist Heute beim Bearbeiten bzw. Abschleifen der Vega 10 GPU und der Raven Ridge APU ein auffallend silberner Layer begegnet. ob dies Kobalt war läßt sich nicht sagen, sollte aber schon wundern wenn plötzlich wieder Aluminium ins Spiel kommt.

Underfill/Microbumps --> Gold Layer --> Kobalt/Aluminium Layer? --> Gold Layer --> Kupfer Layer --> ...

Soweit ich mich erinnern kann, ist mir das bei modernen Chips, so noch nicht untergekommen. Mangels ausführlicher Dokumentation, läßt sich das aber nicht mit voller Gewissheit sagen.

[Gipsel]

Naja, erstmal bzw. auch.

Aber bei Intel werden scheinbar definitiv in den ersten beiden Layern Kobalt genutzt:Und genau da war bisher eben Wolfram üblich. Kobalt wird für die local interconnects der unteren Layer in Betracht gezogen (bzw. vereinzelt schon eingesetzt). Das bedeutet nicht, daß jetzt die Kupferleitungen wegfallen (bzw. aus Kobalt gefertigt würden). Das ist im Prinzip genauso wie man eben mit den bisherigen Wolfram local interconnects auch auf Kupferleitungen setzt (und die Interconnects zwischen den oberen Layer sind typischerweise auch aus anderen Materialien als Wolfram).

Edit:
In Deinem Quote von GloFo steht doch sogar explizit drin, daß man Wolfram durch Kobalt ersetzt (nicht Kupfer durch Kobalt):
John Pellerin, a vice president at GlobalFoundries who directs global research and development, said GlobalFoundries decided that for its 7nm logic technology, ramping in mid-2018, it would replace tungsten with cobalt at the trench contact level,

[dildo4u]

Ist Zen 2 zu früh für DDR5?

https://www.pcwelt.de/a/ddr5-speicher-in-der-planung-doppelt-so-schnell-wie-ddr4,3443660

[HOT]

Jep, Matisse ist AM4. Aber, der Picasso-Nachfolger, welcher ja der Zen2-Generation zugerechnet werden dürfte, könnte durchaus schon AM5 mit DDR5 sein.

[robbitop]

Du verstehst es immernoch nicht.
Du argumentierst dass sehr hoch getakteter DDR4 mit hoch getaktetem Ring schneller ist als niedrig getakteter eDRAM.
Das ist richtig aber völlig belanglos. Hoch getakteter DDR3 hat auch mehr Bandbreite als niedrig getakteter DDR4.
Es geht mir nicht um Bandbreite sondern um Latenz. Ein höher getakteter eDRAM wäre aber in dieser Hinsicht sicherlich auch schneller. Ja, hast du Recht. :)

Und nochmal: Wenn du einen L4 anhängst dann läuft der auch über IF. Schon L3 zu L3 läuft über IF. Der L4 kann keine niedrigere Latenz haben als der L3 im anderen CCX. Außer man macht den L4 an sich schneller als den L3 und das ist völliger Schwachsinn.
Die IF erzeugt laut den Messungen, die man so findet ~40-45 ns Latency beim Zugriff auf den L3 auf einem anderen CCX. Da kann man ~10 ns für den L3 an sich abziehen, kommt eine Latenz von ~30-35 ns für die IF heraus. Nicht so toll. Ein großer L4 hätte sicherlich (wenn die Dichte / Leistungsaufnahme besser werden soll -> relativ geringe Assoziativität) nochmal eine schlechtere Zugriffszeit. Insgesamt sind ~50 ns sicherlich nicht unrealistisch. Stimmt schon. Lohnt dann nicht mehr so richtig, wenn man die IF auch generell schneller machen kann. Ich gebe dir auch hier Recht. :)



Es geht hier nicht um absolute Werte sondern um relative. CFL, SR und RR laufen bei dem Test alle mit dem selben Speicher. RR hat niedrigere Latenz als SR. Das ist eine Verbesserung.
Ich verstehe was du meinst. Ich sehe hier aber leider keine Verbesserung in den Reviews (RAM latency messen leider nicht viele reviews :().

https://www.techporn.ph/wp-content/uploads/AMD-Ryzen-5-2400G-Benchmarks-5.png
Gleicher RAM:
1600X: 82,9 ns
2400g: 81,3 ns

Golem misst für den 2400g 81,5 ns
https://www.google.de/search?q=2400g+aida64&safe=off&rlz=1C1GGRV_enDE751DE751&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiInNXmobfZAhXN_qQKHcXYBiMQ_AUICygC&biw=1920&bih=1094#imgrc=HwsFQJsd4D5gaM:




Die Rechnung stimmt hinten und vorne nicht.
SR hat ~200mm².
213 mm². Ich hatte ~300 in Erinnerung. Mea culpa.


Man baut nicht den Cache in 7nm und den Rest in 14nm. Also entweder mit 14nm Größen für beides rechnen oder mit ~100mm² für SR, wobei das auch nicht ganz stimmt weil die Interfaces wie IMC bei Weitem nicht so stark schrumpfen.
So war das nicht gemeint. Gemeint war, dass AMD offenbar ein ~300 (bzw nun wissen wir dass es ein ~200 sqmm) Budget ansetzt. Bei einem Shrink könnte man den Vorteil 1:1 in eine verkleinerte Die Size umsetzen. Nur wird die freie Fläche - bzw das Budget idR ausgeschöpft durch mehr Logik/SRAM um die Leistung zu steigern.


16 mm² für 64 MiB sind auch Schwachsinn. 8 MiB L3 kosten 16 mm² auf 14nm. Also 128 mm² für 64 MiB. Selbst wenn man annimmt, dass L4 dichter ist, werden da bei 7nm beim besten Willen keine 16 mm² draus.
Ich habe nur die Zellgröße genommen und entsprechend extrapoliert. Ist die Dichte nicht auch ein ganzes Stück von der Assoziativität abhängig? IIRC kann man bei einer relativ geringen Assoziatität die Dichte deutlich erhöhen.



Aber L4 der auch am IF hängt kostet keine Energie?
Ohne Zugriff praktisch nein. Bei einem Zugriff ja. Aber sicherlich weniger als ein Zugriff auf den RAM (cache miss im L1-L3). Weiterer Weg -> höherer Energiebedarf.

Interessant übrigens die Messungen und Schlussfolgerungen von Anandtech zu Raven Ridge zum Thema IF.


For the core only power, the Ryzen 5 2400G uses less power than the Core i3-8350K, despite the situation being reversed when considering the whole package. This means that Infinity Fabric takes a lot of power here, and the ring bus solution that Intel uses benefits from being simpler, and Intel can push more power to its individual cores.
https://www.anandtech.com/show/12425/marrying-vega-and-zen-the-amd-ryzen-5-2400g-review/13

Offenbar ist die IF relativ "durstig" im Vergleich zu Intels Ring. Und dazu auch noch langsamer.

Ich gebe dir Recht, dass hier eine Menge "Optimierungspotenzial" besteht. :)

[y33H@]

Anandtech liest das per HW-Info aus, vermute ich?

[robbitop]

Ich tippe mal ja. Keine Ahnung wie genau das ist. Bei GPUs soll das ja (laut igor?) ziemlich ungenau sein.

[ndrs]

Ohne Zugriff praktisch nein. Bei einem Zugriff ja. Aber sicherlich weniger als ein Zugriff auf den RAM (cache miss im L1-L3). Weiterer Weg -> höherer Energiebedarf.
Allerdings sollte der RAM-Zugriff bei vorhandenem L4 ebenfalls teurer werden, da hier erst ein Miss festgestellt werden muss, oder?

Interessant übrigens die Messungen und Schlussfolgerungen von Anandtech zu Raven Ridge zum Thema IF.
https://www.anandtech.com/show/12425/marrying-vega-and-zen-the-amd-ryzen-5-2400g-review/13
Für ein solches Szenario sollte doch ein Benchmark ideal sein, der nahezu vollständig im Cache laufen kann und sehr hohe Kommunikationslast zwischen den Cores anlegt. Gibt es sowas? Dann könnte man auch den absoluten Energieverbrauch vergleichen und müsste sich nicht auf die Angaben bestimmter Tools verlassen.

[SKYNET]

Jep, Matisse ist AM4. Aber, der Picasso-Nachfolger, welcher ja der Zen2-Generation zugerechnet werden dürfte, könnte durchaus schon AM5 mit DDR5 sein.

evtl. bleibts auch bei AM4, so das die neuen CPUs mit DDR4 und 5 umgehen können... zumindest würde das bei AMD ins konzept passen, das sie immer recht lange an einem sockel festhalten.

[robbitop]

Allerdings sollte der RAM-Zugriff bei vorhandenem L4 ebenfalls teurer werden, da hier erst ein Miss festgestellt werden muss, oder?


Ja aber das passiert dann dafür aufgrund der großen Größe deutlich seltener. Also unterm Strich ein Gewinn.

[HOT]

evtl. bleibts auch bei AM4, so das die neuen CPUs mit DDR4 und 5 umgehen können... zumindest würde das bei AMD ins konzept passen, das sie immer recht lange an einem sockel festhalten.
Na ich denke eher, dass AM4 mit Matisse wirklich sein Finalstadium erreicht hat. Eine neue APU in dem Segment wird DDR5 einfach brauchen.

[Piefkee]

https://www.reddit.com/r/Amd/comments/7zayer/an_epyc_master_plan_adoredtv/

Neues Video von AdoredTV über EPYC.

Was haltet ihr von dem Gerücht das AMD bei EPYC die Cores und den Cache trennt? Also bei einem 64 Core EPYC, fünf Packages verwendet. 4 Packages mit jeweilgs 16 Cores und 1 Package für den Cache? Würde sowas überhaupt funktionieren?

Jim meint zudem das EPYC bei TSMC gefertigt wird. Gründlage für dafür ist der Artikel von
https://www.extremetech.com/computing/263286-sitting-globalfoundries-talk-7nm-euv

Unlike its competitors, GlobalFoundries is skipping 10nm altogether and heading straight for 7nm, with an AMD Vega chip designed for machine intelligence workloads apparently serving as a so-called “pipe cleaner” to test the design and its capabilities.


Er bezieht sich darauf das GloFo Vega 7nm macht und deshalb TSMC EPYC macht. Weil alles wird GloFo nicht stemmen können.

[bbott]

@Piefkee

Nette Idee, allerdings wäre dann beim L3 immer ein CCX konten dazwischen, was zuviel Performance kostet.

[robbitop]

IBM hat bei ihren POWER CPUs vor Jahren ähnliches mit eDRAM als LLC auf dem Package gemacht. (glaube es war in dem Fall sogar L3)
Ist halt langsamer - dafür größer. :)

[Der_Korken]

Für einen L3 ist sowas doch viel zu langsam. Behält man die 2MB pro Core bei, käme man bereits auf 128MB L3 für alle Kerne zusammen. Da müsste Off-Die Cache schon wirklich deutlich größer sein, damit er was bringt. Da würde ein HBM-Stack mit 8GB und 256GB/s (eventuell sogar 300, wenn es bis dahin 1,2Ghz schnellen HBM2 gibt) als L4-Cache schon mehr Sinn ergeben imho.

[robbitop]

War vieleicht für damalige Serverworkloads (sehr großes Instruction set und relativ hohe memory latencys) sinnvoll. Das war Power5 oder 6 IIRC.

Die Frage ist, ob HBM wesentlich schnellere Latencys bietet als schnell angebundener RAM. Ich denke Setsul hat schon Recht. Die Fabric muss einfach schneller werden. Man sieht, wie stark das SKL-X ggü SKL (in Spielen) pro Takt einschränkt. Gleiche mArch aber je nach Spiel zwischen 10-15% langsamer pro Takt. Immer wenn man über das Mesh/Fabric muss (anderer L3 Slice, IMC->RAM) bremst es die Latency. Und es scheint auch Leistungsaufnahme zu "kosten". Skalierbarkeit ist anscheinend leider nicht umsonst.

Ich nehme aber mal an, dass die aktuellen Fabrics (Mesh/IF) noch einiges an Optimierungspotenzial haben.

Ein Anfang wäre es schon mal, wenn es für Pinnacle Ridge einen separat einstellbaren Taktgeber für die IF gäbe (so dass man hier ggf höhere Taktraten fahren könnte).

[Der_Korken]

Die Latenz des HBM müsste vielleicht gar nicht mal geringer sein. 8xDDR4 3200 sind auch "nur" 204,8GB/s. Da kann ein HBM2-Stack schon 50% mehr bieten (Samsung hatte afaik mal 1,2Ghz angekündigt) und würde sicherlich auch Energie sparen, wenn die ganzen Zugriffe nicht aus dem Sockel rausmüssen. Ob es was bringt, weiß ich nicht, aber man wird ja nicht umsonst 6 oder 8 Memory Channel bei den dicken CPUs verbauen, wenn es nichts bringen würde.

[Unicous]

Wie alles was aus dem Mund von diesem "Youtuber" stammt völliger Blödsinn (oder alternativ von irgendjemandem geklaut und in endlos lange Videos gestreckt). Keine Ahnung aus welchen Reddit-Thread oder Forum er sich solch eine absurde Idee geholt hat aber man darf sicher sein, dass der Typ es als seine eigene vermarktet.

Dass AMD bei TSMC und möglicherweise auch Samsung fertigen lassen könnte, ist jetzt keine neue Erkenntnis aber warum ausgerechnet Epyc exklusiv bei TSMC gefertigt werden soll würde ich dann auch gerne mal wissen.:rolleyes:

Dieses im Trüben Gefische und das dann als Fakt Gerücht zu verkaufen ist schon sehr traurig.

[BoMbY]

Es praktisch 100% sicher, dass ausschließlich GloFo AMD's CPUs produzieren wird. Die waren dort schon immer der Primärposten, und allerhöchstens werden GPUs und SemiCustom-Gedöns extern gefertigt.

Und dieser Youtuber erzählt in der Tat eine Menge Unsinn.

[robbitop]

Die Latenz des HBM müsste vielleicht gar nicht mal geringer sein. 8xDDR4 3200 sind auch "nur" 204,8GB/s. Da kann ein HBM2-Stack schon 50% mehr bieten (Samsung hatte afaik mal 1,2Ghz angekündigt) und würde sicherlich auch Energie sparen, wenn die ganzen Zugriffe nicht aus dem Sockel rausmüssen. Ob es was bringt, weiß ich nicht, aber man wird ja nicht umsonst 6 oder 8 Memory Channel bei den dicken CPUs verbauen, wenn es nichts bringen würde.
Bandbreite ist (für CPUs @Spielen im CPU Limit) kein Bottleneck derzeit. QC bringt nahezu nichts und das was es bringt ist der gleiche Effekt wie DR vs SR. Die Zugriffszeit ist ein wenig schneller.

Für APUs/IGPs wäre mehr Bandbreite hingegen sicherlich sehr wünschenswert. Sicherlich gibt es auch Anwendungen (Server/Enterprise Bereich?) die auch von Bandbreite profitieren. :)

[Unicous]

100% sicher aus Bombys Mund bedeutet dann wohl dass GF nur noch GPUs fertigt und TSMC und Samsung sich die CPU/APU Fertigung teilen.:freak:

GF ist im Vergleich zu TSMC und Samsung (und Intel) eine kleine Nummer. Wenn AMD mehr Kapazitäten braucht, stoßen sie über kurz oder lang an eine Grenze die GF nicht mehr bedienen kann, da sie nur eine Fab haben die 14nm bzw. dann 7nm fertigen kann. Sollte AMD also signifikante Marktanteile erobern brauchen sie auch entsprechend Volumen. Von "praktisch 100% sicher" auszugehen ist also nicht nur vermessen sondern zeugt von wenig Vorausschau.

[Piefkee]

Dass AMD bei TSMC und möglicherweise auch Samsung fertigen lassen könnte, ist jetzt keine neue Erkenntnis aber warum ausgerechnet Epyc exklusiv bei TSMC gefertigt werden soll würde ich dann auch gerne mal wissen.:rolleyes:


Ehrlich gesagt finde ich seine Videos schon gut. Das Video über PCPer und auch Intel fand ich schon interrsant und auch sehenswert.

Er hat kein Gerücht verbreitet, er meinte nur damit das AMD auch woanders fertigen muss.

Lisa Su hatte ja gesagt das AMD in Zukunft auch bei TMSC und Samsung fertigen wird.

Ich denke die Behauptung kommt aus dieser Grundlage.
AMD Ryzen (Consumer) wird komplett bei GloFo gefertigt
AMD GPU (Vega 7nm) wird ebenfalls bei GloFo gefertigt, siehe Link.
AMD EYPC wird woanders (TMSC) gefertigt, damit minimiert man sich das GloFo Risiko, falls sie mit 7nm wieder Probleme bekommen, siehe 14nm.

Persönlich halte ich das Scenario für wahrscheinlicher...
CPU = GloFO
GPU = TMSC

[BoMbY]

100% sicher aus Bombys Mund bedeutet dann wohl dass GF nur noch GPUs fertigt und TSMC und Samsung sich die CPU/APU Fertigung teilen.:freak:

Ich frage mich wirklich warum man Dich hier nach belieben herumtrollen lässt. In jedem anderen Forum wärst Du schon 10x auf Lebenszeit gesperrt worden.

Aber egal, siehe z.B. das 2017 Proxy Statement (http://ir.amd.com/static-files/83eeb3ba-5aed-4f7b-9a7a-0aa2e6e94bdd):


Pursuant to the WSA, we are required to purchase all of our microprocessor and accelerated processing unit (“APU”) product requirements and a certain portion of our graphics processing unit (“GPU”) product requirements from GF with limited exceptions.


Und ja, das hat auch nach der Erweiterung von 2016 noch Gültigkeit.

[Unicous]

@Piefkee

Ehrlich gesagt... hat er keinen blassen Schimmer von dem was er so über die keine Ahnung 30 Minuten oder länger? palavert. Schon allein zu behaupten es wäre eine gute Idee den Cache auszulagern zeugt von wenig Kompetenz, wenn man heutzutage so wenig Cache-Latenz wie möglich erreichen möchte und durch Abspaltung in einen hypothetischen Die eben diese in die Höhe schießen, ganz zu schweigen davon, dass die Komplexität dieses Chips sich nicht verringert den jeder CPU-Die muss natürlich "verdrahtet" werden, dass heißt zig extra PHYs, das bedeutet ein größeres Package mit mehr Verbindungen bloß um ein wenig Die area zu sparen? Oder was denkt er wird daraus Positives entstehen. Das ist eine undurchdachte Luftnummer.

Ich kann nicht nachvollziehen, was an dem Typen und seinen Videos "gut" sein soll. Das einzige was er tut ist sich der AMD fanboybase anzubiedern und hat sie sogar darauf trainiert seine billig inszenierten shitstorms zu viralisieren. Wenn ich bei Reddit in die Threads schaue komme ich aus dem ROFLen und dem Augen rollen gar nicht mehr heraus. Er hat sich da ein paar Skript-Kiddies angelacht die, wie er, keinen blassen Schimmer haben aber dennoch bereit sind für ihn in den heiligen Krieg zu ziehen. Dabei ist er ein ganz laues Lüftchen.

Das zeigt auch das ganze PC Per Drama. Ihm ging es nicht um Aufklärung. Ihm ging es um Aufmerksamkeit und selbstgerechtes Fingerzeigen, dabei labert er sich selbst um Kopf und Kragen, aber offensichtlich scheint das niemanden zu interessieren. Wer einmal lügt dem... schenkt man seine Views und Aufmerksamkeit scheint die Devise im Informationszeitalter zu sein. ¯\_(ツ)_/¯

@BoMbY

Wir haben 2018, 2019 werden die ersten 7nm Chips released, das WSA wird jedes Jahr neu verhandelt (und auch der schöne legal text hat sich in den letzten Jahren in Nuancen geändert, das hatten wir alles schon mehrfach diskutiert), AMD hat bereits angekündigt mit Samsung zu kooperieren.

Interessant finde ich auch, dass du immer wieder aufs Neue nur Passagen postest die deiner Narrative entsprechen. Warum postest du nicht auch diese Sätze?:confused:

The sixth amendment also provides us a limited waiver with rights to contract with another wafer foundry with
respect to certain products in the 14nm and 7nm technology nodes and gives us greater flexibility in sourcing foundry
services across our product portfolio. In consideration for these rights, we agreed to pay GF $100 million, which will be
paid in installments starting in the fourth fiscal quarter of 2016 through the third fiscal quarter of 2017. Starting in 2017
and continuing through 2020, we also agreed to make quarterly payments to GF based on the volume of certain wafers
purchased from another wafer foundry.

Im Übrigen ist das kein Trollen sondern dir den Spiegel vorhalten. Du hast in der Vergangenheit schon so viele Nostradamus-Erkenntnisse mit uns geteilt die dann am Ende irgendwie nicht so eingetreten sind wie von dir verlautbart, ich würde dir einfach raten von solchen Behauptungen Abstand zu nehmen.:up:

Was 2016 und 2017 noch aktuell war entspricht seit Ryzen Launch einfach nicht mehr der Realität.

[Piefkee]

@Piefkee

Das zeigt auch das ganze PC Per Drama. Ihm ging es nicht um Aufklärung. Ihm ging es um Aufmerksamkeit und selbstgerechtes Fingerzeigen, dabei labert er sich selbst um Kopf und Kragen, aber offensichtlich scheint das niemanden zu interessieren. Wer einmal lügt dem... schenkt man seine Views und Aufmerksamkeit scheint die Devise im Informationszeitalter zu sein. ¯\_(ツ)_/¯

Die ganze PCPer Geschichte halte ich für wichtig in der Industrie. Sowas geht einfach nicht wenn ich unabhängig Review haben will. Ich weis nicht ob du das ganze verfolgt hast. Aber PCPer hat AdoredTV zuvor auf das Intel Video angeriffen. Und die Nachfrage das Video zu machen kam aus der Industrie, laut AdoredTV.

Ich finde ein YT Channel, der tiefer in die Materie eingeht als die TechMedien hat seine dassein Berechtigung. Sicherlich ist nicht alles was er sagt auf die Goldwage zu legen aber mit machen Dingen hat er schon recht. Und es ist schon auch eine Arbeit sich die ganzen Informationen herauszusuchen. Siehe das Intel Video über die "Zahlungen" an die OEM. Ich will gar nicht wissen wieviele Tage er in den ganzen Gerichtsdokumenten herumgesucht hat. Sowas finde ich einfach Klasse und auch sehenswert.

[Piefkee]

Aber egal, siehe z.B. das 2017 Proxy Statement (http://ir.amd.com/static-files/83eeb3ba-5aed-4f7b-9a7a-0aa2e6e94bdd):

Und ja, das hat auch nach der Erweiterung von 2016 noch Gültigkeit.

Die aktuelle WSA kennt doch niemand genau? Was man unter den ausnahmen verstehen kann weis doch niemand außer GloFo und AMD.

GloFo wird sicherlich gerade bei 100% Auslastung sein. Wenn man nun auf 7nm wechselt und GloFo nur eine fähige FAB hat, wird AMD zwangsläufig auslagern müssen. Was das nun ist, keine Ahnung.

Ich denke GloFo wird nicht die Kapazität haben wenn EPYC (2) aus dem einstelligen Bereich in den zweistelligen Marktbereich kommt.

[Unicous]

Das geht jetzt ziemlich weit ins OT.

Entschuldige, aber was geht denn da tiefer? Der Herr postet ellenlange Videos mit Informationen die andere in 5 Minuten abhandeln. Seine Videos sind von dem was ich "lese" (ich kann mir das Gebrabbel nicht länger als ein paar Minuten anhören, sorry) gespickt mit Fehlinformationen, Fehlinpretationen und ganz allgemein Blödsinn. Er ist im Grunde genommen WTF-Tech in Video Form. Er greift jedes noch so blödsinnige Gerücht auf, zumeist über AMD, und tut dann so als wäre er da ganz allein drauf gekommen bzw. "analysiert" das in minutenlangen Abhandlungen. Es geht im auch nicht um journalistische Ethik, er will einfach nur Leute anpinkeln. Denn er selbst schert sich nicht um Ethik und Moral. Das kann man in seinen zahlreichen ("gelöschten") Posts bei r/hardware nachlesen oder dem email-Verkehr mit Ryan Shrout). He's a phony, plain and simple.

[BoMbY]

Es ist doch eigentlich recht eindeutig formuliert:

"Entsprechend dem WSA sind wir verpflichtet alle unserer CPU und APU Bedarfe, und einen bestimmten Teil unserer GPU Bedarfe, mit limitierten Ausnahmen bei GF einzukaufen."

Und nein, die Verlängerung von 2016 gilt bis 2020. Ja, leider ist die öffentliche Version zensiert, aber praktisch alle Ausnahmen sind namentlich benannt, und GF muss allen Ausnahmen zustimmen, und zusätzlich muss AMD abhängig von der Menge an Wavern die bei anderen gekauft wurden Strafzahlungen an GF leisten.

"a limited waiver with rights to contract with another wafer foundry with respect to certain products in the 14nm and 7nm technology nodes"

"we also agreed to make quarterly payments to GF based on the volume of certain wafers purchased from another wafer foundry"

In der Vergangenheit waren die Ausnahmen ebenfalls auf GPUs und Semi-Custom beschränkt. Die CPUs sind das Brot und Butter Geschäft, und eher geben die die Freigabe für alles andere, als für die CPUs.

[|MatMan|]

Ich denke GloFo wird nicht die Kapazität haben wenn EPYC (2) aus dem einstelligen Bereich in den zweistelligen Marktbereich kommt.
Was ist das denn für ne schwachsinnige Behauptung? EPYC besteht aus 4 zusammengeklebten Ryzen, wenn man so will. Das ist AMDs großer Vorteil. 1 Die fertigen und damit Consumer (Ryzen), HighEnd Desktop / Workstation (Threadripper) und Server (EPIC) bedienen. Jetzt soll man nur wegen den paar Server CPUs zu ner anderen Fab gehen, deren Herstellungsprozess völlig verschieden ist? Das kostet Unmengen Geld und Manpower! Für eine handvoll CPUs nur für den Server Bereich? Na klar! Macht voll Sinn, die geschickte Strategie von Zen1 direkt wieder über Board zu werfen!

[Unicous]

In der Vergangenheit ist aber nicht mehr die Gegenwart und die Zukunft, mein Freund.:wink:

Du verstehst nicht/du willst einfach nicht verstehen, dass AMD dafür GF bezahlt, dass GF nicht seine vertraglich zugesicherten "100%" Fertigung (CPU/APU) bei GF erzwingt(plus ein wenig GPU-Fertigung).

AMD hat das sogar noch erweitert und bezahlt jetzt GF sogar für die Kapazitäten, dass sie bei anderen Foundries einkaufen, was du jetzt auch langsam mitbekommen hast.

Du hast recht, das Amendment gilt bis 2020, das habe ich verdrängt... es ändert aber... nichts.:freak:

AMD kauft Kapazitäten bei anderen Foundries bezahlt dafür eine "Strafe" und für das Volumen zahlen sie auch eine entsprechende Summe. Für AMD ein nicht ganz so guter Deal, dafür sind sie frei Kapazitäten bei Samsung, TSMC oder wem auch immer einzukaufen.:up:

Wir könnten dann mal so langsam wieder zum eigentlichen Thema zurückfinden.

[Setsul]

Es geht mir nicht um Bandbreite sondern um Latenz. Ein höher getakteter eDRAM wäre aber in dieser Hinsicht sicherlich auch schneller. Ja, hast du Recht. :)

Ging in dem Fall um das Beispiel, DDR3 hätte ja schon bei gleichem Takt bessere Latenz.


Ich verstehe was du meinst. Ich sehe hier aber leider keine Verbesserung in den Reviews (RAM latency messen leider nicht viele reviews :().

Das ist ein Problem der Messungenauigkeit. Wenn man sich jeweils den Bereich anschaut in dem SR und RR landen, dann sieht man dass RR ein paar Prozent schneller ist. Ist natürlich nicht viel, aber es ist ein Anfang.



So war das nicht gemeint. Gemeint war, dass AMD offenbar ein ~300 (bzw nun wissen wir dass es ein ~200 sqmm) Budget ansetzt. Bei einem Shrink könnte man den Vorteil 1:1 in eine verkleinerte Die Size umsetzen. Nur wird die freie Fläche - bzw das Budget idR ausgeschöpft durch mehr Logik/SRAM um die Leistung zu steigern.

So entwirft niemand CPUs. "Wir kommen über 200mm², lass den Memory Controller und L3 Cache rauswerfen". Es wird vorher entschieden was die Architektur braucht um gut zu funktionieren und geschätzt ob man sich das leisten kann. Wenn man denkt das wird zu teuer dann wird umgeplant.
Wenn man erstmal angefangen hat dann muss auch alles rein. Man kann nichts mehr weglassen oder das ganze Kartenhaus fällt zusammen. Siehe Bulldozer oder Itanium. Es war sicher irgendwann klar, dass die Dies zu groß werden, aber man kann dann nichts mehr weglassen.

AMD wird also sicherlich nicht an Zen2 rangehen und wenn die Schätzungen bei 160mm² landen sagen "lass noch ein bisschen L4 drankleben damit wir auf 200mm² kommen".


Ich habe nur die Zellgröße genommen und entsprechend extrapoliert. Ist die Dichte nicht auch ein ganzes Stück von der Assoziativität abhängig? IIRC kann man bei einer relativ geringen Assoziatität die Dichte deutlich erhöhen.

Das funktioniert nicht, bei Cache sind noch Muxes und alles mögliche dabei, das ist nicht reiner SRAM. Vergleich zwei Standardzellen und wenn die um 50% schrumpfen, dann schrumpft auch ein Cache um ungefähr 50%. Also aus 16mm² für 8MB werden 8mm² für 8MB. Von 128mm² für 64MB kommt man nicht auf 16mm² für 64MB.

Natürlich kann man einen direct-mapped L4 bauen aber was soll das bringen?

Gehen wir mal die 4 Gründe für Cache misses durch:
-compulsory: Da bringt der L4 nichts.

-coherency: Writes im eigenen CCX kann man sich direkt vom entsprechenden L2 holen. Aus einem anderen CCX müsste man zumindest die Tags für alle lines in der ganzen CPU im L4 haben, ansonsten kann man die Anfrage gleich an die CCX schicken, was auch noch niedrigere Latenz hat. Abgesehen davon hätte man dann effektiv einen inclusive L4 der nur so groß ist wie die L3s und dann gibts ja noch die L2s. Also auch sinnlos.

-capacity: Könnte theoretisch etwas bringen, aber >2,5MB/Kern haben weder Intel noch AMD bis jetzt gebaut, aus gutem Grund. Es bringt einfach nicht mehr wirklich viel. Außerdem könnte man einfach die L3s auf 10, 12 oder 16MB aufbohren.

-conflict: Deshalb haben die höheren Cache höhere Assoziativität.
Die zwei Randszenarien:
1. Lines die immer schön ins selbe Set wollen weil fast alle bits identisch sind. Dann haben wir 8 Wege im L2, 16 Wege im L3, also 24 insgesamt. Direct-mapped L4 bringt noch einen mehr. Jaaaaa, Cache verdoppeln für 1/24 mehr nützliche Lines lohnt sich nicht.
2. Lines die gut verteilt sind und nur wegen der Cachegröße im selben Set landen. Bei perfekter Verteilung sind das reine capacity misses, irgendwo zwischen Fall 1 und 2 ist je nach Größe der Caches der Übergang zum conflict miss.
Was in einem Set im L2 (1024 Sets) landet, kann im L3 (8192 Sets) in 8 Sets landen. Also 8+8*16=136.
Bei einem 64MB direct-mapped L4 Cache könnten die Lines in 1024 Sets landen. Allerdings ist die Latenz dafür natürlich fürchterlich wenn man wieder 4 Dies hat. Realistisch also eher ein L4 pro Die, damit die Lines die vom eigenen RAM kommen nicht ans Ende der Welt verschifft werden nur um dann nur vom eigenen Die gebraucht zu werden. NUMA scheduling usw. Also eher 256. Doppelter L3 bringt 128.

Also der Nutzen gegenüber einem größeren L3 und/oder mehr Wege im L3 ist sehr begrenzt.


Ohne Zugriff praktisch nein. Bei einem Zugriff ja. Aber sicherlich weniger als ein Zugriff auf den RAM (cache miss im L1-L3). Weiterer Weg -> höherer Energiebedarf.

Wenn auf den L4 nicht zugegriffen wird dann bringt er offensichtlich nichts.
Es geht darum, dass ein Zugriff auf den L4 mehr Energie verbraucht beim IF, das jetzt mehr Verbindungen hat und dann zusätzlich noch im L4 selbst Energie verbraucht. Das ist nicht wirklich billiger als das IF breiter zu machen oder höher zu takten. Der einzige Vorteil ist dass es eventuell weniger Energie vebraucht als ein RAM-Zugriff. Aber wenn man sich anschaut wie viel IF frisst (siehe anandtech) dann ist das auch nicht so sicher.




Was haltet ihr von dem Gerücht das AMD bei EPYC die Cores und den Cache trennt? Also bei einem 64 Core EPYC, fünf Packages verwendet. 4 Packages mit jeweilgs 16 Cores und 1 Package für den Cache? Würde sowas überhaupt funktionieren?

L1/L2 sind natürlich unmöglich.
L3 wäre einfach viel zu hohe Latenz.
L4 halte ich an sich nicht für sinnvoll.
Kleines Detail noch zu den Bezeichnungen: Package ist das wo man die Chips/Dies draufklebt, also 5 Chips/Dies, aber nur 1 Package. Jetziger EPYC hat auch nur 1 Package, 4 Chips.


IBM hat bei ihren POWER CPUs vor Jahren ähnliches mit eDRAM als LLC auf dem Package gemacht. (glaube es war in dem Fall sogar L3)
Ist halt langsamer - dafür größer. :)
Das waren POWER4/5. Bei 16/18MB L3 PRO KERN in einer Zeit als nur der Pentium 4 überhaupt L3 hatte kann man das in der Tat "groß" nennen.
Aber seit POWER7 ist der eDRAM L3 aus gutem Grund auch on-chip. 27 Takte bei 5 GHz (POWER8) für die Kern-eigene 8BM slice würde ich nicht mehr langsam nennen. 130 Takte für remote L3 sind zwar nicht so toll aber IF ist auch nicht besser.

Für einen L3 ist sowas doch viel zu langsam. Behält man die 2MB pro Core bei, käme man bereits auf 128MB L3 für alle Kerne zusammen. Da müsste Off-Die Cache schon wirklich deutlich größer sein, damit er was bringt. Da würde ein HBM-Stack mit 8GB und 256GB/s (eventuell sogar 300, wenn es bis dahin 1,2Ghz schnellen HBM2 gibt) als L4-Cache schon mehr Sinn ergeben imho.
Siehe oben.
IBM hat 96MB L3 on-chip und wirft dann trotzdem nochmal 128MB L4 bei den externen memory controllern dazu. Dafür ist es dann wieder eine Überlegung wert, wenn die memory controller auf einem anderen Chip sind.
Für das was AMD macht ist es aber besser jeweils ein Paar Kerne und memory channels auf jedem Die zu haben und dann eben NUMA.

HBM hat nur höhere Bandbreite, aber DRAM ist DRAM und die Latenz ist fast identisch.
Ein schönes Bild dazu von der alten Hynix HBM1 Präsentation.
https://i.imgur.com/eUZz1kO.png

[reaperrr]

GloFo wird sicherlich gerade bei 100% Auslastung sein. Wenn man nun auf 7nm wechselt und GloFo nur eine fähige FAB hat, wird AMD zwangsläufig auslagern müssen. Was das nun ist, keine Ahnung.
Jep:
https://www.anandtech.com/show/12445/the-anandtech-podcast-episode-45-globalfoundries-and-fab-8

Relativ weit unten, "50:38 Fab 8 Running at 100% Capacity (and Other Info)"

Wenn AMD's Marktanteile weiter steigen, brauchen sie mehr Kapazität um nicht in Lieferengpässe zu laufen. Es gab auch irgendwo schonmal einen Bericht, dass Vega10 tatsächlich von 3(!) verschiedenen Foundries produziert wird, kann sich dabei fast zwangsläufig nur um GloFo, Samsung (14LPP) und TSMC (16FF+) handeln.

Wenn Raven und Pinnacle zu nochmal mehr Nachfrage führen, werden wahrscheinlich V10 und P10 noch weiter zu Samsung verschoben, da die APUs und CPUs höchstwahrscheinlich sowieso höhere Gewinnmargen und deshalb Priorität haben.

[Dino-Fossil]

Es gab auch irgendwo schonmal einen Bericht, dass Vega10 tatsächlich von 3(!) verschiedenen Foundries produziert wird, kann sich dabei fast zwangsläufig nur um GloFo, Samsung (14LPP) und TSMC (16FF+) handeln.

Hat sich das nicht eher auf das Packaging von GPU/Interposer/HBM bezogen?

[LadyWhirlwind]

In der Vergangenheit ist aber nicht mehr die Gegenwart und die Zukunft, mein Freund.:wink:

Du verstehst nicht/du willst einfach nicht verstehen, dass AMD dafür GF bezahlt, dass GF nicht seine vertraglich zugesicherten "100%" Fertigung (CPU/APU) bei GF erzwingt(plus ein wenig GPU-Fertigung).

AMD hat das sogar noch erweitert und bezahlt jetzt GF sogar für die Kapazitäten, dass sie bei anderen Foundries einkaufen, was du jetzt auch langsam mitbekommen hast.

Du hast recht, das Amendment gilt bis 2020, das habe ich verdrängt... es ändert aber... nichts.:freak:

AMD kauft Kapazitäten bei anderen Foundries bezahlt dafür eine "Strafe" und für das Volumen zahlen sie auch eine entsprechende Summe. Für AMD ein nicht ganz so guter Deal, dafür sind sie frei Kapazitäten bei Samsung, TSMC oder wem auch immer einzukaufen.:up:

Wir könnten dann mal so langsam wieder zum eigentlichen Thema zurückfinden.

GF wird im Gegenzug auch Pflichten haben. Gibt es eine andere Quelle für das Agreement als das Risiko Statement von AMD?

Möglich das GF AMd bezahlen muss, wenn Sie die von AMD verlangte Menge nicht in der vereinbarten Zeit produzieren können.
Möglich auch das AMD die Kompensation nicht oder nur teilweise bezahlen muss, wenn es GF gelingt andere Kunden zu finden.

Das Agreement soll meiner Meinung nach AMD Produktionskapazitäten sichern und GF kriegt im Gegenzug gewisse Einnahmen zu gesichert. Für beide ist das gut für die Planung.
Möglich auch das die Preise ganz oder teilweise gefixt sind.

[Unicous]

Das WSA wurde ja seinerzeit geschlossen um AMD an GF zu binden als AMD die Fabs abgestoßen hat. Sonst hätte GF nicht lange überlebt, da AMD so gut wie der einzige Kunde war. Das hat sich erst im Laufe der Zeit geändert.
Die einzige Verpflichtung die mir spontan einfällt wäre, dass sie Wafer liefern müssen. Öffentlich gibt es afair darüber hinaus keine Verpflichtung seitens GF. Deshalb ja der Disclaimer von AMD. Wenn GF nicht liefern kann ist AMD am Arsch.

@reaperrr

Danke für das Heraussuchen, es war zwar eigentlich klar, dass GF in "New York" an der Kapazitätsgrenze arbeitet, aber eine offizielle Aussage dazu war mir bis dato nicht bekannt.

Da GF lediglich eine Kapazitätserhöhung von 20% vor einem Jahr verkündet (die Anfang 2018 erreicht werden sollte) hat und sie dennoch auf 100% Auslastung laufen, muss AMD logischerweise Kapazität zukaufen (zumal AMD längst nicht mehr der einzige Kunde ist).

[Pirx]

wenn Navi an TSMC geht, wäre wieder einiges mehr für CPUs frei bei GF

[amdfanuwe]

12 oder 16 Core CPUs in 7nm?
Ich denke mal, AMD bringt beides.
A: Einen 6 Core CCX für APU.
B: 2 X 6 Core CCX für die Vielfalt, die aktuell Zeppelin bietet.
C: Ein Die mit 16 Core, 4 * 4 CCX und doppeltem I/O, 4 Speicherkanäle, praktisch ein doppelter Zeppelin.

Zu B: ergäbe 12 Core Desktop, 24 Core Threadripper, bis 48 Core EPYC.

Zu C: dadurch ließe sich Threadripper und die neuen 16 Core embedded Chips durch einen einzigen Chip ersetzen. Sollte Kosten sparen. Auch Low Cost EPYC bis 32 Core ließe sich mit 2 dieser Chips realisieren. Mit 4 dieser Chips wären dann 64 Core EPYC möglich.

Warum überhaupt noch B?
Der Die dürfte wesentlich kleiner als C sein, nur 1 mal I/O, 2 Speicherkanäle und damit Kostengünstiger.

Damit gäbe es :
4 und 6 Core APUs, 4/6 Core CPU aus A
8 und 12 Core CPU mit B und 16 Core CPU mit C.

Threadripper:
4, 8, 12, 16 Core CPU aus 1 X C, 20/24 Core CPU aus 2 X B und 28/32 Core aus 2 X C

EPYC und embedded überlass ich euch.

Ich denke mal, es würde auf jeden Fall für AMD Sinn ergeben, aktuelle 2 Die Lösungen wie Threadripper und embedded 16Core zukünftig mit einem Chip zu ersetzen.

[mboeller]

12 oder 16 Core CPUs in 7nm?
Ich denke mal, AMD bringt beides.
A: Einen 6 Core CCX für APU.


mal eine kurze Frage. Macht das eigentlich noch Sinn?
Wir wissen ja jetzt, dass GF 7nm >40% schneller wird bei gleichem Verbrauch im Vergleich zu 14nm.

4 Kerne @ 5GHz sollten nahezu so schnell sein wie 6 Kerne @ 3,6GHz (bei optimal parallelem Code)

6 Kerne in 7nm sollten wahrscheinlich nur bis 4GHz gehen bei gleichem Verbrauch wie jetzt die 4 Kerne. 6Core Zen @ 95W => 6Core Zen2 @ 60W

Gleichzeitig benötigen 4 Kerne natürlich weniger Die-Fläche als 6 Kerne. Und mit einem (Basisfrequenz) 5GHz QuadCore kann man, denke ich besser Werbung machen. 6 Kerne @ 4GHz sind im Vergleich dazu meh... gibt es schon mit 95W statt 65W.

[Brillus]

12 oder 16 Core CPUs in 7nm?
Ich denke mal, AMD bringt beides.
A: Einen 6 Core CCX für APU.
B: 2 X 6 Core CCX für die Vielfalt, die aktuell Zeppelin bietet.
C: Ein Die mit 16 Core, 4 * 4 CCX und doppeltem I/O, 4 Speicherkanäle, praktisch ein doppelter Zeppelin.

Zu B: ergäbe 12 Core Desktop, 24 Core Threadripper, bis 48 Core EPYC.

Zu C: dadurch ließe sich Threadripper und die neuen 16 Core embedded Chips durch einen einzigen Chip ersetzen. Sollte Kosten sparen. Auch Low Cost EPYC bis 32 Core ließe sich mit 2 dieser Chips realisieren. Mit 4 dieser Chips wären dann 64 Core EPYC möglich.

Warum überhaupt noch B?
Der Die dürfte wesentlich kleiner als C sein, nur 1 mal I/O, 2 Speicherkanäle und damit Kostengünstiger.

Damit gäbe es :
4 und 6 Core APUs, 4/6 Core CPU aus A
8 und 12 Core CPU mit B und 16 Core CPU mit C.

Threadripper:
4, 8, 12, 16 Core CPU aus 1 X C, 20/24 Core CPU aus 2 X B und 28/32 Core aus 2 X C

EPYC und embedded überlass ich euch.

Ich denke mal, es würde auf jeden Fall für AMD Sinn ergeben, aktuelle 2 Die Lösungen wie Threadripper und embedded 16Core zukünftig mit einem Chip zu ersetzen.

Amd sagt selbst das die multi chip Lösung fast 50% kosten spart gegenüber monolithisch, wie du jetzt auf die Idee kommst das es mit dem nächsten die anders sein soll erschließt sich mir nicht.

[Piefkee]

Ich denke mal, es würde auf jeden Fall für AMD Sinn ergeben, aktuelle 2 Die Lösungen wie Threadripper und embedded 16Core zukünftig mit einem Chip zu ersetzen.


Macht keinen Sinn, meiner Meinung.

Threadripper wird weiterhin 2 Dies bekommen. Was im Desktop landet ist entweder ein 12 Core oder eben auch der 16 Core. Je nach dem ob es einen 6 Core CCX oder einen 8 Core CCX gibt.

Threadripper und EPYC werden davon 2 oder auch 4 bekommen.

[YfOrU]

Meine Vermutung sind zwei CCX mit je 6C. Bei 8C pro CCX (->16C) kommt man langsam in den Bereich bei dem DC DDR4 zum limitierenden Faktor wird. Also wie bei den großen Broadwell-DE SoCs (Xeon-D mit 16C). Betrifft sowohl die Bandbreite als auch die Speichermenge. Die Nachfolger haben bei Intel ein QC DDR4 Interface bekommen und das kann AMD nicht machen ohne die Kompatibilität mit der bestehenden Infrastruktur zu brechen (da immer ein DC Interface pro Chip auf dem Package). 16C erwarte ich bei AMD eher zusammen mit der Einführung von DDR5.

[Der_Korken]

12C passen eigentlich nicht zur Spekulation eines 64C Epyc-Prozessors. Für den können es eigentlich nur 16 Kerne pro Die sein. Für den Consumer könnte es dann erstmal "nur" 12 Kerne geben, während die vollen Dies alle in den HPCs und Servern landen. Die passende APU bekäme dann wieder 50% der Kerne wie RR plus eben eine iGPU.

[YfOrU]

Die Spekulation war 48 und 64C auf Basis zweier Chips. Das macht wirtschaftlich betrachtet mit Blick auf die Stückzahlen eigentlich überhaupt keinen Sinn. Mit einer Ausnahme: 12 und 16C kommen nicht halbwegs zeitgleich sondern die zweite Variante ist eine Weiterentwicklung. Halte ich für nicht so unwahrscheinlich denn 7nm wird sicherlich eine ganze Weile mit diversen Verbesserungen aktuell bleiben.

[HOT]

Die Malta-Fab-Erweiterung müsste mit 7nm in Betrieb gehen, aber ich glaube, erst mit 7 EUV.
AMD wird die GPUs nicht bei GloFo fertigen mMn. Man wird die 14nm GPUs weiter bei GloFo und vor allem Samsung produzieren, die 7nm GPUs nach TSMC shiften, aufgrund der Kapazitätsprobleme, und die GloFo 7nm-DUV-Fertigung komplett für Matisse verwenden. Da das Teil ein echter Kracher werden dürfte, ist finde ich absehbar, werden die alle Kapazitäten verwenden, die man dafür kurzzeitig bekommen kann. Angeblich ist GloFos 7 DUV sogar AMD-Exklusiv. Die 7nm-TSMC-Fertigung ist mMn nur eine Übergangslösung, die nur für die GCN-Restposten V20 und N10 gilt und aus der Kapazitätsnot heraus geboren ist. Das wird 2016 schon klar gewesen sein, dass man da in Probleme hineinläuft, da ja da schon klar war, dass Intel die 10nm nicht vor 2019 in Großserie gebacken bekommt, abgesehen von Cannonlake - und der hat ja bekanntlich auch nicht gepackt.

[basix]

8C pro CCX sollten in 7nm gut machbar sein: >60-65% Energieeinsparung gegenüber 14nm, Scaling von 0.37 bei der Fläche (im Optimalfall). Auch wenn man nun Chipteile wie I/O Interfaces nicht stark skalieren kann. Sollte der Chip bei doppelter Anzahl Cores eine geringere Fläche aufweisen.


30% können nicht skaliert werden, keine Flächenensparung (I/O Zeugs, PCIe, GMI Links usw.): 30%
30% können skaliert werden um 0.4, ohne mehr davon zu benötigen (Server Logik Zeugs, Infinity Fabric Logik usw): 30% + 0.4*30% = 42%
40% können um 0.4 skaliert werden, braucht aber das doppelte davon (CCX mit doppelt so vielen Kernen): 42% + 0.4*40%*2 = 74%
74% * 213mm2 = 158mm2


So 160mm2 wäre eigentlich ziemlich schick von der Die Grösse her. Jetzt noch den doppelten L3 zu spendieren würde ebenfalls drin liegen, dann käme man etwa bei 180-190mm2 raus.

Bei selben Taktraten würde man mit doppelter Anzahl Kernen im Optimalfall bei ca. 70% Energieaufnahme landen. Hier noch +10-20% Takt obendrauf und man wäre gut unterwegs. Das würde ca. 4.3 GHz All-Core Turbo für einen 16-Kerner in 95W bedeuten.

[bbott]

12 oder 16 Core CPUs in 7nm?
Ich denke mal, AMD bringt beides.

Wieso? Das 16er Die würde kaum verbaut werden und der Ausschuss ist am größten.

Entweder 12 ODER 16 Kerne, die APU bekommt ein 6C oder 8C CCX.

Ein 16er Die mit 8er CCX wäre erstrebenswert.

[Piefkee]

So 160mm2 wäre eigentlich ziemlich schick von der Die Grösse her. Jetzt noch den doppelten L3 zu spendieren würde ebenfalls drin liegen, dann käme man etwa bei 180-190mm2 raus.



Der L3 soll ja laut Conad vervierfacht werden.
Ich denke ein 8-Core CCX wird auf <250mm² kommen.

[Unicous]

Die Malta-Fab-Erweiterung müsste mit 7nm in Betrieb gehen, aber ich glaube, erst mit 7 EUV.
AMD wird die GPUs nicht bei GloFo fertigen mMn. Man wird die 14nm GPUs weiter bei GloFo und vor allem Samsung produzieren, die 7nm GPUs nach TSMC shiften, aufgrund der Kapazitätsprobleme, und die GloFo 7nm-DUV-Fertigung komplett für Matisse verwenden. Da das Teil ein echter Kracher werden dürfte, ist finde ich absehbar, werden die alle Kapazitäten verwenden, die man dafür kurzzeitig bekommen kann. Angeblich ist GloFos 7 DUV sogar AMD-Exklusiv. Die 7nm-TSMC-Fertigung ist mMn nur eine Übergangslösung, die nur für die GCN-Restposten V20 und N10 gilt und aus der Kapazitätsnot heraus geboren ist. Das wird 2016 schon klar gewesen sein, dass man da in Probleme hineinläuft, da ja da schon klar war, dass Intel die 10nm nicht vor 2019 in Großserie gebacken bekommt, abgesehen von Cannonlake - und der hat ja bekanntlich auch nicht gepackt.

Die Malta Erweiterung ist Anfang 2018 abgeschlossen... also jetzt.:rolleyes:
Und wenn man mal die Pressemitteilung lesen würde, wird man feststellen,...


In the United States, GF plans to expand 14nm FinFET capacity by an additional 20 percent at its Fab 8 facility in New York, with the new production capabilities to come online in the beginning of 2018. (https://www.globalfoundries.com/news-events/press-releases/globalfoundries-expands-meet-worldwide-customer-demand)

dass 14nm explizit genannt wird. Es macht auch überhaupt keinen Sinn die Tools zu bestellen zu installieren und dann ca. 1 Jahr zu warten bis 7nm in HVM geht. Das ist ökonomischer Selbstmord. Das wäre dir auch sofort aufgefallen, wenn du etwas nachgedacht hättest.:rolleyes:

Desweiteren finde ich es genial wie du immer wieder konsequent den Konjunktiv verweigerst bei deinen prophetischen Eingebungen. Ob und wie AMD Samsung als Foundry-Partner nutzt ist völlig ungewiss da AMD nicht einfach das Design für Umme portieren kann und da GF eine andere Tool-Konfiguration hat als Samsung wird es auch kleine aber feine Anpassungen brauchen die afaik in neuen Masken resultiert. Also Kosten über Kosten. Stattdessen könnte man Samsung(/TSMC) auch gleich neue Designs fertigen lassen. Es ist ja mitnichten so, dass AMD mittlerweile im Geld schwimmt und die paar Milliönchen aus der Portokasse bezahlen könnte.

Was du schon wieder als angeblich AMD exklusiv ausgibst möchte ich übrigens nochmal belegt haben.

[reaperrr]

Ich persönlich bleibe bei der unpopulären Meinung, dass AMD bei 4 Kernen je CCX bleiben wird.

Den Aufwand, den sie in die mehr als doppelt so komplexe Verdrahtung eines 6C-CCX stecken müssten, sollen sie lieber in mehr Takt, mehr Optimierungen der Kerne selbst, und eine separate Clock-Domain + höheren Takt des IF investieren.

[HOT]

Die Malta Erweiterung ist Anfang 2018 abgeschlossen... also jetzt.:rolleyes:
Und wenn man mal die Pressemitteilung lesen würde, wird man feststellen,...



dass 14nm explizit genannt wird. Es macht auch überhaupt keinen Sinn die Tools zu bestellen zu installieren und dann ca. 1 Jahr zu warten bis 7nm in HVM geht. Das ist ökonomischer Selbstmord. Das wäre dir auch sofort aufgefallen, wenn du etwas nachgedacht hättest.:rolleyes:

Desweiteren finde ich es genial wie du immer wieder konsequent den Konjunktiv verweigerst bei deinen prophetischen Eingebungen. Ob und wie AMD Samsung als Foundry-Partner nutzt ist völlig ungewiss da AMD nicht einfach das Design für Umme portieren kann und da GF eine andere Tool-Konfiguration hat als Samsung wird es auch kleine aber feine Anpassungen brauchen die afaik in neuen Masken resultiert. Also Kosten über Kosten. Stattdessen könnte man Samsung(/TSMC) auch gleich neue Designs fertigen lassen. Es ist ja mitnichten so, dass AMD mittlerweile im Geld schwimmt und die paar Milliönchen aus der Portokasse bezahlen könnte.

Was du schon wieder als angeblich AMD exklusiv ausgibst möchte ich übrigens nochmal belegt haben.
Ich kann soviel Konjunktiv nutzen, wie ich will. :D Danke für die Korrektur.

[Unicous]

Es ist ja nicht so dass ich das mit dem Abschluss der Kapazitätserhöhung Anfang 2018 nicht bereits erwähnt hätte und dass seit Längerem bekannt ist, dass erst 2019 7nm in HVM geht.:wink:

Du erweckst mit deiner Schreibweise immer wieder den Anspruch auf Allgemeingültigkeit zumal du explizit auf 7nm verweist bzw. auf 7nm EUV.:rolleyes: (Und um ehrlich zu sein glaube ich auch nicht, dass das unbewusst geschieht.:wink:)

"Wird" ist im Übrigen kein Konkjunktiv und Behauptungen über angebliche Exklusivität ohne konkrete Anhaltspunkte helfen deinem Fall auch nicht wirklich. Es ist ja nicht das erste Mal und wird auch nicht das letzte Mal sein, dass du deine eigenen Spekulationen als allgemeingültigen Fakt darstellst und erst zurückruderst wenn es schon zu spät ist.

edit:

Deine Sätze wegzueditieren zeugt auch nicht von gutem Stil, btw.

[Hübie]

Ich persönlich bleibe bei der unpopulären Meinung, dass AMD bei 4 Kernen je CCX bleiben wird.

Den Aufwand, den sie in die mehr als doppelt so komplexe Verdrahtung eines 6C-CCX stecken müssten, sollen sie lieber in mehr Takt, mehr Optimierungen der Kerne selbst, und eine separate Clock-Domain + höheren Takt des IF investieren.

Dafür spricht zumindest die Aussage, dass monolithische Dies nicht so kosteneffizient eingesetzt werden können. Eine separate clock domain täte der Latenz / Bandbreite des IF wirklich gut.

[basix]

Schlussendlich ist es ja eigentlich egal, ob es 2x 8C oder 4x 4C CCX gibt, solange die Leistung stimmt. Für Server sehe ich letzteres als wahrscheinlicher an.

Für uns und hauptsächlich Spiele wäre reduzierte Latenz von Vorteil. Grösserer L3$ hilft sicher, wie viel weiss ich nicht. AMD ist ja nicht Intel, dazu sind die Architekturen mit Ringbus und IF zu verschieden. Ich sehe es grundsätzlich wie Hübie, der grösste Hebel besteht beim IF. Beschleunigt man den (niedrigere Latenz) haben alle was davon. Reduziert man sie genug, kann man im günstigsten Fall beliebig viele CCX auf den Die knallen, ohne gross Performance-Nachteile zu haben.

Was ich aber als Problem sehe beim verbleiben bei 4C CCX:

Mobile: Bleibt man bei 4C? Oder geht gleich auf 8C? Weil 6C als Zwischenschritt fällt dann aus.
SKUs: Bei Summit Ridge muss man die CCX symmetrisch "cutten". Bei 4x4C CCX müssten die SKU Schritte dementsprechend in 4C Schritten sein, was relativ grosse Schritte wären

[amdfanuwe]

Amd sagt selbst das die multi chip Lösung fast 50% kosten spart gegenüber monolithisch, wie du jetzt auf die Idee kommst das es mit dem nächsten die anders sein soll erschließt sich mir nicht.
Klar, ein 800mm² die hat wesentlich schlechteren Yield als die Multi Chip Lösung und ist daher wesentlich teurer.
Aber ein Chip in der 200mm² Klasse mit gutem Yield ist dann wiederum günstiger als 2 Chips.
Wie ich darstellte: Günstige 16 Core Threadripper und embedded EPYC 3000er.
Für Mehrkernsysteme verwendet man dann wieder die Multi Chip Lösung mit diesem Die. Reicht dann für 32 Core Threadripper und 64 Core EPYC.

Also praktisch 2 Zeppelin geschrinkt auf einem Die mit Anpassungen an Meltdown und Spectre und sonstigen wesentlichen ZEN2 Core verbesserungen.
Sollte ohne großen Entwicklungsaufwand herstellbar sein.

Zusätzlich als neuer ZEN2 Core ein 6Core CCX Design das in den gleichen Variationen verbaut wird wie aktuell Zeppelin.

[amdfanuwe]

Bei 4x4C CCX müssten die SKU Schritte dementsprechend in 4C Schritten sein, was relativ grosse Schritte wären

Bei mehr als 8 Cores willst du nicht wirklich kleine Core Schritte.
Also 26, 28, 30, 32 Core etc. Macht keinen Sinn.
Die Core Entwicklung seh ich eher so:
1, 2,(3), 4, 6, 8, 12, 16, 24, 32, 48, 64, 96, 128 ...

[tm0975]

naja davon ist die software-entwicklung noch 100 jahre entfernt...

[gravitationsfeld]

Noe.

[basix]

Bei mehr als 8 Cores willst du nicht wirklich kleine Core Schritte.
Also 26, 28, 30, 32 Core etc. Macht keinen Sinn.
Die Core Entwicklung seh ich eher so:
1, 2,(3), 4, 6, 8, 12, 16, 24, 32, 48, 64, 96, 128 ...

Stimme ich dir grundsätzlich zu. Aber man begrenzt die Freiheiten. Mit 4x4C geht eine 6C SKU halt einfach nicht. 6C sehe ich im Mainstream Bereich momentan als perfekte Grösse an.

Was ich für AMD sehe: 8C + GPU für Mainstream bis Mobile, 16C für Highend, 32C für Enthusiast / Threadripper.

Intel wird so wie es aussieht 8C Coffee Lake bringen. Hier ein entsprechendes Gegenprodukt zu haben wäre gut. Ich wäre aber nicht traurig, wenn es anstatt ein 8C Vielfaches eins mi 6C gibt, wenn man dafür den Takt gut anheben könnte.

[Pirx]

Ich persönlich bleibe bei der unpopulären Meinung, dass AMD bei 4 Kernen je CCX bleiben wird.

Den Aufwand, den sie in die mehr als doppelt so komplexe Verdrahtung eines 6C-CCX stecken müssten, sollen sie lieber in mehr Takt, mehr Optimierungen der Kerne selbst, und eine separate Clock-Domain + höheren Takt des IF investieren.
Wäre die Verdrahtung denn überhaupt wesentlich komplexer? Gibt es für Inter-Core im CCX wirklich eine Direktverbindung zwischen allen Cores ode läuft das iwie über den L3?

[reaperrr]

Wäre die Verdrahtung denn überhaupt wesentlich komplexer?
Von 12 (4x3) auf 56 (8x7) Verbindungen zu den anderen Kernen, also Faktor 4,67.
Würde nur mit Ringbus Sinn machen, mMn.

Wäre die Verdrahtung denn überhaupt wesentlich komplexer? Gibt es für Inter-Core im CCX wirklich eine Direktverbindung zwischen allen Cores ode läuft das iwie über den L3?
Bin mir ziemlich sicher, dass es Direktverbindungen sind, nicht nur wegen AMDs eigenem Schaubild.

Der L3 ist a) ziemlich langsam, b) nur exklusiver Victim-Cache und c) würde es vermutlich auch mehr Strom kosten, wenn für jede noch so kleine Interaktion zwischen den Kernen der L3 hochgefeuert werden müsste.

[5CH4CHT3L]

Ihr dürft nicht vergessen, dass bei Zen auch einzelne CCX deaktiviert werden können (siehe 4+0 config des 1400 vs 2+2 des 1500X)

d.H. bei 4x4C CCX wären 1,2,3,4,6,8,9,12,16 Cores möglich, halt z.T. nur nicht mit vollem L3$.
Wobei ich es aber für sehr unwahrscheinlich halte, dass ein Die um mehr als 50% der Cores beschnitten wird. Ich denke auch nicht, dass wir schon nächstes Jahr 16C auf AM4 sehen, da wir ja jetzt einen quasi 8C refresh bekommen.

Mein Tipp: 2x6C CCX und SKUs dann jeweils in 2er Schritten

[w0mbat]

(siehe 4+0 config des 1400 vs 2+2 des 1500X)

Hat der R5 1400 wirklich 4+0?

[amdfanuwe]

Mit 4x4C geht eine 6C SKU halt einfach nicht. 6C sehe ich im Mainstream Bereich momentan als perfekte Grösse an.

Momentan ist nicht Morgen.
Der 4x4C wäre auch nicht für Mainstram sondern zur verbilligung der aktuellen 2 Chip Designs und könnte zusätzlich für High End eingesetzt werden.
Für Mainstream spekuliere ich eher auf 6C CCX + GPU in 7nm.
Die Frage ist doch eigentlich: Was lohnt sich für AM4 mit 2 Kanal Speicheinterface?
Irgenwann verhungern zusätzliche Cores an mangelnder Speicherbandbreite.
Macht da ein 2x6Core mit höherem Takt überhaupt noch Sinn für AM4?
Könnte AMD mit einem 4x4C Chip einen 16Core Chip für 300€ für die Threadripper Platform anbieten?
AMD dürfte es sich auch langsam leisten können mehr als 2 Dies, CPU und APU, für die verschiedenen Märkte herzustellen.
Ist halt die Frage, wie sich die Märkte für AMD entwickeln.

@5CH4CHT3L
Laut CB gibt es keinen 4 + 0, ist nur bei den APUs der Fall.
da wir ja jetzt einen quasi 8C refresh bekommen
Ohne AMD hätte es bei Intel sicherlich auch noch ein paar weitere 4C refreshs gegeben.

Das 6C aktuell Mainstream ist, liegt an der Preisklasse.
Mal sehen, was AMD in 7nm für 200€ - 350€ liefert.

[amdfanuwe]

Mir gefällt der Gedanke, AMD könnte 2019 die Threadripper Platform für die Computerentusiasten und Gamer ausbauen.
CPUs 4+ GHz, 8 bis 16 Core im Preisbereich von 150 bis 400€ und günstigere Boards ab 100€ sind alles, was dazu nötig ist.
Eine günstige single Chip Threadripper CPU wäre mit 7nm möglich.
Dazu dann noch die dual Chip Lösungen mit 24 und 32 Core für 600€ und 1000€.

AM4 wäre dann "nur noch" für den normalen Heimbedarf und Bürokisten.

[das_Apo]

Was ist eigentlich vom Raven Ridge Nachfolger zu erwarten?

Oder ist das dafür eigentlich der falsch Thread, denn laut der untenstehenden Road Map wird Picasso weiterhin auf Raven Ridge basieren?
https://s14.postimg.org/inpdd2j2p/AMD-_Matisse-_Picasso.jpg

[robbitop]

Der L3 ist a) ziemlich langsam, b) nur exklusiver Victim-Cache und c) würde es vermutlich auch mehr Strom kosten, wenn für jede noch so kleine Interaktion zwischen den Kernen der L3 hochgefeuert werden müsste.

Wieso langsam? ~11 ns beim 1800X @4000 mhz
10.5 ns bei cfl @4500 mhz (die Daten habe ich in 2 min Google aus aida screenshots)

Innerhalb eines ccx scheint der L3 relativ flott zu sein. RR und PR verringern die Latenz noch weiter.

Eigentlich ist nur die IF etwas bei Ryzen was man als langsam titulieren kann IMO.

[basix]

Was ist eigentlich vom Raven Ridge Nachfolger zu erwarten?

Oder ist das dafür eigentlich der falsch Thread, denn laut der untenstehenden Road Map wird Picasso weiterhin auf Raven Ridge basieren?
https://s14.postimg.org/inpdd2j2p/AMD-_Matisse-_Picasso.jpg

Ich denke, es wird Ende 2019 für die 7nm APUs, einfach weil 7nm dann stabiler läuft und man Navi braucht. Finde ich ein wenig schade, kann man aber nicht viel dagegen machen. Was man aber wahrschenlich bei Picasso nutzen wird ist 12nm LP wie bei Pinnacle Ridge. Das sollte gut +10-20% Energieeffizienz bringen und dementsprechend mehr Leistung.

[Setsul]

Wäre die Verdrahtung denn überhaupt wesentlich komplexer?Von 12 (4x3) auf 56 (8x7) Verbindungen zu den anderen Kernen, also Faktor 4,67.
Würde nur mit Ringbus Sinn machen, mMn.
Hab das nochmal ausgerechnet: Wenn man bidirektional rechnet dann sind es 4*3/2=6 bzw. 8*7/2=28 von jedem L2 zu jedem anderen L2, aber das sind ja nicht die einzigen Verbindungen. Die Frage ist auch ist das wirklich so verbunden? Nachdem die Tags dupliziert sind im L3 wäre es auch möglich, dass die Anfrage erstmal an die richtige L3 slice geht und dann von dort an den richtigen L2 und zurück. Wobei der direkte Weg zurück günstiger wäre.
Jeder L2 zu jeder L3 slice sind nochmal 4*4=16 bzw. 8*8=64 Verbindungen.
Dann jeder L2 und jede L3 slice zum IF nochmal 2*4=8 bzw. 2*8=16 Verbindungen.

Insgesamt 30 zu 108. Also "nur" Faktor 3,6 wenn alles mit allem verbunden ist (außer L3 slice untereinander), aber trotzdem recht unangenehm.


Man muss eigentlich noch das IF miteinbeziehen.
Gehen wir mal von 16C Dies aus.
Wenn man alles zentral macht dann sind das 3 Verbindungen für on-package, 1 für den anderen Sockel, je nachdem ob 2*2 Channel oder 1*4 dann 1 oder 2 zum memory controller und 2 oder 4 zu den CCX.
So viel inter-CCX traffic spart man sich auch nicht also müssten die 2 CCX mit 8 Kernen eigentlich mit der doppelten Bandbreite angebunden sein und es nimmt sich nichts.
Wenn man jetzt aber CCX und evtl. die memory controller untereinander verbinden will dann braucht man etwas mehr Verbindungen mit 4 CCX. Einfach nur untereinander wären 6 Verbindungen zusätzlich bei 4 CCX, bei 2 CCX nur 1.

Also völlig unabhängig davon ob man die Latenz zu den anderen Dies verbessern kann ist die Frage was am meisten bringt und wieviel Energie es kostet.
Alles zentral und Latenz drücken? IF muss allen traffic zwischen den CCX dann zentral verwalten aber es bring natürlich auch am meisten für RAM-Latenz.
Verbindungen zwischen den CCX? Wieviel kostet 5 zusätzliche IF Verbindungen im Vergleich zu denm zusätzlichen Verbindungen im CCX bei 8 Kernen? Blinde snoops an alle CCX und evtl. RAM oder dupliziert man alle tags? Tags wären natürlich billiger bei nur 2 CCX, doppelte soviele die der CCX sowieso verwaltet und 1 anderer CCX, also anstatt 4 mal tags für den L3 von 12 Kernen zu duplizieren nur 2 mal von 8 Kernen.
RAM zentral und dann entweder als ein 16 Kern NUMA-Node oder vier 4 Kern Nodes wenn man auf CCX-Ebene will oder RAM aufteilen und dann zwei 8 Kern Nodes wo dann 8 Kern CCX alles schön einheitlich machen könnten?

Es ist letztendlich alles nicht so einfach.
Ich bin immernoch der Meinung, dass 8 Kerne pro CCX nicht helfen werden und durch die höhere L3 Latenz eher schaden.
Fast alle Probleme die Zen momentan lassen sich darauf zurückführen, dass die Latenz außerhalb des CCX zu hoch ist. Größere CCX lösen das Problem nicht sondern schieben es nur ein bisschen weiter.
Doppelte IF Breite oder doppelter Takt oder Koppelung an den L3 Takt oder komplett unabhängiger Takt (die letzten zwei machen den Übergang vom RAM zum IF etwas unangenehmer) sind zwar nicht fürchterlich elegant, aber würden mMn das meiste bringen und völlig ohne größere Veränderungen.

[fondness]

Die Diskussion hier kommt mir ein bisschen vor wie wünsch dir was. Ja, Ringbus-CPUs haben bessere Latenzen, allerdings auch klare Nachteile was Skalierbarkeit angeht. Vergleichbar mit der IF ist Intels Mesh in den Skylake-X-CPUs - und dort hat man oh Wunder die selben Latenznachteile wie bei der IF. Jetzt zu erwarten, dass AMD eine Skalierung von womöglich bis zu 64C pro Sockel (128C/256T bei Dual Sockel) hinkriegt, alles erreichbar mit nur einem hop wohlgemerkt UND gleichzeitig die Latenzen senkt kommt mir ein bisschen vor wie die berühmte Quadratur des Kreises. Durch größere CCX oder mehr CCX werden die Latenzen potentiell sogar steigen. Intel kann sich den Luxus leisten, viele verschiedenen Dies und Designs auflegen zu können und hat deshalb den Vorteil, dass man für Desktop ein anderes Design wählen kann wie für Server, AMD muss mit einem einzige Die alles abdecken, das bedeutet natürlich auch Kompromisse einzugehen. Im Endeffekt scheint mir die IF für den Einsatzzweck sogar ziemlich optimal zu sein, zumindest gibt es weit und breit kein besseres Konzept am Markt.

[robbitop]

Das Mesh ist schneller (memory latency) als die IF. Liegt aber sicher am deutlich höheren Takt.
Ansonsten denke ich auch dass Energie/Latenz und Skalierbarkeit diametral sind.

[fondness]

Wo genau?

https://s14.postimg.org/yu46tgoox/aida64-memlatency.png (https://postimages.org/)

https://techreport.com/review/32111/intel-core-i9-7900x-cpu-reviewed-part-one/4

Was ist eigentlich vom Raven Ridge Nachfolger zu erwarten?

Oder ist das dafür eigentlich der falsch Thread, denn laut der untenstehenden Road Map wird Picasso weiterhin auf Raven Ridge basieren?
https://s14.postimg.org/inpdd2j2p/AMD-_Matisse-_Picasso.jpg

AMD bringt schon länger nur mehr alle zwei Jahre ein neues Design. Auf ein neues Design folgt im darauf folgenden Jahr stets ein Refresh. Deshalb ist es wenig verwunderlich, dass Picasso nur ein Refresh wird und erst mit Navi eine neue APU-Generation folgt. Allerdings heißt das nicht, dass es nicht auch kleinere Überarbeitungen oder einen neuen Fertigungsprozess geben kann, siehe auch PR vs SR.

[Setsul]

Zum Beispiel 3 Monate später.
https://techreport.com/r.x/2017_08_17_AMD_s_Ryzen_Threadripper_1920X_and_Ryzen_Threadripper_1950X_CPUs_revi/memlatency.png
https://techreport.com/review/32390/amd-ryzen-threadripper-1920x-and-ryzen-threadripper-1950x-cpus-reviewed/5

Es verlangt niemand Wunder, auf die Latenz der <=6 Kerne Ringbus-Dies werden weder SKL-SP und Nachfolger noch Zen kommen. Aber es bleiben 2 gravierende Probleme:
1. Die Latenz zum anderen L3 auf dem selben Die ist fürchterlich im Vergleich zum Mesh bei Intel. Ja, das Mesh frisst viel Energie, aber IF ist auch nicht so stromsparend. Am Ende muss die Leistung stimmen.
Einfach entsprechende Access Size vs Latency Diagramme anschauen, oberhalb von 8MB und unterhalb der L3-Größe von SKL-SP ist Zen weit abgeschlagen.
2. Die durchschnittliche RAM-Latenz muss auch noch besser werden. Das hat sich AMD selbst eingebrockt mit dem MCM-Ansatz, aber rumheulen hilft auch nicht. Zen hat keine Probleme wenn alles in einem CCX bleibt und genauso ist die Latenz schon nah an SKL-SP wenn man auf einem Die bleibt, aber wenn die Latenz zum anderen so schlecht ist, dass man nie etwas darauf laufen lassen will das man nicht auf NUMA-Nodes aufteilen kann, dann ist das Ganze ziemlich sinnlos. Dann könnte man auch gleich weniger Verbindungen zwischen den Dies nutzen, man kann ja sowieso nicht mit Intel konkurrieren. Wenn man mehrere kleinere Dies statt einem großen hat, bei dem die memory controller ganz am Rand sind, dann ist es doch nicht zu viel verlangt, dass man auf den kleinen Dies zum eigenen RAM niedrigere Latenz hat. Dann muss man die Latenz zu den anderen Dies nicht mehr viel drücken und der Schnitt stimmt und alle sind glücklich.


Das hat nichts zu tun mit "wünsch dir was". Das Ende vom Lied kann bei IF+CCX nicht sein "wie Mesh, nur schlechter".

[dildo4u]

AMD Ryzen 3000: Globalfoundries rechnet mit 5,0 GHz beim 7-nm-Prozess

http://www.pcgameshardware.de/CPU-Hardware-154106/News/AMD-Ryzen-3000-Globalfoundries-7-nm-Taktraten-1251629/

[tm0975]

nett. der fertigungsvorsprung von intel wird immer kleiner....

[mboeller]

AMD Ryzen 3000: Globalfoundries rechnet mit 5,0 GHz beim 7-nm-Prozess

http://www.pcgameshardware.de/CPU-Hardware-154106/News/AMD-Ryzen-3000-Globalfoundries-7-nm-Taktraten-1251629/

dann würde es aber IMHO bei 4 Kernen pro CCX bleiben.

[HOT]

Denke mittlerweile auch, dass das Teil einfach 4 CCX bekommt.

[robbitop]

AMD Ryzen 3000: Globalfoundries rechnet mit 5,0 GHz beim 7-nm-Prozess

http://www.pcgameshardware.de/CPU-Hardware-154106/News/AMD-Ryzen-3000-Globalfoundries-7-nm-Taktraten-1251629/
Sofern die Implementierung der Zen2-µArch das auch hergibt. Das ist ein nicht unwesentlicher Faktor - wahrscheinlich sogar wesentlicher als der Fertigungsprozess. IBM hatte bspw schon 2008 5 GHz mit dem POWER6 (595). Das war noch 65 nm!
Signallaufzeiten, Anzahl der Pipelinestufen etc. haben da einen großen Einfluss.

[HOT]

Das Teil hatte letztes Jahr Tapeout, die haben Samples. Man wird das einfach rausposaunt haben, weil man nicht davon ausging, dass das jetzt ein großes Geheimnis wär.

[Setsul]

GloFo hat in den Folien 14nm auch als ">3,5 GHz" bezeichnet, nur so zum Vergleich.
Also an sich vom Verhältnis bei Zen2 schon hinkommen aber es kommen noch 3 andere Sachen dazu:
1. "Länge"/Dauer jeder Pipeline-Stufe. Könne bei Zen2 durchaus länger sein.
2. Verbrauch. Es bringt nichts das Ding auf 5,x Ghz hochzuprügeln aber dann weniger Kerne als vorher zu haben.
3. GloFo schätzt da auch etwas, die Zahlen sind nicht in Stein gemeißelt.

@HOT:
Welches Ding? Zen2? Wenn das seit letztem Jahr mit 5 GHz läuft wieso braucht AMD dann noch 2 Jahre um das auf den Markt zu bringen? Ich meine es läuft mit 5 GHz, wieviele Respins kann man da noch brauchen?

[BoMbY]

Die ersten Tapeouts sind definitiv erfolgt - das heißt aber noch lange nicht, dass der Prozess fertig für die Massenproduktion ist, und bei einem nagelneuen Prozess inkl. Architekturveränderungen wird man sicher auch mehrere Revisionen mit einplanen. Bei Summit Ridge hat man ja scheinbar auch schon mehr als einen Versuch gebraucht.

[Brillus]

GloFo hat in den Folien 14nm auch als ">3,5 GHz" bezeichnet, nur so zum Vergleich.
Also an sich vom Verhältnis bei Zen2 schon hinkommen aber es kommen noch 3 andere Sachen dazu:
1. "Länge"/Dauer jeder Pipeline-Stufe. Könne bei Zen2 durchaus länger sein.
2. Verbrauch. Es bringt nichts das Ding auf 5,x Ghz hochzuprügeln aber dann weniger Kerne als vorher zu haben.
3. GloFo schätzt da auch etwas, die Zahlen sind nicht in Stein gemeißelt.

@HOT:
Welches Ding? Zen2? Wenn das seit letztem Jahr mit 5 GHz läuft wieso braucht AMD dann noch 2 Jahre um das auf den Markt zu bringen? Ich meine es läuft mit 5 GHz, wieviele Respins kann man da noch brauchen?

Bugs im CPU design, yield Verbesserungen, Validierung, vorhandene Produktionskapazität.

Wären so spontan Gründe die mir einfallen.

[robbitop]

Das Teil hatte letztes Jahr Tapeout, die haben Samples. Man wird das einfach rausposaunt haben, weil man nicht davon ausging, dass das jetzt ein großes Geheimnis wär.
Die Rede war vom Prozess nicht von der CPU. GF bietet den Prozess ja frei an. Völlig unabhängig von Zen.

[Setsul]

Es geht mir darum wenn GloFo die 5 GHz davon hat, dass Zen2 Samples schon auf 5 GHz laufen, dann laufen sowohl der Prozess als auch das Design schon viel zu gut dafür, dass es dann 2 Jahre dauern soll.
Mal abgesehen davon hat GloFo schon in der ersten Hälfte von 2017, wenn nicht schon früher, Folien gehabt auf denen bei 7nm "5 GHz" stand.

Ich bin also der festen Überzeugung, dass GloFo damit kein Geheimnis ausgeplaudert hat.
AMD hat definitiv nicht seit Juni 2017 oder noch früher Zen2 Samples auf 5 GHz.

[robbitop]

Denke ich auch. Man bezieht sich auf den Prozess - ausgehend von Referenzbauteilen oÄ.

[N0Thing]

Man sollte vor allem mit dem Blick auf die Überschriften mancher News-Seiten nicht vergessen, dass Gary Patton nur eine persönliche Schätzung zur erreichbaren Taktrate gegeben hat. Keinen Ist-Zustand und kein Versprechen.

Q17: Does the first generation of 7LP target higher frequency clocks than 14LPP?

GP: Definitely. It is a big performance boost - we quoted around 40%. I don't know how that exactly will translate into frequency, but I would guess that it should be able to get up in the 5GHz range, I would expect

[basix]

GloFo hat in den Folien 14nm auch als ">3,5 GHz" bezeichnet, nur so zum Vergleich.

Ich hatte was von >3.0 GHz im Kopf, aber egal. So wie es aussieht, wird Pinnacle Ridge in die Nähe von 4.5 GHz Single Core Boost kommen. Da fehlt nicht mehr viel zu 5.0 GHz. Viel wichtiger wäre die Frage, auf wie vielen Kernen man den Takt halten kann oder ob es eben "nur" SC Boost ist. Aber alles >= 4.0 GHz bei 16C All-Core wäre eh schon sehr fett.

Edit:
Noch zu einem hypothetischen 512 Bit HBM Interface. Bei Vega 10 benötigt das HBM-Interface + Mem-Controller + HBCC ca. 50mm2. Nimmt man eine Verkleinerung auf 512 Bit an (Low Cost HBM) sowie 7nm, sollte das Interface + HBCC in <10mm2 realisierbar sein. Wäre eigentlich ein guter Deal von der Fläche her, wenn man sich den potentiellen Performance-Sprung der iGPU überlegt. Das wären ca. +5% Fläche bei gut möglichen +100% Performance.

[Setsul]

Kann auch 3,0 gewesen sein, ich finde die Folie auf die Schnelle nicht.

Grob ausgerechnet mit den Die Shots kommt ein 1024-bit HBM PHY bei 28nm Fiji auf 12mm².
Ein 1024-bit HBM PHY bei 14nm Vega 10 kommt auf ... 12mm².

Da könnte man jetzt Vermutungen anstellen wie groß das ungefähr auf 7nm sein wird.

Außerdem auch Low Cost HBM kostet mehr als gar nichts und einfach nur DDR RAM was den die CPU sowieso braucht.
Und dann müsste Low Cost HBM natürlich auch erst einmal zu kaufen sein.

Also an sich natürlich interessant wenn es dann geht, aber nur dort wo die iGPU wirklich wichtig ist. Letztendlich der Markt den Kaby Lake G bedient nur mit Low Cost HBM ohne Interposer und als einzelner Die. Praktisch exakt wie Kaby Lake G, aber billiger in der Herstellung. Freut AMD, wie viel billiger das dann als KBL-G und Nachfolger wird hängt von Intel und der Nachfrage ab.

[basix]

Außerdem auch Low Cost HBM kostet mehr als gar nichts und einfach nur DDR RAM was den die CPU sowieso braucht.
Und dann müsste Low Cost HBM natürlich auch erst einmal zu kaufen sein.

Also an sich natürlich interessant wenn es dann geht, aber nur dort wo die iGPU wirklich wichtig ist. Letztendlich der Markt den Kaby Lake G bedient nur mit Low Cost HBM ohne Interposer und als einzelner Die. Praktisch exakt wie Kaby Lake G, aber billiger in der Herstellung. Freut AMD, wie viel billiger das dann als KBL-G und Nachfolger wird hängt von Intel und der Nachfrage ab.

Die 7nm APUs werden wahrscheinlich eh erst gegen Ende 2019 aufschlagen, bis dahin ist noch viel Zeit. HBM allgemein wird bis dahin schon einiges gereifter sein. Ob HBM-Interface + HBCC dann 10mm2 oder 15mm2 benötigt, ist ja eigentlich nicht so dramatisch. Mit 5-10% mehr Chipfläche aber potentiell doppelte GPU-Leistung rausholen wäre für mich ein genug guter Grund. Ausserdem sollte HBM pro GByte/s wesentlich energieffizienter zu Werke gehen, da könnte man im Power-Budget limitierten Fall nochmals was rausholen.

Ich sehe das ebenfalls wie du: HBM einfach bei den Top-End SKUs und wo die iGPU wichtig ist. Sagen wir mal ein 4700U hat noch keinen HBM (3700U wird RR Refresh sein). Ein 4800U dann schon. Irgendwie sowas. Für diese SKU verlangt man dann auch 40-50$ mehr, dann hat man trotz den 10-30$ Kosten für den HBM noch eine höhere Marge dazu. Das selbe beim Desktop und evtl. auch bei den Embedded Lösungen.
Ich denke, z.B. Apple könnte das AMD für starke und dünne Notebook-Lösungen aus den Händen reissen. Also ich finde, dass ein genug grosser Markt für solche SKUs vorhanden ist.

[CompuJoe]

Hier wohl besser aufgehoben

Also auch der Zen 2 refresh für AM4 2020:

https://informaticacero.com/exclusivo-roadmap-nombres-los-proximos-amd-ryzen-se-viene-mattisse-vermeer/

https://informaticacero.com/wp-content/uploads/2018/03/roadmap-AMD.jpg

[spotz]

Ich bin ein wenig verwirrt. Diese neue Grafik suggeriert das AMDs APUs und CPUs gleichzeitig einem Inflection-Optimization Rhythmus folgen. Bisher dachte ich das dieser Rhythmus bei APUs und CPUs um ein Jahr versetzt erfolgt.

Also das 2019 Matisse in 7 nm (Inflection) kommt und Picasso in 12 nm (Optimization). Also so wie es in der älteren Grafik von der Farbgebung und dem Stichpunkt "Power/Performance Uplift" bei Pinnacle Ridge und Picasso dargestellt wird. Übersehe ich da etwas?

https://s14.postimg.org/inpdd2j2p/AMD-_Matisse-_Picasso.jpg

[HOT]

Hier wohl besser aufgehoben

Also auch der Zen 2 refresh für AM4 2020:

https://informaticacero.com/exclusivo-roadmap-nombres-los-proximos-amd-ryzen-se-viene-mattisse-vermeer/

https://informaticacero.com/wp-content/uploads/2018/03/roadmap-AMD.jpg
Oh AMDs Tick Tock :D.
Damit ist Zen3 aber 2020 wohl vom Tisch, denn das passt nicht zu der Folie.
Zen1 14nm -> Zen1+ 12nm -> Zen2 7nm -> Zen2+ 7nm EUV -> Zen3
würd ich da jetzt reininterpretieren.

Ich freu mich auf Renoir. Hat sicherlich 8 Kerne und sicherlich 20 CUs (auf AM5 + DDR5).

Und ja, die Folie ist etwas irreführend, denn die unteren Pfeile müsste man für die APUs genau gegenteilig gestalten :D. Aber ich vermute, man wollte damit nur ausdrücken, dass man das in dem Jahr eben macht und die APUs eben auch dazugehören. Man kommt halt in Gestaltungsschwierigkeiten, wenn man das nicht so macht und die APUs unbedingt mit draufhaben will :D.

[tm0975]

Vermeer :-)

https://de.wikipedia.org/wiki/Vermeer_(Spieleserie)

@HOT: AMDs Tick Tock scheint recht plausibel.

[BoMbY]

Oh AMDs Tick Tock :D.
Damit ist Zen3 aber 2020 wohl vom Tisch, denn das passt nicht zu der Folie.


Zen3 ist scheinbar schon fest gesetzt, obwohl es im Moment aussieht als wäre Zen3 nur ein Zen2 mit AVX512 ... Ich könnte mit sogar vorstellen, dass Zen2 und Zen3 gleichzeitig raus kommen - es gab ja auch schon Gerüchte über einen kleinen und einen großen Chip. Eventuell ist der kleine Zen2 mit 12c/24t und der große Zen3 mit 16c/32t und AVX512. Beide sind jedenfalls wohl Family 18h.

Die ganze Nomenklatur bei AMD scheint auf jeden Fall immer noch irgendwie durcheinander.

[M4xw0lf]

Was AMD auf dieser Folie zeigt ist eher TICK - tock ;)

[Ravenhearth]

Die 5,0 GHz-Angabe von GF würde ich nicht überbewerten. Selbst wenn der Prozess wirklich so viel mitmacht und AMD diese Frequenzen anpeilt, wird das kaum für All-Core gelten. Dann würde man den ganzen Verbrauchsvorteil von 7nm für Takt verballern, hätte keinen Spielraum für Turbo mehr und OC wäre auch kaum noch möglich. Viel wahrscheinlicher ist ein niedrigerer Basistakt von bspw. 4,2 GHz mit Turbo bis hinauf zu 5,0 GHz max, aber nur für Singlecore dann. Somit gäbe es noch Verbrauchsreserven für mehr Kerne und es wäre ordentlich All-Core-OC drin.

[basix]

Viel mehr als 4.0 GHz All-Core bei 16C werden es sicher nicht werden. 2-3x Verbesserung der Energieeffizienz durch den Prozess. Doppelte Kerne. +10% Takt (ausgehend von 3.7 GHz für Pinnacle Ridge). Damit hat man das Energie-Budget sicher aufgebraucht. Interessant wäre dann aber auch noch z.B. der 6C und 8C Boost hinsichtlich Spieleleistung.

5.0+ Ghz Single Core Boost wird es aber wahrscheinlich schon werden. Sie sind ja schon heute über den offiziellen Spec-Limits für 14nm. Zudem wären 5.0+GHz auch marketingtechnisch eine gute Nummer.

[robbitop]

7 nm ist auch nochmal ein richtig guter Sprung - man hat ja einen Node (10nm) ausgelassen. Fast so wie von 28 nm auf 14/16 nm. Dafür muss man aber eine ganze Weile damit auskommen, bis irgendwann mal 5 nm kommt.

IMO hat Ryzen 3000 (Zen2) gute Chancen/Voraussetzungen, ein richtig guter Wurf zu werden.

Mehr Kerne, mehr Takt, mehr IPC. Alles gleichzeitig. Könnte ein sehr langlebiger Prozessor werden (in Bezug auf Upgradebedarf)...

[Ravenhearth]

Also der Sprung von 16/14nm auf 7nm scheint ja genauso groß oder sogar etwas größer zu sein wie von 28nm auf 16/14nm. Bei TSMC steht bspw. -70% Fläche und -60% Verbrauch auf dem Papier, bei Globalfoundries sinds -63% Fläche (bzw. Faktor 2,7) und auch -60% Verbrauch. Von 28nm auf 14nm bei GF lagen die Angaben bei up to -55% Area und -60% Power, ähnliches bei TSMC.

[AffenJack]

7nm sind aber nur 30% geringere Transistorkosten im Vergleich zu 16nm bei GF. Dementsprechend muss man entweder massiv die Produktionskosten der Dies erhöhen oder zu kleineren Dies übergehen. Ich glaube an letzteres und deswegen glaube ich auch eher an 12 Kerne, als an 16 Kerne. Bei 12 Kernen kann man dann auch den Takt hochfahren. Bei 16 Kernen wird einem nix anderes übrig bleiben als bei ~4 Ghz zu bleiben.

[robbitop]

Allcore meinst du? Aber durch den gestaffelten Takt sind viele Kerne heute kein Hindernis mehr um hohe Taktraten für einzelne Kerne zu fahren. Wenn die Applikation nicht alle 16C nutzt, verbrauchen die auch keinen Strom, man kann also genauso fahren wie ein 12C Die.

Steigende Produktionskosten betreffen die ganze Branche. Das müssen alle auf den Kunden schieben. Auch Intel.

[BoMbY]

Die Kosten pro Chip sinken in der Regel, trotz höherer Kosten pro Wafer (natürlich bei gleicher Anzahl Transistoren) ... GloFo sagt zu 7LP: "Up to 30% lower die cost (vs. 14nm)".

[N0Thing]

Wenn nur ein reiner Shrink vorgenommen wird, sicherlich. Nur bleibt die Anzahl er Transistoren nicht gleicht, irgendwo muss die Mehrleistung ja herkommen.

[AffenJack]

Allcore meinst du? Aber durch den gestaffelten Takt sind viele Kerne heute kein Hindernis mehr um hohe Taktraten für einzelne Kerne zu fahren. Wenn die Applikation nicht alle 16C nutzt, verbrauchen die auch keinen Strom, man kann also genauso fahren wie ein 12C Die.

Steigende Produktionskosten betreffen die ganze Branche. Das müssen alle auf den Kunden schieben. Auch Intel.

Jop Allcore, hast recht, ob nun 12 oder 16 Core macht keinen so großen Unterschied, wenn man jetzt zb 8 Kerne hoch takten lässt. Den Rest muss man ja nicht hochfahren.

Oder sie gehen alle zu kleineren Diegrößen. Prinzipiell haben CPUs sowieso verdammt gute Margen, aber es ist eben die Frage ob man die verringern will/ Preise erhöhen will oder ob man nicht eher etwas konservativer bei den Diegrößen wird.

Die Kosten pro Chip sinken in der Regel, trotz höherer Kosten pro Wafer (natürlich bei gleicher Anzahl Transistoren) ... GloFo sagt zu 7LP: "Up to 30% lower die cost (vs. 14nm)".

Kosten pro Transistor sinken, Kosten pro Chip sind die letzten Jahre tendenziell eher gestiegen.

[BoMbY]

Kosten pro Transistor sinken, Kosten pro Chip sind die letzten Jahre tendenziell eher gestiegen.

Hast Du da auch irgendwelche Zahlen zu? Alte Prozesse werden in der Regel günstiger, weil die ihre Maschinen ausgelastet halten wollen, und die Chips werden in der Regel mit neuen Prozessen nicht größer als bei den alten Prozessen, auch wenn sie mehr Transistoren haben. Zum Beispiel Tonga XT 5000×10^6 / 359 mm² vs. Ellesmere XT 5700×10^6 / 232 mm².

Edit: Oder Fiji XT 8900×10^6 / 596 mm² vs. Vega10 12.5×10^9 / 486 mm²

[reaperrr]

Hast Du da auch irgendwelche Zahlen zu? Alte Prozesse werden in der Regel günstiger, weil die ihre Maschinen ausgelastet halten wollen, und die Chips werden in der Regel mit neuen Prozessen nicht größer als bei den alten Prozessen, auch wenn sie mehr Transistoren haben. Zum Beispiel Tonga XT 5000×10^6 / 359 mm² vs. Ellesmere XT 5700×10^6 / 232 mm².

Edit: Oder Fiji XT 8900×10^6 / 596 mm² vs. Vega10 12.5×10^9 / 486 mm²
Das sind Milchmädchenrechnungen.

Die Wafer-Kosten für 16/14nm sind sicherlich aktuell wegen der hohen Nachfrage noch immer höher als die 28nm-Wafer-Kosten in 2015, hinzu kommt, dass die Design-Kosten pro Chip durch die komplexer werdenden Chips und Prozesse zugenommen haben.

Die 30% geringeren Kosten in 7nm beziehen sich nur auf die reinen Produktionskosten eines Chips mit gleicher Transistorzahl, alles, was an Designaufwand davor passiert, wird dabei nicht berücksichtigt.

[BoMbY]

Nochmal: Wafer werden teurer, ja. Aber trotzdem werden die Chips günstiger ...

[Gipsel]

Nochmal: Wafer werden teurer, ja. Aber trotzdem werden die Chips günstiger ...Nur wenn sie auch deutlich kleiner werden, also z.B. bei gleicher Transistorzahl. Wenn Du die Platzersparnis nutzen willst, um einen auch nur annähernd gleich großen Chip (in mm²) zu bauen, wird es teurer.

[AffenJack]

Hast Du da auch irgendwelche Zahlen zu? Alte Prozesse werden in der Regel günstiger, weil die ihre Maschinen ausgelastet halten wollen, und die Chips werden in der Regel mit neuen Prozessen nicht größer als bei den alten Prozessen, auch wenn sie mehr Transistoren haben. Zum Beispiel Tonga XT 5000×10^6 / 359 mm² vs. Ellesmere XT 5700×10^6 / 232 mm².

Edit: Oder Fiji XT 8900×10^6 / 596 mm² vs. Vega10 12.5×10^9 / 486 mm²
Fiji mit 596mm² dürfte deutlich billiger zu fertigen sein, als Vega10 mit 486 mm²
Aber darum geht es mir genau, was du als Bsp genommen hast. bei 16nm gab es keine gute Verringerung der Kosten/Transistor mehr, deswegen wurden die Diegrößen kleiner. Genau das gleiche erwarte ich von 7nm. Davor waren die Diegrößen relativ stabil.

Z.B.
https://josepjroca.files.wordpress.com/2015/12/eezbrge.jpg

https://josepjroca.files.wordpress.com/2015/12/eezbrge.jpg

Alte Prozesse werden schon günstiger, aber nie mehr so günstig wie die vorherigen, da die Prozesse viel aufwendiger sind. Die Produktionszeit bei einem 16nm Wafer ist glaube 10 Wochen im vergleich zu 8 Wochen bei 28nm. Es sind viel mehr Masken usw.

Schön hier zu sehen:
http://electroiq.com/wp-content/uploads/2015/07/Fig-1.png
http://electroiq.com/blog/2015/07/process-watch-increasing-process-steps-and-the-tyranny-of-numbers/

[BoMbY]

Im Worst Case sind die Kosten für eine Vega10 gegenüber einem Fiji gleich geblieben - mehr sehe ich da immer noch nicht.

[reaperrr]

Im Worst Case sind die Kosten für eine Vega10 gegenüber einem Fiji gleich geblieben - mehr sehe ich da immer noch nicht.
V10 ist auch immerhin fast 20% kleiner als Fiji.

Laut GloFo selbst(!) soll 7nm im best-case auf 37% von 14LPP skalieren, trotzdem aber nur auf best-case 70% Kosten. Was sagt uns das über die Kosten pro mm²?

[AffenJack]

Vega10 Transistoren 1,4x Fiji
14nm Transistorkosten im Vergleich zu 28nm 0,4/0,5=0,8 (20% billiger pro Transistor als 28nm, aus der AMD Grafik)
Dementsprechend sind die Kosten ganz grob bei 1,4 x 0,8 = 1,12 <-- Daher ganz grob nur mit AMDs Zahlen gerechnet ist Vega10 10% teurer als Fiji. Vielleicht wurde 14nm bis 2017 billiger als die Projektionen gezeigt haben. Dann sind es im Best-Case eher ähnliche Kosten wie Fiji.

[Setsul]

@basix:
Meine Bedenken sind eigentlich hauptsächlich ob Low Cost HBM wirklich auftaucht, da hat man ja lange nichts mehr gehört.
Generell denke ich AMD wird sich fürs high end sowieso irgendwann APUs mit HBM gönnen, egal ob es dann HBM2, HBM3 oder Low Cost HBM wird. Solange Intel keinen Preisdruck aufbaut kann man sich das so oder so versilbern lassen. Bei >400$ und durchaus ein bisschen für den Speicher selbst machts der Interposer auch nicht mehr aus.

@topic:
Inflection-Optimization ist eigentlich das genaue Gegenteil von Tick-Tock.
Tick-Tock war neuer Prozess, gleiche Architektur dann gleicher Prozess, neue Architektur. Beides relativ viel Aufwand.
Inflection-Optimization ist neuer Prozess und neue Architektur, dann bleibt beides gleich und es gibt ein Jahr mit ein paar Prozent mehr Effizienz, 100 MHz mehr Takt und eventuell mehr Kerne bei gleicher Nummer à la KBL/CFL.

[Duplex]

Zen3 ist scheinbar schon fest gesetzt, obwohl es im Moment aussieht als wäre Zen3 nur ein Zen2 mit AVX512 ... Ich könnte mit sogar vorstellen, dass Zen2 und Zen3 gleichzeitig raus kommen - es gab ja auch schon Gerüchte über einen kleinen und einen großen Chip. Eventuell ist der kleine Zen2 mit 12c/24t und der große Zen3 mit 16c/32t und AVX512. Beide sind jedenfalls wohl Family 18h.

Die ganze Nomenklatur bei AMD scheint auf jeden Fall immer noch irgendwie durcheinander.
Was für ein Schwachsinn wird hier geschrieben, nach dieser Darstellung bräuchte man Zen2 nicht vermarkten.

Über Zen3 kann man bisher nichts sagen, erstmal sollte man abwarten was für Architektur Änderungen in das Zen 2 Design eingeflossen sind.

Wenn ich mir die Marktanteile ansehe spielt AVX nur eine Nebenrolle bei AMD, das Design wurde so festgelegt! Klar kann man die Architektur ändern, aber das macht man nicht einfach so, die Architektur Basis wird sich nicht viel ändern, einige träumen zu viel.

[BoMbY]

Ja, wenn Du meinst ... nur gibt es mehr Informationen als Dir bekannt zu sein scheinen ...

[Locuza]

Gibt es für das arme Volk hier im Thread auch ein paar Krümel von diesen Informationen, die darauf hindeuten das Zen3 hauptsächlich wie Zen2 aussieht, nur mit AVX512-Zusatz?

[basix]

Gibt es eigentlich Tendenzen / Hinweise, dass Zen 2 im Performance Segment ebenfalls mit Grafik kommt? Zum Beispiel so:

Mobile und Mainstream: 6C + 1024 Shader (Navi), keine Server Features
Performance: 12C + 1024 Shader (Vega?), keine Server Features
High End + HEDT: 16C + 16C MCM, inkl. Server Features


Alles in allem sollten 12C + 1k Vega Shader + ohne Server Features in 7nm in etwa vergleichbar viel Platz brauchen wie heute Summit Ridge. Eher sogar weniger, da viele I/O Interfaces wegfallen würden. Wäre zumindest für AM4 und Komplettsysteme kein schlechter Gedanke. Und würde auch Sinn machen hinsichtlich 12C und 16C Gerüchten.

[maguumo]

Solange der Grafikteil nicht als Chiplet drangetackert werden kann geht die Wahrscheinlichkeit dafür das Produkte mit dem zwei (oder in Zukunft mehr?) CCX Chip damit kommen gegen 0 würde ich sagen.

[reaperrr]

Solange der Grafikteil nicht als Chiplet drangetackert werden kann geht die Wahrscheinlichkeit dafür das Produkte mit dem zwei (oder in Zukunft mehr?) CCX Chip damit kommen gegen 0 würde ich sagen.
Ich auch.

Die anvisierten Kunden sind Leute, die entweder a) sowieso eine Grafikkarte verbauen (Spieler), oder b) keine IGP brauchen (Server-Kunden).

Ist in dem Fall dann nur Verschwendung von Silizium und Gewinnmargen.

[robbitop]

Ich bin gespannt, wann AMD full speed avx256 einbaut. Das wird schon sehr transistorintensiv. AVX512 dann sicherlich zunächst half rate, oder?

[fondness]

Wieder zwei Folien, die sich schon um Ryzen 4000 in 2020 bzw. Threadripper 3000 drehen. Viele schöne Worte und eine Bestätigung: Auch Vermeer, Renoir und Dali kommen noch für Socket AM4.
https://videocardz.com/75231/amd-ryzen-threadripper-3000-to-take-a-leadership-in-hedt-market

Neuer Sockel also frühestens mit Ryzen 5000 in 2021.

[y33H@]

Bitte immer die originale Quelle: https://informaticacero.com/mas-diapositivas-que-confirman-amd-castle-peak-monster-truck-of-computer/

[Locuza]

Hat jemand eine Ahnung, wie es mit der Lizenzierung und dem Erwerb von Stockfotos aussieht, welche die IHVs vielleicht in ihre Folien packen?

Den Monstertruck von einer der Folien habe ich gestern mit Bing gefunden:
http://stadiumsupertrucks.com/wp-content/uploads/2013/01/Bigfoot11.png
http://stadiumsupertrucks.com/bigfoot-monster-trucks/

[aceCrasher]

Wenn man AVX512 implementieren würde hätte man einen entscheidenden Vorteil im Bereich encoding, gerade mit x265. Ansonsten muss man sich dort in Intel geschlagen geben, vorallem Skylake X und späteren HEDT Plattformen. Mit AVX512, selbst half rate hätte man zusammen mit mehr Cores fürs Geld endlich mal einen Grund fürs encoden zu Ryzen zu greifen.

[amdfanuwe]

Macht der Mehraufwand für AVX512 für AMD überhaupt schon Sinn?
Gibt doch kaum Applikationen, die das unterstützen.
AMD will doch eher darauf hinaus, dass die GPU solche parallelen Aufgaben übernimmt.

[y33H@]

Hat jemand eine Ahnung, wie es mit der Lizenzierung und dem Erwerb von Stockfotos aussieht, welche die IHVs vielleicht in ihre Folien packen?

Den Monstertruck von einer der Folien habe ich gestern mit Bing gefunden:

http://stadiumsupertrucks.com/wp-content/uploads/2013/01/Bigfoot11.png
http://stadiumsupertrucks.com/bigfoot-monster-trucks/Und ich dachte, der Folien-Ersteller hätte das linke Hinterrad so schlecht geshoppt, aber das ist beim Stock-Bild ja schon so ;D

Wenn man AVX512 implementieren würde hätte man einen entscheidenden Vorteil im Bereich encoding, gerade mit x265. Ansonsten muss man sich dort in Intel geschlagen geben, vorallem Skylake X und späteren HEDT Plattformen. Mit AVX512, selbst half rate hätte man zusammen mit mehr Cores fürs Geld endlich mal einen Grund fürs encoden zu Ryzen zu greifen.Wo wird den AVX-512 genutzt außer bei x265 direkt und in etwa Handbrake? In Adobe Premiere zB nicht soweit ich das sehe, weil Encoding alleine macht noch kein geschnittenes Video ;)

[TheAntitheist]

Macht der Mehraufwand für AVX512 für AMD überhaupt schon Sinn?
Gibt doch kaum Applikationen, die das unterstützen.
AMD will doch eher darauf hinaus, dass die GPU solche parallelen Aufgaben übernimmt.
Tja was AMD will ist aber nicht das was der Realität entspricht, Video Encoding mit guter Quali bleibt der CPU vorenthalten und das gilt auch für andere Bereiche wo AVX eben sehr viel hilft.

[TGKlaus]

und das gilt auch für andere Bereiche wo AVX eben sehr viel hilft.

Na dann bring doch mal Fakten und klär uns auf, wo AVX512 so viel helfen soll ...

[Skysnake]

avx512 seh ich für AMD nicht wirklich als sinnvoll an. Die sollen bitte lieber die Ressourcen in huma stecken. Also das die iGPUs von APUs einfach avx512 Code ausführen.

DAS wäre viel viel sinnvoller meiner Meinung nach.

[HOT]

Vielleicht löst man ja da ja über 4 passes :freak:

[bbott]

Wenn man AVX512 implementieren würde hätte man einen entscheidenden Vorteil im Bereich encoding, gerade mit x265. Ansonsten muss man sich dort in Intel geschlagen geben, vorallem Skylake X und späteren HEDT Plattformen. Mit AVX512, selbst half rate hätte man zusammen mit mehr Cores fürs Geld endlich mal einen Grund fürs encoden zu Ryzen zu greifen.

Welches AVX512? Es gibt ja nicht nur eine Version?!

Ein Zen2 wird wahrscheinlich AVX256 erhalten, evtl. kommt dann Zen3 mit AVX512.

Ich meine mich auch noch dunkel daran erinnern zu können eine Folie mit diesen Infos gesehen zu haben.

[Setsul]

@bbott:
Es gibt kein AVX256. Zen unterstützt AVX2 und selbst AVX ist schon 256bit. Also nicht die Breite der Hardware mit dem Instruktion Set vermischen.
Von der ISA her hat Zen schon "AVX256" aber die Hardware ist 128bit.

Es stellen sich zwei fast unabhängige Fragen:
1. Bekommt Zen2 oder Zen3 AVX512.
2. Wird die Hardware bei Zen2/3 128bit, 256bit oder 512bit (natürlich nur sinnvoll mit AVX512)?

256bit sollten auf 7nm machbar sein. AMD kann einfach beim gleichen System bleiben wie bei Zen nur eben 512bit in 2x256bit splitten. AVX512 bringt durchaus ein paar nützliche Sachen mit unabhängig von der Breite.

Wenn AMD es elegant lösen kann die oberen 128bit zu powergaten, dann spricht eigentlich nichts gegen 256bit, Platz sollte wirklich genug sein und AVX2 ist nun wirklich nicht selten.

Falls AVX512 kommt, dann hoffe ich, dass es nicht so eine fürchterliche Salamitaktik wird wie bei Intel.
ER, PF, 4FMAPS und 4VNNIW mal außen vor braucht Intel 3 Generationen um AVX512 einzuführen.
F, CD, VL, DQ und BW mit Skylake, IFMA und VBMI mit Cannonlake und dann VPOPCNTDQ, VPCLMULQDQ, VNNI, GFNI, VAES, VBMI2 und BITALG mit Ice Lake. Anstatt einfach Code für SSE (128b), AVX (256b) (eventuelle getrennte Version für AVX2) und AVX512 (512b) zu haben muss man entweder auf einen Großteil der Features verzichten oder man darf jedes Jahr eine neue Version hinzufügen. Anstatt 3 verschiedenen hat man 5. Wer tut sich das an?
Einfach warten und dann alles auf einmal unterstützen, egal ob es Zen2 oder Zen3 ist und egal ob die Hardware dann 256b oder 512b ist.
Dann laufen alle AVX512 Programme, egal ob sie alles ausnutzen oder nur die "Basisversion" damit es auf möglichst vielen CPUs läuft.

@HOT:
Die Decoder können doch alle 2 Mops/instruction. Scheduler kann danach in 2 µops teilen so wie schon bei 256b->128b.
Machbar. :freak:

[Der_Korken]

Ich dachte bisher, dass der Verzicht auf 256bit breite Hardware einer der Gründe ist, warum die Zen-Kerne so schlank und sparsam sind. Warum also die zusätzlichen Transistoren nicht einfach in mehr Kerne investieren und den AVX-Nachteil darüber kompensieren? Code, der so breite Vektorisierung nutzt, wird doch sicherlich auch gut parallelisierbar sein.

[Setsul]

Vektorisierung und Parallelisierung sind zwei Paar Stiefel.
Eine doppelt so breite FPU kostet außerdem weit weniger als doppelt soviele Kerne.


Wenn AMD es elegant lösen kann die oberen 128bit zu powergaten, dann spricht eigentlich nichts gegen 256bit, Platz sollte wirklich genug sein und AVX2 ist nun wirklich nicht selten.

Das ist der Trick. Wenn man die Vorteile von 256bit bekommen kann ohne den Verbrauch zu erhöhen, wenn man die Breite nicht ausnutzt, dann ist das für alles das die Breite nutzen kann ein klarer Gewinn und bei allem anderen kostet es nur Platz, der auf 7nm wesentlich leichter zu verschmerzen ist.

[Der_Korken]

Müsste für volles 256bit-AVX nicht auch die Cache-Bandbreite verdoppelt werden wie bei Haswell plus eventuell weitere interne Datenverbindungen im Kern?

[basix]

Soweit ich weiss, wurde die L1 Bandbreite verdoppelt. Siehe Aida Benches mit BRD-E vs. Zen.

[Loeschzwerg]

Soweit ich weiss, wurde die L1 Bandbreite verdoppelt. Siehe Aida Benches mit BRD-E vs. Zen.

Bundesrepublik Deutschland Extended? :uponder:

[Setsul]

@Der_Korken:
Müssen ist relativ. Es würde sicherlich nicht schaden.
Andererseits würde man auch nicht die Kerne verdoppeln aber die Bandbreite pro Kern halbieren.

Bei allem, das sich so gut vektorisieren lässt, gewinnen breitere Vektoren immer.
Die Frage ist wieviel kostet es für den Fall, wenn Vektorisierung nichts bringt (oder die zusätzliche Breite nichts bringt)?

Breitere Vektoren konkurrieren selten direkt mit mehr Kernen. Die Kosten sind einfach nicht vergleichbar. Außerdem muss nicht vektorisierbar sein was parallelisierbar ist und umgekehrt.

@basix:
Bei Haswell wurden L1 und L2 Bandbreite verdoppelt gegenüber Sandy Bridge.

[mboeller]

zumindest bei ARM's SVE bringt 512bit gegenüber 256bit nicht so viel:

https://semiaccurate.com/2016/09/07/arm-adds-2048-bit-vectors-v8a-sve/

[basix]

@Setsul: jo, haste recht. Hatte das selbe im Kopf. Nur habe ich dann einen Bench zwischen BDW-E (besser? ;)) und Zen angeschaut. Dort ist nur die L1 Banbreite die Hälfte, L2 war vergleichbar. Deswegen habe ich das wohl vermischt. Aber: In demfall müsste Zen 2 nur die L1 Bandbreite verdoppeln, um auf das Niveau von Intel zu kommen?!

[TheAntitheist]

Na dann bring doch mal Fakten und klär uns auf, wo AVX512 so viel helfen soll ...
lern mal lesen, ich schrieb AVX...

[Setsul]

War nur als Bestätigung gemeint.
Das Problem ist, dass das alles peak bandwidth ist. Zum Glück sind alle 2 loads und 1 store, damit bleibt wenigstens das gleich.
Ich formatiere das jetzt nicht aber einfach immer die Reihenfolge HSW, BDW, SKL, SKL-SP, Zen:
L1D peak: 96, 96, 96, 192, 48
L1D sustained: ?, 93, 81, 133, ?
L2 peak: 64, 32, 64, 64, 32
L2 sustained: ?, 25, 29, 52, ?
Alles Angaben direkt vom Hersteller, vielleicht steht auch noch irgendwo etwas zu sustained bandwidth bei Haswell und Zen.

Es kann also gut sein dass Zen und BDW L2 nicht schlechter sind als bei HSW.
32B/cyc sind völlig in Ordnung für 256b solange auch 25-30B/cyc ankommen.

Der L1D bei Zen ist einfach (2+1)*16B gegen (2+1)*32B, nichts überraschendes. Also es wäre durchaus machbar.

EDIT: Das Ganze wird noch interessanter wenn man bedenkt, dass der L1 bei Intel single-ported ist, also entweder mit dem Kern kommuniziert oder mit dem L2, aber nicht beides gleichzeitig. Zen kann theoretisch 32B/cyc vom L2 bekommen. https://blogs.fau.de/hager/files/2017/03/Ryzen_1700X_tp_triad-1.png
SKL (nicht SKL-SP wohlgemerkt) kann die 64B/cyc niemals erreichen. Es ist einfach technisch unmöglich. https://blogs.fau.de/hager/files/2017/03/Skylake_desktop_tp_triad.png

[mksn7]

Die beiden Graphen sind übrigens aus einem Blogartikel von Georg Hager, der da noch mehr Details rund um die Caches von Skylake und Ryzen beschreibt:

Skylake: https://blogs.fau.de/hager/archives/7825
Ryzen: https://blogs.fau.de/hager/archives/7810

[Locuza]

Vermutlich ein Zen3-Thema, aber AMD arbeitet laut Gamers Nexus an ihrer DDR5-Infrastruktur und möchte ernsthaft Intel bei der Einführung zuvorkommen.
Dafür hat man ein R&D-Lab in Austin (Texas), welches sich nur auf DDR5 konzentrieren soll und AMD arbeitet mit mindestens einem Speicherherstellern eng zusammen.
https://youtu.be/evBKIfBeGJk?t=2m3s

Ebenso soll AMD an einer HBM-Speicherlösung für CPUs arbeiten.

[basix]

Hört sich gut an, ausser dass es teuer sein wird :D

APU mit HBM wir kommen! HPC CPU mit HBM wir kommen!

[SKYNET]

Hört sich gut an, ausser dass es teuer sein wird :D

APU mit HBM wir kommen! HPC CPU mit HBM wir kommen!

dürfte externe grakas im low bis mid segment dann ziemlich schnell überflüssig machen... :cool:

[Der_Korken]

Bleibt natürlich die Frage, ob die CPUs auch in irgendeiner Form vom HBM profitieren können. Laut der Experten hier im Forum liefert der nur mehr Durchsatz, aber keine besseren Latenzen. Damit wäre er als L4-Cache unbrauchbar.

[SKYNET]

Bleibt natürlich die Frage, ob die CPUs auch in irgendeiner Form vom HBM profitieren können. Laut der Experten hier im Forum liefert der nur mehr Durchsatz, aber keine besseren Latenzen. Damit wäre er als L4-Cache unbrauchbar.

denke, der speicher wird nur mit dem GPU part in der APU kommunizieren können, mehr brauch es ja auch nicht.

[Ph03n!X]

Gibt es schon konkrete Informationen zum Refresh des Threadrippers für dieses Jahr bzw. Threadripper in 2019?
Des Weiteren müsste ich wissen ob Threadripper und Asus ROG Zenith Extreme in ein Phantek Evolv Case passen?

[dildo4u]

Ein Zen+ Update kommt in der zweiten Jahreshälfte alles weitere ist Spekulation.

http://www.legitreviews.com/amd-shows-off-2018-ryzen-processor-roadmap-slashes-prices_201648

[HOT]

2.HJ kommt sicherlich ein 2300G und 2500G RR mit entsprechenden grafiklosen Pendants, der 2800X ist sicherlich als Konter für Intels 8C-Coffeelake gedacht - im 2.HJ könnte die 12nm-Fertigung auch etwas ausgereifter sein -, zudem gibts offenbar noch den Z490-Chipsatz, welcher das echte Upgrade für die 2k-Generation ist und TR gibts ja auch noch. Der neue Z490 dürfte auch gleichzeitig der neue Unterbau für Matisse sein. 500er-Chipsätze gibts mMn erst bei dessen Nachfolger.

Sollte Matisse tatsächlich über mehr Kerne verfügen, wird und PR auch noch lange erhalten bleiben, da die dann coexistieren werden.

[Oranje7]

Wer glaubt eigentlich daran, dass AMD auch wieder gesonderte Modelle auflegt welche übertaktet werden können.
Irgendwie könnte ich mir das vorstellen, könnte sich Geldtechnisch für sie lohnen

[maximus_hertus]

2.HJ kommt sicherlich ein 2300G und 2500G RR mit entsprechenden grafiklosen Pendants, der 2800X ist sicherlich als Konter für Intels 8C-Coffeelake gedacht - im 2.HJ könnte die 12nm-Fertigung auch etwas ausgereifter sein -, zudem gibts offenbar noch den Z490-Chipsatz, welcher das echte Upgrade für die 2k-Generation ist und TR gibts ja auch noch. Der neue Z490 dürfte auch gleichzeitig der neue Unterbau für Matisse sein. 500er-Chipsätze gibts mMn erst bei dessen Nachfolger.

Sollte Matisse tatsächlich über mehr Kerne verfügen, wird und PR auch noch lange erhalten bleiben, da die dann coexistieren werden.

Z490?! Was soll das sein?

2500G bzw. 2300G sind möglich, aber auch da imo eher weniger wahrscheinlich.
Imo könnte eher ein 3400G bzw. 3200G zum Jahreswechsel kommen - RR als kompletter Zen+ in "12nm" aka Picasso.

Wenn ich es richtig im Kopf habe, lauten AMDs Pläne wie folgt:

Mai/Juni: B450 Chipsatz
Sommer/Früh-Herbst: Threadripper 2, Zen+ Basis, ggf. X499 Chipsatz
Winter (grob Jahreswechsel): Picasso, Zen+ mit Vega Grafik
Frühling (wieder Richtung April, mit genug Abstand zum Chinese New Year): Matisse, Zen 2 in 7nm, wahrscheinlich X570 Chipsatz

[Opprobrium]

Wer glaubt eigentlich daran, dass AMD auch wieder gesonderte Modelle auflegt welche übertaktet werden können.
Irgendwie könnte ich mir das vorstellen, könnte sich Geldtechnisch für sie lohnen
Glaube ich für die nächsten Generationen noch nicht dran, die müssen jetzt erstmal wieder richtig Fuß fassen. Ich finde die Strategie gerade eigentlich recht gut, mit durch die Bank übertaktbaren CPUs und Threadripper als Enthusiasten Lösung.

Gibt es eigentlich schon Infos zur 7nm mobilen APU/RavenRidge 2?

[Tobalt]

unlocked macht nur Sinn wenn es viel Spielraum gäbe. diesen Spielraum werden aber Intel und AMD in nächster Zeit ein ab Werk nutzen müssen um Konkurrenzfähig zu sein. außerdem haben extra unlocked Modelle halt einen Faden Beigeschmack wie schon erwähnt. wird es also demnächst nicht geben.

außerdem werden mit den immer dynamischeren boost modi die automatischen Taktungsmöglichkeiten immer optimaler.. dh händisches OC wird immer sinnloser. Da kann ich mir in Zukunft eher vorstellen dass man nur noch Temp und Power limits vergibt und die CPU selbst dynamisch alles regelt.

[HOT]

Z490?! Was soll das sein?

2500G bzw. 2300G sind möglich, aber auch da imo eher weniger wahrscheinlich.
Imo könnte eher ein 3400G bzw. 3200G zum Jahreswechsel kommen - RR als kompletter Zen+ in "12nm" aka Picasso.

Wenn ich es richtig im Kopf habe, lauten AMDs Pläne wie folgt:

Mai/Juni: B450 Chipsatz
Sommer/Früh-Herbst: Threadripper 2, Zen+ Basis, ggf. X499 Chipsatz
Winter (grob Jahreswechsel): Picasso, Zen+ mit Vega Grafik
Frühling (wieder Richtung April, mit genug Abstand zum Chinese New Year): Matisse, Zen 2 in 7nm, wahrscheinlich X570 Chipsatz

http://www.pcgameshardware.de/Mainboard-Hardware-154107/News/AMD-Pinnacle-Ridge-Z490-Chipsatz-1254586/

Und die 2300G und 2500G kommen schon allein deshalb, weil ab Sommer ja keine B1 mehr produziert werden. Und das ist doch völlig unabhängig von den 3000ern.

Ab Sommer dürfte TR 2000 und die neuen APUs an den Start gehen, B1 ist ab da EOL, ab Spätsommer ist dann der 2800X mit Z490 zu erwarten, als Reaktion auf den 8C-Coffeelake und Z390.

[reaperrr]

http://www.pcgameshardware.de/Mainboard-Hardware-154107/News/AMD-Pinnacle-Ridge-Z490-Chipsatz-1254586/

Und die 2300G und 2500G kommen schon allein deshalb, weil ab Sommer ja keine B1 mehr produziert werden. Und das ist doch völlig unabhängig von den 3000ern.

Ab Sommer dürfte TR 2000 und die neuen APUs an den Start gehen, B1 ist ab da EOL, ab Spätsommer ist dann der 2800X mit Z490 zu erwarten, als Reaktion auf den 8C-Coffeelake und Z390.

Und die 2300G und 2500G kommen schon allein deshalb, weil ab Sommer ja keine B1 mehr produziert werden. Und das ist doch völlig unabhängig von den 3000ern.
2500G wird es nicht geben, wenn dann einen teildeaktivierten PR als 2500X.
2400G ist von den Specs das Maximum, was mit RR in 14LPP in 65W möglich ist. GPU hängt meist am Bandbreiten-Limit, CPU kratzt am Temp-Limit. Mehr Takt macht in 14LPP einfach keinen Sinn.

2300G glaube ich auch nicht dran, in der Praxis ist der Perf-Unterschied zwischen 2200G und 2400G so gering, dass AMD inoffiziell schon den Preis des 2400G senken musste damit die Leute nicht fast alle zum billigeren 2200G greifen, und da sollen sie jetzt noch einen 2300G zwischenquetschen?
Dann eher einen PR-basierten 2300X.
Kann mir aber auch vorstellen, dass sie die Lücke einfach offen lassen.

[HOT]

Halte ich für blödsinn. Da wird man noch 200MHz rausbekommen, wenn man das will.

[amdfanuwe]

Nachdem die 2200GE und 2400GE 35W Modelle jetzt auch offiziell sind, denk ich mal, dass die 2000er Serie Komplett ist.
https://www.computerbase.de/2018-04/amd-ryzen-5-2400ge-ryzen-3-2200ge-specs-launch/
Als 4 Kerner ohne GPU würde ich an AMDs Stelle die "alten" 1000er verramschen.
Wenn die 1600(X) und 1700(X) besser abverkauft sind, werden sich auch die Preise der 2000er noch nach unten bewegen.
Aktuell ist der 1600 für 150€ immer noch ein guter Deal.

[Loeschzwerg]

2300/2500G halte ich auch für gewagt. Besteht doch überhaupt kein Zwang für dieses Segment.

[johla]

Kommen 2019 auch neue Laptop-Ryzen-CPUs raus?

[dildo4u]

Vieleicht gehen sie dort direkt auf 7nm,da es im Mobile Bereich mehr bringt.
Auf der Roadmap steht erstmal nix von Zen+ in Mobile Segment.

[Loeschzwerg]

Halte ich für sehr wahrscheinlich, etliche RR Mobile Produkte haben es noch gar nicht erst auf den Markt geschafft, da muss AMD keine APU mit Zen+ nachschieben.

[robbitop]

Ist Picasso H2 2018 nicht auch nur ein RR Refresh so wie es PR zu SR war?

[Loeschzwerg]

Picasso H2 2018

Ist doch 2019, oder hat sich da was geändert?