AMD - Zen 2, 7nm, PCIe 4.0, 2019 (Matisse, Renoir, Castle Peak, Rome), Matisse-Refresh 2020 [Archiv] - Seite 12

Leonidas

2019-01-14, 10:07:09

Nope der Ryzen 3000 CPU wird ziemlich genau auf 65Watt TDP sein. Die 130 Watt liegen am Netzteil an, sprich da ist die komplette Verlustleistung des PSU mit einberechnet. Nehmen wir an die haben ca. 90% Effz.((80 Plus Gold hat bei 115V 87% Wirkungsgrad) dann hast haben alle Komponenten noch 117 Watt.

117 - 65 = 52Watt (der Rest)
Realistisch wird der TDP jedoch etwas höher sein als 65Watt. Aber es handelt sich mit sehr größer Sicherheit um eine 65Watt CPU!

Da hast Du sicherlich genauer kalkuliert als ich. Ob der Rest allerdings wirklich 52 Watt verbraucht, bezweifle ich etwas. Das wird etwas weniger sein, sagen wir 30 Watt. Außer dem Mobo gibt es in so einem Testsystem keine großen Verbraucher mehr. Alles ist integriert, hinzu kommt SSD, RAM und Spar-Gfx.

Opprobrium

2019-01-14, 10:14:24

Der_Korken

2019-01-14, 10:23:00

Es wäre sicher selbst in 7nm kein Problem einen 8-Kerner auf 95W hochzuprügeln. Die Frage ist nur, ob AMD das so will? Der Sweetspot lag für 12nm schon eher beim 2700/65W, d.h. für 7nm wird er deutlich niedriger liegen, vielleicht bei 40W. Die Gewinne von 95W gegenüber 65W sind vermutlich relativ gering und man muss sich mit hohen Temps rumschlagen, weil die Chipfläche jetzt viel kleiner wird. 80W auf 80mm² (15W IO) entsprächen 200W auf einem Pinnacle Ridge Die von der Wärmedichte her und da ist PBO noch gar nicht eingerechent. Eine Aufteilung 8 Kerne = 65W, 12 Kerne = 95W, 16 Kerne = 105W wäre für mich schlüssiger. Dadurch würde sich der 12-Kerner auch bei Last auf <= 8 Kernen immer noch leicht vor den 8-Kerner schieben und wird nicht kannibalisiert.

mboeller

2019-01-14, 10:43:41

Der Core i9-9900K saugt aber (viel) mehr als seine TDP, auch schon unter Cinebench. Demzufolge würde ich den AMD-Prozessor aufgrund des Deltas von ca. 50W auf knapp 100 Watt Verbrauch einschätzen - sprich 95W TDP.

Aber natürlich dürfte der im Vorserien-Status noch mit mehr Spannung laufen. Die wichtigste Vorgabe dürfte gewesen sein, nicht live abzustürzen.

warum spekulierst du dazu noch so viel?

https://www.anandtech.com/show/13829/amd-ryzen-3rd-generation-zen-2-pcie-4-eight-core

At Just Over Half The Power…?!

Also, in that same test, it showed the system level power. This includes the motherboard, DRAM, SSD, and so on. As the systems were supposedly identical, this makes the comparison CPU only. The Intel system, during Cinebench, ran at 180W. This result is in line with what we’ve seen on our systems, and sounds correct. The AMD system on the other hand was running at 130-132W.

If we take a look at our average system idle power in our own reviews which is around 55W, this would make the Intel CPU around 125W, whereas the AMD CPU would be around 75W.

basix

2019-01-14, 10:47:48

Da hast Du sicherlich genauer kalkuliert als ich. Ob der Rest allerdings wirklich 52 Watt verbraucht, bezweifle ich etwas. Das wird etwas weniger sein, sagen wir 30 Watt. Außer dem Mobo gibt es in so einem Testsystem keine großen Verbraucher mehr. Alles ist integriert, hinzu kommt SSD, RAM und Spar-Gfx.

Die 133W der Ryzen Demo sind mit sehr grosser Wahrscheinlichkeit mit einem 65W Sample entstanden. Siehe CB Test: Die 65W Modelle von AMD liegen alle zwischen 124-133W. Die 95W Modelle liegen alle bei 165W rum, also den +30W mehr. Dieser Test zeigt auch, wieso der 9900K "nur" 45W mehr saugt: Je nach Motherboard 10-15W geringere Idle Power.

https://www.computerbase.de/2018-10/intel-core-i9-9900k-i7-9700k-cpu-test/3/

Edit @ mboeller:
Die 75W und 125W Delta wären aber inklusive Netzteil und MoBo Spannungswandler Verluste. Bei jeweils 90% Effizienz würde man eher bei 60W und 100W landen. Da die 55W Idle Werte von Anandtech nur geschätzt wurden und wie beim CB Test die Idle Werte eher so 40W für Intel und 50W für AMD sind, wären wir bei 65W für AMD und 115W für den 9900K. Das klingt für mich eigentlich recht plausibel in nahe an der Realität. Also irgendwas zwischen 60-65W für AMD nd 100-115W für Intel.

Gipsel

2019-01-14, 14:36:57

Da hast Du sicherlich genauer kalkuliert als ich. Ob der Rest allerdings wirklich 52 Watt verbraucht, bezweifle ich etwas. Das wird etwas weniger sein, sagen wir 30 Watt. Außer dem Mobo gibt es in so einem Testsystem keine großen Verbraucher mehr. Alles ist integriert, hinzu kommt SSD, RAM und Spar-Gfx.Die hatten beide eine Radeon RX Vega 64 drin ;). Die alleine sollte so 15W im idle sein.
Achja, und je nachdem wie man das bewerten will (die Einblendung erfolgte erst nach Starten von Cinebench, aber wer weiß, mit wieviel Verzögerung und Mittelung das behaftet war), das intel-System zeigte als niedrigsten Wert ~46W (vermutlich nah am idle-Wert), das AMD-System 67W, bevor bei intel das auf ~180W und bei AMD auf ~133W hochging. Den hohe idle-Wert des AMD-Systems (sollte der denn tatsächlich 67W gewesen sein) könnte man z.B. auch auf deaktivierte Stromsparmaßnahmen (da Vorserienmodell) zurückführen, wodurch z.B. die Spannung im idle nicht reduziert wurde. Dem kann man also im Moment nicht unbedingt viel Vertrauen schenken (anders als den 46W bei intel, die ziemlich plausibel aussehen).

Also für den 9900K stehen bei dem Test ziemlich sicher 134W Delta zu Buche, bei dem Zen2-Prototypen ist das Delta von 66W eher so eine Untergrenze, da Serienmodelle im idle-Verbrauch noch tiefer liegen könnten (und eigentlich auch sollten). Mit den Netzteil und Spannungsregler-Effizienzen ist ein 100+W-Verbrauch des 9900K (vermutlich 105-110W in Cinebench, müßte man mal mit Tests gegenchecken) ziemlich sicher, die AMD-CPU sollte dagegen wohl so maximal 70W (tendentiell etwas weniger) verbraucht haben.

Lehdro

2019-01-14, 15:39:30

Was hier oft bei den TDP Diskussionen vergessen wird: Der Sprung vom 8 zum 16 Kerner zieht nicht zwangsläufig eine TDP Verdopplung nach sich, Stichwort Chipletdesign. Im Stromverbrauch des 8 Kerners ist ja schon der ganze I/O Die enthalten, der u.a. vorallem den Speichercontroller beinhaltet - diesen kann man dann sicherlich gut und gerne auf rund 10 W schätzen, was man so bedenkt was der SoC bei Ryzen 1000 & 2000 so an Strom verballert (ebenfalls 14nm). Somit geben auch die "alten" TDP Kategorien von bis zu 105W genug "Saft" her für einen 16 Kerner mitsamt ordentlichen Taktraten.

Ravenhearth

2019-01-14, 16:21:02

Ich glaub bei Ryzen 1000/2000 verbraucht der I/O-Teil rund 20W, jedenfalls kam der 1700X eines Rechners, den ich mal zusammengebaut habe, laut HWInfo auf ca. 100W insgesamt und 80W für die Kerne. Da der I/O-Teil von Ryzen 3000 ebenfalls in 14nm ist, dürfte sich daran nicht allzu viel ändern. Bei 65W für den Zen 2 Octacore macht das 45W nur für die Kerne, ein 16-Kerner kommt laut Milchmädchen auf ~110W. Passt.

Zossel

2019-01-14, 20:21:34

Ich kann mir für die APU irgendwie keine 4 Kerne vorstellen. Nicht in 7nm.

Denkbar wäre auch eine richtige Low-Power APU in einem Low-Power Prozess die OEMs in kleinen und schmalen Geräten verbauen können und die sich auch wunderbar in den Embedded Markt verkaufen könnte. Vom Sizing vergleichbar mit den derzeitigen APUs.

Und alles darüber wird aus Chiplets zusammengeklebt.

robbitop

2019-01-14, 20:49:19

Zossel

2019-01-14, 21:44:46

Wozu? Kann man doch alles über Deaktivierung von Einheiten machen. Kosten drückt man mit salvage. Stückzahl für diesen speziellen Markt müsste für AMD schon sehr hoch sein, dass sich eine eigene Maske lohnt. AMD hat da leider noch ganz andere Stückzahlen und Ressourcen als Intel.

Eine eigene Maske braucht es für eine monolitische APU sowieso, und Salvage ersetzt kein richtiges LowPower Design in einem LowPower Prozess.

Warum dann nicht mit einer eigenen Maske diese Märkte erschliessen, wenn der Rest mit kleben von Chiplets erschließbar ist?

HPVD

2019-01-14, 21:45:02

für die aktullen TR scheint man ja ganz langsam auf dem Weg zur Lösung der Performance Bremsen unter Windows zu sein
-> schöner Bericht zum aktuellen Stand
https://www.anandtech.com/show/13853/amd-comments-on-threadripper-2-performance-and-windows-scheduler

Da das ja schon recht generelle Dinge sind die da noch nicht rundlaufen, bin ich mal gespannt ob das für die nächste TR-Generation auch gleich hilft oder ob man da wieder bei 0 anfängt....

Zossel

2019-01-14, 21:59:21

Opprobrium

2019-01-14, 22:06:00

MS kriegt seit Jahrzehnten keinen vernünftigen Scheduler auf die Kette. Wenn Intel jetzt mit Big.Little kommt wird das unter Windows mit hoher Wahrscheinlichkeit wieder ein Drama ohne Ende.
Halb so wild, Microsoft arbeitet doch schon darauf hin den Sprung zu Linux zu machen ;)

BoMbY

2019-01-14, 22:25:20

Halb so wild, Microsoft arbeitet doch schon darauf hin den Sprung zu Linux zu machen ;)

Sollten sie auch besser. Unter der Annahme, dass Geekbench für Windows und Linux das gleiche berechnen ist das schon bezeichnend, dass die Linux Version unter Windows ausgeführt deutlich schneller ist: http://browser.geekbench.com/v4/cpu/compare/8025529?baseline=8025806

Eldoran

2019-01-15, 00:18:38

Naja es gab einmal Pläne für so eine kleine APU - Stichwort Banded Kestrel. Allerdings scheint es keine sonderliche Nachfrage zu geben. Das Problem ist aber auch, dass das von der Leistungsklasse der Smartphones liegt - die sind i.d.R. billiger zu haben und derzeit ist ARM bei embedded kein Nachteil gegenüber x86. Für aufwendigeres landet man da ohnehin schon bei den embedded EPYCs (und von denen kann man wohl die Modelle im Hndel an einer Hand abzählen). Objektiv betrachtet dürfte das kein sonderlich lukrativer Markt sein. Intel versenkt da schon seit Jahren massenhaft Ressourcen ohne durchschlagenden Erfolg. Extra Modelle für diesen Zweck sind da wohl kaum gewinnbringend.
Für mich erschliesst sich auch nicht, weshalb es dafür ein monolithischer Die sein muss - etwa der BGA embedded EPYC 3xxx wird auch nicht als nacktes Silizium geliefert, sondern auf einem package und das kann genauso mehr als ein die tragen.

Eldoran

2019-01-15, 01:13:05

Kurioserweise scheint AMD derzeit Bristol Ridge (Restposten?) in dem low cost x86 embedded Segment zu verhökern. Etwa: https://www.servethehome.com/amd-opteron-x3421-benchmarks-and-review-a-low-cost-atom-competitor/
Auch die neuen Chromebooks von der CES sind Bristol Ridge...

Brillus

2019-01-15, 01:31:36

Nightspider

2019-01-15, 04:19:35

Interessant wird ob die 7nm Chiplets eine harte Clockwall haben oder man mit Wasserkühlung nochmal groß etwas rausholen können wird.

8C 7nm mit 5,5 Ghz unter Wasser wäre schon sweet, sofern die RAM-Latenz nicht zu sehr bremst.

Aber hat AMD mit Zen 2 noch eh die Caches vergrößert? Vielleicht entspannt das etwas den Nachteil bei den Latenzen.
Kenne mich da aber zugegeben weniger aus.

@ Eldoran
Etwas monolithisches kleines für embedded und Low-End Systeme wird schon gebraucht. Wegen der Montage als BGA direkt auf dem Board ohne Chipträger.
8 Core wäre schon denkbar, da sich die Kerne bei Fehlern gut abschalten lassen und als salvage Lösung verkaufen lassen.

Im billigen LowEnd Bereich könnte AMD wirklich die ganzen 7nm Abfälle auch als Chiplets verkaufen. Da kommts auf die Größe nun wirklich nicht an.

Das es in Laptops nicht nur auf die Größe ankommt sieht man ja an den riesigen Nvidia RTX Mobile Chips, die jetzt in alle Gaming und Workstation Laptops kommen.

Und der 7nm Chiplet ist jetzt auch wirklich nicht so riesig, als ob es dann eine Rolle spielt ob davon 50 oder 75% tot sind. Interessanter wäre, ob man die 7nm Chiplets auch mit kleineren IO Chiplets in Notebooks steckt.

Wie groß ist denn der IO Chiplet im Vergleich zum 1700 und 2700 Die?

Edit:

Okay, Ryzen 1 hat rund 210mm² und das IO Chiplet wohl 80 und das 7nm Chiplet wohl 122mm². Gut mit dem Paket wird man dann schon größer sein als eine Ryzen 1700.

Braucht man zumindest für die flachen Laptops wohl doch ein monolithisches SoC bzw. CPU Design.

amdfanuwe

2019-01-15, 05:10:30

Okay, Ryzen 1 hat rund 210mm² und das IO Chiplet wohl 80 und das 7nm Chiplet wohl 122mm².
Umgekehrt. I/O 122mm², CPU Chiplet ~77mm².

Geht ja nicht nur um Notebook. Im Automotive Bereich wird um jeden Cent und mm gefeilcht. Hat man im 7er oder E-Klasse noch Platz, wirds 1er doch eng.

Kleiner, leichter, billiger, mehr Leistung, mehr Funktionalität, weniger Verbrauch ist immer noch der Haupttreiber der Chiptechnik.
Ultrabooks, Desktop, Grafikkarten sind ja nur die Spitze des Eisberges, die wir sehen. Was die Industrie antreibt liegt unter Wasser.

BlackBirdSR

2019-01-15, 08:12:50

Schonmal überlegt, dass dies durch den Compiler kommen kann?
Schon mal überlegt, wie gut das Tool dann für Vergleiche zu ARM oder zwischen Android und iOS "nicht" geeignet wäre, bei so großen Abweichungen schon am gleichen Rechner?

Sollten sie auch besser. Unter der Annahme, dass Geekbench für Windows und Linux das gleiche berechnen ist das schon bezeichnend, dass die Linux Version unter Windows ausgeführt deutlich schneller ist: http://browser.geekbench.com/v4/cpu/compare/8025529?baseline=8025806

danarcho

2019-01-15, 08:33:32

Schonmal überlegt, dass dies durch den Compiler kommen kann?
Schon mal überlegt, wie gut das Tool dann für Vergleiche zu ARM oder zwischen Android und iOS "nicht" geeignet wäre, bei so großen Abweichungen schon am gleichen Rechner?
Das kann man doch ganz leicht testen.
@BoMbY:
Sind die Ergebnisse von dir? Würdest du dann auch mal die Windows Version unter Wine dagegen halten? Und vielleicht noch die Linux Version unter Linux. Dann hätten wir alle 4 und könnten recht genaue Aussagen machen, welcher Unterschied durch OS und Compiler kommt.

robbitop

2019-01-15, 08:44:27

Eine eigene Maske braucht es für eine monolitische APU sowieso, und Salvage ersetzt kein richtiges LowPower Design in einem LowPower Prozess.

Warum dann nicht mit einer eigenen Maske diese Märkte erschliessen, wenn der Rest mit kleben von Chiplets erschließbar ist?

Weil Signale aus dem Die/Chilet heraus wesentlich mehr Energie kosten. Einfache Physik. Für Notebooks wäre das ggf doof. Zumindest sollte es bis zu den 35W Modellen eine Rolle spielen.

Ich halte das Vorgehen wie bei Raven Ridge für wahrscheinlicher. Eine APU für alle mobiles die nur entsprechend getaktet und Einheiten deaktivert werden um allle Märkte und TDPs abzudecken. Allerdings dank 7nm mit mehr Ausführungseinheiten als RR.

BoMbY

2019-01-15, 09:39:39

Das kann man doch ganz leicht testen.
@BoMbY:
Sind die Ergebnisse von dir? Würdest du dann auch mal die Windows Version unter Wine dagegen halten? Und vielleicht noch die Linux Version unter Linux. Dann hätten wir alle 4 und könnten recht genaue Aussagen machen, welcher Unterschied durch OS und Compiler kommt.

Ja, das sind meine Ergebnisse, aber ich hab im Moment kein Linux mit Wine am laufen auf dem PC. Ich denke ich würde das frühestens am WE schaffen.

Aber eigentlich suche ich noch einem halbwegs ordentlichen Benchmark den ich selbst kompilieren kann, dann könnte man eventuell den gleichen Compiler für jedes System nutzen, und sicher sein was die Einstellungen angeht.

Der_Korken

2019-01-15, 09:54:08

Interessant wird ob die 7nm Chiplets eine harte Clockwall haben oder man mit Wasserkühlung nochmal groß etwas rausholen können wird.

8C 7nm mit 5,5 Ghz unter Wasser wäre schon sweet, sofern die RAM-Latenz nicht zu sehr bremst.

Hier wäre es eigentlich cooler, wenn man die PStates anpassen könnte, also z.B. den Baseclock von 4 auf 4,5 Ghz anheben und den Boost von 4,8 auf 5,2 (Fantasiezahlen), denn 5Ghz Allcore dütften auf der kleinen Fläche nicht zu kühlen sein.

HOT

2019-01-15, 10:11:12

Klar geht das. Ist doch eh wieder verlötet. Es stellt sich eher die Frage, ob das Ding wieder in einen Taktwall läuft.

Der_Korken

2019-01-15, 10:25:32

SKYNET

2019-01-15, 10:29:02

Wenn ich mal aus der Präsentation auf der CES schließe, dass Zen2 40% weniger Strom bei gleichem Takt verbraucht (ungefähr), dann würde man mit 5Ghz Allcore irgendwo bei knapp 250W*0,6=150W landen, auf 77mm². Das entspräche einem Pinnacle Die, den man mit 400W befeuert oder einem Polaris mit 450W ASIC Power. Da fände ich die Lösung mit PStates besser, denn Spiele die 8 Kerne nutzen, werden auch mit 4,5Ghz bestens laufen, nur bei Spielen mit schlechter Multicore-Optimierung bringen die letzten Mhz noch wirklich was. Und wenn man an einen 12- oder 16-Kerner denkt, wird es immer absurder unbedingt alle Kerne mit maximalem Takt laufen haben zu wollen.

mit mehr kernen steigt aber auch die kontaktfläche... probleme sehe ich eher bei den luftkühlern, bei einem chiplet = 8C wird die wärme wohl primär nur direkt in einen teil der heatpipes wandern, heisst die hersteller müssen die bodenplatten dicker machen, damits sich besser auf alle heatpipes verteilt... wasserkühler werden das problem wohl nicht so stark zu spüren bekommen.

BoMbY

2019-01-15, 11:25:02

probleme sehe ich eher bei den luftkühlern, bei einem chiplet = 8C wird die wärme wohl primär nur direkt in einen teil der heatpipes wandern,

Man könnte natürlich auch endlich mal über sowas wie Panasonic PGS nachdenken zur besseren Verteilung. Da hat bis zu 1350 W/(m·K) in der Fläche - das dreifache von Kupfer.

SKYNET

2019-01-15, 11:39:17

Man könnte natürlich auch endlich mal über sowas wie Panasonic PGS nachdenken zur besseren Verteilung. Da hat bis zu 1350 W/(m·K) in der Fläche - das dreifache von Kupfer.

zu dünn... :frown:

BoMbY

2019-01-15, 12:01:25

Irgendein schaluer Kühler-Hersteller könnte ja auch mal auf die Idee kommen mit denen zusammen zu arbeiten, und etwas gutes zu entwickeln.

Die haben zum Beispiel auch gerade eine neue komprimierbare PGS-Variante als Wärmeleitpad heraus gebracht (https://na.industrial.panasonic.com/products/thermal-management/thermal-management/thermal-management-products/series/graphitetimcompressible-type-pgs-low-thermal-resistance/AYA0005?reset=1).

Edit:Thermal conductivity : X-Y direction 400W/m∙K, Z direction (28W/m∙K)

BlackBirdSR

2019-01-15, 12:18:01

Was dann wieder so wäre, als würde man 4 Sportwagen vergleichen, die alle nur in einer der besten Disziplinen antreten eines der 4.

Man müsste eigentlich die optimalen Compiler für jedes System und einmal einen Std Compiler nutzen und das dann vergleichen. Dann sieht man auch gleich, wo die großen Sprünge herkommen zwischen den prozessoren.

Aber eigentlich suche ich noch einem halbwegs ordentlichen Benchmark den ich selbst kompilieren kann, dann könnte man eventuell den gleichen Compiler für jedes System nutzen, und sicher sein was die Einstellungen angeht.

][immy

2019-01-15, 12:48:15

Weil Signale aus dem Die/Chilet heraus wesentlich mehr Energie kosten. Einfache Physik. Für Notebooks wäre das ggf doof. Zumindest sollte es bis zu den 35W Modellen eine Rolle spielen.

Ich halte das Vorgehen wie bei Raven Ridge für wahrscheinlicher. Eine APU für alle mobiles die nur entsprechend getaktet und Einheiten deaktivert werden um allle Märkte und TDPs abzudecken. Allerdings dank 7nm mit mehr Ausführungseinheiten als RR.
Mehr Ausführungseinheiten machen meiner Meinung nach wenig sinn, da bereits Raven Ridge durch die Speicherbandbreite limitiert. Das würde höchstens sinn ergeben wenn man gleichzeitig höhere Taktraten beim DDR4 Speicher zu ließe (offiziell) oder man entsprechend Cache verbauen würde, der dann aber auch wieder Platz einnehmen würde.

Natürlich könnte durch Optimierung etc noch ein wenig was rausgeholt werden, aber meist limitiert ja inzwischen tatsächlich das Speicherinterface.

Sollten sie auch besser. Unter der Annahme, dass Geekbench für Windows und Linux das gleiche berechnen ist das schon bezeichnend, dass die Linux Version unter Windows ausgeführt deutlich schneller ist: http://browser.geekbench.com/v4/cpu/compare/8025529?baseline=8025806
Wie schon des Öfteren festgestellt wurde, geekbench misst Mist wenn du Systemübergreifend testest. Wenn es nach dem ginge würden wir inzwischen unsere high-end Boliden alle gegen ARM-Chips ersetzt haben. Du kannst höchstens Ergebnisse mit gleicher Arch & OS miteinander vergleichen. Bei allem anderen versagt das ding als "benchmark".

dildo4u

2019-01-15, 13:03:10

Die ganzen Threadripper Benches zeigen aber das selbe Bild Linux läuft dort deutlich besser,möglich das unter Windows diese kurzen Tests nicht gut mit dem Stromsparmechanismen arbeiten.
Ich hab keine Daten dazu aber Taktet Ryzen in Linux überhaupt runter?

robbitop

2019-01-15, 13:05:54

[immy;11901435']Mehr Ausführungseinheiten machen meiner Meinung nach wenig sinn, da bereits Raven Ridge durch die Speicherbandbreite limitiert. Das würde höchstens sinn ergeben wenn man gleichzeitig höhere Taktraten beim DDR4 Speicher zu ließe (offiziell) oder man entsprechend Cache verbauen würde, der dann aber auch wieder Platz einnehmen würde.

Natürlich könnte durch Optimierung etc noch ein wenig was rausgeholt werden, aber meist limitiert ja inzwischen tatsächlich das Speicherinterface.

Mit "mehr Ausführungseinheiten" sind vor allem mehr CPU Cores gemeint.

Weiterhin ist Vega im Vergleich zu Pascal und Turing nicht besonders bandbreiteneffizient. Ich gehe davon aus, dass Navi hier nochmal ordentlich was drauflegen kann. Insofern wären auch ein paar mehr CUs möglich.

HOT

2019-01-15, 13:35:29

Renoir wird denke ich nicht mehr als 1 CCX bekommen. Das Ding muss billig bleiben. Natürlich kann man ein paar CUs mehr verbauen und den RAM-Suppot auf 3200+ offiziell hochschrauben. 14CUs sind denke ich problemlos drin.

robbitop

2019-01-15, 13:40:49

Über billig verdient man schlechter als wenn man kompetativ ist und oben mitspielt. Fokus auf Gewinnspanne und höhere erzielbare Preise. (der Atom Preisbereich wirft eh kaum etwas ab) Mit 4C braucht AMD Ende 2019/Anfang 2020 nicht mehr anzukommen. Das ist dann nur noch im 15W Segment interessant.
In den höheren TDP Klassen hat Intel schon jetzt 6C und ab Jahresende 8C.
Die Strategie, bessere oder wenigstens gleich gute Produkte zu liefern hat bei Ryzen extrem gut funktioniert. Warum sollte man jetzt den Schwanz einziehen? Die günstigeren Notebooks bekommen halt Salvage CPUs.

Außerdem ist ein CCX @7nm eh winzig. Dürfte keinen so enormen Unterschied machen. Und dann hat man gleich ein Design, was vieles abdecken kann über Deaktivierung.

BoMbY

2019-01-15, 13:44:45

Was dann wieder so wäre, als würde man 4 Sportwagen vergleichen, die alle nur in einer der besten Disziplinen antreten eines der 4.

Man müsste eigentlich die optimalen Compiler für jedes System und einmal einen Std Compiler nutzen und das dann vergleichen. Dann sieht man auch gleich, wo die großen Sprünge herkommen zwischen den prozessoren.

Man könnte auch einfach die gleiche Vanilla-Clang-Version für beide Systeme nutzen. Aber vermutlich wirst Du es ehh nur akzeptieren, wenn Du es selbst gemacht hast.

aufkrawall

2019-01-15, 13:56:50

][immy

2019-01-15, 14:31:02

Mit "mehr Ausführungseinheiten" sind vor allem mehr CPU Cores gemeint.

Weiterhin ist Vega im Vergleich zu Pascal und Turing nicht besonders bandbreiteneffizient. Ich gehe davon aus, dass Navi hier nochmal ordentlich was drauflegen kann. Insofern wären auch ein paar mehr CUs möglich.
ach so, CPU Kernchen meintest du :). Da geht wohl noch was, das stimmt.
Aber was Navi angeht, da mach ich mir wenig Hoffnung das da die Bandbreite besser wird. AMDs HBM Experimente zeigen ja schon, das Bandbreite nicht mehr zu deren Probleme gehört ;)
Schaden könnte es natürlich nicht die zur Verfügung stehende besser zu nutzen.

robbitop

2019-01-15, 14:58:11

Navi nutzt wieder gddr. Weiterhin kostet Bandbreite halt Geld. Breiteres SI (PCB, IMC) und in Grenzfällen muss man mehr Speicher kaufen, weil krumme Konfigurationen problematisch sind.
GP106 kam mit 192bit aus und verbaute nur 6gb (was in der Lebenszeit knapp reichen sollte). Polaris musste 256 bit und 8 gb im top tier verbauen. 4gb wären wahrscheinlich hin und wieder problematisch.
Das betrifft auch die Nextgen Konsolen. Gerade da ist Geld in der bom immer knapp. Insofern denke ich schon, dass sich dort etwas tut.

Im Prinzip tat sich ja auch bei vielen gcn Iterationen ja schon etwas. Tonga brachte dcc, Polaris verbesserte sie und Vega brachte den DSBR. Die Sprünge waren allerdings recht klein.

HOT

2019-01-15, 15:22:50

Das sehen wir dann, welcher dann GDDR nutzt. Davon bin ich noch nicht überzeugt. Die HBM-Infrastruktur steht und will auch genutzt werden. Die Kosten müssen weiter sinken, wenn man daraus Vorteile ziehen will. Ich bin nicht davon überzeugt, dass N10 GDDR mitbringt. Ich tippe auf 2-3 Stapel.
Die kleineren sind sicherlich GDDR, da besteht kaum ein Zweifel.

w0mbat

2019-01-15, 15:42:21

SKYNET

2019-01-15, 15:47:22

Es soll ja auch noch HBM3 kommen der die Kosten weiter drückt. Abgesehen von Polaris und seinen refresh Versionen hat AMD seit langem nur noch HBM GPUs auf den Markt gebracht: Fiji, Vega10 und jetzt Vega20.

Zumal auch GDDR6 sehr teuer sein soll, man deutlich mehr Platz auf dem PCB benötigt und auch der Strombernrauch höher anfällt. Mit zwei Staple HBM3 sollte man schon hinkommen.

Ich fände es sehr doof wenn AMD jetzt einen Rückzieher macht und Navi wieder auf alte Technologie setzt.

zumal GDDR6 und HBM2 beide gleich viel kosten --> 8GB +/- $150

sehe da also keinen vorteil, eher einen nachteil, da es aufwendigere kühllösungen braucht bei GDDR6 und das PCB viel aufwendiger gestaltet werden muss... also sollte unterm strich HBM2(HBM3) dann deutlich günstiger sein beim fertigen endprodukt.

Zossel

2019-01-15, 21:21:55

Ich hab keine Daten dazu aber Taktet Ryzen in Linux überhaupt runter?

Ja.

w0mbat

2019-01-19, 01:24:50

https://www.gamersnexus.net/news-pc/3428-amd-converting-epyc-to-x570-dropping-asmedia

The previous AMD chipsets were made by ASMedia, which introduced some early challenges in development for the 1000-series Ryzen parts. For the new series of chipsets, our understanding is that AMD will be designing the silicon itself rather than tapping ASMedia for assistance.

Launch ist für Juni geplant!

Zossel

2019-01-19, 10:00:20

Man könnte auch einfach die gleiche Vanilla-Clang-Version für beide Systeme nutzen. Aber vermutlich wirst Du es ehh nur akzeptieren, wenn Du es selbst gemacht hast.

Die Qualitäten eines Schedulers deckt man nicht mit bestimmten Compilern auf, sondern durch entsprechende Anwendungslasten. Sowas wie der SAP S&D Benchmark wäre da sicherlich besser geeignet. Leider kenne ich nichts in der Art ein paar Nummern kleiner.

HOT

2019-01-19, 10:16:40

https://www.gamersnexus.net/news-pc/3428-amd-converting-epyc-to-x570-dropping-asmedia

Launch ist für Juni geplant!
Na da steigen die Chancen für ordentliches PCIe aber.

AlterSack

2019-01-19, 12:28:34

AlterSack

2019-01-19, 12:29:55

zumal GDDR6 und HBM2 beide gleich viel kosten --> 8GB +/- $150

sehe da also keinen vorteil, eher einen nachteil, da es aufwendigere kühllösungen braucht bei GDDR6 und das PCB viel aufwendiger gestaltet werden muss... also sollte unterm strich HBM2(HBM3) dann deutlich günstiger sein beim fertigen endprodukt.

Navi + HBM wäre seine saubere Sache!

BlacKi

2019-01-19, 17:06:10

Es soll ja auch noch HBM3 kommen der die Kosten weiter drückt. Abgesehen von Polaris und seinen refresh Versionen hat AMD seit langem nur noch HBM GPUs auf den Markt gebracht: Fiji, Vega10 und jetzt Vega20.

Zumal auch GDDR6 sehr teuer sein soll, man deutlich mehr Platz auf dem PCB benötigt und auch der Strombernrauch höher anfällt. Mit zwei Staple HBM3 sollte man schon hinkommen.

Ich fände es sehr doof wenn AMD jetzt einen Rückzieher macht und Navi wieder auf alte Technologie setzt.
kommt auch darauf an ob die verfügbarkeit stimmt. für navi brauchts mehr ram als die paar vega karten bisher. im vergleich zu polaris ist vega kaum ein massenprodukt:biggrin:

LivingAudio

2019-01-21, 00:01:34

Wie hoch wird eigentlich der Preis bei der Latenz und somit der Spiele-Leistung wegen dem IO-Chip euerer Glaskugel nach?

Das ist der einzige Punkt der mir nicht gefällt bisher an dem AMD-Plan mit dem Chiplet-Design... Ich denke das kostet den ganzen Vorsprung bei der Spiele-Leistung... oder kann man sowas quasi verlustfrei lösen?

BoMbY

2019-01-21, 01:37:10

Ich würde tippen es bleibt ähnlich zu den jetzigen Werten, was die Latenz angeht. Verbesserungen auf der einen Seite, gegen Verschlechterung durch den längeren Weg auf der anderen Seite, könnten sich am Ende praktisch aufheben.

robbitop

2019-01-21, 07:10:13

Sehe ich auch so. Der verdoppelte L3 Cache und der verbesserte Prefetcher implizieren, dass man versucht, dieses Manko abzufedern. Ggf ist ja die InterCCX Latenz innerhalb eines Cores nun deutlich besser, so dass man auch den L3 des Nachbar CCX effektiv nutzen kann. Das was ja bei SR/PR zu langsam dazu.

w0mbat

2019-01-21, 11:58:18

Das I/O chiplet kann die Latenz auch senken, wir wissen es einfach nicht. Die CPU chiplets sind so nahe am I/O die dran, hier kann AMD viel optimieren.

Complicated

2019-01-21, 12:34:10

Studien zeigen eine gestiegene Latenz von ca. 20% von einem 64-Core monolithischen Chip zu einem 16x4-Core Chiplet-Design.
Also im Grundsatz ohne zusätzliche Technik das abzufedern.

Gipsel

2019-01-21, 13:09:24

Der_Korken

2019-01-21, 13:23:45

robbitop

2019-01-21, 13:30:44

Das I/O chiplet kann die Latenz auch senken, wir wissen es einfach nicht. Die CPU chiplets sind so nahe am I/O die dran, hier kann AMD viel optimieren.
Gegenüber einem monolithischem Chip bei denen die Daten im Chip bleiben? Bei gleichem Interface nur schwer zu glauben.
Wenn das Interface (unabhängig davon ob Chiplet oder monolithisch) besser geworden ist: ja. Dann wäre es auf einem monolitischen Chip noch schneller.

Kann mir ehrlich gesagt kaum vorstellen, dass das nicht Latenz kostet. Ggf. wiegt die Verbesserung am Interface aber den Nachteil des höheren Signalweges wieder auf. Eine deutliche Verbesserung ist hier schwer vorstellbar.

mboeller

2019-01-21, 14:16:28

Gegenüber einem monolithischem Chip bei denen die Daten im Chip bleiben? Bei gleichem Interface nur schwer zu glauben.
Wenn das Interface (unabhängig davon ob Chiplet oder monolithisch) besser geworden ist: ja. Dann wäre es auf einem monolitischen Chip noch schneller.

Kann mir ehrlich gesagt kaum vorstellen, dass das nicht Latenz kostet. Ggf. wiegt die Verbesserung am Interface aber den Nachteil des höheren Signalweges wieder auf. Eine deutliche Verbesserung ist hier schwer vorstellbar.

so groß ist der Abstand zw. IO-Chip und CPU-Chiplet beim Ryzen 3000 auch nicht. Ich komme, mit dem Bild von anandtech auf einen Abstand von 3,67mm.

https://images.anandtech.com/doci/13829/cpu33.jpg

HOT

2019-01-21, 14:17:33

Man braucht eigentlich einen Cache um die Latenz abzufangen.

BoMbY

2019-01-21, 14:31:59

Es dürfte wohl darauf ankommen, wie die Datenpakete logisch verarbeitet werden, also wie viele Hops zwischen Core und IMC liegen. Jemand hatte hier mal ein Bild gepostet, wo das IF als kompliziertes Netzwerk mit aufwändigem Routing dargestellt wurde. Da lässt sich sicherlich was machen. Die Signallaufzeit von einem Die zum anderen dürfte den Kohl eigentlich nicht fett machen, denn verglichen mit der physikalischen Distanz zum RAM ist das fast nichts.

Meinst Du das:

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

?

Jedenfalls dürfte es bei Zen2 wahrscheinlich so aussehen, dass der IO-Die einen entsprechend dimensionierten Cross Bar Switch enthält. Die Frage ist womit genau die CPU-Chiplets angebunden sind - wobei die ja wenigstens die Geschwindigkeit von Dual Channel DDR4 erreichen sollten, also mindestens etwa 64 GB/s, ansonsten ergibt das wenig Sinn - das sollte in etwa PCIe 4.0 x16 entsprechen, wobei die vermutlich nicht das PCIe-Protokoll nutzen werden.

robbitop

2019-01-21, 15:35:38

so groß ist der Abstand zw. IO-Chip und CPU-Chiplet beim Ryzen 3000 auch nicht. Ich komme, mit dem Bild von anandtech auf einen Abstand von 3,67mm.

https://images.anandtech.com/doci/13829/cpu33.jpg
Im Chip ist es nur ein Bruchteil. Auch kostet jedes Signal aus dem Chip heraus mehr Energie. Schon sind Taktrate und Latenz ganz andere. Man schaue sich mal die Intercore Latenz von Epyc/Threadripper an und vergleiche sie mit InterCCX innerhalb eines Cores.

Oder auch die erhöhte Memorylatency von Intels Clarkdale an. Da ist eine ähnliche Konstellation vorhanden.

Den MC in die CPU zu integrieren hatte aus Latenzgründen schon ihre Vorteile.
Man kann nicht alles haben. AMD will die Chiplets um mit wenigen Masken alle Märkte bedienen zu können und muss mit den Nachteilen so gut es geht leben bzw diese technisch kaschieren.

Cross-Flow

2019-01-21, 15:39:09

mboeller

2019-01-21, 16:16:29

Clarkdale war der i3 auf LGA 1156?

Gibt es da aktuelle Messungen zu oder war das damals noch kein Thema?

Würde Interessant sein wenn jemand so ne Hardware mal raus kramt und sich damit mal eben beschäftigt.

1min google, 1min lesen:

https://www.anandtech.com/show/2901/2

der Unterschied zum Ryzen 1xxx ist nicht so groß

amdfanuwe

2019-01-21, 16:26:01

AMD will die Chiplets um mit wenigen Masken alle Märkte bedienen zu können und muss mit den Nachteilen so gut es geht leben bzw diese technisch kaschieren.
AMD braucht die Chiplets auch um die Kosten für leistungsfähige Systeme gering zu halten. Wie willste denn 64 ZEN Cores monolitisch unterbringen? Auf einem 900mm² Chip? Yield läßt grüßen.
Technik ist halt immer ein Kompromiss.

S940

2019-01-21, 16:36:36

Kann mir ehrlich gesagt kaum vorstellen, dass das nicht Latenz kostet. Ggf. wiegt die Verbesserung am Interface aber den Nachteil des höheren Signalweges wieder auf. Eine deutliche Verbesserung ist hier schwer vorstellbar.
Ja Besserungen wirds wohl kaum geben, aber möglicherweise bleibt es gleich. Im Endeffekt hängt es doch in erster Linie vom XBar-Takt ab. Der war bei Zen1 aber schon - ziemlich schlecht - identisch mit dem Speichertakt.

1600 MHz bei DDR4-3200 sind ondie für den L3 & Co. nun wirklich nicht der Hit, da wäre sicher mehr drin gewesen. Da das komplette Zen-Programm aber eines aus einem Guss ist, macht das Ganze mit dem Chiplet-Design wieder Sinn, denn 1600 MHz schafft man damit sicher auch noch.

Memory-OC könnte aber schwieriger werden, das dürfte der einzige Nachteil sein.

unl34shed

2019-01-21, 16:43:20

L3 läuft bei Zen doch mit dem Kerntakt. Nur das IF und Memorycontroller laufen mit RAM-Takt.

https://i1.wp.com/thetechaltar.com/wp-content/uploads/2017/03/C6eUL0DWAAAeCQG.jpg?ssl=1

fondness

2019-01-21, 16:43:22

AMD will die Chiplets um mit wenigen Masken alle Märkte bedienen zu können und muss mit den Nachteilen so gut es geht leben bzw diese technisch kaschieren.

Es braucht drei unterschiedliche Chips/Masken für EPYC und Ryzen Desktop (2 I/O Dies und ein Chiplet-Die). Dazu noch Minimum eine für die APU. Ich sehe hier also keine Einsparung der Masken ggü. einem monolithischem Design. Dass das Chiplet-Design natürlich viele andere Vorteile hat steht außer Frage.

Dino-Fossil

2019-01-21, 16:47:46

Eine Einsparung ist vermutlich dadurch gegeben, dass zwei 14/12nm I/O-Dies + ein 7nm Chiplett günstiger zu designen sein dürfte als zwei größere 7nm Dies, von der Fertigung ganz zu schweigen (Ausbeute).

Complicated

2019-01-21, 17:54:00

Hast Du mal einen Link?
Außerdem haben wir bei Epyc 8x8C Chiplets und by Ryzen3000 1-2x8C Chiplets.
Hab ihn raus gesucht:
https://www.planet3dnow.de/vbulletin/threads/422600-AMD-Interposer-Strategie-Zen-Fiji-HBM-und-Logic-ICs?p=5117402&viewfull=1#post5117402

http://www.planet3dnow.de/vbulletin/attachment.php?attachmentid=34744&d=1474815067
Zusätzlich mit Kostenbetrachtung bei unterschiedlichen Defektraten.

basix

2019-01-21, 18:14:33

Studien zeigen eine gestiegene Latenz von ca. 20% von einem 64-Core monolithischen Chip zu einem 16x4-Core Chiplet-Design.
Also im Grundsatz ohne zusätzliche Technik das abzufedern.
Hast Du mal einen Link?
Außerdem haben wir bei Epyc 8x8C Chiplets und by Ryzen3000 1-2x8C Chiplets.

Er meint wohl folgendes Paper (lohnt sich zu lesen):
http://www.eecg.toronto.edu/~enright/Kannan_MICRO48.pdf --> Figure 4 zeigt die durchschnittliche Latenz auf.

Das hier ist die Vorgängerarbeit (ebenfalls interessant):
http://www.eecg.toronto.edu/~enright/micro14-interposer.pdf

Edit:
Ach jetzt war er schneller :)

Gipsel

2019-01-21, 18:19:30

Hab ihn raus gesucht:
https://www.planet3dnow.de/vbulletin/threads/422600-AMD-Interposer-Strategie-Zen-Fiji-HBM-und-Logic-ICs?p=5117402&viewfull=1#post5117402

http://www.planet3dnow.de/vbulletin/attachment.php?attachmentid=34744&d=1474815067
Zusätzlich mit Kostenbetrachtung bei unterschiedlichen Defektraten.
Und auch noch der Betrachtung der höheren Compute-Performance (Latenzen sind auch nicht Alles) des Chiplet-Designs (durch besseres, feingranulareres Binning):

https://abload.de/img/chiplet-taktep1jo9.png

Der Median liegt grob bei 25% höherer Frequenz, das obere 5% Percentil gar bei >30% höherer Frequenz.

Und die schlechtere Latenz in der Grafik trifft nur auf den simpelsten Fall eines 2D-Meshes zu (praktisch die schlechteste untersuchte Variante). Weiter hinten finden sich optimierte Netzwerkstrukturen, die das Bild ziemlich auf den Kopf stellen ;). *)

https://abload.de/img/mesh-latenzenb2jws.png
Das normale 2D-Mesh aus der von Dir geposteten Grafik ist die dünne schwarze Kurve im Diagramm (a). Wie man sieht, ist der Verlauf der anderen Layouts deutlich anders (allgemein niedrigere Latenzen und zusätzlich sinkt die Latenz gar mit Chiplets statt dem monolithischem Die [wobei ich nicht weiß, wie die das in dem Modell hinbekommen haben, aber grob konstante Latenzen wären wohl machbar]).

Achja, all das bezieht sich übrigens auf (aktive) Interposer-Verbindungen mit 1GHz Takt. Nicht ganz das, was wir bei Epyc2 bzw. Ryzen3000 sehen werden.

*):
Der normale Mesh verbindet übrigens jeden Core miteinander. Dies steht ja gar nicht zur Wahl. Besser als Baseline wäre der "CMesh" genannte concentrated Mesh, bei dem jeweils 4 Kerne (1 CCX!) sich einen Netzwerkport teilen.
Und im Prinzip passen alle dort untersuchten Topologien nicht zu Zen2. Hier stellt der IO-Die den zentralen Switch dar (wie auch immer der intern verdrahtet ist), jedes Chiplet hat nur genau einen Link zum IO-Die. Das Ganze ist also genau genommen überhaupt gar kein Mesh (oder maximal ein degeneriertes).

S940

2019-01-21, 18:26:30

L3 läuft bei Zen doch mit dem Kerntakt. Nur das IF und Memorycontroller laufen mit RAM-Takt.

https://i1.wp.com/thetechaltar.com/wp-content/uploads/2017/03/C6eUL0DWAAAeCQG.jpg?ssl=1

Ach ja, der L3 war noch dabei. Ist in dem Fall aber auch egal, es ging ja nur um den Fabric-Anschluss. Der war schön gemächlich und das eben vermutlich wg. der schon im Hintergrund eingeplanten Chiplet-Strategie.

basix

2019-01-21, 18:32:43

@Gipsel / Complicated:
Die Meshes sind alle ohne zentrales I/O Die gedacht. Beim Paper sind auf einem (aktiven) Interposer mehrere Netzwerk-Nodes eingefügt, welche den Traffic weiterleiten. Durch den I/O Die ändert sich das Netzwerk natürlich drastisch. Ich bin eher skeptisch, dass man die Zahlen zu den Latenzen für Zen 2 verwerten kann. Die Zahlen zum Binning schon eher.

Gipsel

2019-01-21, 18:42:44

Complicated

2019-01-21, 18:56:17

Gipsel

2019-01-21, 19:01:27

Natürlich kanm man das nicht für Zen 1:1 annehmen. Ich schrieb ja es ist eine grobe Betrachtung ohne berücksichtigung von Optimierungen und Implementierung. Es zeigt aber mal die Grössenordnung.Und wie gezeigt, kann sich bei der optimalen Implementierung sogar der Trend umkehren (Chiplets haben niedrigere Latenz als monolithischer Die). Wir lernen also nicht viel.
@Gipsel
Die 3 Linien in der Grafik sind Kostenunterschiede bei Defektraten. Siehe Untertitelung der Grafik.Ja und? Das ist mir erstens klar und zweitens ändert das an dem von mir Geschriebenen herzlich wenig.
Ich meinte die Latenz-Kurve (in Deiner Grafik grün, in meiner dritten zweiten Grafik dünn schwarz [das sind laut Paper die gleichen, nur eine ist normiert, die andere mit absoluten Werten]).

Complicated

2019-01-21, 19:16:07

Und auch noch der Betrachtung der höheren Compute-Performance (Latenzen sind auch nicht Alles) des Chiplet-Designs (durch besseres, feingranulareres Binning):

Ich hatte wohl missinterpretiert, dass sich der Satz auf die von mir zitierte Grafik bezog, da er darunter stand. Daher mein erneuter Hinweis.

Sehr interessant fand ich übrigens diese Tabelle:
http://www.planet3dnow.de/vbulletin/attachment.php?attachmentid=34743&d=1474814569

robbitop

2019-01-21, 19:51:10

AMD braucht die Chiplets auch um die Kosten für leistungsfähige Systeme gering zu halten. Wie willste denn 64 ZEN Cores monolitisch unterbringen? Auf einem 900mm² Chip? Yield läßt grüßen.
Technik ist halt immer ein Kompromiss.
So ist es. Die Kernaussage ist, dass man nicht alles haben kann. Dass es dafür mehr als einen (exemplarisch genannten) Grund gibt, sollte bekannt sein.

Es braucht drei unterschiedliche Chips/Masken für EPYC und Ryzen Desktop (2 I/O Dies und ein Chiplet-Die). Dazu noch Minimum eine für die APU. Ich sehe hier also keine Einsparung der Masken ggü. einem monolithischem Design. Dass das Chiplet-Design natürlich viele andere Vorteile hat steht außer Frage.

7 nm ist aber knapper von der Fertigungskapazität (nur 1x Design heisst nur eine Linie) und die Masken / Tools sind sicher teurer. Yield ist bei kleinen Chiplets sicherlich das Hauptargument. Ändert an der Kernaussage, dass man nicht alles haben kann nichts.

Complicated

2019-01-21, 20:08:07

Die IO Dies sind keine 7nm. Alleine diese Fläche auf 14nm anstatt 7nm unterzubringen spart reichlich 7nm-Wafer. Das muss bei monolithischen Dies sowohl bei den Designkosten als auch Waferfläche mit gerechnet werden.

basix

2019-01-21, 20:13:12

Sehr interessant fand ich übrigens diese Tabelle:

Interessant auf jeden Fall. Was ich erstaunlich fand ist, dass man auch bei hohen Defektraten und grossen Interposern (864mm2 im Beispiel) noch gut über 90% Yield erhält, solange die aktive Fläche nicht zu gross wird. Bei 864mm2 sind 15% schon 130mm2 und somit die Grösse des Ryzen 3000 I/O Die ;)

Zossel

2019-01-21, 20:16:51

so groß ist der Abstand zw. IO-Chip und CPU-Chiplet beim Ryzen 3000 auch nicht. Ich komme, mit dem Bild von anandtech auf einen Abstand von 3,67mm.

3,6mm Leitungslänge schafft es auch locker auf einem Die, dafür braucht es keine Chiplets.

robbitop

2019-01-21, 20:31:44

basix

2019-01-21, 20:37:03

3,6mm Leitungslänge schafft es auch locker auf einem Die, dafür braucht es keine Chiplets.

Die ganzen Leitungslängen könnt ihr bezüglich Latenz eh vernachlässigen. Die Ausbreitungsgeschwindigkeit eines elektrischen Signals in Kupfer ist ca. 2/3*c und somit 20cm pro Nanosekunde. Da sind die 3.6mm relativ irrelevant. Es ist eher die zusätzliche Kontrolllogik, Buffer usw. der Interfaces, welche Latenz hinzufügen. Umso weniger Logik, desto weniger Latenz.

Zossel

2019-01-21, 20:45:07

Die ganzen Leitungslängen könnt ihr bezüglich Latenz eh vernachlässigen. Die Ausbreitungsgeschwindigkeit eines elektrischen Signals in Kupfer ist ca. 2/3*c und somit 20cm pro Nanosekunde. Da sind die 3.6mm relativ irrelevant. Es ist eher die zusätzliche Kontrolllogik, Buffer usw. der Interfaces, welche Latenz hinzufügen. Umso weniger Logik, desto weniger Latenz.

Braucht es den aufwendige PHYs oder gar Schutzdioden für die Verbindung von Chiplets?
Mehr Leitungslänge bringt allerdings immer auch mehr parasitäre Induktivitäten und Kapazitäten mit, komplett irrelevant ist die Länge als nicht.

Complicated

2019-01-21, 21:32:59

AMD hier mit Synopsys etwas eigenes im Custom-Desing entwickelt.
https://www.synopsys.com/dw/doc.php/ss/amd_ss.pdf

basix

2019-01-21, 22:46:40

Braucht es den aufwendige PHYs oder gar Schutzdioden für die Verbindung von Chiplets?
Mehr Leitungslänge bringt allerdings immer auch mehr parasitäre Induktivitäten und Kapazitäten mit, komplett irrelevant ist die Länge als nicht.

Irrelevant für die Latenz / Signallaufzeit von Pad zu Pad. Für andere Dinge wie Stromverbrauch, maximale Taktfrequenz usw. ist es definitiv relevant (siehe deine Auflistung). In dieser Hinsicht sind eigentlich alle Off-Chip Verbindungen internen Verbindungen unterlegen. Die PHYs sind bei MCM sicher anspruchsloser als wenn es aus dem Sockel raus muss. Wie gross der effektive Unterschied ist, kann ich dir aber nicht sagen.

Ich muss mich aber ein wenig korrigieren bezüglich realer Latenz für Anwendungen. Umso mehr Buffering man betreiben muss (weiss nicht in welcher Grössenordnung das effektiv so ist), desto nehr kann die Distanz ins Gewicht fallen.

Beispiel Off-Chip Verbindung mit 1.0GHz bei den genannten 3.6mm Leitungslänge:
- Wellenlänge = 20cm
- Signallaufzeit = 18ps --> Jedes Bit braucht so lange, bis es beim anderen Pad ankommt
- Solange also das Buffering nicht allzu gross ausfällt, absolut unkritisch
- Problem Buffering: Bevor das Ziel etwas mit den Daten machen kann, müssen z.B. 256 Bit angekommen sein, vielleicht ein AVX Datenpaket. Macht also 4.61ns für das ganze Paket, bis es durch die Leitung durch ist.
- Sind es mehrere Datenpakete etc. summiert sich das schnell
- Das kann man mit parallellen Verbindungen abschwächen. Bei Off-Chip aber begrenzte Breite der Datenpfade, da eben stark erhöhter Stromverbrauch verglichen mit On-Chip Verbindungen.

Setsul

2019-01-21, 22:51:25

Das Paper sagt relativ wenig über Zen 2 aus.

Die verglichenen Designs sind alle auf Interposer mit dem gleichen Weg zum HBM und bis auf Mesh alles CCX-ähnliche Cluster. Die 50% memory traffic werden keine großartig andere Latenz haben, egal ob monolithisch oder nicht. Je nach Topologie wird einfach in der Mitte die Bandbreite generell knapp.
Normales Mesh wie SKL wird besser je weniger Chips es sind.

Solange Zen 2 kein HBM und Interposer benutzt und Intel monolithisch ohne HBM und ohne Interposer mit einem Mesh offensichtlich bessere Latenzen bekommt als AMD bei Zen 1 mit Concentrated Mesh und 4 Dies, obwohl das Paper das Gegenteil vorhersagt, sind die Ergebnisse einfach nicht 1:1 übertragbar.

Gipsel

2019-01-22, 01:38:53

Beispiel Off-Chip Verbindung mit 1.0GHz bei den genannten 3.6mm Leitungslänge:
- Wellenlänge = 20cm
- Signallaufzeit = 18ps --> Jedes Bit braucht so lange, bis es beim anderen Pad ankommt
- Solange also das Buffering nicht allzu gross ausfällt, absolut unkritisch
- Problem Buffering: Bevor das Ziel etwas mit den Daten machen kann, müssen z.B. 256 Bit angekommen sein, vielleicht ein AVX Datenpaket. Macht also 4.61ns für das ganze Paket, bis es durch die Leitung durch ist.
:confused:
Was? Nee!
Die 18ps reine Signallaufzeit ist nicht die Zeit, die die Übertragung von einem Bit benötigt. 256 Bit über die eine Leitung benötigen also nicht 256*18ps=4,6ns sondern 256Bit*1ns=256ns (falls SDR Signaling und die 1GHz Takt 1GT/s bedeutet), falls irgendwer wirklich einen 1Bit-Link verbaut (wie z.B. PCIe x1 einer ist), was man für CPU-Interconnects sicher nicht machen wird.
Ansonsten, die bisherigen IFOP-Links sind 32Bit breit (Kombination aus zwei unidirektionalen 32Bit-Links).

amdfanuwe

2019-01-22, 03:44:57

Seh ich das richtig:
Ein RAM Kanal hat 64bit. Für die Übertragung einer Cache Line von 64 Byte braucht der RAM also 8 Takte.
Der IFOP überträgt 32 Bit pro Takt, braucht dann also 16 Takte für die Daten, also 8 Takte länger als das RAM.
Diese 8 Takte machen bei 3200er RAM ca. 2,5ns aus. Wahrscheinlich hängt noch ein FIFO dazwischen und verzögert nochmal um einen Takt, dann sind es ca. 2,8ns zusätzliche Latenz durch den IFOP.

Richtig übel wird es natürlich, wenn viele Kerne mit schlecht lokalisiertem Code und Daten gefüttert werden und dauernd neue Adressen ans RAM angelegt werden müssen. Vom Anlegen der Adressen bis der RAM die ersten Daten liefert dauert es schließlich auch 20 - 25 ns.

Windi

2019-01-22, 06:48:29

Es braucht drei unterschiedliche Chips/Masken für EPYC und Ryzen Desktop (2 I/O Dies und ein Chiplet-Die). Dazu noch Minimum eine für die APU. Ich sehe hier also keine Einsparung der Masken ggü. einem monolithischem Design. Dass das Chiplet-Design natürlich viele andere Vorteile hat steht außer Frage.
Wenn man alles Monolitich haben will, braucht man aber noch viel mehr Masken.
Zum einen sind die beiden I/O Chips nur in 14nm, zum anderen brauchen nicht alle Menschen solch gigantische Chips, wie sie nun bei AMD möglich werden.
Nicht jeder braucht am Desktop 16 Kerne, da bräuchte man dann zwei unterschiedliche Masken, einmal mit 8 und einmal mit 16 Kernen.
Das Gleiche gilt für den Server/Workstation-Bereich. Mindestens 2 Masken mit 32 und 64 Kernen.
Für die APUs kann ich mir mittlererweile auch die Chipletvariante gut vorstellen. Bei einer Version die nur den normalen DDR Speicher verwendet, reicht sicherlich ein GPU-Chiplet das nicht größer als das CPU-Chiplet ist. Natürlich hat das Nachteile beim Stromverbrauch, aber dafür hat man die Chiplet-Vorteile. Und zum anderen wird AMD kaum in höherwertigen Notebooks verbaut. Das ist Schade aber leider Relaität.

AMD kann nun mit 4 Chips alle Märkte bedienen. Davon sind 2 allerdings im günstigeren 14nm Prozess und die 2 anderen sehr klein.
Auch kann AMD zukünftig ihre Prozessoren in achter Schritten selbst "zusammen kleben", ohne das sie neue Masken brauchen. Für einen EPYC 16 Kerner einen 64 Kerner zu nehmen und dann 3/4 zu deaktivieren wäre eine Katastrophe.

Weitere Vorteile gibt es dann noch, wenn auch ein Konsolenhersteller die Chiplets verwenden möchte. Da gibt es neben den Konsolen von MS/Sony ja auch noch die Subor Z aus China. Sinn würde es machen, da die Konsolenhersteller immer auf die Kosten achten und die Standard-Chiplets wohl die günstigste Lösung wären.

Auch wird manch eine exotische Lösungen erst durch die Chiplets möglich.
Man könnte z.B. einen EPYC mit 4 CPU-Chiplets und 4 GPU-Chiplets bringen. Vieleicht hat ja irgend jemand Verwendung für so etwas? Aber für solch einen (noch nicht entwickelten) Markt eine eigene Maske zu fertigen wäre wirtschaftlich völlig durchgeknallt.

HOT

2019-01-22, 07:28:54

Das mit den APUs hat sich ja erledigt, das ist dementiert worden. Renoir ist also tatsächlich eine eigene Maske.

Windi

2019-01-22, 07:39:23

Es wurde doch nur gesagt, das es bei Ryzen 3000 keine APU mit Chiplet geben wird, oder? (Picasso)

Renoir kommt doch 2020 und heißt dann Ryzen 4000.
Oder habe ich was verpasst? Kann auch sein.

HOT

2019-01-22, 08:08:28

Es wurde doch nur gesagt, das es bei Ryzen 3000 keine APU mit Chiplet geben wird, oder? (Picasso)

Renoir kommt doch 2020 und heißt dann Ryzen 4000.
Oder habe ich was verpasst? Kann auch sein.
Es gibt keine Chiplet APU weil die dafür keinen Markt sehen, das wurde im Dementi deutlich. Renoir ist einfach billiger als monolithischer Chip und auch das Powermanagement wird deutlich einfacher sein. Das I/O-Die wird auch keine Videobestandteile haben.

Windi

2019-01-22, 08:42:31

Es gibt keine Chiplet APU weil die dafür keinen Markt sehen, das wurde im Dementi deutlich. Renoir ist einfach billiger als monolithischer Chip und auch das Powermanagement wird deutlich einfacher sein. Das I/O-Die wird auch keine Videobestandteile haben.
Ich habe nichts gegen eine monolithiche APU. Ich habe nur noch nichts darüber gelesen, das es in Zukunft auch so bleiben wird.
Das man momentan Raven Ridge und Picasso über alles lobt ist natürlich verständlich. Schließlich ist das die APU für die nächsten ein bis anderthalb Jahre.

edit:
https://www.anandtech.com/show/13852/amd-no-chiplet-apu-variant-on-matisse-cpu-tdp-range-same-as-ryzen2000
AMD stated that, at this time, there will be no version of the current Matisse chiplet layout where one of those chiplets will be graphics. We were told that there will be Zen 2 processors with integrated graphics, presumably coming out much later after the desktop processors, but built in a different design. Ultimately APUs are both mobile first as well as lower cost parts (usually), so different design decisions will have to be made in order to support that market.
This doesn't rule out a future processor using chiplet graphics, this is just for Matisse.

Ok, das hört sich natürlich schon so an, das es bei Renoir noch das monolithische Design sein wird. Wie genau es aussieht, weiß man aber auch nicht.
Und Renoir gehört ja eigentlich eher zur Vermeer Generation und nicht zu Matisse.

HOT

2019-01-22, 08:55:30

Ich habe nichts gegen eine monolithiche APU. Ich habe nur noch nichts darüber gelesen, das es in Zukunft auch so bleiben wird.
Das man momentan Raven Ridge und Picasso über alles lobt ist natürlich verständlich. Schließlich ist das die APU für die nächsten ein bis anderthalb Jahre.

Vielleicht gibts ja mit DDR5 ne Chiplet APU in 2 Jahren oder so.

basix

2019-01-22, 09:07:51

:confused:
Was? Nee!

1 Bit Links macht sicher niemand. Zum Rest: war wohl zu spät gestern ^^

amdfanuwe

2019-01-22, 09:45:08

Bei der Diskussion zum Chipportfolio sollte man nicht vergessen, dass AMD die letzten Jahre finanziell eingeschränkt war und nicht mit dem großem Marktanteil gerechnet hat der sich nun durch Intels Durchhänger ergeben hat.
Nun hat AMD wieder mehr finanziellen Spielraum und Stückzahlen, dass es sich durchaus lohnt eigenständige Designs aufzulegen.
Ich könnte mir durchaus vorstellen, dass sie noch ein 14 nm I/O mit 11 CU Vega GPU auflegen für 8 - 16 Kern APUs.
Vielleicht hat aber Picasso schon einen IF Link mitbekommen und kann zu einer 8 Core APU erweitert werden.
Wenn sie für die EPYC 3000 Serie Nachfolger bringen wollen, bräuchten sie für die 12/16 Kerner mit 64PCIe Lanes und 4 Speichekanälen eine eigenes I/O, der Salvage I/O von ROME wäre dafür zu groß. Idealerweise passte so ein 200mm² I/O dann auch für Threadripper 3000.

In 7nm erscheint mir eine monolitische APU 4C 11CU als Nachfolger von RavenRidge für embedded und als Low End APU sinnvoll.
Könnte mir aber auch zusätzlich eine BIG APU mit 8 Core 20 CU und HBM Anbindung vorstellen.

AMD hat viele Möglichkeiten und wird sich genau ausrechnen welches Design lohnt.

HOT

2019-01-22, 10:14:47

Wenn da gibts einen neuen I/O-Chip wenn DDR5 kommt, der auch für Grafik vorbereitet ist. Ich sehe das jedoch nicht vorher, macht einfach keinen Sinn. Wie du sagst war AMD bisher eingeschränkt, man wird sich auf das konzentriert haben, was sich wirklich verkauft. Und das sind CPUs im Leistungsmarkt und APUs für Mobil-/Billigmarkt.

Windi

2019-01-22, 10:33:14

Vielleicht hat aber Picasso schon einen IF Link mitbekommen und kann zu einer 8 Core APU erweitert werden.
Daran glaube ich nicht, dann würde man ja 4 Zen+ 14nm Kerne mit 8 Zen2 7nm Kerne kombinieren. Außerdem hätten die Kerne dann deutlich unterschiedliche Latenzen zum Speicher.

Wenn sie für die EPYC 3000 Serie Nachfolger bringen wollen, bräuchten sie für die 12/16 Kerner mit 64PCIe Lanes und 4 Speichekanälen eine eigenes I/O, der Salvage I/O von ROME wäre dafür zu groß. Idealerweise passte so ein 200mm² I/O dann auch für Threadripper 3000.
Bei EPIC hat man ja eine deutlich höhere Marge, da wäre das wohl nicht so schlimm. Natürlich ist beides möglich.
AMD ist momentan auch bereit eine riesige Fläche des Raven Ridge zu deaktivieren, nur um ihn dann als 50€ Athlon zu verkaufen.
In 7nm erscheint mir eine monolitische APU 4C 11CU als Nachfolger von RavenRidge für embedded und als Low End APU sinnvoll.
Könnte mir aber auch zusätzlich eine BIG APU mit 8 Core 20 CU und HBM Anbindung vorstellen.

AMD hat viele Möglichkeiten und wird sich genau ausrechnen welches Design lohnt.
Ich mache mir nur Sorgen wegen dem großen I/O Anteil. Anscheinend kann man den nicht so problemlos schrumpfen. Aus 120mm² werden wohl nicht so leicht 60mm². Wenn die Wahrheit in der Mitte liegt, dann wären wir bei ungefähr 90mm², das ist dann schon ein ganz schöner Brocken.
AMD könnte auch einen Chip aus CPU + GPU + Speicherkontroller in 7nm designen. Der ganze Rest wie PCIe, USB und SATA könnte dann weiterhin auf einen Extra Chip ausgelagert werden. Man könnte das I/O DIE auch noch etwas erweitern, so das man im Notebook keinen weiteren Chipsatz mehr benötigt. (mehr USB, GbitLan, WLAN)

Aber ja, AMD hat wirklich viele Möglichkeiten bei den nächsten APUs.

SKYNET

2019-01-22, 10:45:31

Man könnte das I/O DIE auch noch etwas erweitern, so das man im Notebook keinen weiteren Chipsatz mehr benötigt. (mehr USB, GbitLan, WLAN)

hat das amd nicht schon jezt? mir war so... :wink:

https://www.amd.com/de/products/embedded-ryzen-v1000-series

amdfanuwe

2019-01-22, 10:56:08

Daran glaube ich nicht, dann würde man ja 4 Zen+ 14nm Kerne mit 8 Zen2 7nm Kerne kombinieren. Außerdem hätten die Kerne dann deutlich unterschiedliche Latenzen zum Speicher.
...

Aber ja, AMD hat wirklich viele Möglichkeiten bei den nächsten APUs.
Dachte eher, die ZEN+ Kerne zu deaktivieren bzw. salvaged Chips zu verwenden mit defekten ZEN+ Cores. Die 8 7nm Cores sollten vom Verbrauch her nicht schlechter sein als die 4 ZEN+ Cores. Damit hätte man dann eben 8 Kerne bei gleichem Verbrauch.
Wenn die Nachfrage nicht zu groß ist, könnte AMD damit einige ohne großen Aufwand glücklich machen.

OK, AMD will Kohle verdienen. Die gehen auch mit Spaß an die Arbeit, sonst gäbe es wohl keinen Threadripper. Letztendlich zählen Gewinn, ob finanziell, Image oder Marktanteile.

Windi

2019-01-22, 11:12:57

hat das amd nicht schon jezt? mir war so... :wink:

https://www.amd.com/de/products/embedded-ryzen-v1000-series
Ist das ein eigenständiger Chip? :eek:
Oder wird der Raven Ridge dort im Package irgendwie erweitert?
Habe ich gar nicht mitbekommen.

Enhanced I/O (FP5)
• Up to 4x USB 3.1 (10Gb/s) / 2 Type-C with ALT. DP power delivery capable
• 1x USB 3.1 (5Gb/s)
• 1x USB 2.0
• 2x 10 Gigabit Ethernet :freak:
• eMMC5.0, SD3, or LPC
• 2x UART, 4x I2C, 2x SMBus, SPI/eSPI, I2S/HDA/SW, GPIO

Setsul

2019-01-22, 11:17:40

Seh ich das richtig:
Ein RAM Kanal hat 64bit. Für die Übertragung einer Cache Line von 64 Byte braucht der RAM also 8 Takte.
Der IFOP überträgt 32 Bit pro Takt, braucht dann also 16 Takte für die Daten, also 8 Takte länger als das RAM.
Diese 8 Takte machen bei 3200er RAM ca. 2,5ns aus. Wahrscheinlich hängt noch ein FIFO dazwischen und verzögert nochmal um einen Takt, dann sind es ca. 2,8ns zusätzliche Latenz durch den IFOP.
CAKE nimmt jeden Takt ein 128 bit Paket, IFOP schiebt dann pro Takt 4x 32b und IFIS 8x 16b in die Leitung. Sonst würde es auch von der Bandbreite nicht reichen.
SDF/CAKE nimmt also 1x128b pro Takt, DDR4 2x64b pro Takt, deshalb eben der gleiche Takt für beide, dann funktioniert das auch.

Ganz so einfach ist das alles nicht, ich nehme an dass das SDF nur ganze Pakete überträgt, also muss der RAM erstmal 2 Takte übertragen bevor der Memory Controller überhaupt ein Paket schnüren kann, dass er ins SDF werfen kann.

SKYNET

2019-01-22, 11:52:18

Ist das ein eigenständiger Chip? :eek:
Oder wird der Raven Ridge dort im Package irgendwie erweitert?
Habe ich gar nicht mitbekommen.

halt so verlöt zeugs für kleine, flache notebooks, tablets usw. auch mobile spielekonsolen verbauen das ding...

https://www.notebookcheck.net/Smach-Z-handheld-gaming-PC-to-integrate-AMD-s-Ryzen-V1000-embedded-CPU.285008.0.html

amdfanuwe

2019-01-22, 12:03:39

CAKE nimmt jeden Takt ein 128 bit Paket, IFOP schiebt dann pro Takt 4x 32b und IFIS 8x 16b in die Leitung. Sonst würde es auch von der Bandbreite nicht reichen.
SDF/CAKE nimmt also 1x128b pro Takt, DDR4 2x64b pro Takt, deshalb eben der gleiche Takt für beide, dann funktioniert das auch.

Ganz so einfach ist das alles nicht, ich nehme an dass das SDF nur ganze Pakete überträgt, also muss der RAM erstmal 2 Takte übertragen bevor der Memory Controller überhaupt ein Paket schnüren kann, dass er ins SDF werfen kann.
Ich denke, jetzt gerätst du mit BaseTakt und Datentakt durcheinander.
Base Takt für DDR 4 ist 400MHz. Datentakt 1600MHz, Double Data Rate entspricht Übertragung bei steigender und fallender Flanke. Ergibt 3200 MHz effektive Burst Datenrate mit 64 Bit Datenbreite. Wird mit Dual Channel interleaved gearbeitet, kommen sogar 128 Bit mit der Datenrate an.
IFOP arbeitet auch mit Quad DDR, hat also dieselbe Datenrate, jedoch nur 32 Bit Datenbreite.

Windi

2019-01-22, 12:05:54

halt so verlöt zeugs für kleine, flache notebooks, tablets usw. auch mobile spielekonsolen verbauen das ding...

https://www.notebookcheck.net/Smach-Z-handheld-gaming-PC-to-integrate-AMD-s-Ryzen-V1000-embedded-CPU.285008.0.html
ja, aber wie wurde das Teil realisiert?

Raven Ridge und ein extra Chip im selben Package?
Und wie wurden die verbunden? PCIe, IF, ....

Die werden dafür doch nicht extra einen eigenen Chip aufgelegt haben?

Complicated

2019-01-22, 12:08:10

Hier ein aktuelles Produkt mit V1000 Varianten:
https://www.google.com/url?sa=i&source=web&cd=&ved=2ahUKEwj0ifLHn4HgAhWJmbQKHdkRAWwQzPwBegQIARAC&url=https%3A%2F%2Fwww.heise.de%2Fnewsticker%2Fmeldung%2FMini-PC-Mainboard-kombiniert-AMD-Ryzen-mit-Arduino-4085058.html&psig=AOvVaw3_Mda7VVqR6C1yCJUTiLuL&ust=1548241603922664

amdfanuwe

2019-01-22, 12:20:59

Ist das ein eigenständiger Chip? :eek:
Oder wird der Raven Ridge dort im Package irgendwie erweitert?
Habe ich gar nicht mitbekommen.
Ist nur RR. Auf AM4 wird nur nicht alles rausgeleitet.
AM4 hat ja auch die Beschränkung auf 24 PCIe Lanes. In Embedded, bei Threadripper und EPYC liefert der Zeppelin Chip 32 PCIe Lanes.

mboeller

2019-01-22, 12:39:20

Ist das ein eigenständiger Chip? :eek:
Oder wird der Raven Ridge dort im Package irgendwie erweitert?
Habe ich gar nicht mitbekommen.

Ryzen ist ja ein SoC:

https://rog.asus.com/media/14878984098.gif

Windi

2019-01-22, 13:21:52

Ich verstehe nicht was ihr meint??!???

Raven Ridge wird doch wohl nicht von Anfang an 2x 10 Gigabit Ethernet integriert gehabt haben, um es dann die ganze Zeit brach liegen zu lassen.
Dazu gibt es dann noch 2x USB und weiteren Kleinkram.

Einen Extra Chipsatz sehe ich auch nicht auf den Bildern und ich kenne auch keinen mit 2x 10 Gigabit Ethernet.

Da muss es doch einen weiteren AMD Embedded Chipsatz geben.
Und ich bin nur zu blöd den zu erkennen.

Setsul

2019-01-22, 13:36:40

Ich denke, jetzt gerätst du mit BaseTakt und Datentakt durcheinander.
Base Takt für DDR 4 ist 400MHz. Datentakt 1600MHz, Double Data Rate entspricht Übertragung bei steigender und fallender Flanke. Ergibt 3200 MHz effektive Burst Datenrate mit 64 Bit Datenbreite. Wird mit Dual Channel interleaved gearbeitet, kommen sogar 128 Bit mit der Datenrate an.
IFOP arbeitet auch mit Quad DDR, hat also dieselbe Datenrate, jedoch nur 32 Bit Datenbreite.
Nein, das ist jetzt völliger Schwachsinn.
DDR4 hat nicht generell 400 MHz.
Die 400 MHz sind memory clock, kein "Base Takt". SDF/CAKE sehen die nie und es ist völlig egal, das ist genauso wie ranks und banks, das ist außerhalb des IMC irrelevant.
I/O clock ist richtig, aber es gibt keine "Datentakt" weil es kein Takt ist. Das ist eine Übertragungsrate von 3200 MT/s.
Dual Channel ist erstmal außen vor, du hast von einem Kanal gesprochen also hab ich auch mit einem Kanal gerechnet.
Quad DDR existiert nicht. Es gibt Single Data Rate, Double Data Rate und Quad Data aber nicht Quad Double Data Rate.

Der Punkt ist diese Rechnung
Seh ich das richtig:
Ein RAM Kanal hat 64bit. Für die Übertragung einer Cache Line von 64 Byte braucht der RAM also 8 Takte.
Der IFOP überträgt 32 Bit pro Takt, braucht dann also 16 Takte für die Daten, also 8 Takte länger als das RAM.
ist völlig falsch.
Entweder rechnest du mit IF/IO-clock, dann braucht der RAM mit einem Kanal aber nicht 8 Takte für 64 Byte sondern nur 4, oder du rechnest mit dem nicht existenten "Datentakt", dann kannst du aber nicht die Takte von IFOP und RAM direkt vergleichen weil sie nicht die gleiche Taktrate haben.
Egal mit welchem Takt du rechnest IFOP überträgt nicht 32 Bit pro Takt sondern 128 bit pro IF/IO-Takt. Außer du willst mit der Datenrate rechnen, die ist dann aber vier mal so hoch, also doppelt so hoch wie die vom RAM also kannst du die Takte wieder nicht 1:1 gegeneinander aufrechnen.
Die Rechnung stimmt einfach hinten und vorne nicht.

BoMbY

2019-01-22, 13:38:05

Der Designware Enterprise 12G PHY lässt sich für alles mögliche verwenden:

https://i.imgur.com/TEE1gv0.jpg

amdfanuwe

2019-01-22, 13:45:36

Die Rechnung stimmt einfach hinten und vorne nicht.

Du sagst nur so nicht und falsch ,falsch, falsch.
Rechne es doch mal am Beispiel vor, dann sehe ich wo ich falsch liege.
Nimm DDR4 3200 als Beispiel.

Windi

2019-01-22, 13:46:41

Also hat man extrem flexible Kontroller, die sich als alles mögliche ausgeben können?

edit: Wohl falsch ausgedrückt.
Für alle Schnittstellen gibt es eine dazugehörige Logik. Die verbraucht allerdings nicht viel Fläche, da man sie gut schrumpfen kann.
Die "Leistungselektronik" / "Digital/Analog-Wandler", die die Signale aus dem Prozessor herausschickt, ist hingegen sehr flexibel und kann alles mögliche. Dafür ist sie aber auch recht groß, um die höheren Spannungen und Ströme auszuhalten.

OK, das ist beeindruckend.

SKYNET

2019-01-22, 14:14:50

Einen Extra Chipsatz sehe ich auch nicht auf den Bildern und ich kenne auch keinen mit 2x 10 Gigabit Ethernet.

das eine was theoretisch möglich wäre, das andere was hersteller umsetzen...

und nein, brauchs beim SoC ja auch nicht...

auf ryzen AM4 zb. brauchs den chipsatz bei ITX brettern eigentlich nur für die SATA anschlüsse, der PCIe 3.0 16x slot und und bis zu 2x m.2 PCIe 3.0 4x sind ja eh nativ an die CPU gebunden...

Complicated

2019-01-22, 14:49:48

Rechne es doch mal am Beispiel vor, dann sehe ich wo ich falsch liege.
Nimm DDR4 3200 als Beispiel.
https://en.wikichip.org/wiki/amd/infinity_fabric
The Infinity Fabric On-Package (IFOP) SerDes deal with die-to-die communication in the same package. AMD designed a fairly straightforward custom SerDes suitable for short in-package trace lengths which can achieve a power efficiency of roughly 2 pJ/b. This was done by using a 32-bit low-swing single-ended (https://en.wikichip.org/w/index.php?title=single-ended&action=edit&redlink=1) data transmission with differential clocking which consumes roughly half the power of an equivalent differential drive. They utilize a zero-power driver state from the TX/RX impedance termination to the ground while the driver pull-up is disabled. This allows transmitting zeros with less power than transmitting ones which is also leveraged when the link is idle. Additionally inversion encoding (https://en.wikichip.org/w/index.php?title=inversion_encoding&action=edit&redlink=1) was used to save another 10% average power per bit.
Due to the performance sensitivity of the on-package links, the IFOP links are over-provisioned by about a factor of two relative to DDR4 channel bandwidth for mixed read/write traffic. They are bidirectional links and a CRC is transmitted along with every cycle of data. The IFOP SerDes do four transfers per CAKE clock.

https://en.wikichip.org/w/images/thumb/9/91/amd_if_ifop_link_example.svg/600px-amd_if_ifop_link_example.svg.png

Since the CAKEs operate at the same frequency as the DRAM's MEMCLK frequency, the bandwidth is fully dependent on that. For a system using DDR4-2666 DIMMs, this means the CAKEs will be operating at 1333.33 MHz meaning the IFOPs will have a bi-directional bandwidth of 42.667 GB/s.

Gipsel

2019-01-22, 15:03:33

auf ryzen AM4 zb. brauchs den chipsatz bei ITX brettern eigentlich nur für die SATA anschlüsse, der PCIe 3.0 16x slot und und bis zu 2x m.2 PCIe 3.0 4x sind ja eh nativ an die CPU gebunden...
Wobei das Die an sich auch bis zu 8 SATA Ports selber liefern könnte, wenn es denn entsprechend verdrahtet und vom BIOS so geschaltet wäre. Ist halt nicht vorgesehen, daß der Boardhersteller die Lanes völlig frei zuweisen kann. Ansonsten wäre insbesondere bei ITX-Boards (aber eigentlich auch bei Einsteiger-µATX) wirklich für praktisch gar nichts ein Chipsatz nötig. Man hat genügend SATA Ports (bis zu 8, geht von den PCIe-Lanes ab), USB3 (4 Stück, sind separate PHYs, gehen also nicht von den PCIe-Lanes ab; wenn das nicht reicht, kann man ja noch einen kleinen PCIe-Zusatzcontroller auf dem Mainboard verlöten) und Netzwerkports (bis zu 4, geht ebenfalls von den PCIe-Lanes ab, ein 1G oder 10G Port belegt eine Lane, unterstützt werden theoretisch auch noch höhere Datenraten [die dann mehr als 1 Lane benutzen]). Selbst ohne die vollen 32 Lanes sondern mit den nur 24 verfügbaren bei AM4, bleibt da genügend übrig, daß man Einsteiger-Boards den Chipsatz wirklich weglassen könnte. Z.B. für ein µATX-Board:

1x Slot x8: für GPU
1x Slot x4: für Steckkarte
1x Slot x1: für Steckkarte
1x .M2 Steckplatz (4 Lanes)
1x 2 Port USB3.1 Gen2 Controller (2 Lanes)
4x SATA 3G Ports (4 Lanes)
1x GigE (1 Lane)
-------------------------------
24 Lanes belegt für:
3 PCIe-Slots (x8 + x4 +x1)
1x .M2 mit x4 PCIe (wenn nicht genutzt, könnte man einen zweiten x4-Slot damit belegen, oder man baut noch einen zweiten M2-Steckplatz ein, der dann die Lanes vom x4-Slot klaut)
4x SATA 3G
6 USB 3.1 Ports (4x Gen1 integriert [RavenRidge kann offenbar direkt Gen2, da wäre das also in der Summe 6x Gen2] + 2x Gen2 per Controller [der dann auch noch ein paar USB2 Ports dazuschmeißen kann])
1x GigE

Könnte man auch anders aufteilen, aber 8 USB3-Ports, 2 GigE oder mehr M2 oder SATA wären für ein Einsteigerboard wohl fast schon Overkill und sollten in dem Bereich kaum ein Limit sein.

Setsul

2019-01-22, 15:08:13

@amdfanuwe:
So schwer ist es doch nicht. Egal ob 2400 oder 3200, RAM I/O clock und IF clock sind identisch.
Ein RAM Kanal übertragt in jedem dieser Takte 2x64b (weil DDR) und ein CAKE überträgt 1x128b.

Wie das CAKE das jetzt macht und was physisch dahinter steckt interessiert nicht wirklich. Ob es in dem Takt 8 mal 16 bit schickt oder 4 mal 32 bit ändert ja nichts.

Wenn man jetzt also 64 Byte übertragen will dann braucht ein RAM Kanal dafür 4 Takte (64*8 / (2*64)) und das IFOP braucht dafür auch 4 Takte (64*8 / 128).
Dual Channel ändert daran auch nichts. Der RAM könnte zwar 2*128b pro Takt liefern, aber das CAKE nimmt nur zu jedem vollen Takt ein Paket an. Es geht also sowohl von den Takten als auch von der Bandbreite nicht und dauert immernoch genauso lange.

Das Endergebnis ist also, dass der RAM 4 Takte @1600 MHz (oder 1200 MHz mit 2400 RAM) also 2,5ns braucht um alle Pakete loszuschicken. Das ist dann die sogennante Serialisierungszeit. Das ist aber noch nicht die Latenz.
Wenn das Paket in jedem Takt ein Switch weiter geschickt wird und durch 23 Switches muss um an sein Ziel zu kommen dann kommt das erste Paket eben nach 24 Takten an und das letzte nach 27 Takten. Die 23 Takte Ausbreitungsverzögerung machen da also viel mehr aus.

Serialisierungszeit ist direkt proportional zur Bandbreite und Paketgröße, aber die Ausbreitungsverzögerung kann man damit nicht ausrechnen.

Einfach Beispiel: Der L1D-Cache kann pro Takt 32 Byte übertragen und trotzdem braucht jede Load Instruction mindestens 4 Takte. Der L3 kann auch 32 Byte pro Takt und trotzdem brauch eine 64 Byte Cache Line nicht 2 sondern 40 Takte vom L3 in den Kern.

Der RAM ist auch nicht daran schuld dass ein Zugriff auf den L3 im anderen CCX fast genauso lange dauert wie ein Zugriff auf den RAM. Da stecken 30 oder 40 ns vom IF drin ohne dass der RAM beteiligt ist. Also völlig unabhängig vom Rest ob da jetzt 2,5ns mehr oder weniger Seralisierungszeit drinstecken und ein Takt mehr oder weniger für eine FIFO-Qeue, das erklärt bei weitem nicht die 30-40ns die das IF langsamer ist als Intel und egal wie viel man an diesen 2,5ns schraubt können die auch das Problem nicht lösen.
Also das IF hat eine relativ hohe Latenz, aber die entsteht nicht an dieser Stelle und da lässt sich auch relativ wenig rausholen.

SKYNET

2019-01-22, 15:30:38

Wobei das Die an sich auch bis zu 8 SATA Ports selber liefern könnte, wenn es denn entsprechend verdrahtet und vom BIOS so geschaltet wäre. Ist halt nicht vorgesehen, daß der Boardhersteller die Lanes völlig frei zuweisen kann. Ansonsten wäre insbesondere bei ITX-Boards (aber eigentlich auch bei Einsteiger-µATX) wirklich für praktisch gar nichts ein Chipsatz nötig. Man hat genügend SATA Ports (bis zu 8, geht von den PCIe-Lanes ab), USB3 (4 Stück, sind separate PHYs, gehen also nicht von den PCIe-Lanes ab; wenn das nicht reicht, kann man ja noch einen kleinen PCIe-Zusatzcontroller auf dem Mainboard verlöten) und Netzwerkports (bis zu 4, geht ebenfalls von den PCIe-Lanes ab, ein 1G oder 10G Port belegt eine Lane, unterstützt werden theoretisch auch noch höhere Datenraten [die dann mehr als 1 Lane benutzen]). Selbst ohne die vollen 32 Lanes sondern mit den nur 24 verfügbaren bei AM4, bleibt da genügend übrig, daß man Einsteiger-Boards den Chipsatz wirklich weglassen könnte. Z.B. für ein µATX-Board:

1x Slot x8: für GPU
1x Slot x4: für Steckkarte
1x Slot x1: für Steckkarte
1x .M2 Steckplatz (4 Lanes)
1x 2 Port USB3.1 Gen2 Controller (2 Lanes)
4x SATA 3G Ports (4 Lanes)
1x GigE (1 Lane)
-------------------------------
24 Lanes belegt für:
3 PCIe-Slots (x8 + x4 +x1)
1x .M2 mit x4 PCIe (wenn nicht genutzt, könnte man einen zweiten x4-Slot damit belegen, oder man baut noch einen zweiten M2-Steckplatz ein, der dann die Lanes vom x4-Slot klaut)
4x SATA 3G
6 USB 3.1 Ports (4x Gen1 integriert [RavenRidge kann offenbar direkt Gen2, da wäre das also in der Summe 6x Gen2] + 2x Gen2 per Controller [der dann auch noch ein paar USB2 Ports dazuschmeißen kann])
1x GigE

Könnte man auch anders aufteilen, aber 8 USB3-Ports, 2 GigE oder mehr M2 oder SATA wären für ein Einsteigerboard wohl fast schon Overkill und sollten in dem Bereich kaum ein Limit sein.

dann isses ja eigentlich noch tragischer das die hersteller das nicht auch so umsetzen, gerade im ITX formfaktor, hätten sie dann mehr platz für spannungsversorgung, oder 4x so-dimm anstelle 2x dimm etc.

wenn AM4 dann nämlich wirklich 16 kerne bekommt(wovon ich ausgehe), könnte man dank 4x so-dimm dann ne mini workstation aufbauen, kleines raijintek metis und genug power für alles was im hobbysektor an video/grafik/photo zu machen ist... weil das QC interface von TR brauch man nicht zwingend für videoschnitt im privaten sektor, da kommts eher weniger auf die paar sekunden an dies einsparen würde.

amdfanuwe

2019-01-22, 16:39:02

The IFOP SerDes do four transfers per CAKE clock.
For a system using DDR4-2666 DIMMs, this means the CAKEs will be operating at 1333.33 MHz meaning the IFOPs will have a bi-directional bandwidth of 42.667 GB/s.
Danke, denke jetzt hab ich es.
Ich dachte, der IFOP arbeitet auch mit den 1333,33 MHz. War mir nicht klar, dass der mit der doppelten Frequenz arbeitet und somit auf seinen 32 Bit die gleiche Bandbreite wie der RAM mit 64 Bit Breite erreicht.

amdfanuwe

2019-01-22, 16:45:21

@amdfanuwe:

Wie das CAKE das jetzt macht und was physisch dahinter steckt interessiert nicht wirklich.
Mich schon :-) Da lag mein Problem. Ich brauch erst mal eine physische Vorstellung sonst komm ich mit dem abstraktem nicht klar. Aber ist ja jetzt geklärt.

amdfanuwe

2019-01-22, 16:50:55

daß man Einsteiger-Boards den Chipsatz wirklich weglassen könnte. Z.B. für ein µATX-Board:

Macht ASRock doch jetzt beim DeskMini.
http://www.pcgameshardware.de/Ryzen-5-2400G-CPU-267145/News/Asrock-Deskmini-A300-ohne-Chipsatz-1269854/

EPYC braucht auch keinen Chipsatz.

Gipsel

2019-01-22, 16:58:20

Macht ASRock doch jetzt beim DeskMini.
http://www.pcgameshardware.de/Ryzen-5-2400G-CPU-267145/News/Asrock-Deskmini-A300-ohne-Chipsatz-1269854/Zum einen ist das unnötig eingeschränkt (die CPUs können mehr, als was AMD auf dem Desktop freigegeben hat). Und der Artikel nennt die Möglichkeiten der CPUs falsch (angeblich nur 6 bzw. 8 PCIe-Lanes, wer hat denn den Scheiß geschrieben?).
EPYC braucht auch keinen Chipsatz.Das ist bekannt. Dort kann der Boardhersteller nämlich die Lanes frei verteilen, wie er lustig ist, siehe hier (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11907106#post11907106). ;)

Dort steht dann pro Die Folgendes zur Verfügung:
32 PCIe-Lanes (für maximal 16 separate PCIe-Links), wahlweise konfigurierbar für bis zu:
8x SATA 3G
4x Ethernet
dazu noch separate PHYs für 4 USB3.1 Gen 1 Ports.
Einem kompletten Epyc1 Chip stehen somit neben 16 USB3.1 Gen1 Ports insgesamt 128 PCIe-Lanes zur Verfügung, wovon bis zu 32 als SATA 3G Ports und bis zu 16 als Ethernet Links konfiguriert werden können (was selbst im Extremfall immer noch 80 PCIe Lanes übrig läßt). Das sollte wohl meist reichen.

amdfanuwe

2019-01-22, 17:05:25

@amdfanuwe:

Das Endergebnis ist also, dass der RAM 4 Takte @1600 MHz (oder 1200 MHz mit 2400 RAM) also 2,5ns braucht um alle Pakete loszuschicken. Das ist dann die sogennante Serialisierungszeit. Das ist aber noch nicht die Latenz.
OK, mir gings ursprünglich darum zu zeigen, dass die "Latenz" durch die Übertragung an ein Chiplet vernachlässigbar ist. Viele meinten ja, dass das Chipletdesign die Latenz in die Höhe treibt.

amdfanuwe

2019-01-22, 17:12:54

Zum einen ist das unnötig eingeschränkt (die CPUs können mehr, als was AMD auf dem Desktop freigegeben hat). Und der Artikel nennt die Möglichkeiten der CPUs falsch (angeblich nur 6 bzw. 8 PCIe-Lanes, wer hat denn den Scheiß geschrieben?).

Die CPUs wohl, aber der Sockel gibt es anscheinend nicht her.
Dass der Autor jetzt die 16PCIe für GPU nicht mitgerechnet hat, sei ihm verziehen.

Gipsel

2019-01-22, 17:36:28

Die CPUs wohl, aber der Sockel gibt es anscheinend nicht her.Aus dem AM4-Sockel kommen bis zu 24 PCIe-Lanes.
Dass der Autor jetzt die 16 PCIe für GPU nicht mitgerechnet hat, sei ihm verziehen.Die nicht unbedingt für die GPU benutzt werden müßten (insbesondere wenn man eine APU benutzt; das gezeigte STX-Board hat überhaupt gar keinen PCIe-Steckplatz für eine Grafikkarte und RavenRidge verbaut wohl auch nur 8 Lanes, die offiziell für die GPU gedacht sind). Da kommen halt schlicht Lanes raus. Ohne Beschränkungen dafür, wie man die aufteilt und konfiguriert, wäre mehr ohne Chipsatz möglich. Genau das sagte ich ja.

Edit:
Aber ist ja hier eigentlich auch egal.

Setsul

2019-01-22, 18:31:53

Danke, denke jetzt hab ich es.
Ich dachte, der IFOP arbeitet auch mit den 1333,33 MHz. War mir nicht klar, dass der mit der doppelten Frequenz arbeitet und somit auf seinen 32 Bit die gleiche Bandbreite wie der RAM mit 64 Bit Breite erreicht.
Das war das erste was ich geschrieben habe.

CAKE nimmt jeden Takt ein 128 bit Paket, IFOP schiebt dann pro Takt 4x 32b und IFIS 8x 16b in die Leitung. Sonst würde es auch von der Bandbreite nicht reichen.

Ich bin mir auch nicht ganz sicher wie du von "four transfers per CAKE clock" auf doppelte Frequenz kommst.
Aber das wichtigste ist, dass dir jetzt klar ist dass IF/IFOP pro Richtung die gleiche Bandbreite wie ein Kanal RAM haben und das der Latenz nicht wirklich schadet.

amdfanuwe

2019-01-22, 22:44:06

Ich bin mir auch nicht ganz sicher wie du von "four transfers per CAKE clock" auf doppelte Frequenz kommst.
In einem Takt kann ich 2 Transfers durchführen (DDR), pro Flanke einen. Für 4 Transfers brauch ich die doppelte Frequenz oder einen 2ten Takt, der um 90° Phasenverschoben ist, damit ich pro Takt 4 Flanken habe.

Gipsel

2019-01-22, 23:47:00

QDR for the rescue!

Setsul

2019-01-22, 23:52:09

amdfanuwe

2019-01-23, 00:54:19

Also du merkst, dass die Aussage, das IFOP mit doppelter Frequenz läuft so pauschal einfach nicht richtig ist. QDR mit bei gleichem Takt ist offensichtlich möglich, aber SDR bei vierfachem Takt ist auch eine Option. Nicht die ganze Welt läuft mit DDR.
Hatte irgendwo gelesen, dass QDR verwendet wird.
Bei SDR vierfachem Takt wären wir für DDR4 3200 bei 6,4GHz. Unnötige Energieverschwendung, wenn man auch mit der Hälfte auskommen kann.
OK, bin kein Hardwareentwickler und Studium ist schon 20 Jahre her.

JVC

2019-01-23, 09:47:58

SKYNET

2019-01-23, 10:30:22

https://www.pcgamesn.com/amd/amd-matisse-cpus-3rd-gen-ryzen-aida64-5800mhz-memory
"AMD Matisse CPUs and 5,800MHz DDR4 memory modules referenced in AIDA64. Wait… what?"
( https://twitter.com/KOMACHI_ENSAKA/status/1087710670659809280 )

5800mhz DDR4 :confused:

https://www.tomshardware.com/news/ryzen-amd-third-gen-7nm-processor,38474.html
"Papermaster: AMD's 3rd-Gen Ryzen Core Complex Design Won’t Require New Optimizations"

m.f.g. JVC

ich denke wohl eher 4700 und 4800MHz... wenn das der offiziell supportete ramspeed ist, wundert mich ja garnix mehr... das ding ist/wird ein monster. :eek:

und ich habe schon den passenden speicher dazu ;D

Gipsel

2019-01-23, 10:33:23

ich denke wohl eher 4700 und 4800MHz... wenn das der offiziell supportete ramspeed ist, wundert mich ja garnix mehr... das ding ist/wird ein monster. :eek:

und ich habe schon den passenden speicher dazu ;D
Die neuen CPUs und der neue RAM aus der Meldung haben bloß überhaupt nichts miteinander zu tun. ;)
Es wurde kein Matisse gesichtet, der mit dem RAM-Speed lief.

dildo4u

2019-01-23, 10:33:33

Nötig wenn sie 16 Kerne verbauen,nur kein Plan wer diese Module liefern soll.
Dadurch wäre auch der Sprung zu DDR5 mäh,zumindest im Desktop im Notebook will keine Module mit 1.5Volt verbauen.

SKYNET

2019-01-23, 10:38:14

Die neuen CPUs und der neue RAM aus der Meldung haben bloß überhaupt nichts miteinander zu tun. ;)
Es wurde kein Matisse gesichtet, der mit dem RAM-Speed lief.

ahhh, stimmt.... nur mit nem halben auge auf den tweet geschaut :rolleyes: X-D

bleibts wohl doch bei DDR4 3200 oder evtl. 3333

Unicous

2019-01-23, 10:42:38

Kann mir mal jemand erklären warum immer häufiger diese Dilettanten von PCGAMESN verlinkt werden? Alle paar Tage wird ein neuer "Artikel" durchs Dorf getrieben. Ich hatte bis vor einem halben Jahr noch nicht mal von denen gehört und jetzt sind sie gefühlt die neuen WTF-Tech, und es schmerzt mich das zu sagen, sie haben wirklich noch weniger Ahnung.

Lehdro

2019-01-23, 11:57:37

Nötig wenn sie 16 Kerne verbauen,nur kein Plan wer diese Module liefern soll.
Woher kommt eigentlich immer diese Aussage das die Kerne nach Bandbreite hungern? Wenn dem so wäre, würde TR4 sich deutlich von AM4 absetzen, ebenso wie SKL-X von CFL-R. Ist beides aber abseits von speziellen Anwendungen überhaupt nicht der Fall. Viel mehr lechzt alles nach möglichst kurzen Latenzen.

Diese "mehr Bandbreite nötig" Gerüchte geistern schon seit den ersten Dualcores durch die Foren, von wegen "doppelte Kerne brauchen doppelte Bandbreite". Bei Quadcores kamen die Gerüchte dann wieder ... zieht sich bis heute durch. Woher kommt das? :confused:

Complicated

2019-01-23, 12:47:19

Tja...damit wäre PCIe 4.0 schon mehr als nur nice-to-have
https://www.computerbase.de/2019-01/ssd-transcend-pcie-x4-interface/

Der 4x Link für M2.SSDs ist mit den neuen SSDs mit PCIe 3.0 am Limit.

HOT

2019-01-23, 12:53:01

Na ja SSD-Speed ist nice to have :D.

amdfanuwe

2019-01-23, 12:57:43

Woher kommt das? :confused:
Ernsthaft?
Wer wirklich Ahnung von der Materie hat, was nur wenige sind, treibt sich kaum in den Foren rum.
Denke auch daran, jedes Jahr kommen neue "Spezialisten" hinzu, die erstmal wieder die Grundlagen lernen müssen.

SKYNET

2019-01-23, 14:07:44

Woher kommt eigentlich immer diese Aussage das die Kerne nach Bandbreite hungern? Wenn dem so wäre, würde TR4 sich deutlich von AM4 absetzen, ebenso wie SKL-X von CFL-R. Ist beides aber abseits von speziellen Anwendungen überhaupt nicht der Fall. Viel mehr lechzt alles nach möglichst kurzen Latenzen.

Diese "mehr Bandbreite nötig" Gerüchte geistern schon seit den ersten Dualcores durch die Foren, von wegen "doppelte Kerne brauchen doppelte Bandbreite". Bei Quadcores kamen die Gerüchte dann wieder ... zieht sich bis heute durch. Woher kommt das? :confused:

korrekt, nen 2950X ist in games, trotz 50MHz(=4400MHz) mehr 1-2C boost, langsamer als der 2700X.... einfach weil die latenzen höher sind... bandbreite kann der null ausspielen, sind evtl. ne handvoll anwendungen die von der bandbreite profitieren, aber games und 0-8-15 anwednungen, sinds definitiv nicht.

basix

2019-01-23, 14:32:21

Die einzigen Tools, die im 08/15 User Case von Bandbreite profitieren sind Packer. Etwas anderes kommt mir gerade nicht in den Sinn.

Savay

2019-01-23, 14:37:37

Etwas anderes kommt mir gerade nicht in den Sinn.

RAW Konverter/Demosaicing und Panorama/HDR Stacking vielleicht noch.
Da fällt halt dekodiert nen riesen Haufen Daten an der wahrlich nicht mehr in irgendwelche Caches passt.

LR reagiert beim Export ja auch wirklich außergewöhnlich gut auf die Quad-Channel CPUs/Plattformen!
Die Kernskalierung an sich ist dagegen ab einem bestimmten Grenzwert eher extrem flach.

Pirx

2019-01-24, 08:31:47

basix

2019-01-24, 09:41:33

Der SC Score sieht gut aus. Stimmen die 3.6-3.7GHz Boost wären es +5...10% mehr IPC als Coffee Lake. MC sieht sowieso gut aus :)

M4xw0lf

2019-01-24, 09:47:34

Tum Apisak, der alte(?) Fuchs:D

https://twitter.com/TUM_APISAK/status/1088264161191022593

https://www.userbenchmark.com/UserRun/14076820 edit: nur 1x4 GB RAM

https://www.computerbase.de/2019-01/cpu-amd-matisse-12-kerne/
Die Benchmarks sagen mal wieder nicht sehr viel, aber jeder Leak von Zen 2 bringt den Launch näher ^^
Und natürlich ein erster handfester Beleg für den 3-Die (IO+2xCPU chiplets) Ryzen 3000, auch wenn dessen Existenz nicht zweifelhaft war.

BlacKi

2019-01-24, 10:29:15

Tum Apisak, der alte(?) Fuchs:D

https://twitter.com/TUM_APISAK/status/1088264161191022593

https://www.userbenchmark.com/UserRun/14076820 edit: nur 1x4 GB RAM

https://www.computerbase.de/2019-01/cpu-amd-matisse-12-kerne/
sieht dann das chiplet design dann so aus, oder welche cpu/apu soll das sonst sein?
https://abload.de/img/chipletajjp5.png

HOT

2019-01-24, 10:32:14

So könnte eine große APU ausehen. Links Zen2-Chiplet, mitte I/O-Chip, rechts kleiner Navi. Bei 22CUs wär die Speicherbandbreite aber "etwas" überfordert :D.

BlacKi

2019-01-24, 10:41:31

hab das ryzen 3000 foto mal daneben gestetzt zum vergleichen. navi wäre dann aber so 70-80mm² groß? der IO Die sieht auch ganz anders aus als vom ryzen3000
https://abload.de/img/chiplett1j8w.png

M4xw0lf

2019-01-24, 10:42:29

sieht dann das chiplet design dann so aus, oder welche cpu/apu soll das sonst sein?
https://abload.de/img/chipletajjp5.png
Das ist einfach nur ein zusammengeshopptes Fantasie-package.

BlacKi

2019-01-24, 10:47:01

egal, der hypetrain braucht sprit^^

BoMbY

2019-01-24, 11:09:13

Das ist einfach nur ein zusammengeshopptes Fantasie-package.

Exakt. Das ist älter als das erste tatsächliche Bild, und war nur eine Vorstellung davon wie es aussehen könnte.

SKYNET

2019-01-24, 11:31:01

So könnte eine große APU ausehen. Links Zen2-Chiplet, mitte I/O-Chip, rechts kleiner Navi. Bei 22CUs wär die Speicherbandbreite aber "etwas" überfordert :D.

nicht wenn DDR4 5700/5800 kommt, wie im anderen faden als AIDA changelog aufgetaucht... :freak: dann würde das ding abgehen wie hülle, klar immernoch bandbreiten limitiert, aber deutlich weniger.... weil das wären dann schon -realistisch- um die 82-84GB bandbreite die dabei rauskommen würden im DC :eek:

JVC

2019-01-24, 11:50:18

Ich bezweifle irgendwie das AMD den Speicherkontroller so enorm verbessern konnte ...
Das wäre ja fast ne Verdoppelung :eek:
(gibt ja auch keinen passenden Ram dafür, nicht mal annähernd)

Ich wäre schon glücklich wenn Zen2 zuverlässig mit 4000sender Ram laufen würde :smile:
(das halte ich für durchaus möglich)

m.f.g. JVC

Screemer

2019-01-24, 12:07:43

nicht wenn DDR4 5700/5800 kommt, wie im anderen faden als AIDA changelog aufgetaucht... :freak: dann würde das ding abgehen wie hülle, klar immernoch bandbreiten limitiert, aber deutlich weniger.... weil das wären dann schon -realistisch- um die 82-84GB bandbreite die dabei rauskommen würden im DC :eek:
und dann kauf ich mir für meine 150€ apu 16gb ram für >400 (https://geizhals.de/?cat=ramddr3&asd=on&asuch=ddr4%204600&xf=15475_sonstige&sort=p#productlist)€? seeehr sinnig.

Opprobrium

2019-01-24, 12:27:38

SKYNET

2019-01-24, 14:18:36

und dann kauf ich mir für meine 150€ apu 16gb ram für >400 (https://geizhals.de/?cat=ramddr3&asd=on&asuch=ddr4%204600&xf=15475_sonstige&sort=p#productlist)€? seeehr sinnig.

wird zum sommer hin noch min. 50% fallen der rampreis, und es profitiert ja nicht nur die GPU im prozessor von dem speichertakt... ;)

SKYNET

2019-01-24, 14:20:45

Wenn AMD eine halbwegs leistungsfähige GPU in den I/O Chip verfrachten würde, dann könnten sie sich doch eigentlich 16 PCIe Landes sparen, oder? Dann könnte man eine 8-Kern APU mit HBM basteln und hätte ein super Midrange Produkt.

Der ganze Chiplet Ansatz ist doch eigentlich ein wahrgewordener Traum für Semi-Custom.

viel geiler wäre: 8C/16T APU mit 8GB HBM2 onboard, und zwar so gemanaged, das der als hauptspeicher genutzt werden kann... wäre dann wohl die schnellste CPU/APU überhaupt für die kommenden jahre. ;D

zumal man sich den ram spart, aber der aufpreis wäre saftig, weil 8GB HBM2 sind $150... dafür bekommt man inzwischen 16GB 3400er speicher.

Screemer

2019-01-24, 14:22:49

wird zum sommer hin noch min. 50% fallen der rampreis, und es profitiert ja nicht nur die GPU im prozessor von dem speichertakt... ;)
dann kostet der ram immer noch mehr als die apu ;) aber dein wort in gottes gehörgang.

Pirx

2019-01-24, 14:25:51

viel geiler wäre: 8C/16T APU mit 8GB HBM2 onboard, und zwar so gemanaged, das der als hauptspeicher genutzt werden kann... wäre dann wohl die schnellste CPU/APU überhaupt für die kommenden jahre. ;D

zumal man sich den ram spart, aber der aufpreis wäre saftig, weil 8GB HBM2 sind $150... dafür bekommt man inzwischen 16GB 3400er speicher.
Absolut, könnten auch 4 GB sein mit HBCC, damit würde man den Markt richtig aufmischen.:ulol:
Kommt aber wohl leider nicht.

SKYNET

2019-01-24, 14:34:26

dann kostet der ram immer noch mehr als die apu ;) aber dein wort in gottes gehörgang.

wäre ich mir nicht so sicher, sone fette APU lässt AMD sich sicherlich auch ordentlich bezahlen...

nur als theorie: 8C/16T, 8GB HBM2, navi 20CUs --> 450€ würde ich mal behaupten... dafür hat man dann aber wohl auch ne APU mit +/- RX570 leistung... bei aktuellen preisen 2700X + RX570 + 8GB Ram(man muss dann ja schon fetten ram nehmen, zum vergleich mit HBM2 = 3600er): 570€

amdfanuwe

2019-01-24, 15:17:32

viel geiler wäre: 8C/16T APU mit 8GB HBM2 onboard, und zwar so gemanaged, das der als hauptspeicher genutzt werden kann... wäre dann wohl die schnellste CPU/APU überhaupt für die kommenden jahre. ;D

Das wird kommen.
Die könnte man dann erstmal in Ultra Ultrabooks bei entsprechendem Preis verbauen bis der HBM billiger wird. Sehr klein im Vergleich zu anderen Lösungen und einfaches Boarddesign. Könnte ich mir auch mit 2 HBM Stacks und 16GB vorstellen. Die Technik dafür hat AMD.
Ist wohl noch eine Kostenfrage bzw. zu großes Risiko, dass die OEMs sich dagegen sperren weil sie erst ihre Intel Verträge erfüllen müssen.

Setsul

2019-01-24, 16:11:43

Also nochmal für alle zum Mitschreiben:
Release notes:

RGB LED / support for Cooler Master MP750 mousepad
LCD2USB LCD / support for 8 pages
improved sensor support for EVGA iCX2
motherboard specific sensor info for EVGA Z390 Dark
improved motherboard specific sensor info for ASRock boards
physical CPU information for AMD Matisse
identification of DDR4-5700, DDR4-5800 memory modules
fixed: SensorPanel Manager / exporting with blank custom gauge state filenames
fixed: Storage / SMART / Reallocated Sector Count data field
fixed: motherboard specific sensor info for Gigabyte Z390 Aorus Master
fixed: motherboard specific sensor info for MSI MS-7A75
Das heißt, dass AIDA64 jetzt Matisse und DDR4-5700/5800 erkennen kann, aber die Einträge haben nichts miteinander zu tun.
Der Weltrekord mit LN2 liegt bei 5.608 MHz, also hat AMD ganz sicher nicht offiziellen Support für 5700 und 5800, das weltweit noch nie jemand zum Laufen gebracht hat.

Bezüglich APU würde ich mal die Erwartungen zurückschrauben. JEDEC geht nur bis 3200 und AMD hat generell ein Problem mit der Bandbreiteneffizienz bei GPUs. Was mit der Bandbreite nicht möglich ist, wird auch nicht gebaut, AMD wird nicht 4800 MHz RAM vorraussetzen. Wenn man sich anchaut wieviele Polaris CUs auf >100 mm² passen und dann bedenkt was noch alles außer den CUs drinsteckt (ich bezweifle stark dass AMD einen 7nm Die ohne Speicherinterface designed und dann noch einen zweiten Die für den Low End Markt macht) und von größeren CUs als bei Polaris ausgeht dann würde ich für so ein <80mm² Chiplet deutlich weniger als 20 CUs erwarten. Dann reicht auch die Bandbreite wieder.

Chiplets + HBM sind für semi-custom tatsächlich hochinteressant, als Upgrade gegenüber dem jetzigen SoC + GDDR. Ob man das dann kaufen kann, darf aber bezweifelt werden. Fenghuang gibts auch nicht einzeln.

Dass 20 Navi CUs mit recht begrenzter TDP (alle APUs waren bis jetzt <=100W, aber selbst bei 150W will die CPU ja auch ein bisschen) +/- RX570 Leistung (32 CUs bei 150W TDP) erreichen halte ich für etwas zu optimistisch.

SKYNET

2019-01-24, 16:27:07

Also nochmal für alle zum Mitschreiben:

Das heißt, dass AIDA64 jetzt Matisse und DDR4-5700/5800 erkennen kann, aber die Einträge haben nichts miteinander zu tun.
Der Weltrekord mit LN2 liegt bei 5.608 MHz, also hat AMD ganz sicher nicht offiziellen Support für 5700 und 5800, das weltweit noch nie jemand zum Laufen gebracht hat.

Bezüglich APU würde ich mal die Erwartungen zurückschrauben. JEDEC geht nur bis 3200 und AMD hat generell ein Problem mit der Bandbreiteneffizienz bei GPUs. Was mit der Bandbreite nicht möglich ist, wird auch nicht gebaut, AMD wird nicht 4800 MHz RAM vorraussetzen. Wenn man sich anchaut wieviele Polaris CUs auf >100 mm² passen und dann bedenkt was noch alles außer den CUs drinsteckt (ich bezweifle stark dass AMD einen 7nm Die ohne Speicherinterface designed und dann noch einen zweiten Die für den Low End Markt macht) und von größeren CUs als bei Polaris ausgeht dann würde ich für so ein <80mm² Chiplet deutlich weniger als 20 CUs erwarten. Dann reicht auch die Bandbreite wieder.

Chiplets + HBM sind für semi-custom tatsächlich hochinteressant, als Upgrade gegenüber dem jetzigen SoC + GDDR. Ob man das dann kaufen kann, darf aber bezweifelt werden. Fenghuang gibts auch nicht einzeln.

Dass 20 Navi CUs mit recht begrenzter TDP (alle APUs waren bis jetzt <=100W, aber selbst bei 150W will die CPU ja auch ein bisschen) +/- RX570 Leistung (32 CUs bei 150W TDP) erreichen halte ich für etwas zu optimistisch.

halte ich nicht für sooo unrealistisch... ne 1080Ti hat 37.5% mehr rops als ne 2080, trotzdem ist die 2080 gleich schnell... du musst halt bedenken das es eine komplett andere architektur sein wird, da kanns auch mal schnell 50% mehr leistung bei gleicher anzahl rops & takt sein :)

Setsul

2019-01-24, 16:40:02

Wir reden hier von CUs, nicht ROPs.
Die 1080 Ti hat nur 21,7% mehr Cuda Cores und wegen niedrigerem Takt nur 12,6% mehr Rechenleistung. 10-15% sind kein Hexenwerk.

Das ist eine ganz andere Größenordnung als 60%. Großartige Sprünge beim Takt sind auch nicht drin wegen der TDP. Wann hat AMD das letzte mal 50% rausgeholt mit einer neuen Architektur? Es wäre toll, aber ich würde nicht darauf wetten.

SKYNET

2019-01-24, 16:56:06

Eldoran

2019-01-24, 19:50:32

Diese extrem-APUs dürften wohl auf absehbare Zeit ein Wunschtraum bleiben - wir reden da immerhin von dem Äquivalent eines Ryzen 2700 + Vega 20. Das ganze monolithisch oder eben die GPU in 7nm incl. HBM zu einem Kampfpreis.

Schon von der Grösse/Fläche her ist eher fraglich ob so etwas überhaupt für AM4 machbar wäre. Selbst wenn - mehr als beim nächsten Vega 20 Äquivalent zusätzlich zum PCIe Interface ein IF IFIS einzubauen, damit man das dann effizient auf ein grösseres BGA Package zusammen mit je einem Ryzen IO/CPU Die verbauen kann macht da keinen Sinn (erspart die Probleme von kaby lake G mit PCIe).
Das Problem fängt ja schon dabei an, dass der use-case unklar ist, vor allem muss dabei erklärt werden, warum das ganze so viel besser sein soll als eben einen Ryzen 3xxx mit einer Vega 20/16 BGA nebeneinander zu verbauen. Die Fläche wird nicht viel kleiner werden. Und billiger wird es wohl auch kaum sein - das ganze wäre ja wohl kaum ein Massenprodukt.
Und von wegen dünner / Ultrabook - deswegen gibt es etwa den Vega 20 in einem besonders dünnen Package, andererseits nackt ohne organisches (BGA) Package Substrat habe ich keine der Ryzen Dies verbaut gesehen. Es wäre also praktisch in jedem Fall ein MCP.

dildo4u

2019-01-24, 21:49:10

8DPXQVsqyPw

Setsul

2019-01-25, 14:00:49

Vega 20 im Sinne von 20 Vega CUs oder im Sinne vom Radeon VII / MI60 Chip?

Wenn es auf ein Package soll dann reicht IFOP, wozu IFIS?

Die Vorteile wären erstens die Größe und zweitens die Bandbreite zur CPU.
Dass man bei LGA nicht einfach eine BGA GPU daneben aufs Mainboard löten kann sollte klar sein.
Bei Laptops wird aber meistens auch nicht direkt aufs Board gelötet sondern die CPUs und GPUs kommen auf ihrem eigenen Package mit Kondensatoren, Spulen und allem drum und dran wodurch das ganze Ding gerne mal 3 mal so breit und lang ist wie der eigentliche Chip mit vielen freien Flächen. Wenn man beide auf ein Package packt wird das schon deutlich kleiner.
Und dann eben die Bandbreite wenn man nicht mehr durch PCIe muss sondern über IFOP geht, was besonders bei wenig VRAM dem HBCC die Arbeit erleichtert.

Wenn an etwas zu zweifeln ist, dann am HBM. Der Interposer macht alles dicker und teurer, bei KBL-G braucht es nur eine kleine Brücke, bei so einer APU müsste die ganze GPU auf den Interposer. Zusätzlich braucht man erstmal einen Chip mit HBM Interface und wenn wir von 80-100 mm² GPUs reden, dann sind das einfach keine Kandidaten dafür. Außerhalb von Semi-Custom und 400$ Laptop APUs ergibt das keinen Sinn. Bei einer 100$ Low End GPU ist HBM viel zu teuer.

Was ich für realistisch halte ist dass ein Low End GPU Chip wiederverwendet wird. Also vielleicht 16 CUs, weil das eine der Grenzen ist bei GCN, vielleicht mehr, und dann nimmt man sich einen Salvage Chip und hängt ihn an den I/O-Die zusammen mit einem 8C Chiplet. Wenn Navi ein bisschen höhere Bandbreiteneffizienz hat, dann sind 13 oder 14 CUs im Vergleich zu RR mit max 11 CUs nicht völlig abwegig.
Als normale Low End GPUs würden die mit ~100 GB/s versorgt werden, was mit 64 bit GDDR6 geht, das kann man dann bei den Mobile-APUs noch dazugeben. Dann hat man eine kleinere APU, weil nur ein Package für alles, 2 GB GDDR6, was von der Kapazität am unteren Ende ist, aber man merkt es kaum weil HBCC mit >40 GB/s über IFOP relativ problemlos vom RAM nachladen kann. Für Mobile könnte man sogar noch den nächstgrößeren Chip nehmen, aber für AM4 wird AMD wohl kaum GDDR6 unter den IHS stecken (der wird schließlich festgelötet, das tut den Plastikchips nicht gut) und auch generell ist der Platz knapp und >100 mm² GPU unwahrscheinlich. Für Mobile dürfte eine CPU + GPU + 2 GDDR6 Chips auf einem Package sehr kompakt sein und tatsächlich billiger zu produzieren und zu verbauen sein (freut die OEMs) als CPU einzeln + GPU einzeln + mehr Speicher. Im Idealfall kann man damit einfach direkt die Intel "APUs" ersetzen und durchs ganze Small Form Factor Lineup nur APUs verbauen und muss nie auf einzelne GPUs zurückgreifen die mehr Platz verbrauchen (vor allem MXM).

Aber HBM wird auf Semi-Custom beschränkt bleiben denke ich. Man muss schon sehr in Platznot sein wenn man sich für 200GB/s nicht 4xGDDR6 leisten kann statt einem HBM Stack und bei >400 GB/s sind wir weit über dem was man normalerweise als APU kauft. Das ergibt nur bei All-in-Ones (iMac o.ä.) und Konsolen Sinn, aber nicht für PCs oder Notebooks.

Eldoran

2019-01-25, 23:14:35

Vega 20 im Sinne von 20 Vega CUs oder im Sinne vom Radeon VII / MI60 Chip?
Im Sinne von Vega CUs (die kleine Vega die IMHO derzeit nur von Apple verbaut wird). Das entspricht relativ gut den hier im Thread herumgeisternden 22CU Navi.

Wenn es auf ein Package soll dann reicht IFOP, wozu IFIS?
Ich hatte die beiden verwechselt - ich meinte die on package Verbindung (ergo IFOP).

Die Vorteile wären erstens die Größe und zweitens die Bandbreite zur CPU.
Dass man bei LGA nicht einfach eine BGA GPU daneben aufs Mainboard löten kann sollte klar sein.
Bei Laptops wird aber meistens auch nicht direkt aufs Board gelötet sondern die CPUs und GPUs kommen auf ihrem eigenen Package mit Kondensatoren, Spulen und allem drum und dran wodurch das ganze Ding gerne mal 3 mal so breit und lang ist wie der eigentliche Chip mit vielen freien Flächen. Wenn man beide auf ein Package packt wird das schon deutlich kleiner.
Und dann eben die Bandbreite wenn man nicht mehr durch PCIe muss sondern über IFOP geht, was besonders bei wenig VRAM dem HBCC die Arbeit erleichtert.

Das habe ich vermutlich etwas unglücklich formuliert. AMD hat momentan grob die Wahl von etwa "Raven Ridge" in 7nm - das kann vielleicht noch Sinn machen, wen man bedenkt, dass damit die Gesamtfäche begrenzt bleibt - von den Produktionskosten vermutlich ähnlich wie der 1 Chiplet Ryzen. Allerdings reden wir da von einer 4C/8T + 10CU APU, also grob die Hälfte dessen was sich viele hier wünschen. Es dürfte zwar teurer wie die aktuelle Generation sein, aber wenn die Perf/W steigt, könnte es sich trotzdem lohnen.
Aber sobald das ganze deutlich leistungsfähiger werden soll, wird es schwierig. Monolithisch dürfte es der 7nm Vega (VII) von der Fläche nahe kommen. Und schon Raven Ridge kratzt deutlich an der Bandbreite bzw. wird im Low Power Bereich hauptsächlich durch den Verbrauch begrenzt. Wodurch die kleineren Modelle den grösseren kaum nachstehen. Das begrenzt den Nutzen einer Verdopplung der Ressourcen. Vor allem wenn man nicht weite Teile anderweitig nutzen kann, wird das nicht profitabel, denn für Low-cost wäre das viel zu teuer. Andererseits muss das vom Kosten/Nutzen passen. Da eben ein Ryzen 3xxx sowie eine diskrete Vega 20 offensichtlich möglich sind, muss sich diese besondere Performance APU auch daran messen. Ich sehe eben keinen so spektakulären Flächenvorteil - auch auf dem Mainboard. Spätestens wenn man ggf. noch unkonventionelle Betriebsarten bei der Verbindung zulässt. Schließlich könnte wie Kaby Lake G die nächste Generation CPU bzw. GPU eben für eine besonders nahe Platzierung vorgesehen werden (nicht zwangsweise am selben Package). Ich meine einfach die besonders kurze PCIe Verbindung.

Wenn an etwas zu zweifeln ist, dann am HBM. Der Interposer macht alles dicker und teurer, bei KBL-G braucht es nur eine kleine Brücke, bei so einer APU müsste die ganze GPU auf den Interposer. Zusätzlich braucht man erstmal einen Chip mit HBM Interface und wenn wir von 80-100 mm² GPUs reden, dann sind das einfach keine Kandidaten dafür. Außerhalb von Semi-Custom und 400$ Laptop APUs ergibt das keinen Sinn. Bei einer 100$ Low End GPU ist HBM viel zu teuer.

Ich habe auch so meine Zweifel bezüglich HBM. Das Argument bezüglich der Dicke incl. Package passt allerdings nicht so ganz. Das diesbezüglich optimierte Package von Kaby Lake G ist genau so dick wie das optimierte Package von Vega 20 (14nm). Intel hat eben ein EMIB ins Package eingelassen und AMD das ganze Interposter tiefer in das Package eingelassen (es ist in diesem Bereich besonders dünn). Auf dem selben Package dürfte das allerdings nicht funktionieren.

Setsul

2019-01-26, 01:02:37

Also einfach für ULP usw. erwarte ich eine monolithische APU.

Von 4C/8T + ~10 CUs was wohl kaum über 150 mm² kommt bis zu VII (331 mm²) ist es schon noch ein ganzes Stück, aber in dem Bereich ist ein Chiplet Design einfach praktischer. IFOP auf eine Low End GPU drauf, 8C Chiplet und I/O-Die gibts schon und fertig ist das Ding. Die Kosten IFOP auf den dGPU mitzuschleppen ohne es zu brauchen sind lächerlich im Vergleich zu dem was man an Entwicklungskosten und Masken spart.
Zum Flächenvorteil:
https://scr3.golem.de/screenshots/1801/KBL-G-CES-2018/KBL-G-CES-2018-03.png
Zwei getrennte Packages nehmen schon einiges an Platz weg.
Mal andersrum gefragt: Welchen Vorteil hätte AMD dadurch an den Packages rumzusägen um weniger Platz zu brauchen und sie näher zusammenrücken zu können, wenn sowohl GPU als auch CPU dann andere Packages brauchen (also 2 zusätzliche statt 1) und mit Intel CPUs oder nVidia GPUs verwendet werden können? AMD CPU und GPU direkt zusammenzupacken sollte für AMD einfach besser sein. Will man APU-Größe muss man dann alles bei AMD kaufen (oder KBL-G, aber damit kann AMD auch leben). Die zusammengesägte Variante führt eventuell zu mit Intel/nVidia gemischten Lösungen und muss mit Intel Iris konkurrieren die trotz eDRAM deutlich kleiner sein dürften, egal wieviel man am Package stutzt. Gerade im Bereich der gerade noch so mit RAM-Bandbreite zurechtkommt (~14 CUs oder so) nimmt allein der zusätzliche Speicher zu viel Platz weg.

Der Vergleich mit KBL-G bezog sich nur auf die Kosten. Egal ob IP oder EMIB dem Ganzen sind Grenzen gesetzt und ohne beides bekommt man die niedrige Dicke wesentlich einfacher. Hauptsächlich kostet einfach ein ganzer Interposer wesentlich mehr und die Vorteile von HBM müssen schon sehr wichtig sein, dass es sich im Vergleich zu GDDR5X/GDDR6 lohnt.

Eldoran

2019-01-26, 01:44:20

Von 4C/8T + ~10 CUs was wohl kaum über 150 mm² kommt bis zu VII (331 mm²) ist es schon noch ein ganzes Stück, aber in dem Bereich ist ein Chiplet Design einfach praktischer. IFOP auf eine Low End GPU drauf, 8C Chiplet und I/O-Die gibts schon und fertig ist das Ding. Die Kosten IFOP auf den dGPU mitzuschleppen ohne es zu brauchen sind lächerlich im Vergleich zu dem was man an Entwicklungskosten und Masken spart.

die Schätzung von >300mm² bezog sich auf hypothetische 8C + 20CU monster APUs...
Eben ein Äquivalent von Raven Ridge - 4C + 10CU (Zen2/Navi?) in 7nm hätte ich auf grob 160mm² geschätzt. Einfach da beim neuen Ryzen die Dies eher an der oberen Grenze des erwarteten herausgekommen sind und auch einiges kaum schrumpfen wird. Billig wäre aber schon das nicht - die Produktionskosten gehen da voraussichtlich grob 50% nach oben.
Bezüglich IFOP war das auch mein Grundgedanke - es kostet realtiv wenig so etwas einzubauen und man könnte es für derartige Sondermodelle nutzen. Ich bin mir nur nicht sicher, ob AMD grundsätzlich so etwas bauen möchte.

Zum Flächenvorteil:
https://scr3.golem.de/screenshots/1801/KBL-G-CES-2018/KBL-G-CES-2018-03.png
Zwei getrennte Packages nehmen schon einiges an Platz weg.
Mal andersrum gefragt: Welchen Vorteil hätte AMD dadurch an den Packages rumzusägen um weniger Platz zu brauchen und sie näher zusammenrücken zu können, wenn sowohl GPU als auch CPU dann andere Packages brauchen (also 2 zusätzliche statt 1) und mit Intel CPUs oder nVidia GPUs verwendet werden können? AMD CPU und GPU direkt zusammenzupacken sollte für AMD einfach besser sein. Will man APU-Größe muss man dann alles bei AMD kaufen (oder KBL-G, aber damit kann AMD auch leben). Die zusammengesägte Variante führt eventuell zu mit Intel/nVidia gemischten Lösungen und muss mit Intel Iris konkurrieren die trotz eDRAM deutlich kleiner sein dürften, egal wieviel man am Package stutzt. Gerade im Bereich der gerade noch so mit RAM-Bandbreite zurechtkommt (~14 CUs oder so) nimmt allein der zusätzliche Speicher zu viel Platz weg.

Naja der intel Vergleich wird extrem durch das RAM verzerrt. Wenn man es mit Kaby Lake + Vega vergleichen würde, wäre der Unterschied nicht sonderlich gross ausgefallen. Der offensichtlichste Vorteil wäre schlicht und einfach, dass sich AMD erspart zusätzlich zu den separaten Packages auch noch ein kombiniertes zu verkaufen. Man braucht nur schauen wie das bei Kaby Lake G läuft - für portable braucht das ganze eigentlich schon zu viel Strom und ist zu gross, andererseits muss es besonderen Platzbedürfnissen unterliegen, sonst wäre wieder die billigere Variante mit separaten Packages effizienter. Es ist ein Nischenprodukt - bislang war das nicht gerader der Bereich für den sich AMD besonders interessiert hätte. Es sei denn ein grosser Kunde will das so und zahlt - semicustom.

amdfanuwe

2019-01-26, 03:28:54

Betrachtet es mal aus OEM Sicht. Würdet ihr lieber 3 Komponenten, CPU, GPU und VRAM einkaufen ,testen, und auf einem relativ großem, komplexem Mainboard verbauen oder eher eine Komponente auf einem einfacherem Mainboard?

amdfanuwe

2019-01-26, 03:46:29

Kaby Lake G ... ist ein Nischenprodukt - bislang war das nicht gerader der Bereich für den sich AMD besonders interessiert hätte. Es sei denn ein grosser Kunde will das so und zahlt - semicustom.
Bislang hat AMD noch nicht genug in der Kasse und nicht die besten Beziehungen zu den OEMs um so ein Produkt auf Verdacht zu bringen. Einen Flop kann sich AMD kaum leisten. Man sieht ja, wie zögerlich AMD von den OEMs ins Programm aufgenommen wird.

HOT

2019-01-26, 05:55:18

mczak

2019-01-26, 06:02:00

Wenn schon eine APU mit HBM dann gleich richtig und den normalen Speicher weglassen - Speicher wird ja eh (in Notebooks) meist verlötet, und das würde dann effektiv Platz sparen.
Leider wäre das ein Nischenprodukt (nur besonders kleine Notebooks) und teuer, da bräuchte man dann wohl sogar 16 GB HBM statt nur 8 (was die meisten Notebooks heutzutage haben), und 16 GB Stacks sind mit "HBM 2" noch nicht mal vorgesehen und wären eh viel zu teuer (mehrere Stacks hingegen wären auch nicht sinnvoll, schon einer bietet definitiv mehr als genug Bandbreite).
Und wo bleibt eigentlich low-cost HBM, davon habe ich schon Ewigkeiten nichts mehr gehört (hätte immer noch genug Bandbreite), hat wohl die Kosten auch nicht wirklich gesenkt...
Für ddr5 ist es leider auch noch zu früh (reicht wohl noch nicht mal für den Nachfolger von Renoir...), das würde ordentlich was bringen und wäre eigentlich derzeit ziemlich ausreichend für so eine "normale" APU (jedenfalls in einer dual-channel Konfiguration).

HOT

2019-01-26, 06:33:13

HBM ist bis 24GB pro Stapel vorgesehen...

amdfanuwe

2019-01-26, 06:34:37

Was soll dieses Schwadronieren immer noch über diese Chiplet APU? Su hat doch unlängst klar gemacht, dass es keine Chiplet APU auf Matisse Basis genen wird. Ergo ist Renior automatisch monolithisch, da gibts niix zu diskutieren.
Klar, Matisse ohne GPU.
Picasso kleine 12nm APU.
Renoir kleine 7nm APU.

Und wer sagt, dass nicht noch an einer großen APU im Labor gewerkelt wird?

HOT

2019-01-26, 06:41:47

Mit Vermeer als Grundlahe frühestens. Glaub ich aber auch nicht dran, da der den I/O-Chip einfach erben wird. Eine größere Chiplet APU macht erst ab DDR5 Sinn und das dauert bis frühestens 2021.

amdfanuwe

2019-01-26, 06:51:15

Wenn schon eine APU mit HBM dann gleich richtig und den normalen Speicher weglassen - Speicher wird ja eh (in Notebooks) meist verlötet, und das würde dann effektiv Platz sparen.
Leider wäre das ein Nischenprodukt (nur besonders kleine Notebooks) und teuer, da bräuchte man dann wohl sogar 16 GB HBM statt nur 8 (was die meisten Notebooks heutzutage haben), und 16 GB Stacks sind mit "HBM 2" noch nicht mal vorgesehen und wären eh viel zu teuer (mehrere Stacks hingegen wären auch nicht sinnvoll, schon einer bietet definitiv mehr als genug Bandbreite).
Was heißt teuer? Vielleicht noch im Moment. Wenn HBM im Preis noch etwas runter geht gibt es irgendwann den break even an dem die Vorteile ( einfacheres Boardlayout, geringerer Flächenbedarf, einfachere Kühlung, geringeren logistischen Aufwand etc.) den Aufpreis zur HBM Lösung rechtfertigen.
Hast ja schon gesagt, dass an einer Billig HBM Lösung gearbeitet wird. Wer weiß, was da grad in den Laboren ausgetüftelt wird. Bei Fitji war man ja auch ziemlich überrascht wegen der HBM Lösung.

amdfanuwe

2019-01-26, 07:00:35

Mit Vermeer als Grundlahe frühestens.
Bloß weil Lisa sagte, dass Matisse keine GPU bekommt, heißt das doch nicht, dass sie keinen I/O incluse GPU bringen könnten.
Sozusagen ein Picasso ohne CPU Cores, dafür IF nach außen für CPU Chiplets.
AMD könnte damit ordentlich überraschen und könnten auch für Mobile eine 8 Core APU vorstellen.
Nachdem sie Picasso vorgestellt haben frag ich mich nur, wie sie die benennen könnten.

robbitop

2019-01-26, 07:30:16

Hatte Su nicht gesagt, dass es keine 3xxx Chiplet APU geben wird? Die APUs kommen doch immer erst zum Jahresende und haben seit 2017 immer eine Modellnummer höher als der im gleichen Jahr eingeführte cpu topdog.
Ryzen 1700 war SR und Ryzen 2400G RR. Gleiche Gen. 14nm.
Ryzen 2700 war PR und Ryzen 3xxxG Picasso. Gleiche GEn. 12 nm.
Ryzen 3700 wird Matisse und Ryzen 4xxx wahrscheinlich Renoir. Gleiche Gen. 7 nm.

Wenn es wirklich so ist, wie ich mich erinnere - bitte mich hier korrigieren! - dann hatte Su technisch keine Aussage über Renoir sondern über Picasso betrieben? In Bezug auf Chiplets?

MSABK

2019-01-26, 08:08:55

amdfanuwe

2019-01-26, 08:17:59

Meines Wissens nach sagte SU, dass es der freie Platz bei Matisse nicht mit einem GPU Chiplet versehen wird.
Ergibt auch keinen Sinn ein ~11 CU Chiplet zu fertigen und Chiplets mit mehr CUs benötigen eigenen Speicher und passen dann nicht mehr bei Matisse auf AM4.

Fände es schon etwas komisch, das AMD keine 6/8 Core APU bringen wird wobei das mit etwas GPU im I/O einfach machbar wäre. Intel hat schließlich auch schon 6 Kern Mobile und 8 Kern Mobile sind angekündigt. Wäre für AMD die Gelegenheit auch hier "erster" zu rufen.

Kann man natürlich auch Matisse mit 35W TDP verbauen und dazu dedizierte GPU.

amdfanuwe

2019-01-26, 08:36:58

Glaube im mobilen Sektor warten echt alle auf was neues.
Naja, die Home Office Nutzer und die das Notebook nur als Mediaplayer nutzen, sind eigentlich schon mit 2 flotten Kernen gut ausgestattet.
Die Gamer kriegen den Hals eh nicht voll.
Ich denke, aus eigener Erfahrung, mehr an die Entwickler die ihre multithreaded Client Server Software auf 2 oder mehr virtuellen Maschinen testen müssen. Da wirds schon nervig auf einem 4 Core Notebook das dann vornehmlich mit Taskswitching beschäftigt ist. Wer Anwendungen hat, die viele Kerne nutzen, der wird dankbar sein.

MSABK

2019-01-26, 08:43:21

Opprobrium

2019-01-26, 09:19:17

Da habe ich ja z.B Gerüchte gelesen, dass Microsoft nach Alternativen zu Intel schaut. Wahrscheinlich weil sich da nichts bewegt. Da finde ich sollten die 7nm APUs zeitnah eine Antwort sein.
Wenn da was dran sein sollte, dann wäre das vermutlich Semi-Custom. MS ist da ja durch die XBox ohnehin schon Kunde.

amdfanuwe

2019-01-26, 09:27:32

Da rechne ich eher Anfang 2020 mit einer 7nm APU.
Erstmal müssen sie jetzt 7nm Navi fertigstellen und rausbringen, dann brauchen sie noch Erfahrung mit 7nm I/O. Wenn das soweit ist, können sie an die monolithische APU gehen. Der Vorteil bei den Chiplets besteht ja auch darin, dass ein High Performance für die CPU und ein High Density Prozess für die GPU genutzt werden kann. Hoffentlich laufen sie nicht wieder in Probleme, die sie schon bei Llano hatten.

HOT

2019-01-26, 11:04:42

Naja, die Home Office Nutzer und die das Notebook nur als Mediaplayer nutzen, sind eigentlich schon mit 2 flotten Kernen gut ausgestattet.
Die Gamer kriegen den Hals eh nicht voll.
Ich denke, aus eigener Erfahrung, mehr an die Entwickler die ihre multithreaded Client Server Software auf 2 oder mehr virtuellen Maschinen testen müssen. Da wirds schon nervig auf einem 4 Core Notebook das dann vornehmlich mit Taskswitching beschäftigt ist. Wer Anwendungen hat, die viele Kerne nutzen, der wird dankbar sein.
Alter, red ich chinesisch? Wenn Su sagt, dass es mit Matisse keine APU geben wird, schließt das doch den I/O-Chip mit ein. Das heißt im Klartext es gibt keinen I/O-Chip der das kann. Und wie gesagt rechne ich fest damit, dass Vermeer den I/O-Chip einfach übernimmt, das wird also auch nix mit deiner Chiplet-APU.
Erst mit Zen4 wirst du einen neuen I/O-Chip sehen (vermutlich in 7nm), der DDR5, PCIe5 und USB 3.2 kann, der wird dann sicherlich auch GPU-Gedöns implementieren, aber eben nicht vorher.
die APUs sind monolithisch, jedenfalls solange AM4 besteht. Renoir wird AM4 sein und damit auf keinen Fall mehr als 14CUs bieten, man wird mit aller Macht versuchen unter 150mm² zu bleiben damit, damit die Kosten im Griff bleiben. Das wird ganz klassischen 4 Kerne und 14 CUs sein. Andere APUs brauchst du bis vor Ende 2021 nicht zu erwarten, Punkt.
Alle weiteren APUs sind semi-Custom, aber nicht für den PC-Markt.

Brillus

2019-01-26, 12:49:42

Ich persönlich finde, AMD muss schon gegen Herbst eine 7nm APU bringen. Man sieht das Intel in der Produktion Probleme hat und das muss man einfach nutzen. Glaube im mobilen Sektor warten echt alle auf was neues.

Ich glaube selbst wenn sie wollten könnten sie nicht, APUs für OEM brauchen nochmal mehr Chips als Ryzen und irgendwo ist die Fertigungskapazitäten am Ende.

SKYNET

2019-01-26, 13:17:46

Ich glaube selbst wenn sie wollten könnten sie nicht, APUs für OEM brauchen nochmal mehr Chips als Ryzen und irgendwo ist die Fertigungskapazitäten am Ende.

ehm, sie haben/können die kapazitäten haben die apple freigemacht hat... das sollte mehr als genug sein.

amdfanuwe

2019-01-26, 13:36:24

Andere APUs brauchst du bis vor Ende 2021 nicht zu erwarten, Punkt.

LOL, der Weise hat gesprochen.

Setsul

2019-01-26, 14:31:43

@Eldoran:
Klar verzerrt der RAM das, aber AMD müsste entweder Vega mit vollem Interposer verbauen was alt und teuer ist oder eine Low End GPU mit HBM entwickeln. Beides wenig sinnvoll.

KBL-G ist allein durch den Preis sehr eingeschränkt. Aber 4C mit hohem Takt + 20-24 CUs auf 14nm frisst natürlich auch Strom. Zen2 mit 16 CUs oder so auf 7nm wären auch bei Notebook TDP kein Problem. 6C oder sogar 8C APUs mit etwas mehr CUs als auf dem Desktop sinnvoll wären und dafür mit niedrigerem Takt und/oder externem Speicher scheinen schon nützlich. Im Gegensatz zu KBL-G würde es auch nicht mehr kosten als separate CPU und GPU mit Speicher, eher weniger, einfach weil HBM wegfällt. OEM und AMD sind beide glücklicher wenn die Dinger im Paket verkauft werden, also wieso sollte AMD sie trennen? Platzersparnis und evtl. teilweise oder komplette Speicherersparnis ist ein Bonus.
Im Gegensatz zu >500$ "APUs" mit eDRAM oder HBM wie Intel sie verkauft ist das auch kein Nischenprodukt. Mobile APUs mit mehr als 4 Kernen und mehr als 10 CUs sind wirklich nichts verrücktes, einfach nur ein logischer Schritt um 7nm voll auszunutzen.

@Rest:
Bezüglich Chiplet APU auf AM4: Bedenkt dass es für Desktop nur bedingt sinnvoll ist. Wer nur geringe Ansprüche hat ist mit einer monolithischen <=4C + <=10 CU APU völlig zufrieden. Für Gamer ist die APU uninteressant und für Workstations sind 16 Kerne viel wichtiger als ein paar Euro zu sparen dadurch dass man keine GPU braucht.
Aber für Mobile ist 6 oder 8C + ~16 CU sehr interessant und mit Chiplets wesentlich billiger zu realisieren als 2 monolithische Dies aufzulegen oder 2C und 4C + 6 CU APUs aus einem riesigen 8C + 16CU Die zu schnitzen. Mit 12-14 CUs kann man wahrscheinlich gerade so noch mit DDR4 auskommen, aber drüber, wo es sehr interessant wird weil Intel außer KBL-G nichts vergleichbares hat, muss AMD wohl ein bisschen GDDR6 dazugeben und das ist auf AM4 weder sinnvoll noch praktikabel, aber für Mobile völlig normal.

Nightspider

2019-01-26, 18:05:18

Alter, red ich chinesisch? Wenn Su sagt, dass es mit Matisse keine APU geben wird

Quelle?

Soweit ich weiß wurde nur gesagt das auf dem gezeigten Prozessor auf die freie Fläche keine GPU wandern wird.

Es wird also keine Chiplet APU geben, in dieser Generation.

Eine mobile APU im monolithschen Design wird also kommen.

Unicous

2019-01-26, 18:28:58

Ich möchte dazu sagen: HOT hat das Konzept des Konjunktivs offensichtlich immer noch nicht erfasst und seine prophetischen Voraussagungen sind wie wir ja alle wissen in der Vergangenheit immer Realität geworden, daher macht ihr euch alle der Ketzerei schuldig, wenn ihr ihm widersprecht.:eek:

(Ich möchte jedoch anmerken, dass ich es für extrem unwahrscheinlich halte, dass AMD zum einen eine iGPU in das Chiplet integriert und darüber hinaus ist es extrem unwirtschaftlich eine APU mit insgesamt 3 Chips zu realisieren, geschweige denn mit 2 Chips wenn ein hypothetischer monolitischer Chip nur sagen wir mal zwischen 100 und 150mm² groß wäre, bitte bedenken, das Raven Ridge lediglich 210mm² groß ist.)

basix

2019-01-26, 19:09:17

APU (Simpsons anyone ;)) = Monolithisch. Alles andere ist Zukunftsmusik. Jetzt sollten wir eher darüber diskutieren, wie üppig sie ausfallen wird ;)

amdfanuwe

2019-01-26, 19:34:30

ist es extrem unwirtschaftlich
Das können wir wohl wirklich nicht beurteilen. Nehme nicht an, dass du Zahlen zum Yield, Pakage Kosten, HBM Preise, möglichen Verkaufspreis, mögliche Absatzmenge etc. hast.
Somit können wir nur spekulieren, was machbar ist und die wirklich unsinnigsten Möglichkeiten ausschließen.
Kann sein, dass AMD mit ROME, Matisse, Picasso und Navi und der Entwicklung zukünftiger Produkte für dieses Jahr voll ausgelastet ist und wirklich nichts anderes mehr kommt.

Unicous

2019-01-26, 20:10:46

Du behauptest also es wäre wirtschaftlich einen, wie groß soll der I/O Die sein 120mm²? oder mehr, plus einen sagen wir ähnlich so großen Die wie den Zen 2 Die auf ein Package zu packen anstatt einen etwas größeren Die und dann nur einen Chip zu haben?

Man hat doch im Gegensatz zu den Epyc/TR/Ryzen CPUs nicht das Problem der Kernskalierung für einen Sockel. Deswegen wurde das doch überhaupt auf den I/O Die ausgelagert.
Raven Ridge im Vergleich zu SR/PR deutlich abgespeckt, der I/O Die wäre also wahrscheinlich overkill.

Falls AMD die APUs aufblasen will und mehr Shadereinheiten und vllt. Sogar mehr Kerne unterbringen will, würde der Schritt Sinn machen, so wie ich das sehe wird AMD aber in der Hinsicht, bis auf Weiteres, deutlich konservativer bleiben.

Interessant wird es erst wenn AMD semi-custom Chips in den Mainstream bringt, also außerhalb der "Konsolen"-Chips, versteht sich.

amdfanuwe

2019-01-26, 20:58:02

Du behauptest also es wäre wirtschaftlich einen, wie groß soll der I/O Die sein 120mm²? oder mehr, plus einen sagen wir ähnlich so großen Die wie den Zen 2 Die auf ein Package zu packen anstatt einen etwas größeren Die und dann nur einen Chip zu haben?

Du behauptest also, Matisse ist nicht wirtschaftlich?

Falls AMD die APUs aufblasen will und mehr Shadereinheiten und vllt. Sogar mehr Kerne unterbringen will, würde der Schritt Sinn machen,

Was denn nun? Wirds dann plötzlich wirtschaftlich?
Ich dachte wir wären uns einig, dass eine kleine monolithische APU kommen wird. Ging doch ansonsten um eine potentielle große APU.
so wie ich das sehe wird AMD aber in der Hinsicht, bis auf Weiteres, deutlich konservativer bleiben.

Raub mir nicht die letzte Hoffnung :-)

Interessant wird es erst wenn AMD semi-custom Chips in den Mainstream bringt, also außerhalb der "Konsolen"-Chips, versteht sich.
Dann ist das kein semi-custom mehr.

SKYNET

2019-01-27, 00:29:45

https://www.tomshw.de/2019/01/26/12-kerne-und-24-threads-amd-ryzen-3000-matisse-gesichtet/

Linmoum

2019-01-27, 00:42:05

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11908609#post11908609

Ganz knapp zu spät dran. ;)

SKYNET

2019-01-27, 01:32:57

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11908609#post11908609

Ganz knapp zu spät dran. ;)

böööhhhh X-D

grad mal gerechnet... der hat 5% bessere pro/takt leistung mit 2666er SC speicher, als mein 2700X mit 3600 C14 DC und gnadenlos optimierten subtimings... das teil wird böse :eek:

ist gekauft würd ich sagen... ;D

MadPenguin

2019-01-27, 08:54:28

https://twitter.com/mustmann/status/1089238684480782336?s=19

Keine Ahnung ob schon angesprochen. Doppelter L3 Cache scheinbar bestätigt

robbitop

2019-01-27, 09:09:15

HOT

2019-01-27, 10:35:50

Das würd ich nicht überbewerten. Unter dem Graph hat jemand vermerkt, dass langsamer RAM bei einem ES zum Einsatz kam, der hält die Latency für ausgesprochen gut für die Verhältnisse. Ich bin geneigt dem zuzustimmen.
Ein Zen1 hat auch 100ns, wenn du RAM auf SPD-Timings laufen lässt. Ich würd mal damit rechnen, dass das kein Unterschied zu jetzt ist.

Pirx

2019-01-27, 10:46:42

mironicus

2019-01-27, 11:17:06

Wie der wohl abgeht, wenn der mit optimalen Settings läuft. Ich könnte mir vorstellen, dass der in Spielen bei gleichem Takt auch Intel schlagen kann.

robbitop

2019-01-27, 12:23:13

Du immer mit deiner Latenz. Als ob das DAS Kriterium wäre. Dort wurde außerdem nur ein Riegel DDR4 2666 verwendet.
Polemik nützt niemandem. Es ist ein Kriterium von vielen. Aber kein unwichtiges. Die beste mArch mit der höchsten Grund-IPC nutzt wenig, wenn sie auf die Instructions warten muss. Sind die Instructions im Cache, kein Problem. Hängt also völlig von der Hitrate der jeweiligen Applikation ab, ob Memorylatency wichtig ist. Je besser das Prefetching und je größer der Cache, desto höher die Hitrate.
Den L3 Cache hat man bei Matisse nicht umsonst vergrößert. Mehr Datenlokalität = bessere Hitrate. Ist ja bei SKL-X auch so gewesen - nur dass dort der L2 vergrößert wurde.

Es gibt viele Applikationen - so ziemlich die meisten - die kein Problem mit der Hitrate haben. Es gibt auch viele Spiele, bei denen es so ist. Es gibt aber auch sehr viele bei denen es eben doch ein Problem ist. Das lässt sich nicht wegdiskutieren.

Genau das war damals der Grund dafür, warum der i7 5775C in einigen Spielen so viel stärker pro Takt zu sein schien als die CPUs ohne L4.
Auch profitiert Ryzen enorm von besserer Memorylatency. Dargo hatte verschiedenste Messungen gemacht, die signifikant waren. Ich habe mit Haswell ähnliches nachgestellt.
Das war auch der Grund, warum Summit Ridge in Anwendungen gegen BDW sehr gut dastand und in einigen Spielen deutlich schlechter abschnitt. Gleiches bei SKL-X vs. SKL/CFL/CFL-R. (dort sogar exakt gleiche mArch und trotzdem taktnormiert deutlich langsamer in vielen Spielen). Mit 20 ns mehr war das kein Wunder. Wenn man mit normierter Memorylatency und normiertem Takt messen würde, läge Ryzen deutlich näher an den Intel Pendants.

Das würd ich nicht überbewerten. Unter dem Graph hat jemand vermerkt, dass langsamer RAM bei einem ES zum Einsatz kam, der hält die Latency für ausgesprochen gut für die Verhältnisse. Ich bin geneigt dem zuzustimmen.
Ein Zen1 hat auch 100ns, wenn du RAM auf SPD-Timings laufen lässt. Ich würd mal damit rechnen, dass das kein Unterschied zu jetzt ist.
Der 2700X muss auch relativ grottigen RAM haben. 80 ns ist nicht besonders gut für Ryzen. Sind IMO default Werte und kein hoher RAM Takt. Optimiert kommt man IIRC auf ~60...65 ns. Dafür braucht es aber schon einiges an Mehrtakt und Timingtuning.

Lehdro

2019-01-27, 12:31:35

Die Memorylatency sieht aber nicht so toll aus. Überschwinger auf 100 ns (ggf weil er da auf den L3 des Nachbar DIEs zugreift?) und dann runter auf 90 ns.
Der 2700x hat 80ns. Hat also auch grottigen Speicher. Bei sehr gutem liegt er auch rund 60 ns. Ein Ringbus Core liegt grob 15 ns vorn ggü PR. Matisse scheint wegen des externen IO Dies nochmal 10 ns draufzupacken. Hoffentlich hilft der verdoppelte L3, diesen Malus auszugleichen.
Ich schmeiß mal meinen Senf dazu:

https://www.userbenchmark.com/UserRun/14108034 (100ns)
https://www.userbenchmark.com/UserRun/14140706 (61ns)

Selber PC, selbe Konfiguration, nur an zwei unterschiedlichen Tagen gemacht. Schaut man sich die Benches an, auch andere mit derselben CPU, so erkennt man das es 50/50 ist, in welcher Region der Latenz man landet. Entweder >100ns oder halt sub 70ns. Ist somit nur dann etwas wert als Benchmark, wenn man mal mehrere Ergebnisse desselben System kontrolliert - da die Schwankung existentiell groß ist.

Wichtig für die Interpretation ist zudem Folgendes: Können die CPU Dies ohne den Umweg über den I/O Die kommunizieren, oder müssen sie immer den extra hop nehmen? Ist IF noch an den RAM Takt gekoppelt?

Wenn ich das bedenke bewerte ich die Latenz folgendmaßen:
Wenn direktes IF zwischen den CPU und IF noch an RAM gekoppelt:
- sehr gute Latenz für nur DDR4 2666

Wenn kein direktes IF zwischen den CPUs, sondern nur über I/O Die und IF noch an RAM gekoppelt:
- extrem gute Latenz für nur DDR4 2666

Zur Info: Mit DDR4 2666 erreicht mein Threadripper mit guten Timings cross-Die >115ns, mit "normalen" (XMP) Latenzen sind es dann absurde 125ns+ - demzufolge ist Zen 2 auf jeden Fall eine deutliche Verbesserung.

Screemer

2019-01-27, 12:32:24

Der 2700X muss auch relativ grottigen RAM haben. 80 ns ist nicht besonders gut für Ryzen. Sind IMO default Werte und kein hoher RAM Takt. Optimiert kommt man IIRC auf ~60...65 ns. Dafür braucht es aber schon einiges an Mehrtakt und Timingtuning.
Das ist schon das höchste der Gefühle bei Ryzen+ mit >3200 ddr4 cl14 und massiv otpimierten Timings. Auch kannst solche Werte mit ryzen vergessen. Da bewegst dich eher im Feld von 65-70ns mit handoptimierten Timings. Ootb mit 2933 liegst du im bereich von 75-80ns und das auch mit r+.

Der_Korken

2019-01-27, 12:38:02

Woher stammt die Info, dass der RAM mit 2666Mhz lief? Auf der userbenchmark-Seite steht "6.1 GB free of 4 GB @ 1.3 GHz". Nimmt man zum Vergleich ein aktuelles, steht dort sowas wie

28.8 GB free of 32 GB @ 3.2 GHz https://cpu.userbenchmark.com/UserRun/13626213
12.6 GB free of 16 GB @ 3.2 GHz https://cpu.userbenchmark.com/UserRun/14153804
123.7 GB free of 128 GB @ 4 GHz https://cpu.userbenchmark.com/UserRun/13278650

Wenn das ES mit nur 1,3Ghz lief, wären die Ergebnisse phänomenal. Vor allem weil ein dermaßen lahmer RAM-Takt auch das IF total ausbremsen könnte. Wahrscheinlich aber nur ein Auslese-Fehler (wegen Single-Channel?), weil die 22GB/s Durchsatz sonst gar nicht erreicht werden könnten.

Lehdro

2019-01-27, 12:43:26

Wahrscheinlich aber nur ein Auslese-Fehler (wegen Single-Channel?), weil die 22GB/s Durchsatz sonst gar nicht erreicht werden könnten.
Bei mir misst Userbenchmark auch nur 2/4 Channeln aus...

bun

2019-01-27, 12:59:49

https://twitter.com/mustmann/status/1089238684480782336

Vergleichsgrafik ist ganz anschaulich.

r-or

2019-01-27, 13:43:17

Ok, das bedeutet L4-cache im IO-chip 'unconfirmed' :D
Schade.

robbitop

2019-01-27, 14:23:45

Ich schmeiß mal meinen Senf dazu:

https://www.userbenchmark.com/UserRun/14108034 (100ns)
https://www.userbenchmark.com/UserRun/14140706 (61ns)

Selber PC, selbe Konfiguration, nur an zwei unterschiedlichen Tagen gemacht. Schaut man sich die Benches an, auch andere mit derselben CPU, so erkennt man das es 50/50 ist, in welcher Region der Latenz man landet. Entweder >100ns oder halt sub 70ns. Ist somit nur dann etwas wert als Benchmark, wenn man mal mehrere Ergebnisse desselben System kontrolliert - da die Schwankung existentiell groß ist.

Wichtig für die Interpretation ist zudem Folgendes: Können die CPU Dies ohne den Umweg über den I/O Die kommunizieren, oder müssen sie immer den extra hop nehmen? Ist IF noch an den RAM Takt gekoppelt?

Wenn ich das bedenke bewerte ich die Latenz folgendmaßen:
Wenn direktes IF zwischen den CPU und IF noch an RAM gekoppelt:
- sehr gute Latenz für nur DDR4 2666

Wenn kein direktes IF zwischen den CPUs, sondern nur über I/O Die und IF noch an RAM gekoppelt:
- extrem gute Latenz für nur DDR4 2666

Zur Info: Mit DDR4 2666 erreicht mein Threadripper mit guten Timings cross-Die >115ns, mit "normalen" (XMP) Latenzen sind es dann absurde 125ns+ - demzufolge ist Zen 2 auf jeden Fall eine deutliche Verbesserung.
Threadripper @UMA? Beim einen Bench sieht es so aus als hätte Die 0 über den IMC von Die 1 zugegriffen. Das würde die höhere Zugriffszeit erklären.
Das gibt es bei PR/SR und Matisse und Rome dann nicht (mehr).
Ansonsten sind zumindest die Aida64 Benches da aus meiner Erfahrung sehr reproduzierbar.

Woher stammt die Info, dass der RAM mit 2666Mhz lief? Auf der userbenchmark-Seite steht "6.1 GB free of 4 GB @ 1.3 GHz". Nimmt man zum Vergleich ein aktuelles, steht dort sowas wie

28.8 GB free of 32 GB @ 3.2 GHz https://cpu.userbenchmark.com/UserRun/13626213
12.6 GB free of 16 GB @ 3.2 GHz https://cpu.userbenchmark.com/UserRun/14153804
123.7 GB free of 128 GB @ 4 GHz https://cpu.userbenchmark.com/UserRun/13278650

Wenn das ES mit nur 1,3Ghz lief, wären die Ergebnisse phänomenal. Vor allem weil ein dermaßen lahmer RAM-Takt auch das IF total ausbremsen könnte. Wahrscheinlich aber nur ein Auslese-Fehler (wegen Single-Channel?), weil die 22GB/s Durchsatz sonst gar nicht erreicht werden könnten.
Ggf wg DDR? DDR2666 ist ja 1333MHz.

Es gibt ja auch eigentlich gar keinen ddr41333 MHz und würde auch gar keinen Sinn machen, den absichtlich niedriger zu takten.

——

Man muss natürlich auf richtige Ergebnisse warten. Aber dieses sieht zunächst so aus als wenn es für den ausgelagerten IMC eine kleine Penalty gibt. Wäre auch merkwürdig wenn es nicht so wäre. Zaubern kann AMD auch nicht.
Aber iirc soll der Prefetcher besser geworden sein und der L3 ist größer. Entsprechend kann man diesen Malus sicherlich wettmachen. Der erhöhte Takt und die generellen anderen Architekturverbesserungen sollten schon entsprechende Leistungssteigerungen mit sich bringen.

Wenn man diese enorme Skalierbarkeit haben will und dies immer weiter treiben will, muss man halt prinzipbedingt damit rechnen, dass man etwas mehr Latenz hat als der Ringbus. Aber Intel hat ja bei den hedts nicht aus Spaß auf ein Mesh als Fabric gewechselt.
Irgendeinen sauren Apfel gibt es immer.

Der_Korken

2019-01-27, 15:16:31

Ggf wg DDR? DDR2666 ist ja 1333MHz.

Aber warum wird bei anderen System der effektive Takt (3200Mhz) angegeben? Wie gesagt, vermutlich ein Auslesefehler, aber etwas komisch eben doch.

SKYNET

2019-01-27, 15:36:54

robbitop

2019-01-27, 15:51:24

Ein bisschen weniger Latenz macht ja auch Sinn, weil L1, L2 und in AMDs Fall auch L3 mit Kerntakt laufen. Und genau diese Latenzen liegen in Addition mit dem Zugriff auf den RAM weil ja vorher immer erst Caches abgefragt werden. Das dürften aber nur wenige ns sein.
Wenn es mehr ist, läuft da noch was anderes komisches (ein Automatismus?) mit irgendwelchen Latenzen/Taktgebern ab.

Kann das jemand anders verifizieren?

Der_Korken

2019-01-27, 15:53:39

oder mal beispiel mein 1500X --> alles stock, speicher auf 2666MHz --> 98ns, CPU auf 4.1GHz, speicher mit gleichen timings wie 2666(=C16, keine optimierungen) auf 3200 --> 72.8ns :)

Das ergibt technisch keinen Sinn. Das einzige, was mit steigendem CPU-Takt schneller wird, ist der Cache. 3Ghz sind 0,33ns pro Takt, 4Ghz sind 0,25ns. Der L3-Cache hat ~40 Takte, was zusammen 3,33ns Unterschied ergibt.

Lehdro

2019-01-27, 15:55:03

Threadripper @UMA? Beim einen Bench sieht es so aus als hätte Die 0 über den IMC von Die 1 zugegriffen. Das würde die höhere Zugriffszeit erklären.
Ja, genau so ist das. Allerdings ist das zufällig ob der Bench das macht, oder halt nicht:

Ansonsten sind zumindest die Aida64 Benches da aus meiner Erfahrung sehr reproduzierbar.

AIDA hat da tatsächlich keine Probleme, da kommen immer um die 100 GB/s Transferraten und Latenzen im 64ns (+/- 1ns) Rahmen bei raus.

SKYNET

2019-01-27, 15:55:19

Das ergibt technisch keinen Sinn. Das einzige, was mit steigendem CPU-Takt schneller wird, ist der Cache. 3Ghz sind 0,33ns pro Takt, 4Ghz sind 0,25ns. Der L3-Cache hat ~40 Takte, was zusammen 3,33ns Unterschied ergibt.

ist einfach so bei ryzen, mehr CPU takt = stark fallende latenzen

robbitop

2019-01-27, 16:28:14

Ja, genau so ist das. Allerdings ist das zufällig ob der Bench das macht, oder halt nicht:

AIDA hat da tatsächlich keine Probleme, da kommen immer um die 100 GB/s Transferraten und Latenzen im 64ns (+/- 1ns) Rahmen bei raus.

Naja @UMA ist das Verhalten, auch dass es quasi zufällig ist, nachvollziehbar. Mal nimmt er den Umweg über den 2. Core und mal nicht. AIDA scheint da schlauer zu sein. In NUMA müsste es anders sein. Aber wie gesagt für Matisse irrelevant.

ist einfach so bei ryzen, mehr CPU takt = stark fallende latenzen

Bis dato ist dieses Verhalten nur bei deinem System so. Eine Verifizierung, dass es ein generelles Verhalten ist, ist noch nicht vorhanden. Wer weiß was beim bios deines Boards da für Automatismen ablaufen. Und selbst wenn es bei PR so wäre (es also durch einen zweiten User bestätigt ist), heißt das nich lange nicht, dass das auch für Matisse gilt.

SKYNET

2019-01-27, 16:57:32

Naja @UMA ist das Verhalten, auch dass es quasi zufällig ist, nachvollziehbar. Mal nimmt er den Umweg über den 2. Core und mal nicht. AIDA scheint da schlauer zu sein. In NUMA müsste es anders sein. Aber wie gesagt für Matisse irrelevant.

Bis dato ist dieses Verhalten nur bei deinem System so. Eine Verifizierung, dass es ein generelles Verhalten ist, ist noch nicht vorhanden. Wer weiß was beim bios deines Boards da für Automatismen ablaufen. Und selbst wenn es bei PR so wäre (es also durch einen zweiten User bestätigt ist), heißt das nich lange nicht, dass das auch für Matisse gilt.

schau einfach mal in passenden thread bei HWL... es ist nicht nur bei mir so ;)

robbitop

2019-01-27, 17:06:19

Hast du einen Link parat? :)
Klingt als würde die Agesa dann sowas machen - heisst aber noch nicht, dass das auch auf Matisse zutrifft. Zu hoffen wäre es ja.

Langlay

2019-01-27, 17:07:11

Bis dato ist dieses Verhalten nur bei deinem System so. Eine Verifizierung, dass es ein generelles Verhalten ist, ist noch nicht vorhanden. Wer weiß was beim bios deines Boards da für Automatismen ablaufen. Und selbst wenn es bei PR so wäre (es also durch einen zweiten User bestätigt ist), heißt das nich lange nicht, dass das auch für Matisse gilt.

Dem ist wirklich so.

https://abload.de/img/ram25ivjk6.jpg

https://abload.de/img/ram30gkkvn.jpg

https://abload.de/img/ram35mvkzi.jpg

https://abload.de/img/ram40tlkkr.jpg

https://abload.de/img/ram435xejwq.jpg

Die RAM Settings waren immer gleich. Leider liest er das im abgesicherten Modus nicht aus, auch der Ryzen Timing Checker funzt im angesicherten Modus nicht. Also ich müsst mir da vertrauen.

/edit

Das ist die RAM Settings

https://abload.de/img/ramsettingsdujxc.jpg

robbitop

2019-01-27, 17:10:52

interessant, dass der Effekt asymptotisch läuft.

Langlay

2019-01-27, 17:16:41

Der Wert bei 4.0 GHz kam mir auch etwas spanisch vor, aber in mehreren Durchläufen kam ich immer auf das gleiche Ergebnis. (+-0.2ns)

bun

2019-01-27, 19:29:48

AdoredTV - What is Zen 2? - https://www.youtube.com/watch?v=wjVjHce8uME

HOT

2019-01-27, 20:00:00

Normaler DDR2666-RAM mit Ryzen 1k hat 86-90ns, mit PR so 80-82ns. Mit 2133 dürften beide so 95-100ns haben. Das Zen2-ES wird wohl einfach mit letzterem gelaufen sein.

robbitop

2019-01-27, 20:17:21

Der Typ mit seinem komischen Osteuropäischen Akzent. Stellen sich mir die Haare auf. Labert da 20 min rum für einen Inhalt von 2 min. Kann der das nicht lieber in Form von lesbaren Artikeln machen?

Langlay

2019-01-27, 20:25:27

Der Typ mit seinem komischen Osteuropäischen Akzent. Stellen sich mir die Haare auf. Labert da 20 min rum für einen Inhalt von 2 min. Kann der das nicht lieber in Form von lesbaren Artikeln machen?

Das ist ein ein schottischer Akzent. Und das ist natürlich Geschmacksfrage. Ich persönlich mag das. Ist mir lieber als son Cockney Akzent wo man nur die Hälfte von versteht.

Normaler DDR2666-RAM mit Ryzen 1k hat 86-90ns, mit PR so 80-82ns. Mit 2133 dürften beide so 95-100ns haben. Das Zen2-ES wird wohl einfach mit letzterem gelaufen sein.

https://abload.de/img/ddr2133ygkmd.jpg

Mit bischen weniger Coretakt und lascheren Timings könnten die 95ns so ungefähr hinkommen.

aufkrawall

2019-01-27, 20:38:30

https://vignette.wikia.nocookie.net/parody/images/1/14/Raj_camp_lazlo.png/revision/latest?cb=20150819072911
Ist nur die Frage, warum man sich das, außer aus Unterhaltungsgründen, überhaupt geben sollte, nach dem letzten Vollgriff von ihm ins Klo..

SKYNET

2019-01-27, 21:51:12

Der Typ mit seinem komischen Osteuropäischen Akzent. Stellen sich mir die Haare auf. Labert da 20 min rum für einen Inhalt von 2 min. Kann der das nicht lieber in Form von lesbaren Artikeln machen?

sei froh das er nicht in schottisch redet... bei ner kollegen aus airdrie(nähe Glasgow), verstehe ich spätestens wenn sie angetrunken ist, und nur noch das schottische "englisch" spricht, so gut wie garnix mehr ;D

Piefkee

2019-01-28, 07:49:35

Der Typ mit seinem komischen Osteuropäischen Akzent. Stellen sich mir die Haare auf. Labert da 20 min rum für einen Inhalt von 2 min. Kann der das nicht lieber in Form von lesbaren Artikeln machen?

https://twitter.com/lisasu/status/1089715760895852545?s=21

Jim - thanks for following @AMDRyzen so closely 😀.

Lisa Su über das Video von AdoredTV auf Twitter....

Pirx

2019-01-28, 08:16:26

Was ist jetzt der Inhalt, wenn es einen gibt? Hab auch keinen Bock mir das anzusehen.

Piefkee

2019-01-28, 08:26:30

https://pbs.twimg.com/media/Dx8FAx8W0AEvuCB?format=jpg&name=large

https://pbs.twimg.com/media/Dx8E_iwXcAAsMkg?format=jpg&name=medium

Aus dem Video.
Könnte darauf schließen das bei Matisse eine IF link Chip to Chip möglich ist.

Aber das Lisa Su das Video über ihren Offizier Twitter Liked finde ich persönlicher interessant. Falls die Leak nicht echt wären dann würde man sowas nicht liken, besonders als CEO.

Lehdro

2019-01-28, 08:37:16

Was ist jetzt der Inhalt, wenn es einen gibt? Hab auch keinen Bock mir das anzusehen.
TL;DR (soweit ich mich erinnere):

- IF gibts bei Rome/Threadripper 3 nur jeweils zum I/O Die
- IF bei Matisse gibts auch zwischen den CPU-Dies
-> CCXs haben eine große Crossbar(IF) die wie ein "+" auf dem Die aussieht, in den 4 Ecken sind jeweils die 2 Cores
- Matisse wird auch sub 12 Cores 3 Dies (1x I/O, 2x CPU) haben (Salvage)
- 5 GHz sind realistisch als Boost (der8auer + TSMCs 5 GHz L1 Cache Demo)
- Spekulatives IPC, Taktraten und Kerne Raten anhand pessimistischer Taktratenvorhersagen und der AMD Aussage das die CPU-Capability mindestens "verdoppelt" wird
- das für Matisse eine Chiplet-APU von AMD ausgeschlossen wird sagt nur aus das der I/O Die keine Displayengine verbaut hat und eine Chiplet APU demzufolge einen modifizierten I/O Die (auch extra mobile optimiert) bekommt -> eigener Codename, logischerweise kein Matisse

basix

2019-01-28, 08:46:46

Und würde bei EPYC auch Sinn machen. Deswegen diese "2er-Packs" aus Chiplets. Von der Performance her macht es Sinn. Systemtechnisch macht es das aber komplizierter

HOT

2019-01-28, 09:31:58

Das die Chiplets jeweils 2 Ports haben hab ich mir von Anfang an gedacht. Jetzt ist eher die Frage, ob man jedes CCX mit dem I/O-Die verbindet, oder die Chiplets auch untereinander. Schwere Frage, mal sehen ob wir ne Antwort bekommen.

Der_Korken

2019-01-28, 09:52:14

-> CCXs haben eine große Crossbar(IF) die wie ein "+" auf dem Die aussieht, in den 4 Ecken sind jeweils die 2 Cores

Das verstehe ich nicht. Müssten nicht jeweils 4 Kerne gruppiert werden, wenn wir von CCXs reden?

Ich habe die Frage vor 1,5 Jahren bestimmt schon drei Mal gestellt, aber leider vergessen, was drauf geantwortet wurde :redface: : Wird bei einem L3-miss in einem CCX auch der L3 des Nachbar-CCX angefragt? Oder spart man sich das, weil man den IF-Delay sonst doppelt hat (die Wahrscheinlichkeit, dass die Daten ausgerechnet im anderen L3 liegen, dürfte nicht sehr hoch sein). Bei Zen 2 liegen die CCX extrem dicht nebeneinander und müssen für jede Anfrage nach draußen direkt Off-Die. Da frage ich mich, ob man das "IF" (oder etwas anderes) zwischen den CCX nicht auch einfach mit Core-Takt betreiben könnte. Topologisch hätte man dann 2 Doppel-CCX statt 4 Einfach-CCX für Ryzen 3.

robbitop

2019-01-28, 10:11:00

mboeller

2019-01-28, 10:11:07

Das verstehe ich nicht. Müssten nicht jeweils 4 Kerne gruppiert werden, wenn wir von CCXs reden?

siehe das kleinere Bild von Piefkee:

in dem Bild oben siehst du auf der linken Seite 5 weiße Flecken in senkrechter Richtung und 5 Flecken in horizontaler Richtung, wobei die mittleren Flecken sehr schmal sind.

Der Typ interpretiert das so, dass der Crossbar wirklich ein Cross ist, also die mittleren Flecken keine Kerne sind sondern der Crossbar zum IO-Chip und zum 2. CCX/Chiplet. Jedes Chiplet hätte dann 8 Kerne die in 2er Gruppen angeordnet sind.

mboeller

2019-01-28, 10:13:06

- 5 GHz sind realistisch als Boost (der8auer + TSMCs 5 GHz L1 Cache Demo)

weiß wer, welche TSMC Präsentation das ist? Habe ich im Video nicht mitbekommen.

Der_Korken

2019-01-28, 10:27:55

Das Latenzdiagramm sieht aber nicht so aus als gäbe es einen direkten Link unter den Cores. Bei 32 MiB geht die Latenz hoch auf 100 ns und fällt dann auf 90 ns.
Sieht so aus als ob er da den L3 Cache auf dem anderen Die abfragt. Wäre die Verbindung, wie er sagt, zwischen den Dice ~10 ns schneller als über den I/O dürfte da doch kein solcher Überschwinger sein, oder?
Werden denn generell die L3 aller CCX abgefragt bevor der RAM abgefragt wird?

Bei dem Latenzdiagramm ist eventuell das Problem, dass die Latenzen nur von einem Kern aus gemessen werden. Wenn dieser Kern Daten aus seinem L2 wirft, landen die immer in seinem eigenen L3, aber niemals im anderen. Was aus dem L3 fliegt, landet im RAM. Die Hitrate für den anderen L3 dürfte also bei ca. 0% liegen in dem Test. Der Überschwinger ist schon auffällig. Eigentlich kann es aber nichts damit zu tun haben, dass es durch die zusätzliche Anfrage an den anderen L3 zustande kommt, denn wenn ein Core beim L3-miss immer auch im anderen L3 nachschaut, müsste diese Extralatenz auch bei allen Tests >32MB auftreten. Vielleicht feilt AMD noch bei den Cache-Zugriffen und hat noch keinen stabilen Mikrocode, wo der Peak weg ist.

siehe das kleinere Bild von Piefkee:

in dem Bild oben siehst du auf der linken Seite 5 weiße Flecken in senkrechter Richtung und 5 Flecken in horizontaler Richtung, wobei die mittleren Flecken sehr schmal sind.

Der Typ interpretiert das so, dass der Crossbar wirklich ein Cross ist, also die mittleren Flecken keine Kerne sind sondern der Crossbar zum IO-Chip und zum 2. CCX/Chiplet. Jedes Chiplet hätte dann 8 Kerne die in 2er Gruppen angeordnet sind.

Das Layout mit den 2er-Gruppen sehe ich. Für mich klang es nur so, als wären die auch logisch so angeordnet, denn das wäre neu.