AMD - Zen 4 (Raphael, Phoenix & Genoa, 5 nm, AM5, DDR5, PCIe 5.0, Ende 2022) [Archiv]

Geldmann3

2020-05-16, 13:57:11

Gut, mag sein, dass die Kernanzahl steigt, der Preis dann aber auch. Ich glaube nicht, dass man dann z.B für das Geld eines heutigen 6-Kerners ein 8-Kerner kriegt. Ich denke, das bleibt erstmal ne Weile. Aber ich glaube eher nicht an einen Ansteig im Consumerbereich.

Und ich bin mal gespannt, was SMT4 bringt. Ich denke im Gamingbereich bringt das nicht viel, vlt. ist es auch noch schlechter in vielen Fällen.

Doch, ich vermute Du bekommst bei Zen 4 einen 8 Kerner für den Preis eines heutigen 6 Kerners und noch dazu einen 8 Kerner, der in puncto Gaming alles übertrifft, was heute auf dem Markt ist. Für 350€ gibt es dann 12 Kerne, für 500€ 16 und für 750€ sogar 24.

So wie AMD den Markt in den letzten Jahren revolutioniert hat kann ich mir auch noch vorstellen, dass sie dann später einen 32 Kerner für 999€ ins Desktop-Segment nachliefern, sozusagen als Halo-Produkt, worauf Intel dann keine Antwort hat und mal wieder völlig Baff dasteht. Wobei der 24 Kerner Intel bereits etwas alt aussehen lassen wird.

Wobei LasterCluster auch Recht haben könnte und die Kerne einfach so viel größer werden, dass 32 auf dem Consumer Sockel nicht funktionieren. Bisher hat AMD da immer recht positiv überrascht, doch wenn man sich mal anschaut, dass der Cache momentan schon den Großteils des Dies einnimmt.

LasterCluster

2020-05-16, 13:58:03

Ist natürlich reine Spekulation, doch ich rechne unter 3nm durchaus mit noch mehr Kernen, ja, später sogar mit einer Verdopplung, against all odds. Denn AMD sollte sich dann mit einem stärkeren Intel anlegen müssen und sich dabei alle Mühe geben.

Ok, habe ich falsch verstanden. Ja, unter 5nm wird es sicher weiter gehen. Nur bei ZEN4 denke ich nicht, dass AMD maximal pushen wird. Falls Intel Druck macht, kann man durch das modulare Design sehr schnell mit mehr Kernen kontern. Aber in die Offensive muss man da nicht gehen.

Platos

2020-05-16, 13:58:57

LasterCluster

2020-05-16, 14:07:10

Wobei LasterCluster auch Recht haben könnte und die Kerne einfach so viel größer werden, dass 32 auf dem Consumer Sockel nicht funktionieren. Bisher hat AMD da aber immer recht positiv überrascht, doch wenn man sich mal anschaut, dass der Cache momentan schon den Großteils des Dies einnimmt.

AMD plant mit zweistelligen IPC Zuwächsen....pro Jahr. ZEN4 wird ca 30-40% IPC auf ZEN2 drauflegen. Also kann man sicher mit 50%-100% mehr Transistoren pro Kern rechnen.

Der_Korken

2020-05-16, 14:11:52

Wenn man so Sachen wie full-speed-AVX512 und SMT4 bringt, frage ich mich, ob es Sinn macht den Kern aufzuteilen in "scalar" und "vectorized":

SMT2 bringt in der Praxis vielleicht max. 30-40%. Eine weitere Verdopplung bringt entsprechend noch weniger, d.h. man bräuchte massiv mehr Execution Ports, damit sich das lohnt. Andererseits ist ein riesiger Core schlecht für die Latenzen und es kostet sicherlich nicht wenig Strom die Daten ständig über den großen Core zu schieben. Das ist schlecht für Singlethread-IPC und Effizienz. Man könnte den L1D in zwei Caches aufteilen, einen low-latency-Cache mit moderater Größe und Bandbreite (z.B. 32kB, 64B/cl) für skalare Operationen und ein high-latency-Cache mit z.B. 64kB und 128B/cl für AVX. Der L2 muss natürlich dann inklusiv über beide sein, damit das kein Kohärenzalptraum wird. Es kann natürlich trotzdem sein, dass eine solche Aufteilung mehr Probleme aufwirft als löst, aber man könnte damit die Kerne fetter bekommen, ohne dass die einzelnen Teile an sich darunter leiden.

Geldmann3

2020-05-16, 14:14:02

Ich würde eher mit einem smarteren als viel dickeren Design rechnen und mit einer wesentlichen Steigerung der Packdichte. Man sieht bei Navi 10 ja, dass AMD dort noch nicht meisterhaft ist. Der Cache wird viel Platz fressen.

Bei CPUs kann man für die IPC mit mehr Transistoren nicht so viel reißen wie bei GPUs.

~37% mehr IPC als Zen 2 mit 10% mehr Takt kann ich mir bei Zen 4 durchaus vorstellen. Freue mich darauf. :biggrin:

Der_Korken

2020-05-16, 14:20:16

Ich wäre mir da nicht so sicher, was die Skalierung weiterer Transistoren angeht. Ich hatte im Alder Lake Thread mal ein paar Gedanken dazu geschrieben:

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

Ich bin ja mal gespannt, wie Intel die IPC noch so krass steigern möchte. In dem Zitat und Link von gmb sieht man auf der einen Seite, dass man 38% mehr Transistoren für 18% IPC investiert hat und auf der anderen, dass Intel näher an die lineare Steigerung heran will. Allerdings wird es mit zunehmender IPC immer schwerer diese noch zu steigern. Es gibt gewisse "natürliche" Grenzen über die man nur schwer hinwegkommt.

Branches sind immer der Klassiker und ein "800 instruction window" geht über etliche Branches hinweg. Selbst bei 90% korrekter Vorhersage, sind es drei Branches weiter nur noch 0,9^3 ~ 73% Genauigkeit. Je größer das instruction window desto besser muss quasi auch die prediction sein, um den Anteil verworfener Berechnungen beizubehalten und nicht zu verschlechtern.

Und dann gibt es auch Datenabhängigkeiten, d.h. der Operand für den nächsten Befehl hängt vom vorigen ab. Da habe ich keine Ahnung wie lang die Abhängigkeitsbäume bei "normalem" Code sind aber auch da wird der Ertrag geringer wenn man einfach nur mehr Instruktionen anguckt. Am einfachsten wäre es natürlich wenn man die Latenz eines Befehls klein kriegt, aber Hochtaktdesigns funktionierten bisher auf beiden Seiten nicht und die Pipeline kriegt man sicherlich auch nicht einfach so kürzer, ohne dass der Takt wegbricht.

Wenn man IPC so einfach steigern könnte, warum hat man das bisher nicht gemacht? Warum dümpelt Intel jahrelang mit knapp 5% IPC pro Jahr rum? Ice Lake bringt zwar wieder mal 18%, ist aber auch 3-4 Jahre später dran als Skylake. Und scheint in 10nm so viel pro Kern zu saufen wie Skylake in 14nm.

Geldmann3

2020-05-16, 14:22:04

Aber was willst du denn mit noch mehr Kernen? Für Office und Co. ist im Grunde alles über 4c/8t komplett unnötig und für Gaming bisher alles über 8c/16t. Im Anwendungsbereich (Videoschnitt etc.) gibt es da überhaupt eine Software, die mit 32 Threads umgehen kann (vom 16c/32t) ? Was sollen da noch mehr Threads bringen?

Selbst wenn man im Gamingbereich noch von 16 Threads profitieren könnte, dann ist ja der 16 Kerner schon da. Mehr ist eig. ausgeschlossen, ausser bei ein paar Exoten. Die Konsolen haben 16 Threads, ich denke nicht, dass die nächsten 8 Jahre mehr als 16 Threads den geringsten Vorteil haben werden.

Und wenns richtig professionelle Arbeit wird, dann gibts ja Threadripper. Also warum sollte AMD einfach mit mehr Kernen kommen, wenn es in vielen Bereich nichts bringen würde. Damit zerschiessen sie sich die Preise ja nur selbst.

Man wird nicht ewig mit Kernen schmeissen können, zumindest im Consumerbereich. Im Serverbereich wirds natürlich immer gerne angenommen.

Ich kann mir sehr gut vorstellen, dass durch die Kernexplosion neue Entwicklungs-Paradigmen für Spieleengines angestoßen werden, sodass diese dann endlich mal für z.b. realistische Physikberechnungen verwendet werden. Da ist in den letzten 10 Jahren kaum etwas passiert, weil Intel die Gamer großteils quasi auf 4 Kerne gegängelt hat. Warum sollte ein Entwickler fast die ganze CPU brachliegen lassen, wenn er weiß, dass 16 Kerne die Norm sind... Das ist natürlich ein Blick in die etwas ferne Zukunft, wenn das mal der Fall sein sollte. Daher lohnen sich in meine Augen auch mehr Kerne, aus demselben Grund warum sich neuere Hardware schon immer gelohnt hat, auch wenn die Software noch nicht aufgeschlossen hatte. Einfach, damit die Software aufholen kann. Natürlich entwickelt im Moment kein Spieleentwickler für mehr als 12 Kerne, da fast niemand so viele Kerne in der eigenen Kiste hat und auch die Konsolen eher einem heutigen 4 Kerner mit HT entsprechen, als einem 8 Kerner, einfach, weil die Kerne so lahm sind.

Im Prinzip kann man mehr CPU-Kerne für ein Game genauso nutzen wie mehr Shader-Cores in einer GPU, nur, dass die CPU-Kerne andere Berechnungen ermöglichen und viel weniger davon. Auch sollte man zu viel Kommunikation zwischen GPU und CPU vermeiden. Physik, die wirklich Auswirkungen auf das Gameplay hat, ist ein perfektes Anwendungsgebiet für die CPU, da dort in der Regel auch die Physik läuft und die Drawcalls für die GPU abgefeuert werden, die das Bild am Ende nur nach Rezept malt.

Zossel

2020-05-16, 14:48:00

Wie viel Platz und Transistoren wird ein 8C CCX gegenüber einem 4C CCX fressen?

Platos

2020-05-16, 14:48:27

Gut, aber wenn, dann passiert das erst nach Zen4. Denn damit AMD erneut die Kernzahl erhöht, muss Intel wieder ordentlich Druck machen können und das können sie m.M.n erst 2023 mit 7nm (Desktop).

2021 Rocket Lake 14nm (Desktop)
2022 Alder lake angeblich 10nm (Desktop)
2023 Meteorlake angeblich 7nm (Dekstop)

Also aus meiner Sicht passiert sowas frühestens 2023 aber ich würde sagen, wenn dann mit 3nm und das wäre noch später. Also schon sehr weit weg in der Zukunft.

konkretor

2020-05-16, 14:50:13

Also SMT4 wäre ja schon ne geile sache im Server Bereich. Die Frage ist halt ob die Software hinter her kommt. Aktuell kommst jetzt schon Stellenweise die Software nicht hinterher.

Der Windows Shedeuler wird dann wohl endgültig kapitulieren :P

PowerPC CPU hatten das früher auch schon drin, das sie pro CPU Kern 4 oder mehr Threads hatten. Das ist jetzt keine neue Erfindung....

https://en.wikipedia.org/wiki/POWER7
https://de.wikipedia.org/wiki/Power-Architektur

gmb

2020-05-16, 15:01:00

Ich wäre mir da nicht so sicher, was die Skalierung weiterer Transistoren angeht. Ich hatte im Alder Lake Thread mal ein paar Gedanken dazu geschrieben:

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

Wenn man IPC so einfach steigern könnte, warum hat man das bisher nicht gemacht? Warum dümpelt Intel jahrelang mit knapp 5% IPC pro Jahr rum? Ice Lake bringt zwar wieder mal 18%, ist aber auch 3-4 Jahre später dran als Skylake. Und scheint in 10nm so viel pro Kern zu saufen wie Skylake in 14nm.

Weil die zusätzlichen Jahre Icelake nichts gebracht haben, außer ein paar nachträglich eingeschobenen security fixes, das Design ist lange fertig. Ein Effekt der langen Verzögerung wird man also erst bei Golden Cove sehen können. Deswegen wird Golden Cove sehr interessant.

Ansonsten vermute ich aber auch, dass die große Zeit der Kernerhöhungen erstmal vorbei ist innerhalb der nächsten 2 Generationen. Erstens wird der Nutzen immer kleiner im Mainstream und zweitens muss auch AMD irgendwann deutlich mehr Fläche investieren, um weitere Verbesserungen am Kern zu erzielen. Ausgehend von 8-16 Kernen hätte man in der Regel sowieso mehr von IPC Steigerungen als von weiteren Kernsteigerungen, ich nehme lieber 15-20% mehr IPC als mehr Kerne.

RLZ

2020-05-16, 15:12:48

Ich kann mir sehr gut vorstellen, dass durch die Kernexplosion neue Entwicklungs-Paradigmen für Spieleengines angestoßen werden, sodass diese dann endlich mal für z.b. realistische Physikberechnungen verwendet werden. Da ist in den letzten 10 Jahren kaum etwas passiert, weil Intel die Gamer großteils quasi auf 4 Kerne gegängelt hat.
Da gibt es imo andere Gründe :D
a) Die meisten Spieleentwickler werfen ihren Content nur noch fertige Engines.
b) Die Investition lässt sich im Vergleich zu anderen Bereichen schwer rechtfertigen. Das kann man fast nur noch tun, wenn Geld und Risiko eine kleine Rolle spielen. Ich hab nun schon Engine-Entwickler auf Twitter gesehen, die Epic drum gebetet haben keine Details zu Nanite bis zum Release zu veröffentlichen, damit sie sich mal eigene Budgets für Forschung besorgen können.

amdfanuwe

2020-05-16, 16:50:07

32 Kerne in 5nm bezweifle ich. 5nm soll 30% effizienter sein. D.H.: Bei gleichem Takt 30% sparsamer oder bei gleicher TDP und gleichem Takt 50% mehr Kerne. 16 Kerne werden aktuell durch die TDP eingebremst. Die könnten in 5nm richtig flot werden.

AMD differenziert mit CDNA und RDNA GPU für Server und Gaming.
Ich könnte mir vorstellen, dass sie bei den CPUs auch den Weg gehen.
Also fette Kerne mit AVX 512, SMT4, viel Cache etc. für Server und für Desktop abgespeckte günstige CPUs, APUs.

Man sollte auch bedenken, Desktop ist nur ein kleiner Teil des Marktes.
Server CPU dürfen teuer sein, wenn die Leistung stimmt.
Mobile macht einen Großteil des Client Marktes aus.
Durchaus möglich, dass Desktop aus beiden Welten bedient wird.
Bis 8 Core günstiger Mobile Chip und darüber Chiplets oder monolithischer 16 Core.
8 Core unter 200€ und 6 Core ab 100€ gibt es ja jetzt schon. Das wird dann noch etwas flotter werden für den gleichen Preis.
Sei es drum, ist noch eine Weile hin.

Da frage ich mich eher, ob es für Desktop mehr PCIe auf AM5 gibt. Und wie entwickelt sich KI? wird das ein Thema für den Desktop? Wie sieht es mit VR aus?
Beim Takt sind wir am Anschlag, mehr Kerne braucht es für Mainstream auch nicht mehr.
Da fehlt es an neuer Software, die Aufrüstdruck erfordert und im Mainstream einen "haben wollen" Effekt auslöst.

Der_Korken

2020-05-16, 17:55:00

16 Kerne werden aktuell durch die TDP eingebremst. Die könnten in 5nm richtig flot werden.

Da muss ich zumindest bei Zen2 widersprechen. Der 3700X ist mit 65/88W komplett outmaxed, der 3800X mit 60% mehr Spielraum gerade mal 0% (Spiele) bis 3% (Anwendungen) schneller (Link (https://www.computerbase.de/thema/prozessor/rangliste/#diagramm-test-performancerating-fuer-spiele-frametimes-fhd)). In Benches, die stark mit MT skalieren, ist ein 3950X ~28% schneller als ein 3900X, also gerade 4% langsamer pro Kern trotz 25% weniger Verbrauch pro Kern (Link (https://www.computerbase.de/2019-11/amd-ryzen-3950x-test/3/#diagramm-test-corona-13-benchmark)). Und Renoir skaliert sogar selbst mit 8C/16T kaum noch über 35W TDP hinaus. Ich sehe eher das Problem, dass AMD gar nicht mehr weiß wie sie ihr TDP noch sinnvoll investieren sollen im Desktop, wenn diese mit 5nm noch effizienter werden.

amdfanuwe

2020-05-16, 18:26:14

Jup, 3700X ist outmaxed. Dabei dürften nicht mal besonders selectierte Chips verwendet werden. Im 3950X braucht man schon gut selectierte Chips um auf die Werte zu kommen.
Jetzt stell dir halt unter 5nm vor, das 16 Kerne ca. 300MHz Baseclock erhalten.

Opprobrium

2020-05-16, 18:30:18

Also fette Kerne mit AVX 512, SMT4, viel Cache etc. für Server und für Desktop abgespeckte günstige CPUs, APUs.

Das wird mittelfristig interessant, ob die one-die-fits-all Strategie so weitergefahren werden kann und werden wird. Ist ja derzeit ein riesen Vorteil für AMD, daß sie mit einem einzigen CPU Design alles außerhalb des Mobile/Embedded Bereichs abdecken können.

Durch das Chiplet Design ist AMD ja theoretisch ungemein flexibel, und könnte Serverfeatures einfach auf eigenen Chiplets anbieten, bzw. diese in die I/O Dies der Server integrieren. Dadurch müssten sie dann auch in Zukunft keine extra Chips für den Desktop Designen.

Halte es aber auch nicht für völlig ausgeschlossen, daß irgendwann die reinen CPUs ganz aus dem Desktopmarkt verschwinden (von Threadripper evtl. mal abgesehen), und sobald da 16 Kerne möglich sind die APUs diesen Bereich komplett einnehmen.

Rooter

2020-05-16, 18:53:19

Ich tippe auf 20% mehr IPC und 10% mehr Takt.

Ich würde es auch lieber sehen, wenn sie statt mehr Kernen mehr Cache bringen würden. Aber ich denke auch wir werden den 8-Kerner zum Preis eines heutigen 6-Kerners bekommen.

MfG
Rooter

robbitop

2020-05-16, 18:54:20

Wir werden wohl mehr L2 Cache sehen. ;)

Hammer des Thor

2020-05-18, 02:17:40

Mehr CPU Kerne aber dann bei Epic/Threadripper ? Bei Consumer wird man ja wohl kaum auf über 16 Kerne gehen?

AMD hat vor Monaten gesagt, dass im Mainstream bei 16 Kernen nicht Schluss sein wird!

Hammer des Thor

2020-05-18, 02:19:39

Kommt drauf an wie AMD das umsetzt. Denkbar ist weiterhin auf 8c CCDs zu setzen, die dann wesentlich kleiner werden. Dann würde es zumindest nahe liegen weiterhin auf max 16c im Normalodesktop zu gehen.

Werden die CCDs größer wie zB 12c, geht es naheliegernderweise über 16c

Bei 8c könnten auch 3 core chiplets auf ein AM5 rauf wenn Sie entsprechend klein und angeordnet sind!

Hammer des Thor

2020-05-18, 02:23:30

AMD plant mit zweistelligen IPC Zuwächsen....pro Jahr. ZEN4 wird ca 30-40% IPC auf ZEN2 drauflegen. Also kann man sicher mit 50%-100% mehr Transistoren pro Kern rechnen.
Nach dem Tic-Toc sollten es etwas weniger sein von Zen 3 auf Zen 4, wobei der schnellere DDR5-Speicher aber auch noch nen paar % auf die Performance drauflegen sollte!

Hammer des Thor

2020-05-18, 02:27:23

Hammer des Thor

2020-05-18, 02:31:10

Wir werden wohl mehr L2 Cache sehen. ;)

Pro Kern oder insgesamt? Durch den schnelleren DDR5-Speicher sehe ich erst mal noch mehr cache pro Kern nicht für sinnvoll. Wenn die 12c chiplets verbauen mir gleicher Menge cache pro Kern steigt der L3-cache eh!

Korvaun

2020-05-18, 08:30:35

Fragt sich nur wie klein die Chiplets noch werden dürfen bevor das nicht mehr hinhaut mit dem Wärmetransport zu Heatspreader... das könnte ab 5nm starken Einfluß haben auf das Chiplet Design (Menge der Kerne/Cachegröße)?

basix

2020-05-18, 08:34:33

Man wird vermutlich auf etwa der selben Chiplet-Grösse bleiben. Bei 5nm würde das in 10-12C münden, je nach dem wie viel Fläche der vergrösserte L2$, AVX512 usw. benötigen.

robbitop

2020-05-18, 10:31:51

Pro Kern oder insgesamt? Durch den schnelleren DDR5-Speicher sehe ich erst mal noch mehr cache pro Kern nicht für sinnvoll. Wenn die 12c chiplets verbauen mir gleicher Menge cache pro Kern steigt der L3-cache eh!
Natürlich pro Kern. L2 ist bei Zen und Core dem Kern selbst zugeordnet und ist nicht geshared.
Speichertakt ändert an der RAM Latenz gar nichts. 40 ns Memorylatency gab es auch schon vor gut 10 Jahren mit DDR2 und DDR3. Der Takt wird für höhere Timings getauscht. Was ein wenig bringt ist, der höhere Takt des IMCs. Allerdings ist der Teil der Gesamtlatenz schon jetzt so klein, dass eine weitere Verkleinerung bezogen auf die Gesamtlatenz kaum noch was bringt. Was limitiert ist die Fabric. Und das liegt nunmal in der Natur der Sache. Skalierbarkeit kostet nunmal Latenz. Und wir alle wollen ja viele Kerne.

Entsprechend kann man dagegen nur mit Datenlokalität kämpfen. L2 ist schneller als L3 und somit ist eine Steigerung (sofern er nicht langsamer wird - dafür braucht es aber halt Shrinks) sinnvoll. Sieht man ja auch beim L1. Auch der wurde bspw bei Sunny Cove gesteigert.

Man kann davon ausgehen, dass Intel und AMD sehr gute Simulationstools haben und sehen, wo die Bottlenecks sind.
Man hat jetzt die ILP Extraktion stark gesteigert in den letzten Jahren. Breitere Decoder, breiteres Backend, große OOO Windows, buffer für die Sprungvorhersage, bessere Prefetcher etc. Und damit verschiebt sich dann auch mal der Flaschenhals.
Hinzu kommt (auch zukünftig bei Intel) die Steigende Gesamtlatenz zum Memory, da die Fabric skalierbarer sein muss.

Bei Golden Cove wird man im insgesamt dritten Schritt dann alle Cache Level gesteigert haben. L1, L2 und L3.
AMD hat seit Zen hinzu Zen 4 dann L2 und L3 deutlich gesteigert. Ob und was beim L1 passiert, ist noch offen.

Hammer des Thor

2020-05-18, 12:17:13

Oder wird AMD für den Cache dann schon 3D-Stukturen wie jetzt bei Flash verwenden? Für cache sollte es doch wegen der "Gleichheit" viel einfacher gegen als mit Logik? Ist es überhaupt möglich, die Logik einschichtig zu machen und caches mehrschichtig?

Nightspider

2020-05-18, 20:28:47

Bezüglich DDR5: der hat doch eine 30% höhere Effizienz pro Takt wenn ich nicht falsch liege.

Sinkt damit auch die effektive Latenz?

Oder funktioniert das so nicht?

Der_Korken

2020-05-18, 21:11:39

Bezüglich DDR5: der hat doch eine 30% höhere Effizienz pro Takt wenn ich nicht falsch liege.

Sinkt damit auch die effektive Latenz?

Oder funktioniert das so nicht?

Die Latenz wird wie auch schon bei DDR1, DDR2, DDR3 und DDR4 nicht sinken.

Hammer des Thor

2020-05-18, 23:18:58

SKYNET

2020-05-19, 00:20:44

Die Latenz wird wie auch schon bei DDR1, DDR2, DDR3 und DDR4 nicht sinken.

korrekt, das machen die immer schlechter werdenen timings nämlich zunichte. :(

BlacKi

2020-05-19, 05:11:56

korrekt, das machen die immer schlechter werdenen timings nämlich zunichte. :(
who cares, wenn dabei die leistung steigt?

gerade bei der gaming leistung verspreche ich mir durch ddr5 sehr viel.

basix

2020-05-19, 08:14:20

Ich könnte mir auch vorstellen, dass der L3 asymmetrisch zur Kernzahl erhöht wird also 12 C in einem Chiplet dann mit 64 MB L3. Eine Verdoppelung pro Kern bei gleichzeitig noch mehr Kernen halte ich für "zu viel" des Machbaren und sinnvollen!

Ich bin mir nicht sicher, ob sich der L3 vergrössert pro Core. 4MB sind sehr viel, und bei TSMC 5nm soll das SRAM-Scaling nur 1.3x betragen. Wenn du also mehr Cores und mehr Cache verbaust, steigert sich unweigerlich die Die-Size. Und das wird meiner Meinung nach nicht passieren. AMD hat vermutlich mehr von 12C + 48MB L3$ anstatt 10C + 60MB L3$.

Ausserdem: Anscheined soll sich der L2$ verdoppeln. Damit sinkt schon mal der L3-Pressure.

Nightspider

2020-05-19, 08:55:59

gerade bei der gaming leistung verspreche ich mir durch ddr5 sehr viel.

Ich denke Games interessiert die Bandbreite fast gar nicht.

Games interessieren sich doch für den Speichertakt und die dadurch resultierende Latenz.

Bis wir DDR5 mit 500Mhz (DDR5_8000) sehen werden wird es eine Weile dauern.

DDR4_4000 hat einen Speichertakt von 500 Mhz. DDR5_4000 hat nur noch 250 Mhz.

Hammer des Thor

2020-05-19, 13:15:24

Ich bin mir nicht sicher, ob sich der L3 vergrössert pro Core. 4MB sind sehr viel, und bei TSMC 5nm soll das SRAM-Scaling nur 1.3x betragen. Wenn du also mehr Cores und mehr Cache verbaust, steigert sich unweigerlich die Die-Size. Und das wird meiner Meinung nach nicht passieren. AMD hat vermutlich mehr von 12C + 48MB L3$ anstatt 10C + 60MB L3$.

Ausserdem: Anscheined soll sich der L2$ verdoppeln. Damit sinkt schon mal der L3-Pressure.

Ich denke schon, dass der auch pro Kern vergrössert wird bei 12 C Chiplets: Warum: Weil ein 12 Kerner sonst weniger L3 insgesamt hätte als Ryzen 3000 und 4000. Ein 3900X geht ja über 2 chiplets und bekommt da ja den L3 für 16 Kerne! Wenn die den L3 3D-stacken dann sinkt die Fläche wieder!

w0mbat

2020-05-19, 13:26:11

Bis wir DDR5 mit 500Mhz (DDR5_8000) sehen werden wird es eine Weile dauern.

DDR4_4000 hat einen Speichertakt von 500 Mhz. DDR5_4000 hat nur noch 250 Mhz.
Dein Ernst?

Edit: Ja, DDR5 geht wohl echt so weit runter o.O

Platos

2020-05-19, 13:58:31

Ich denke Games interessiert die Bandbreite fast gar nicht.

Games interessieren sich doch für den Speichertakt und die dadurch resultierende Latenz.

Bis wir DDR5 mit 500Mhz (DDR5_8000) sehen werden wird es eine Weile dauern.

DDR4_4000 hat einen Speichertakt von 500 Mhz. DDR5_4000 hat nur noch 250 Mhz.

Die Latenz bleibt aber trotzdem wie schon immer gleich.

basix

2020-05-19, 14:20:22

Ich denke schon, dass der auch pro Kern vergrössert wird bei 12 C Chiplets: Warum: Weil ein 12 Kerner sonst weniger L3 insgesamt hätte als Ryzen 3000 und 4000. Ein 3900X geht ja über 2 chiplets und bekommt da ja den L3 für 16 Kerne! Wenn die den L3 3D-stacken dann sinkt die Fläche wieder!

Dem 3900X bringt der total grössere Cache aber nichts, weil er in 4x 16MB Slices aufgeteilt wird und erst noch auf zwei Die verteilt. Bei Zen 4 wäre es ein Unified 48MB Cache pro Chiplet. Jeder Core kann also theoretisch auf 3x so viel Cache zugreifen wie bei Zen 2.

Sieh dir z.B. Renoir an. 1MB pro Core und es reicht auch. Natürlich liegt das am Use Case von Renoir und dass der Die monolithisch ist (geringerer IF Latenz-Penalty). Aber IF Gen. 3 wird mit hoher Wahrscheinlichkeit Latenzverbesserungen mitbringen, was die Anforderungen an die L3-Grösse nochmals reduzieren sollte. Und es ist nicht so, dass ein grösserer L3$ nicht schneller wäre. Er würde im Vergleich zum Flächenaufwand aber zu wenig bringen. Und wenn du Pech hast, verbrät der Cache zu viel Strom und es wird sogar langsamer.

Wenn man das Zeug 3D stacked, ist das eine etwas andere Ausgangslage. Da könnte man natürlich mehr Cache auf der selben Fläche unterbringen. Aber wäre es dann nicht sinnvoller, den Die von 75mm2 auf 40-50mm2 zu verkleinern? Zwei Chips mit 75mm2 zu belichten wird deutlich mehr kosten als heute, vor allem da 5nm teurer als 7nm sein wird. Was aber interessant ist, dass 1x Zen 2 Core + L2$ in etwa gleich gross ist wie ein 4MB L3$ Slice. Wäre also fast ideal zum stacken, da mehr oder minder deckungsgleiche Fläche ;)

Vorteil wäre, dass die Inter-Core Kommunikation massiv geringere Wege gehen muss, da die Cores dann viel näher beieinanderliegen. Beim gestackten L3$ wären die Cores + L2$ direkt nebeneinander und somit hätte man minimale Wege und somit geringte Latenzen als auch Stromverbrauch.

Ich habe mal per Milchmädchenrechnung die Zen 4 Die Size berechnet (mit ein paar Annahmen wie viel Fläche z.B. AVX512 benötigen wird). Ich habe mit 1 MB L2$ und 1.2x fetterem Core gerechnet. bei 12C inkl. GMI-Anbindung komme ich ohne L3$ auf etwa 45mm2 . 48MB L3$ wären etwa 40mm2. Da der L3$ zwischen Cores und Substrat platziert wäre (Cores müssen näher am Kühler sein, da höhere Wärmeabgabe), müsste man noch etwas Fläche für TSVs spendieren (könnten die 5mm2 Differenz ausmachen) oder der "Core-Die" überlappt den SRAM Die und man benutzt Cu-Pillars oder so (siehe z.B. Intel (https://fuse.wikichip.org/news/3508/left-right-above-and-under-intel-3d-packaging-tech-gains-omnidirectionality/)). Jedenfalls scheint das gar nicht so schlecht aufzugehen. Auch bei 3D-Stacking bleibe ich momentan dabei, dass 4MB pro Core gut passen. Aber wenn man schon 3D-Stacking betreibt, kann man mehrere L3-Chips stacken und so den L3$ skalieren. Mobile = 1-hi; Desktop = 2-hi; Server = 3-hi oder so etwas in dieser Art ;)

Edit:
Bei Mobile würde sich aber vermutlich anbieten, ein eigenes SRAM+GPU Die zu machen: CPU wäre aus drei Chips gestapelt --> Core Die (12C) - SRAM + GPU Die - I/O Die. Das wäre wiederum sehr schmale 45mm2 Fläche und die Grösse der GPU könnte man sogar noch über die Anzahl Stacks steuern, wenn man will.

Gipsel

2020-05-19, 14:27:42

Das Problem bei jeglichem Stacking mit High-Performance-Chips ist immer die Kühlung.

Nightspider

2020-05-19, 14:32:55

Die Latenz bleibt aber trotzdem wie schon immer gleich.

Sicher? Wenn die Taktrate sinkt bei DDR5?

Wieso sinkt die dann bei höheren Taktraten beim RAM OC?

basix

2020-05-19, 15:17:37

Das Problem bei jeglichem Stacking mit High-Performance-Chips ist immer die Kühlung.

Natürlich. Aber ist SRAM und I/O so extrem "High Performance". Dieses Paper (https://minds.wisconsin.edu/handle/1793/65385) z.B. legt nahe, dass der Grossteil des Verbrauches von den Cores + L1 + L2 kommen. Der L3 wäre da schon deutlich weniger kritisch. I/O ist schwierig abzuschätzen aufgrund konzentrierter Bereiche mit hohen Strömen, dort hätte man aber die beste Wärmeableitung gegen das Substrat und das PCB hin.

In Richtung Wärmeableitung bei 3D-Stacking wird ja intensiv geforscht. Bei einem Sandwich-Aufbau aus Cores / L3 SRAM / IOD ist es vermutlich einfacher als bei Cores / GPU / IOD. Bei der GPU reden wir aber von Mobile im Bereich von max. 10-25W für die GPU alleine. Nicht dass es einfach ist, aber es kann realisierbar sein. CPUs kann man bei 150mm2 bis 150W noch einigermassen leicht kühlen. Da sollten 10-35W bei 1/3 der Fläche doch irgendwie machbar sein ;)

robbitop

2020-05-19, 18:46:04

Ich könnte mir auch vorstellen, dass der L3 asymmetrisch zur Kernzahl erhöht wird also 12 C in einem Chiplet dann mit 64 MB L3. Eine Verdoppelung pro Kern bei gleichzeitig noch mehr Kernen halte ich für "zu viel" des Machbaren und sinnvollen!
Ich tippe darauf, dass man die CCX nach wie vor beibehält.

Die CCX ist ja der Kompromiss mit der skalierbaren (und somit nunmal langsamen Fabric). Alles innerhalb der CCX ist schnell angebunden.
Das unterliegt aber nunmal Limitierungen der Anzahl der Teilnehmer. Einfach den CCX immer größer machen führt dann dazu, dass die Latenz innerhalb des CCX steigt.

Entsprechend vermute ich eher, dass man eine ganze Weile bei 8C CCX bleiben wird (und dort auch schon die Intra CCX Latenz leiden wird). Im Gegenzug hat man nun pro Core 2x L3 Cache.

Den Cache noch weiter aufzublasen würde ihn langsamer machen. Größe <-> Latenz.
Darum wird man wohl den L2 noch ein wenig vergrößern.

Mein Tip für Zen4 ist, man bleibt bei den 8C CCX aus Zen3 und auch bei 32 MiB L3.

Achja: und wegen des CCX Ansatzes ist nur der L3 innerhalb des CCX relevant pro Kern.

Ich denke Games interessiert die Bandbreite fast gar nicht.

Games interessieren sich doch für den Speichertakt und die dadurch resultierende Latenz.

Bis wir DDR5 mit 500Mhz (DDR5_8000) sehen werden wird es eine Weile dauern.

DDR4_4000 hat einen Speichertakt von 500 Mhz. DDR5_4000 hat nur noch 250 Mhz.
Der einzige Einfluss auf die Latenz beim Speichertakt ist die Frequenz des IMCs. Nicht des RAMs. Dessen Anteil an der Gesamtlatenz ist verglichen mit der Latenz der Fabric und dem Arbeitsspeicher aber inzwischen so klein, dass da relativ gesehen kaum noch Potenzial vorhanden ist.

Sicher? Wenn die Taktrate sinkt bei DDR5?

Wieso sinkt die dann bei höheren Taktraten beim RAM OC?
IMC Takt.

Gipsel

2020-05-19, 19:35:54

Natürlich. Aber ist SRAM und I/O so extrem "High Performance". Dieses Paper (https://minds.wisconsin.edu/handle/1793/65385) z.B. legt nahe, dass der Grossteil des Verbrauches von den Cores + L1 + L2 kommen. Der L3 wäre da schon deutlich weniger kritisch.Der Vorschlag war doch Kerne (+L2) mit einem L3-Chip zu stacken. Und es ist immer ein Problem, wenn ein High-Performance-Logik-Chip mit irgendwas gestackt wird. RAM-Dies stacken ist okay, aber Logik + irgendwas erheblich schwieriger, wenn es keine low-power Mobilchips mit <5W oder so Verbrauch sind.
Der Wärmetransport über die Lötpunkte ist nunmal relativ mies verglichen mit einem Silizium-Kristall. Es ist vermutlich nicht völlig unmöglich, insbesondere wenn das low-power-Die (hier also der Cache) unten liegt und die Kühlung dann direkt am Logik-Die angreifen kann. Aber auch das erhöht die thermische Dichte und erschwert die Kühlung (bzw. setzt ein niedrigeres Limit für den akzeptablen Verbrauch als anderweitig möglich).
In Richtung Wärmeableitung bei 3D-Stacking wird ja intensiv geforscht. Bei einem Sandwich-Aufbau aus Cores / L3 SRAM / IOD ist es vermutlich einfacher als bei Cores / GPU / IOD. Bei der GPU reden wir aber von Mobile im Bereich von max. 10-25W für die GPU alleine. Nicht dass es einfach ist, aber es kann realisierbar sein. CPUs kann man bei 150mm2 bis 150W noch einigermassen leicht kühlen. Da sollten 10-35W bei 1/3 der Fläche doch irgendwie machbar sein ;)Die beim Verlöten von gestackten Dies mit TSVs benutzten "copper pillars" haben für sich gesehen zwar eine passable Wärmeleitfähigkeit, aber die ist nicht flächig, weil eben nur auf die Kontaktpunkte reduziert. Der Füllfaktor der eigentlichen Lötkontakte in der Fläche beträgt z.B. bei HBM (im Prinzip das, was man halbwegs sicher hinbekommt) maximal 12% (und versuche mal ein CPU-Die zu kühlen, wenn Du nur 12% des Dies mit dem Kühler kontaktierst ;)), was eben selbst mit der höheren Wärmeleitfähigkeit von Kupfer gegen Silizium dann nur grob ein Viertel der Wärmeleitfähigkeit ergibt, als wenn man das mit einer direkten Si-Verbindung vergleicht (der Underfill ist im Verhältnis ziemlich mies und eher so Größenordnung Wärmeleitpaste). Und das würde TSVs über den kompletten Chip erfordern, was ziemlich teuer wird und außerdem Platz kostet (man benötigt dann ja praktisch 10µm durchmessende Löcher überall im Chip, was durchaus eine Herausforderung sowohl für die Produktion als auch das Layout ist, was die Strukturen um diese Löcher herum verteilen muß, in anderen Worten: das ist unrealistisch).

Also kurz: 35W statt 150W auf einem Drittel der Fläche (2/3 der thermischen Dichte) mit 3D-Stacking statt 2.5D (nebeneinander) oder monolithisch ist schon relativ ambitioniert. Es hat schon seinen Grund, warum man dieses Stacking nur bei low-power Chips (Mobilbereich) sieht.

HOT

2020-05-19, 20:41:28

Ich bin mir nicht sicher, ob sich der L3 vergrössert pro Core. 4MB sind sehr viel, und bei TSMC 5nm soll das SRAM-Scaling nur 1.3x betragen. Wenn du also mehr Cores und mehr Cache verbaust, steigert sich unweigerlich die Die-Size. Und das wird meiner Meinung nach nicht passieren. AMD hat vermutlich mehr von 12C + 48MB L3$ anstatt 10C + 60MB L3$.

Ausserdem: Anscheined soll sich der L2$ verdoppeln. Damit sinkt schon mal der L3-Pressure.
Oh ja, ist mir auch aufgefallen, als ich die Daten sah. Allerdings steigt die Logikdichte um 80%. Es wäre also durchaus möglich 10C mit 1MiB L2$ und je 12MiB L3$ zu verbauen, ohne, dass das wesentlich größer wird. Vielleicht macht man auch 12C und landet dann eben bei 85-90mm². Spannend wir das I/O-Die, ob das dann 12LP+ bleibt oder in den 10nm-Bereich oder gar 7nm rutscht.

Hammer des Thor

2020-05-19, 21:47:18

Das Problem bei jeglichem Stacking mit High-Performance-Chips ist immer die Kühlung.

Ich dachte Speicher würdr weniger heiss als Logik? Alleine weil Speicher sehr symmetrisch ist sollten da weniger Leiterbahnen pro Transistor drin sein. Also 2 oder ev. sogar beim L3 4 Schichten könnten doch gut gehen. AMD hat 3D Stacking bald angekündigt, ich denke im SRAM-Bereich macht das erst mal mehr Sinn als im Logik-Bereich!

Hammer des Thor

2020-05-19, 21:50:40

Ich tippe darauf, dass man die CCX nach wie vor beibehält.

Dann wären bei max 24 Kernen doch 3 Core-Chiplets sinnvoll! Für max 32 Kerne sollte TSMC N5 nicht genug Platz brauchen. Und mit Stacking sind die Entfernungen wieder kürzer da übereinander, da würden mehr Kerne 1 CCX doch gehen?

BlacKi

2020-05-19, 21:51:43

Ich denke Games interessiert die Bandbreite fast gar nicht.

Games interessieren sich doch für den Speichertakt und die dadurch resultierende Latenz.
rly? tja, stimmt halt einfach nicht. vl in der ryzen welt.

mein intel system profitiert von ramtakt mehr als von latenz. ich hab mal was getestet. 3200cl12 mit 40,8ns in aida vs 4000cl18 mit 41,7ns

rate mal was 7,5% schneller ist.
https://abload.de/thumb/3200vs4000uujmf.png (https://abload.de/image.php?img=3200vs4000uujmf.png)
wie gesagt ich erhoffe mir viel von ddr5, auch wenn nicht direkt zum start ddr5 8000 zu kaufen sein wird. mit 6400 wäre ich schon zufrieden, vl geht sogar noch mehr mit OC XD

Hammer des Thor

2020-05-19, 21:55:01

Dem 3900X bringt der total grössere Cache aber nichts, weil er in 4x 16MB Slices aufgeteilt wird und erst noch auf zwei Die verteilt. Bei Zen 4 wäre es ein Unified 48MB Cache pro Chiplet. Jeder Core kann also theoretisch auf 3x so viel Cache zugreifen wie bei Zen 2.

Du hast das Wort direkt vergessen, denn über den IO Chip kann auch jeder Kern auf jeden L3 zugreifen nur langsamer. Hat hier im Forum nicht jemand geschrieben, dass das immer noch fast so schnell wie Intel Ring-Bus sei?
Das habe ich übrigens selber oft thematisiert aber RobiRob hat doch gesagt dass trotz DDR5 mehr cache PRO Kern nötig sein wird!

Gipsel

2020-05-19, 23:19:48

Ich dachte Speicher würdr weniger heiss als Logik? Alleine weil Speicher sehr symmetrisch ist sollten da weniger Leiterbahnen pro Transistor drin sein. Also 2 oder ev. sogar beim L3 4 Schichten könnten doch gut gehen. AMD hat 3D Stacking bald angekündigt, ich denke im SRAM-Bereich macht das erst mal mehr Sinn als im Logik-Bereich!Wenn Du den L3 nicht direkt 3D mit der Logik stackst sondern daneben packst, verlierst Du die Vorteile. Leitungslänge, Latenz, Stromverbrauch und so. ;)

==========================

Du hast das Wort direkt vergessen, denn über den IO Chip kann auch jeder Kern auf jeden L3 zugreifen nur langsamer. Hat hier im Forum nicht jemand geschrieben, dass das immer noch fast so schnell wie Intel Ring-Bus sei?Das ist im Vergleich näher an einem RAM-Zugriff. ;)

Hammer des Thor

2020-05-19, 23:22:39

Wenn Du den L3 nicht direkt 3D mit der Logik stackst sondern daneben packst, verlierst Du die Vorteile. Leitungslänge, Latenz, Stromverbrauch und so. ;)

Also geht das doch nicht wie ich gefragt hab! Nur: was will AMD dann 3d stacken, was Sie angekündigt haben?
Dass L3 über den IO deutlich langsamer ist als direkt ist mir schon klar!

Gipsel

2020-05-19, 23:47:30

Also geht das doch nicht wie ich gefragt hab!Also am besten wäre aus Sicht der genannten Kriterien halt L3 Cache mit den Kernen zu stacken (also ein CCD in Kerne + L3 Cache zu trennen und die dann übereinander zu packen). Und das ist eben schwierig außerhalb von Low-Power-Teilen. L3 auf dem IO-Die bringt auch nicht mehr als L3 im IO-Die. Der müßte dann schon sehr groß sein, damit sich das wegen der erhöhten Latenz noch lohnt.
Nur: was will AMD dann 3d stacken, was Sie angekündigt haben?Sie haben doch nur gesagt, daß sie daran rumentwickeln, oder? Das tun sie schon seit 10 Jahren und außer HBM bei GPUs ist noch nicht viel an Produkten rausgekommen ;).
Will sagen, eine konkrete Ankündigung oder ein Versprechen gibt es meines Wissens nicht.

basix

2020-05-20, 00:06:17

Der Wärmetransport über die Lötpunkte ist nunmal relativ mies verglichen mit einem Silizium-Kristall. Es ist vermutlich nicht völlig unmöglich, insbesondere wenn das low-power-Die (hier also der Cache) unten liegt und die Kühlung dann direkt am Logik-Die angreifen kann. Aber auch das erhöht die thermische Dichte und erschwert die Kühlung (bzw. setzt ein niedrigeres Limit für den akzeptablen Verbrauch als anderweitig möglich).

Im Prinzip ist es für mich die einzig gangbare Variante für High Power Chips, den Low Power Chip unterhalb zu platzieren. Damit eben der Kühler seine maximale Performance erreichen kann.

Beim SRAM hätte man den Vorteil, dass die Strukturen sehr regelmässig sind und man in meinem Laienverständnis relativ einfach TSV für die Wärmeableitung platzieren könnte. Danke für die Info bezüglich des 12% Flächenanteils bei HBM :) Die Wärmeableitung wird immer suboptimal bleiben, aber evtl. machen sie wie Intel dünnere Die, das kann helfen.

Wie ich schon erwähnte, würden die Cores durch das wegfallen des L3$ in der Mitte des Die sehr nahe zueinanderrücken. Damit könnte man allfällige Latenznachteile aufgrund des höheren Core-Counts pro CCX (höhere Komplexität) ausgleichen. Auf den ersten Blick sieht das also attraktiv aus. Was ich nicht beantworten kann ist, inwiefern die L3-Latenz vom Stacking beeinflusst würde.

Hammer des Thor

2020-05-20, 00:09:22

Also am besten wäre aus Sicht der genannten Kriterien halt L3 Cache mit den Kernen zu stacken (also ein CCD in Kerne + L3 Cache zu trennen und die dann übereinander zu packen). Und das ist eben schwierig außerhalb von Low-Power-Teilen. L3 auf dem IO-Die bringt auch nicht mehr als L3 im IO-Die. Der müßte dann schon sehr groß sein, damit sich das wegen der erhöhten Latenz noch lohnt.
Wissens nicht.

Na ja, wer weiss was die sich noch alles ausdenken, ev. gibt es Ideen und Lösungen die hier noch keiner kennt!

robbitop

2020-05-20, 07:18:48

Dann wären bei max 24 Kernen doch 3 Core-Chiplets sinnvoll! Für max 32 Kerne sollte TSMC N5 nicht genug Platz brauchen. Und mit Stacking sind die Entfernungen wieder kürzer da übereinander, da würden mehr Kerne 1 CCX doch gehen?

Es sind nicht nur primär die Entfernungen sondern die Eigenschaften der Fabric, die die Latenz ausmachen. Je mehr Teilnehmer, desto komplexer das Netzwerk.

Du hast das Wort direkt vergessen, denn über den IO Chip kann auch jeder Kern auf jeden L3 zugreifen nur langsamer. Hat hier im Forum nicht jemand geschrieben, dass das immer noch fast so schnell wie Intel Ring-Bus sei?
Das habe ich übrigens selber oft thematisiert aber RobiRob hat doch gesagt dass trotz DDR5 mehr cache PRO Kern nötig sein wird!

Also ein bisschen Eigenrecherche bevor man an einer Diskussion teilnimmt, wäre schon sinnvoll.

Schaue dir mal die Intra CCX Latenz an, dann die Inter CCX und Inter CCD Latenz an. Nun vergleiche sie mit der RAM Latenz.
Alles außerhalb des CCX ist leider sehr langsam (latenz) und vergleichbar mit der Memorylatency. Bringt also keinen Vorteil mehr.

Der Grundsatz ist dass Latenz und Skalierbarkeit diametrale Kriterien sind. Will man viele Kerne, muss man eben damit leben, dass die Latenz schlechter wird. Das ist einfach ein Axiom im Bereich der Fabrics. AMD hat sich deshalb die ccx als Kompromiss ausgedacht. Also wenige Teilnehmer und geringe Latenz innerhalb einer eigenen Fabric. So können wenigstens diese untereinander schnell kommunizieren und auf einen L3 zugreifen. Alles außerhalb des CCX muss dann in den sauren Apfel beißen.
Deshalb ist die Vergrößerung der CCX genau das Gegenteil dieser Idee. Das geht sicher noch ein Stück - aber die Latenz wird immer mehr leiden.

L3 Cache wird nur innerhalb des CCX angesprochen. Schaue dir mal Latentency Ladder Measurements an. Da sieht man am Graph sehr gut, dass das so ist. Wäre eben aus o.g. Gründen ziemlich sinnfrei.

Opprobrium

2020-05-20, 09:40:33

L3 Cache wird nur innerhalb des CCX angesprochen. Schaue dir mal Latentency Ladder Measurements an. Da sieht man am Graph sehr gut, dass das so ist. Wäre eben aus o.g. Gründen ziemlich sinnfrei.

Hmmm... Wäre es langfristig möglicherweise eine Option ein weiteres Cache Level, entweder als extra Chiplet oder gleich ins I/O Die integriert (z.B. im der Form von HBM), hinzuzufügen?

unl34shed

2020-05-20, 09:44:01

Der Cache wäre vermutlich nicht nennenswert schneller als der RAM und lohnt daher nicht.

robbitop

2020-05-20, 09:46:57

Hmmm... Wäre es langfristig möglicherweise eine Option ein weiteres Cache Level, entweder als extra Chiplet oder gleich ins I/O Die integriert (z.B. im der Form von HBM), hinzuzufügen?
Das wäre prinzipiell sinnvoll. Aber auch da spuckt uns wieder die IF in die Suppe. Aktuell wäre das kein/kaum ein Vorteil.

Da sich nahezu alles nach dem Gesetz des abnehmenden Grenzertrags (also asymptotisch) verhält, sollte das gar nicht unbedingt notwendig sein.
Der Sprung von Zen zu Zen 2 (besserer Prediktor und doppelter L3) war schon enorm. Zen 2 zu Zen 3 scheint das CCX zu verdoppeln und somit auch den L3. Das wird auch noch etwas bringen - aber weniger. Zen 4 verdoppelt laut Gerüchten den L2, was den L3 Pressure verringert. Der Prediktor wird sicherlich auch noch verbessert. Irgendwann übersteigen die Kosten dann den Nutzen.

IMO wird mit diesen Änderungen der Nachteil der modernen Fabric nahezu ausgebügelt sein und man kann sich weiter darauf fokussieren, die ILP Exctraction zu erhöhen. Ein paar Shrinks später kann man dann ggf. ohne Latency Hit die L1-L3 Caches sukzessiv vergrößern.

mboeller

2020-05-20, 10:17:03

Hammer des Thor

2020-05-20, 10:20:11

Es sind nicht nur primär die Entfernungen sondern die Eigenschaften der Fabric, die die Latenz ausmachen. Je mehr Teilnehmer, desto komplexer das Netzwerk.

Also ein bisschen Eigenrecherche bevor man an einer Diskussion teilnimmt, wäre schon sinnvoll.

L3 Cache wird nur innerhalb des CCX angesprochen. Schaue dir mal Latentency Ladder Measurements an. Da sieht man am Graph sehr gut, dass das so ist. Wäre eben aus o.g. Gründen ziemlich sinnfrei.

Also, das habe ich schon gemacht und weiss dass der Zugriff mit dem Chiplet-Design gut doppelt so schnell ist wie bei Zen 1 über den Interconnex- Damals gab es wohl Microruckler in Spielen durch diesen Zugriff. Bei nicht optimierter SW passiert es doch dass auch CCX-Übergreifend auf den L3 zugegriffen wird? Informieren tu ich mich ja auch hier und kann mich an so einen Post erinnern.
Nach Deinen Vorstellungen müsste Zen3 mit vollen 8 Kernen die pro "CCX" eine Fehlkonstruktion sein, trotzdem soll Zen3 deutlich schneller sein!

HOT

2020-05-20, 10:29:22

AMD ändert die Topologie nicht auch Jux und Dollerei. Das wird schon handfeste Vorteile haben in der Latenz, wenn man die CCX aufbricht. MMn waren die CCX das ne Art Übergangslösung bis man was wirklich gutes zur Verfügung hat.
Und man wird das mMn weiter aufbohren. 8C CCD bei Zen3, 10C CCD bei Zen4 und 12C CCD bei Zen5 (3nm). Danach ist Zen eh beendet und eine neue Basisarchitektur wird Einzug halten.

Der_Korken

2020-05-20, 10:41:29

Ist es wirklich so leicht Nicht-Zweierpotenzen als eine Einheit zu bringen? Ein Vorteil von Zweierpotenzen ist, dass man den Adressraum statisch aufteilen kann und bei einer Adresse immer anhand von bestimmten Bits sofort weiß in welchem Slice die Daten stehen müssen, sofern sie im Cache sind. Aus dem Grund deaktiviert AMD bei den 6-Kernern auch nicht ein Slice pro CCX, weil diese Aufteilung sonst nicht mehr funktioniert. Ich weiß nicht, wie Intel das technisch löst, aber bei denen war die Inter-Core-Latenz immer leicht schlechter als bei Ryzen, eventuell gerade wegen der höheren Flexibilität.

KarlKastor

2020-05-20, 10:44:01

Wie ist denn die Anbindung in einem 8C CCX bei Zen3? Crossbar? Klingt ziemlich komplex.
Aber ohne das zu Wissen, kann man doch jetzt noch nicht vorhersagen ob eine weitere Aufbohrung auf 10 oder 12 Kerne sinnvoll ist.

robbitop

2020-05-20, 10:46:04

Also, das habe ich schon gemacht und weiss dass der Zugriff mit dem Chiplet-Design gut doppelt so schnell ist wie bei Zen 1 über den Interconnex- Damals gab es wohl Microruckler in Spielen durch diesen Zugriff. Bei nicht optimierter SW passiert es doch dass auch CCX-Übergreifend auf den L3 zugegriffen wird? Informieren tu ich mich ja auch hier und kann mich an so einen Post erinnern.
Nach Deinen Vorstellungen müsste Zen3 mit vollen 8 Kernen die pro "CCX" eine Fehlkonstruktion sein, trotzdem soll Zen3 deutlich schneller sein!
Bessser wäre es ein paar Fachartikel und Messungen in diesen zu informieren.
Man hat die IF sukzessive verbessert und auch etwas höher getaktet, das hat ein geholfen.
Zen 2 braucht zwischen 2x CCX rund 70 ns. L3 im CCX liegt bei rund 10 ns. Memorylatency auch etwa bei 70 ns out of the box.

Zen 1 braucht zwischen 2x CCX rund 110 ns. L3 im CCX liegt ebenfalls bei rund 10 ns. Latency auch zwischen 60 und 70 ns.

Kerne haben mWn nie in den L3 anderer CCX zugegriffen. Das ist etwas was mMn nicht über Software passiert sondern über die CPU Firmware gesteuert wird. Der L3 ist ein Victim Cache des L2.
Das Problem war, dass Threads außerhalb der CCX hin und her gesprungen sind.

Dass Zen 3 eine "Fehlkonstruktion" ist, denke ich nicht. Ganz im Gegenteil. Die Latenz innerhalb des CCX könnte (muss aber nicht - innerhalb gewisser Grenzen ist sicherlich Spielraum) ein wenig steigen. Jedoch sollten die Vorteile die eventuellen Nachteile überwiegen. Der L3 pro CCX verdoppelt sich. Das bedeutet Faktor ~1,4 bessere Hitrate. Entsprechend seltener muss auf den RAM zugegriffen werden. Wenn die L3 Latenz im Gegenzug um wenige ns steigen sollte, wäre das kein Drama.
Es ist nunmal so in der Natur und Technik: man kann nicht alles haben - jeder Vorteil bringt automatisch einen Nachteil. Durch Engineering kann man stark daran arbeiten, dass die Nachteile abgeschwächt werden und die Vorteile verstärkt werden. Am Ende muss man aber dennoch Trade-offs eingehen. Dann gilt es darum, die Konstellation so zu wählen, dass das Endergebnis besser ist als vorher. Und genau das tat man IMO seit Zen in 2017 mit jeder Iteration sehr sehr gut. (und auch bei Intel sind bereits ähnliche Muster für Sunny Cove, Willow Cove und Golden Cove erkennbar)

IMO kann man Zen 1 auch ein wenig ausklammern. Zen 1 wurde entwickelt als AMD am Boden lag. Ressourcen waren sehr dünn und man musste alles neu machen. Die Cores, die Fabric. Und der Zeitrahmen war eng. Entsprechend ist das ein Generation 1 Produkt, um erstmal auf den Markt zu kommen. Gerade die Fabric war da schon noch sehr neu und entsprechend konservativ. Ähnliche Sprünge pro Generation sind jetzt kaum noch zu erwarten.

AMD ändert die Topologie nicht auch Jux und Dollerei. Das wird schon handfeste Vorteile haben in der Latenz, wenn man die CCX aufbricht. MMn waren die CCX das ne Art Übergangslösung bis man was wirklich gutes zur Verfügung hat.
Und man wird das mMn weiter aufbohren. 8C CCD bei Zen3, 10C CCD bei Zen4 und 12C CCD bei Zen5 (3nm). Danach ist Zen eh beendet und eine neue Basisarchitektur wird Einzug halten.
Das CCX ist in Verbindung mit der Skalierbarkeit der IF schon eine sehr gute Idee gewesen. Ein toller Kompromiss. Aber ggf. schaut man sich auch andere Fabrics an. Wie beispielsweise ein Mesh oder ein Butterfly. Auch die werden entsprechende Nachteile haben. Sofern sie das umstellen wird die Gesamtsumme dann besser sein als die jetzige Konstellation.

Ob man die CCX auch technisch in Zen 3 "aufbricht" - da bin ich noch skeptisch. Wenn man pro CCD nur 1x CCX hat, ist es relativ sinnfrei, beide Bezeichnungen parallel laufen zu lassen. Am Ende wird man eine Fabric auf dem CCD haben, die schnell ist und eine zum I/O Die, die halt langsamer ist. Ob man das jetzt CCX oder sonst wie nennt, macht aus Sicht der Topologie erstmal keinen Unterschied.

CrazyIvan

2020-05-20, 11:16:07

Ich könnte mir immer noch vorstellen, dass AMD möglicherweise schon zu Zen3 alle mit einer CoWos 2,5D Lösung überrascht, bei der (Teile des) IOD im Interposer sitzen und/oder ein L4 auf diesem Wege angebunden wird. Würde die Energieeffizienz des uncore wohl deutlich erhöhen und die IPC bei MT-Workloads ebenfalls steigern. Ich weiß - dünnes Eis ;)

mboeller

2020-05-20, 11:43:23

Und man wird das mMn weiter aufbohren. 8C CCD bei Zen3, 10C CCD bei Zen4 und 12C CCD bei Zen5 (3nm). Danach ist Zen eh beendet und eine neue Basisarchitektur wird Einzug halten.

Nein, hätte Intel sonst schon so gemacht.

Crossbars haben, wenn ich nicht falsch gesucht habe sehr hohe "Kosten" pro Node: n^2.

4^2 = 16
8^2 = 64
12^2 = 144

http://15418.courses.cs.cmu.edu/spring2013/article/30

Vielleicht benutzt deshalb AMD für ZEN3 schon was anderes und nicht mehr einen einfachen Crossbar

r-or

2020-05-20, 11:57:46

Nein, hätte Intel sonst schon so gemacht.

Crossbars haben, wenn ich nicht falsch gesucht habe sehr hohe "Kosten" pro Node: n^2.

4^2 = 16
8^2 = 64
12^2 = 144

http://15418.courses.cs.cmu.edu/spring2013/article/30

Vielleicht benutzt deshalb AMD für ZEN3 schon was anderes und nicht mehr einen einfachen Crossbar
Das interconnect innerhalb eines CCX sollte eine Point to point sein, keine crossbar. Und ja, dann ist die Anzahl der links O(n^2). Crossbar ist O(N), hat aber einen hop
*Hat n^2 nodes

mksn7

2020-05-20, 11:59:25

Damals gab es wohl Microruckler in Spielen durch diesen Zugriff. Bei nicht optimierter SW passiert es doch dass auch CCX-Übergreifend auf den L3 zugegriffen wird?

Achtung! Diese Schlussfolgerung "Hohe Zugriffslatenz auf anderen Core oder Memory" => "Mikroruckler" hab ich jetzt schon mehrmals gesehen, aber das passiert auf zwei völlig unterschiedlichen Zeitskalen. Diese Zugriffe sind etwa in der Größenordnung 100ns (Nanosekunden). Ein Mikroruckler ist in der Größenordnung von 1ms (Millisekunden). Da ist ein Faktor 10'000 dazwischen.

Sicherlich haben hohe Zugriffslatenzen einen negativen Einfluss auf die performance. Das betrifft dann aber alle frames gleichmäßig. Wenn in einem frame jetzt einmal irgendwo ein weiter entfernter Zugriff passiert, macht das keinen Unterschied. Es müssten schon in einem frame gar kein Zugriffe auf andere L3 caches passieren, und im nächsten frame plötzlich dauernd. In der Realität wird das in jedem frame etwa gleichmäßig oft vorkommen.

HOT

2020-05-20, 12:48:06

Das ist ja der Punkt, wir wissen nicht, wie AMD die on-Chip-Topologie gelöst hat. Das kann alles mögliche sein. Wir werden sehen, was uns da erwartet. Aber die Skalierbarkeit von 4-12 Kernen halte ich für klar.
Das CCX fällt einfach weg. Es gibt dann eben nur noch CCDs. Und klar, CCX war ne ziemlich elegante Lösung, aber eben auch mit saftigen Nachteilen.

Der_Korken

2020-05-20, 14:08:24

basix

2020-05-20, 14:42:23

Wenn Intel Probleme hat, den Ring immer größer zu machen, dann wird AMD ja wohl nicht mal eben 12er oder 16er Blöcke machen, die so performant wie die kleinen Ringe von Intel sind. Für 8 Kerne kann man sich ja noch eine Würfel- oder Torus-Topologie vorstellen, aber darüber wird es dann langsam. Es hat sicher Gründe, warum Intel bei >=12 Kernen kaskadierte Ringe oder ein Mesh verwendet hat.

Was ist das Problem? Du sagst doch selbst, dass man bis 12 Kerne mit dem Ring noch klarkommt. Momentan geht man bei Zen 4 von 10-12C pro CCD aus. Topologien mit mehr Kernen werden dann mit einem 2-Stage Design über Inifinity Fabric gelöst. Passt doch. Es gibt viele reduzierte Topologien, wo man mit max. 2 Hops überall hinkommt. 2 Hops sind viel weniger als bei einem grossen Ring. Mit 3 Hops kannst du Millionen von Teilnehmern verbinden, siehe Cray Slingshot https://www.cray.com/sites/default/files/Slingshot-The-Interconnect-for-the-Exascale-Era.pdf

Platos

2020-05-20, 15:30:47

Momentan geht man bei Zen 4 von 10-12C pro CCD aus.

Wer ist "man" ?

Zossel

2020-05-20, 16:07:04

Anderer Vorschlag: Wie wäre es mit multiported RAM für den L3 als "Crossbar"?

basix

2020-05-22, 12:19:13

Wer ist "man" ?

Die Gerüchteküche und viele hier im Forum ;) Grund: Deutlich gesteigerte Packdichte aufgrund 5nm. Mehr Cores pro CCD machen mehr Sinn als mehr Chiplets.

mironicus

2020-05-22, 12:24:42

Gipsel

2020-05-22, 13:23:08

Anderer Vorschlag: Wie wäre es mit multiported RAM für den L3 als "Crossbar"?Es ist sehr teuer echte multiported SRAM-Zellen zu verbauen (wird heutzutage fast nur noch bei Registern bzw. in der OoO-Logik in CPUs gemacht [wobei man da manchmal streiten kann, was SRAM und was flip-flops sind], sogar die Register von GPUs sind single ported SRAM-Zellen). Typischerweise wird der Cache in mehrere Bänke organisiert, von denen ein gewisse Anzahl parallel angesprochen werden können (pseudo-multiported). Im Falle der L3-Caches bei Zen/Zen2, bestehen die sowieso schon aus je 4 Tiles, die parallel arbeiten können. Eine Crossbar in der Cache-Control-Logik (bzw. zwischen denen der 4 Tiles) ist da sicher die einfachere Variante (und erst recht bei 8 Tiles vs 8 port SRAM :freak:).

Ravenhearth

2020-05-22, 14:39:45

Ich schätze mal es werden 12 Kerne pro CCD in 5 nm.

Die Steigerung macht auch Sinn. Dann werden wir auch 12 Kerne im Laptopbereich haben. Bei 15 Watt selbstverständlich. 8/16 Kerne mit 15 Watt funzt ja auch schon in 7 nm mit Renoir.
Ich glaube nicht an mehr Kerne mit Zen 4. Wer braucht 12 Kerne im Ultrabook? Ich denke, man wird 5nm eher für mehr IPC und Takt nutzen, so ein 4800U hat einen Basistakt von nur 1,8 GHz. Im Desktop wird das ganz ähnlich sein, man geht auf mehr Leistung pro Kern. Man darf auch nicht vergessen, dass TSMC für 5nm nur 30% lower power verspricht bzw. 15% mehr Takt. Das reicht nicht für mehr Kerne UND mehr IPC/Takt. Packdichte ist nicht alles. Man wird angesichts höherer Kosten durch 5nm auch eher versuchen, die Die-Größen zu reduzieren. Das geht besser, wenn man nicht mehr Kerne verbaut.

Berniyh

2020-05-22, 16:43:03

Ich glaube nicht an mehr Kerne mit Zen 4. Wer braucht 12 Kerne im Ultrabook?
Wer braucht 12 Kerne auf dem Smartphone?

Und trotzdem sind da 8 Kerne inzwischen Standard und manche haben bereits 10 oder 12.

basix

2020-05-22, 17:12:24

Genau. Und wer sagt, dass Mobile die selbe Anzahl Cores pro CCX/CCD hat? Desktop und Server = 12C und Mobile = 8C wäre auch eine Option. Ist ja nicht so, dass Renoir keine Unterschiede zu Matisse aufweist ;)

Rooter

2020-05-22, 17:14:08

Wer braucht 12 Kerne auf dem Smartphone?

Und trotzdem sind da 8 Kerne inzwischen Standard und manche haben bereits 10 oder 12.Der Vergleich hinkt sehr da das keine 8 identischen Kerne sind sondern 4 Performance- und 4 Stromspar-Cores.

MfG
Rooter

Berniyh

2020-05-22, 17:32:23

Der Vergleich hinkt sehr da das keine 8 identischen Kerne sind sondern 4 Performance- und 4 Stromspar-Cores.
Na und?

Übrigens will Intel ja genau sowas jetzt auch auf dem Desktop bringen.

Ravenhearth

2020-05-23, 15:16:51

Wenn Zen 4 erst Anfang 2022 kommt, könnte es nicht auch sein, dass man "Ryzen 5000" bei den normalen CPUs überspringt? 5000 ist halt 2021, und da könnts sein dass nur die Zen 3 APUs erscheinen. Dann hätte man CPUs und APUs auch wieder auf einer Linie, Zen 4 wäre dann Ryzen 6000, egal ob mit Grafik oder nicht.

amdfanuwe

2020-05-23, 15:49:12

Ich könnte mir gut vorstellen, dass ZEN4 APUs in 5nm recht früh kommen. Im Mobile Markt lässt sich mehr verdienen, wie im Desktop. Nachdem mit Renoir ordentlich Aufmerksamkeit erzeugt wurde, wird da weiterhin am Ball bleiben müssen um nicht wieder alles zu verspielen.
Also erst mal Mobile und Server in 5nm? Etwas später das Desktop Portfolio mit APUs bis 8 Core und darüber mit Server Chiplets oder Monolithischem 16 Core.
24 Core wären im Desktop mit 5nm sicherlich möglich, aber bringt es das? Gibt ja noch Threadripper wenn 16 Kerne wirklich nicht reichen.
EDIT:
5nm fängt ja jetzt schon die Produktion an. Vielleicht gibt es dann gar keine 7nm ZEN3 APU mehr und AMD geht mit dem Renoir Nachfolger direkt auf 5nm.
Alles etwas verwirrend momentan.

SKYNET

2020-05-23, 18:47:29

Na und?

Übrigens will Intel ja genau sowas jetzt auch auf dem Desktop bringen.

was ja total sinnvoll ist, in zeiten wo eigentlich alles an programmen und games so langsam aber sicher immer mehr kerne will... da schiesst sich intel sicherlich selber ins bein, zumal AMD mit der gleichen anzahl kernen, aber alle als performance, sicherlich trotzdem weniger verbraten wird ;D

KarlKastor

2020-05-23, 20:35:45

@amdfanuwe
Bisher sind Server und Desktop ja gleich. Warum sollte dann Desktop merklich später kommen?
Die APU ist hingegen deutlich mehr Aufwand. Ich denke die wird kaum als erstes kommen. Vor allem da die bei Zen3 ja wohl wieder als letztes kommt.

Zu der Anzahl an Kernen:
Kommt drauf an wie AMDs Plan ist. Wenn die weiterhin mit der Fertigung vorne liegen, können die immer Intel mit mehr Kernen ans Bein pinkeln, ohne das die kontern können. Wie jetzt bei Zen2.
Allerdings stellt sich wirklich die Frage, ob im Consumer Bereich überhaupt so viele Kerne nachgefragt werden. Ich denke da sind es heute auch überwiegend bis 8 Kerne und der Rest eher in homöopathischen Dosen.

SKYNET

2020-05-23, 20:52:21

Rooter

2020-05-23, 20:57:29

Ich denke da sind es heute auch überwiegend bis 8 Kerne und der Rest eher in homöopathischen Dosen.Und vor allem mit den kommenden 8C/16T Konsolen gibt es für die nächsten Jahre keinen Grund, Spiele-Engines für mehr als das zu optimieren.

MfG
Rooter

gmb

2020-05-23, 21:06:22

Ich könnte mir gut vorstellen, dass ZEN4 APUs in 5nm recht früh kommen. Im Mobile Markt lässt sich mehr verdienen, wie im Desktop. Nachdem mit Renoir ordentlich Aufmerksamkeit erzeugt wurde, wird da weiterhin am Ball bleiben müssen um nicht wieder alles zu verspielen.

Das hätte man sich auch schon für Renoir vorstellen können, oder für Picasso. Trotzdem hat AMD zuerst die neue Generation für den Desktop gebracht. Mobile braucht mehr Vorlaufzeit und wenn der Hersteller nicht die Priorität darauf legt, ist der Desktop eher dran. Sieht man ja jetzt wieder, wie schlecht vor allem Renoir-U verfügbar ist im freien Handel.

TheAntitheist

2020-05-23, 22:33:42

Und vor allem mit den kommenden 8C/16T Konsolen gibt es für die nächsten Jahre keinen Grund, Spiele-Engines für mehr als das zu optimieren.

MfG
Rooter
joa nur haben die noch co prozessoren die den schnickschnack abarbeiten wie decompression etc. Wenn das Einzug hält bei den PCs brauchen wir dafür schon ein paar kerne mehr.

mr coffee

2020-05-23, 22:36:16

Noch dazu für die typischen background tasks welche so am pc laufen ...

Rooter

2020-05-24, 00:32:13

joa nur haben die noch co prozessoren die den schnickschnack abarbeiten wie decompression etc. Wenn das Einzug hält bei den PCs brauchen wir dafür schon ein paar kerne mehr.Für diese "Co-Prozessoren" gibst du mir bitte einen Link. :smile:

MfG
Rooter

TheAntitheist

2020-05-24, 02:53:53

Für diese "Co-Prozessoren" gibst du mir bitte einen Link. :smile:

MfG
Rooter
ist doch bekannt, da stand doch überall decompressor worth 9 zen cores blabla... wurd hier auch zig fach geposted.

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

robbitop

2020-05-24, 08:53:11

Wobei die Spiele für die Konsolen sicherlich für 14 Threads optimiert werden. Bedeutet, dass man bis 14 Cores profitieren könnte (Cores sind besser als Threads). Dazu noch der übliche Overhead beim PC. Mit 16Cores macht man sicherlich langfristig wenig falsch.

amdfanuwe

2020-05-24, 09:17:58

SKYNET

2020-05-24, 11:26:20

Der Preis muss auch stimmen:
aktuell verkauft bei MF, AMD 3000er Serie:
200€ Klasse, 6 Core, ~76000
300€ Klasse, 8 Core, ~47000
400+€ Klasse, 12 Core, ~15500
700+€ Klasse, 16 Core, 2100
Wird noch ein paar Jahre dauern, bis 16 Core im Mainstream ankommt. Aktuell scheinen ja 6 Core für die gegebenen Anwendungen gut ausreichend zu sein. Liegt auch daran, dass sie Single Core Performance mit mehr Kernen nicht zunimmt.

naja, bis jetzt ist rein fürs zocken <1440p nen 3300X auch besser als nen 3600/X, zumindest solange es im CPU limit ist, weil sobald die GPU alleine der bremsende faktor ist, dreht sich das bild wieder, da sind dann die >6kerner wieder besser.

aber spätestens 2022, wenn die ersten games kommen, die einzig auf die hardware der neue konsolen gen optimiert wurden, dürften die <8c/16t massiv abstinken.

RLZ

2020-05-24, 13:15:09

ist doch bekannt, da stand doch überall decompressor worth 9 zen cores blabla... wurd hier auch zig fach geposted.

https://i.imgur.com/vnt68ul.jpg
Das würde ich nicht überbewerten. Auch die PS4 hatte schon einen Hardware Decoder für ZLib.
Notfalls geht man halt etwas mit der Kompressionsrate runter und braucht dann wesentlich weniger CPU Leistung dafür.

Ravenhearth

2020-05-24, 13:21:08

Das kann man kaum überbewerten. Die PS4 musste nur Hundert MB/s schaffen, die PS5 liegt bei mehreren GB/s. Und der Hardware-Decoder ist für Kraken.

"By the way, in terms of performance, that custom decompressor equates to nine of our Zen 2 cores, that's what it would take to decompress the Kraken stream with a conventional CPU," Cerny reveals.
https://www.eurogamer.net/articles/digitalfoundry-2020-playstation-5-specs-and-tech-that-deliver-sonys-next-gen-vision

Zossel

2020-05-24, 13:35:32

Das würde ich nicht überbewerten. Auch die PS4 hatte schon einen Hardware Decoder für ZLib.
Notfalls geht man halt etwas mit der Kompressionsrate runter und braucht dann wesentlich weniger CPU Leistung dafür.

Es geht um Dekompression, das ist bei weiten nicht so rechenintensiv, die Lösung von Sony spart vor allen diverse memcpy() bzw. copy_from_user() copy_to_user() Aufrufe.

Rooter

2020-05-24, 16:10:24

ist doch bekannt, da stand doch überall decompressor worth 9 zen cores blabla... wurd hier auch zig fach geposted.

https://i.imgur.com/vnt68ul.jpgDanke, das ging an mir vorüber.

Das kann man kaum überbewerten. Die PS4 musste nur Hundert MB/s schaffen, die PS5 liegt bei mehreren GB/s. Und der Hardware-Decoder ist für Kraken.

https://www.eurogamer.net/articles/digitalfoundry-2020-playstation-5-specs-and-tech-that-deliver-sonys-next-gen-visionDann ist das aber eine seltsame Kompression. Nimmt man für sowas nicht schnelle Algos wie LZ4?

MfG
Rooter

Ravenhearth

2020-05-24, 16:52:37

LZ4 komprimiert halt lange nicht so stark, und bei nur 925GB Speicherplatz ist man ziemlich auf die Kompression angewiesen :redface:
Es erhöht aber auch nochmal die effektive Bandbreite von 5,5 GB/s raw auf 8-9 GB/s

Gipsel

2020-05-24, 17:56:38

Der Konsolenthread ist übrigens nebenan. ;)

RLZ

2020-05-24, 17:58:18

Und der Hardware-Decoder ist für Kraken.
Ich hab da ja auch nichts anderes gesagt für die PS5. Aber die PS4 hatte dafür halt auch schon Hardware, was oft unterging.

TheAntitheist

2020-05-24, 23:50:24

Das würde ich nicht überbewerten. Auch die PS4 hatte schon einen Hardware Decoder für ZLib.
Notfalls geht man halt etwas mit der Kompressionsrate runter und braucht dann wesentlich weniger CPU Leistung dafür.
es wurde gesagt das die Einheit so schnell ist wie 9 zen2 cores... und das wird wohl auch für die SSD mit kraken benötigt. Ich würde das NICHT unterbewerten.

Ich kann nicht einmal photoshop unter 5 sekunden laden und das programm ist auf meiner 970 evo plus blabla die 3.3GB schaffen soll.... und Photoshop ist keine 15gb groß.

TheAntitheist

2020-05-24, 23:51:06

Ich hab da ja auch nichts anderes gesagt für die PS5. Aber die PS4 hatte dafür halt auch schon Hardware, was oft unterging.
ja aber 10gb oder 100mb die sekunde zu dekodieren ist ja wohl ein KLEINER UNTERSCHIED

JVC

2020-05-29, 10:47:34

Leonidas

2020-08-08, 09:33:41

fondness

2020-08-08, 11:02:36

5nm+ läuft anscheinend schon ganz gut...

Falls DDR5 sich nicht verzögert, könnte Zen4 durchaus schon in 5nm+ Ende 2021 kommen.

Oder Zen4 kommt Ende 2022 (weil man vielleicht auf DDR5 wartet)
Dann wäre ein 3+"refresh" durchaus möglich.

M.f.G. JVC

AMD verwendet ohnehin nur HP Prozesse, ergo nie die erste Iteration. Ob man das dann + oder wie auch immer nennt ist egal, aber der HP Prozess kommt Minimum ein Jahr später im Vergleich zu dem was die Smartphone-Chips verwenden.

HOT

2020-08-08, 11:10:40

Neue Details von Komachi nach "Winterschlaf":

1. Stones is something close to Floyd. I think It could be a custom Genoa.
2. Raphael is probably a Zen 4 CPU.
3. Phoenix (PHX) is something of a Zen 4. Details is yet.

https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-7-august-2020
Das kann schon sein, dass die Semi-Custom-Sparte vor allem Custom-Server im Visier hat in Zukunft.

JVC
Nope, die werden erst im Winter ins Tape Out gehen, das bedeutet Q3 22. Zen3 ist und bleibt N7P und ein Warhol wird dasselbe Chiplet nutzen, nur das IOD ist halt fällig.

Leonidas

2020-08-29, 10:21:55

Details & Bestätigungen früherer Gerüchte zu Zen 4:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-28-august-2020

Der_Korken

2020-08-29, 10:36:20

1MB L2-Cache und AVX512 ... Skylake X anyone? ;)

Für mich würde eine zweite Gen von Zen 3 im Desktop da schon Sinn ergeben, denn diese Änderungen klingen ziemlich nach HPC und für den Desktop weniger interessant. 5nm bringt natürlich Effizienz, aber die braucht man ja hauptsächlich für Server und Mobile. Im Desktop wäre Takt wichtiger, aber da bringt ein neuer Prozess bei CPUs normalerweise nicht so viel.

LasterCluster

2020-08-29, 11:22:45

Für mich würde eine zweite Gen von Zen 3 im Desktop da schon Sinn ergeben, denn diese Änderungen klingen ziemlich nach HPC und für den Desktop weniger interessant. 5nm bringt natürlich Effizienz, aber die braucht man ja hauptsächlich für Server und Mobile. Im Desktop wäre Takt wichtiger, aber da bringt ein neuer Prozess bei CPUs normalerweise nicht so viel.

Sehe ich auch so. Warhol als Zen3 Refresh kommt vielleicht auf einem "N7ee" Prozess und holt nochmal 200-300MHz raus. Denke das Ding wird ganz humorlos mit der letzten Generation an AM4 Boards irgendwann August/September 2021 released, quasi als Matisse 2.0 in weniger besch...eiden.

Wenn Zen4 dann ~6 Monate später im Server kommt, kann man dann erst mal gemütlich den Server/HPC-Markt bedienen bis Raphael auf dem DT erscheint.

HOT

2020-08-29, 13:48:58

Eher N6e. Dass Zen4 mehr Cache bringen wird war ja schon vorher vermutet worden.

basix

2020-08-29, 14:52:32

Bei 1MB L2$ + 4MB L3$ pro Core und evtl. 10-12C pro CCX ergäbe das ein ziemliches Cache Monster. 50-60MB für alle Cores, 40-48MB für L3$. Die allergrössten Broadwell-EP mit 24C hatten 60MB L3$ :D

Der_Korken

2020-08-29, 15:08:30

HOT

2020-08-29, 16:03:21

Ich wär da nur etwas vorsichtig, denn Raphael war mit RDNA3 eingetragen in die Roadmap, es könnte also sein, dass der Desktop-Zen4 nichts mit den Chiplets zu tun hat. Den 1MB L2 wird der sicherlich auch erhalten, aber ob er den großen L3 bekommt steht in den Sternen.

Brillus

2020-08-29, 16:15:56

Sehe ich auch so. Warhol als Zen3 Refresh kommt vielleicht auf einem "N7ee" Prozess und holt nochmal 200-300MHz raus. Denke das Ding wird ganz humorlos mit der letzten Generation an AM4 Boards irgendwann August/September 2021 released, quasi als Matisse 2.0 in weniger besch...eiden.

Wenn Zen4 dann ~6 Monate später im Server kommt, kann man dann erst mal gemütlich den Server/HPC-Markt bedienen bis Raphael auf dem DT erscheint.

Wenn richtig im Kopf hat Warhol eine GPU drin ich tippe daher eher AM5 halt mit neuem IO Die.

HOT

2020-08-29, 16:16:30

Wenn richtig im Kopf hat Warhol eine GPU drin ich tippe daher eher AM5 halt mit neuem IO Die.
Nope, wie gehabt CPU.

basix

2020-08-29, 16:22:09

Je nachdem wie der L3-Cache überhaupt bei 8 Kernen aufgebaut ist, könnten 10 oder 12 Kerne pro CCX unmöglich sein. Es hat schon einen Grund warum AMD bei Zen nicht auf einen Ringbus gesetzt hat und jetzt direkt von 4 auf 8 geht statt bei einen Zwischenschritt bei Zen 2 mit 6 Kernen zu machen. Wenn man eine Zweierpotenz als Slice-Anzahl hat, kann man die Speicheradressen statisch schön gleichmäßig verteilen und "weiß" beim Lookup direkt in welchem Slice eine Adresse liegen muss.

Mit dem Thema Speicheradressen kenne ich mich nicht wirklich aus. Aber wenn du eh eine Lookup-Table für die Speicheradressen verwendest, spielt die Anzahl Teilnehmer am Cache doch gar keine Rolle?! Hast ja direkt im Lookup das Ziel hinterlegt, egal wie krumm die Adresse schlussendlich ist. Du verlierst nur etwas Effizienz / Registerplatz des MSB, da nicht komplett ausgenutzt. Vom 2er Potenz Gedanken müssen wir uns aber eh mal verabschieden. 2x Scaling war in Zeiten von Moore's Law OK. Aber 2x Sprünge wirst du nicht mehr alle 1-2 Jahre sehen. Deswegen werden wir immer mehr "krumme" Steigerungen von 1.25, 1.33 oder 1.5 sehen.

Für mich der naheliegenste Grund für 8C: Selbe Kernanzahl pro CCD wie heute und mehr Kerne machen mit 7nm keinen Sinn (Chipletgrösse und Verbrauch). Ausserdem Softwarekompatibilität (4C/8T Clustering der Programme seit Zen 1). Aufgrund letzterem sehe ich 12C als wahrscheinlicher an gegenüber von 10C. Man kann seine Programme und Tasks immer noch in 4C Clusters auf die CPU verteilen, ohne dass man irgendwo eine Zweiteilung auf mehrere CCX bekommt. Nun halt einfach geshared L3$. Wie man das dann verdrahtet ist eine andere Frage. Nvidia hat bei A100 den L2$ über eine Crossbar zweigeteilt. Laut Nvidia führt das zu einer Homogenisierung der Latenz. Es kann sein, dass AMD etwas ähnliches machen wird. Eine L3$ Crossbar einfügen und L3$-4C Blöcke an die Crossbar hängen. Das skaliert dann auch mit mehr Cores wie 12C oder 16C. Die durchschnittliche Latenz wird leicht steigen, man hat aber einen einzelnen riesengrossen L3$. Anstatt eine Crossbar könnte man auch eine direkte L3-Verbindung zwischen den 4C-Blöcken machen. Da kann man bis zu 4x 4C-Blöcke auf die selbe Weise verbinden, wie man das heute innerhalb des 4C CCX macht (max. 6 Verbindungen für direkte Verbindung aller Teilnehmer). Bis und mit 16C und somit bis und mit 3nm Chips hätte man einen Path Forward.

Aus dem A100 Hot Chips Live Blog von Anandtech (https://www.anandtech.com/show/15992/hot-chips-2020-live-blog-nvidia-a100-performance-500pm-pt):
Q: Split L2 with crossbar - does this introduce latency variation? A: It doesn't, but it does equalizes of all the split areas due to data locality. L2 hits ends up with less latency variation

Brillus

2020-08-29, 16:46:52

Nope, wie gehabt CPU.

Hast recht mit Raphael verwechselt.

Der_Korken

2020-08-29, 18:41:23

Mit dem Thema Speicheradressen kenne ich mich nicht wirklich aus. Aber wenn du eh eine Lookup-Table für die Speicheradressen verwendest, spielt die Anzahl Teilnehmer am Cache doch gar keine Rolle?! Hast ja direkt im Lookup das Ziel hinterlegt, egal wie krumm die Adresse schlussendlich ist. Du verlierst nur etwas Effizienz / Registerplatz des MSB, da nicht komplett ausgenutzt.

Ich bin da wahrlich auch kein Experte, das nur vorweg. An Lookup-Tabellen dachte ich eigentlich nicht, sondern einfach nur an den Fall, dass da irgendeine Speicheradresse ankommt und der L3-Controller jetzt entscheiden muss, wo in welcher Cache-Slice er nachguckt. Wenn man z.B. einfach die drei kleinsten Bit (bzw. Bits 7-9 weil Cachezeilen ja schon 64Byte groß sind) quasi als "Adresse" für die Cache-Slice nimmt, dann ist es sehr einfach die Adresse wiederzufinden. Hätte man z.B. 6 Slices, dann müsste man für eine gleichmäßige Verteilung jede Speicheradresse modulo 6 rechnen. Geht natürlich, aber die Division dafür würde vermutlich ein paar Takte Latenz kosten.

Vom 2er Potenz Gedanken müssen wir uns aber eh mal verabschieden. 2x Scaling war in Zeiten von Moore's Law OK. Aber 2x Sprünge wirst du nicht mehr alle 1-2 Jahre sehen. Deswegen werden wir immer mehr "krumme" Steigerungen von 1.25, 1.33 oder 1.5 sehen.

Alle 1-2 Jahre nicht, aber hin und wieder schon. Von 4 auf 8 hat AMD jetzt halt von Zen 1 bis Zen 3 gebraucht. Ich denke für Zen 4 sind 8C/CCX noch gut genug.

Nvidia hat bei A100 den L2$ über eine Crossbar zweigeteilt. Laut Nvidia führt das zu einer Homogenisierung der Latenz. Es kann sein, dass AMD etwas ähnliches machen wird. Eine L3$ Crossbar einfügen und L3$-4C Blöcke an die Crossbar hängen. Das skaliert dann auch mit mehr Cores wie 12C oder 16C.

Ich glaube bei den Topologien kann man sehr kreativ sein. Fakt ist natürlich, dass entweder die durchschnittliche Latenz (=Anzahl Hops) steigt oder der Verdrahtungsaufwand pro Kern. Oder beides. Ich bin mal gespannt wie AMD das bei Zen 3 gelöst hat.

Zen 1 hatte afaik damals innerhalb des CCX bessere Latenzen als Intels 7700K. Ähnliches erwarte ich bei Zen 3 vs 9900K. Nur irgendwo her muss der Vorteil von AMD herkommen und ich vermute dass sie einfach Flexibilität opfern was die Anzahl der Teilnehmer am Cache angeht.

Zossel

2020-08-30, 07:09:32

Mögliche Cachestrukturen: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.107.3602&rep=rep1&type=pdf / https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12316016&postcount=88

reaperrr

2020-08-30, 14:41:25

Ich denke für Zen 4 sind 8C/CCX noch gut genug.
Da gehe ich auch von aus, bzw. nicht nur bei Zen 4. Der einzige Grund, um überhaupt Chiplets größer (bzgl. Kernzahl) zu machen, ist die Anzahl der IF-Links möglichst gering zu halten.
Bei Zen3 werden die ggü. Zen2 aber durch den monolithischen 8C CCX schon halbiert, also selbst wenn Zen4 bei 8C-Chiplets bleibt und stattdessen z.B. auf 12 Chiplets für Genoa erhöht, wären das immer noch nur 75% der IF-Links von Zen2.

Ich gehe davon aus, dass auch Zen5 noch bei 8C-Chiplets bleibt, zumal der vmtl. eh ein ähnliches Update wie Zen3 wird, also noch einen Prozess der 5nm-Klasse verwendet (N5P-HPCoder sowas) und dementsprechend wahrscheinlich auch bei 12 Chiplets bleibt (einfach aus Platzgründen).
Danach kommt dann wahrscheinlich noch Zen6 irgendwann in 2024, vermutlich in einer Art N3-P/-HPC/-e, der einfach nur kleinere 8C-Chiplets und davon dann halt 16 verbaut, dann wäre man eben wieder bei der gleichen Zahl IF-Links wie bei Rome.

Was man hier auch nicht vergessen darf: Bei SRAM fallen die Density-Steigerungen sowohl bei N5 als auch erst recht N3 ziemlich mies aus, AMD wird aber trotzdem sicherlich die Cache-Größen steigern, zusätzlich zu anderen IPC-Verbesserungen, die ebenfalls Fläche kosten.
Soll heißen, deutlich schrumpfen werden die Chiplets auch bei konstanter Kernzahl nicht mehr, und die Designkosten sowie Wafer-Kosten werden immer weiter steigen, so dass die Yield-Rate immer wichtiger wird und AMD deshalb wohl erst recht nicht mehr als 8C ins Chiplet stopfen wird, auch bei Zen5/6 nicht.

Berniyh

2020-08-30, 15:22:11

Es wäre auch denkbar, dass AMD irgendwann in Zukunft (evtl. ja schon mit Zen 4?) mehrere Chiplet-Designs auflegt. Also z.B. eins mit 8C für den Desktop und die meisten Server und dann noch eins mit z.B. 12C für die High-End Varianten.
8 Chiplets à 12C dürften für 96 Cores schlicht effizienter sein als 12 Chiplets à 8C.
Für viele Anwendungen sind 12C/Chiplet aber halt einfach Overkill (auch, wenn man teildeaktivierte Chiplets nutzt).
24C im High-End/Mainstream Desktop braucht einfach niemand wirklich und dafür gibt es ja auch noch die Threadripper.
Teilweise ist das ja sogar jetzt schon mit den 8C/Chiplet der Fall.

reaperrr

2020-08-30, 16:10:08

8 Chiplets à 12C dürften für 96 Cores schlicht effizienter sein als 12 Chiplets à 8C.
Warum?
Man spart ein paar IF-Links, aber die Komplexität des Chiplets geht massiv rauf, die Ausbeute an Chiplets die sowohl gut takten als auch voll funktionsfähig sind deutlich runter.

Vor allem sind 8 Kerne so ziemlich die Obergrenze dessen, was du effizient miteinander verdrahten kannst. Intel musste gerüchtehalber schon für die 10 Kerne von Comet Lake auf einen Dual-Ringbus hochgehen. Auch in Hinblick aufs Layout (Anordnung der Kerne) ist alles über 8C im Grunde Mist, wenn du nicht auf was Mesh-artiges wie Intel bei SKL-X & Co gehst, was aber auch nicht nur Vorteile hat (sonst hätte Intel das statt des Dual-Ringbus für CMTL genommen).

Aber nochmal: Die Vorteile, die ein kleines Chiplet mit 8C bei Ausbeute und Binning bietet, machen die Nachteile der etwas höheren IF-Link-Zahl und des etwas aufwändigeren Packagings meiner Einschätzung nach mehr als wett, und ein zweites Chiplet nur für Desktop-Enthusiasten zu entwickeln wäre ökonomisch kompletter Irrsinn, die Extrakosten holst du nie wieder rein, wenn der Effizienz-Vorteil unter Berücksichtigung von weniger aggressivem Binning am Ende vielleicht bei 5% liegt.

Cyberfries

2020-08-30, 16:40:31

Brillus

2020-08-30, 16:55:03

12 Chiplets mit jeweils einem 8-Kern CCX zu verbauen klingt nicht wirklich erstrebenswert in Bezug auf Komplexität des Gesamtpackages.
Aber warum nicht 6 Chiplets mit je 2x 8-Kern CCX?
Der Aufbau ist im Prinzip gleich in Bezug auf Vernetzung der Bestandteile untereinander, doch das Packaging wird simpler und die Chiplets nicht überbordend groß.

Sowas sehe ich bei 5nm oder 3nm einfach weil irgendwann die Chiplets sonst zu klein würden. Ab irgendeinem Punkt ist halt auch zu kleine, Stichwort Pins oder auch einfach verschnitt beim auseinander schneiden.

Berniyh

2020-08-30, 17:43:01

Warum?
Man spart ein paar IF-Links, aber die Komplexität des Chiplets geht massiv rauf, die Ausbeute an Chiplets die sowohl gut takten als auch voll funktionsfähig sind deutlich runter.
Das stimmt schon, aber auch die Komplexität der Anbindung (Stromversorgung, Anzahl IFs etc.) steigt mit der Anzahl an Chiplets.
Und auch die Komplexität des IO Die.

Letztendlich muss man da abwägen, wie es AMD ja bei Zen 2 auch schon macht.
Vor allem sind 8 Kerne so ziemlich die Obergrenze dessen, was du effizient miteinander verdrahten kannst.
Und wer sagt, dass das nicht bei den Chiplets ebenfalls so ist?
So wirklich genau wissen wir es halt nicht, da bislang außer AMD das noch niemand gemacht hat, aber ich bezweifle, dass wir wirklich viel mehr als 8 Chiplets auf einem Package sehen werden.
Durchaus möglich, dass es noch mehr werden, evtl. mal 10 oder 12, aber dann wird es schon ziemlich eng auf dem Package.

Aber nochmal: Die Vorteile, die ein kleines Chiplet mit 8C bei Ausbeute und Binning bietet, machen die Nachteile der etwas höheren IF-Link-Zahl und des etwas aufwändigeren Packagings meiner Einschätzung nach mehr als wett, und ein zweites Chiplet nur für Desktop-Enthusiasten zu entwickeln wäre ökonomisch kompletter Irrsinn, die Extrakosten holst du nie wieder rein, wenn der Effizienz-Vorteil unter Berücksichtigung von weniger aggressivem Binning am Ende vielleicht bei 5% liegt.
Man würde doch never ever ein zweites Chiplet für Desktop entwickeln.
Wenn, dann hauptsächlich für EPYC. Wo anders kannst du 100 oder mehr Kerne auch gar nicht vernünftig auslasten. Selbst dort ist es schon eine Herausforderung.

Und Binning wäre gar nicht so das riesige Problem. Die Chiplets wären wohl auch mit 10C oder 12C noch so winzig, dass die Ausbeute brutal gut wäre.
Zumal Zen 4 ja auf N5 kommt, was -45% Flächenbedarf gegenüber N7 hat.
Damit hätte man eine mutmaßliche Vergrößerung von 8C auf 12C (sagen wir mal 50-60% mehr Fläche) schon größtenteils wieder wett gemacht und die 12C Chiplets wären kaum größer als die jetzigen 8C Chiplets in N7.

Ob es sich dann am Ende wirklich lohnt (und ob es überhaupt mehr als 64C/CPU geben wird) kann aber nur AMD selbst beantworten.

1Aber warum nicht 6 Chiplets mit je 2x 8-Kern CCX?
Die Chiplets sind ja hauptsächlich für Server und da kann ich mir einfach nicht vorstellen, dass man wirklich wieder eine zusätzliche NUMA Ebene einführen wird, nachdem man zuletzt (laut eigenen Aussagen) daran gearbeitet hat eben jene soweit wie möglich zu entfernen.

Nightspider

2020-08-30, 18:27:57

Zumal 5nm laut TSMC sogar bessere Yields haben soll als 7nm.

B@ndit

2020-08-31, 13:37:17

Und wer sagt, dass das nicht bei den Chiplets ebenfalls so ist?

Aktuell haben wir bei Zen2 zwar 8 Chiplets, jedoch mit jeweils zwei CCX, die getrennt per IF an den IO-Die anschlossen sind, es gibt also schon 16 Verbindungen. Bei Zen3 sollte das mit den 8-Core-CCX auf 8 Verbindungen sinken, wahrscheinlich werden die jedoch irgendwie verbessert um mehr Bandbreite zu liefern. Aber für Zen4 sollten 12 IF-Links nicht das Problem sein. Wie YfOrU richtig angemerkt hat, ist das nicht korrekt und es gibt nur eine Verbindung pro Chiplet (also 8). Daher kein Argument für mehr als 8 Chiplets, schließt es aber auch nicht aus.

Man würde doch never ever ein zweites Chiplet für Desktop entwickeln.
Wenn, dann hauptsächlich für EPYC. Wo anders kannst du 100 oder mehr Kerne auch gar nicht vernünftig auslasten. Selbst dort ist es schon eine Herausforderung.

An zwei verschiedene Chiplets (außer eventuell irgendeine Art von Beschleunigern, sei es CDNA oder etwas spezielles für AI/ML) glaube ich auch nicht. Eher könnte ich mir vorstellen, dass man zwei verschiedene monolithische APUs für den Desktop nutzt. Zum Beispiel einen 8-Core-Chip mit relativ starker iGPU hauptsächlich für die Mobile U-Serie und Mainstream-Desktop und daneben einen 16-Core Chip (mit kleiner iGPU) für die Mobile H-Serie und Desktop im Gaming Bereich. Threadripper könnte darüber weiter mit den Chiplets versorgt werden.

Die Chiplets sind ja hauptsächlich für Server und da kann ich mir einfach nicht vorstellen, dass man wirklich wieder eine zusätzliche NUMA Ebene einführen wird, nachdem man zuletzt (laut eigenen Aussagen) daran gearbeitet hat eben jene soweit wie möglich zu entfernen.

Zwei 8-Core-CCX auf einem Chiplet wäre ja keine weitere NUMA-Ebene. Solange jedes CCX einzeln an den IOD angebunden ist macht das logisch keinen Unterschied. Letztendlich ist das nur ein Rechnung, deren Parameter wir nicht kennen, die AMD aber sicher so löst, wie es am sinnvollsten ist. Genauso könnte man Fragen, warum aktuell nicht 16 Chiplets mit jeweils 4 Kernen genutzt werden. Das würde bei ungefähr gleichem Verdrahtungsaufwand (zumindest für den IF) die Ausbeute noch ein bisschen erhöhen. Anscheined wäre der Ausbeutegewinn das etwas aufwendigere Packaging nicht wert. Der gleiche Fall könnte eventuell auch wieder bei 5nm eintreten.

Ich denke man kann das Ganze schlecht abschätzen ohne die Details zu kennen, aber für >64-Cores gibt es viele Lösungen: Sei es 10 oder 12 8-Core Chiplets, 8 mal 12-Core oder auch 6 oder 8 mal 16-Core mit zwei CCX pro Chiplet.

basix

2020-08-31, 20:55:11

An 16C pro Chiplet glaube ich nicht in 5nm. Die Kerne werden grösser, der L2 auch. Das Chiplet wäre vermutlich knapp 100mm2. Das ginge schon, nur ist 5nm nochmals teurer als 7nm.

Mehr als 12C kommen mMn nur, wenn man den L3$ stacked. Und irgendwie habe ich das Bauchgefühl, das man stacked bei Zen 4 nicht bringen wird.

YfOrU

2020-09-01, 08:28:18

Aktuell haben wir bei Zen2 zwar 8 Chiplets, jedoch mit jeweils zwei CCX die getrennt per IF an den IO-Die anschlossen sind, es gibt also schon 16 Verbindungen. Bei Zen3 sollte das mit den 8-Core-CCX auf 8 Verbindungen sinken, wahrscheinlich werden die jedoch irgendwie verbessert um mehr Bandbreite zu liefern. Aber für Zen4 sollten 12 IF-Links nicht das Problem sein.

Um mal auf AMDs Dokumentation zu verweisen da man es öfter liest:
The two CCXs of a CCD share a single GMI2 Fabric port to the IOD.

Seite 27: https://developer.amd.com/wp-content/resources/55803_0.54-PUB.pdf

Also wie auch in AMDs Illustrationen zu Rome und Matisse ein GMI2 Port pro CCD. Die Zen2 IODs sollten damit ohne jegliche Änderungen auch mit Zen3 funktionieren und genug Bandbreite pro CCD liefern können.

Neue IODs für Zen3 halte ich auch nicht für realistisch. Es gibt keine Änderungen an den zugehörigen Plattformen wie AM4/SP3. Die Ressourcen sind an anderen Stellen besser aufgehoben. Vor allen wenn man bedenkt das AMD bisher meistens eine Refresh Generation eingeschoben hat. Jedes Jahr neue CCDs und IODs wäre da schon extrem viel. Läuft halt auch dem Ansatz entgegen denn einer der Vorteile der Chiplets ist ja gerade das nicht alle Bestandteile pro Generation "neu entwickelt" werden müssen. Bei Cezanne dürfte es ähnlich sein. Bei Renoir hat AMD schon sehr viele Steine umgedreht. Mit FP6 auf der gleichen Plattform und damit sind abseits von Zen3 kaum Änderungen zu erwarten. Wobei eben auch das gegenüber dem bisher üblichen Refresh schon ein großer Schritt ist.

Bezüglich GMI dürfte die Anzahl der Links auch in Zukunft bei einem pro CCD bleiben. Wenn nötig erhöht AMD weiter die Bandbreite. Neue IODs beim Wechsel der Plattform auf DDR5 etc. Wobei ich mir bei 5nm nicht so sicher bin ob AMD nicht evtl. Enterprise abtrennt und auch den Desktop komplett mit APUs bedient. Auf Dauer sind zwei APUs pro Generation in Relation zu Intel zu wenig.

LasterCluster

2020-09-01, 10:50:03

Also wie auch in AMDs Illustrationen zu Rome und Matisse ein GMI2 Port pro CCD. Die Zen2 IODs sollten damit ohne jegliche Änderungen auch mit Zen3 funktionieren und genug Bandbreite pro CCD liefern können.

Das ist sehr interessant und vielleicht nochmals ne Erwähnung im Zen3 Thread wert. Wurde die Bandbreite bei eigentlich Zen2 fest zwischen den CCXs aufgeteilt?

Auf Dauer sind zwei APUs pro Generation in Relation zu Intel zu wenig.
Zwei? Bisher sind es wohl eher so 1,5. Falls die Chiplet-APUs wirklich kommen wie es die geleakte Folie nahegelegt hat, könnte es in Zukunft 3 APU-Klassen geben:
-FPx wie bisher
-FFx mit Van Gogh zum Anfang. Auf der genannten Folie war auch erkennbar, dass es ca 1 Jahr später einen Nachfolger gibt.
-evtl.: Chiplet-basiert.

Falls die FFx Schiene mobile only bleibt wie bei Van Gogh und Nachfolger, könnte es vlt weitere Dali-artige APUs aus der FPx Schiene geben.

YfOrU

2020-09-01, 11:26:48

Das ist sehr interessant und vielleicht nochmals ne Erwähnung im Zen3 Thread wert. Wurde die Bandbreite bei Zen2 fest zwischen den CCXs aufgeteilt?

Da jedes CCX den DC IMC im IOD auslasten kann (Read) eher nicht. Siehe:
Ryzen 3 3100 und 3300X mit 2+2 zu 4+0
https://www.computerbase.de/2020-05/amd-ryzen-3-3100-3300x-test/#abschnitt_ein_achtkernprozessor_halbiert__auf_zwei_arten

Hintergrund: CCD zu IOD, 32B/cycle Read und 16B/cycle Write

2020-09-01, 12:50:37

Es wäre wirklich nett wenn AMD AVX512 bringt, das kann ja auf den alten AVX2 Einheiten laufen, so wie Zen1 AVX2 nur in halben Taktzahl konnte. Dann würde es mehr Software dafür geben. AVX512 bietet ja nicht nur eine Verdopplung, die besten Features sind Gather/Scatter/Masking. Damit lässt es sich sehr viel einfacher und effizienter vektorizierten Code schreiben, gerade beim Portieren.
64Core mit AVX512 :usex:

B@ndit

2020-09-01, 12:51:17

Also wie auch in AMDs Illustrationen zu Rome und Matisse ein GMI2 Port pro CCD.

Danke für den Hinweis, das war mir in der Tat nicht klar. Da es keine logische Verbindung zwischen den CCX gibt, war ich davon ausgegangen es gäbe auch physikalisch zwei getrennte Verbindungen zum IOD.

Damit ist zumindest die Argumentation, dass es aktuell schon 16 GMI-Links gäbe quatsch und wie du richtig anmerkst, könnte damit das aktuelle IO-Die für Zen3 weiterverwendet werden.

Piefkee

2020-09-01, 13:10:07

2020-09-01, 13:18:02

Bitte AMD implementiert den dreck von AV512 nicht... kostet nur DIE Space und bringt nichts
Deinem Kraftausdruck entnehme ich, dass du eigentlich garnicht an einer Diskusion interessiert bist und nur Stunk machen willst, oder?

Piefkee

2020-09-01, 13:39:23

Deinem Kraftausdruck entnehme ich, dass du eigentlich garnicht an einer Diskusion interessiert bist und nur Stunk machen willst, oder?

Habe das smiley vergessen.
Gerne sachlich. Troughput sollte wie bisher durch high-Core count realisiert werden (AMD). Troughput durch separate Vector Einheiten (AVX512) zu realisierten ist supoptimal, weil es DIE Space im Core benötigt. Skylake AVX512 benötigt ca. 10% im Core. Wird aber bei 97,9% der Anwendungen nicht verwendet und ist unnütz.

RLZ

2020-09-01, 13:52:01

Wird aber bei 97,9% der Anwendungen nicht verwendet und ist unnütz.
Die selbe Diskussion gibt es jeder Art von Hardware bei einer Featureset Erweiterung. Das ist exakt das gleiche bei Raytracing oder AI Beschleunigern. Hören wir auf einen der Chipfläche für neue non-Mainstream Featuresets zu opfern, erreichen wir direkt einen Stillstand. Niemand bringt ein neues Hardware Feature mit neuer API raus, das in der ersten Generation breite Anwendung findet. Das ist ein Henne-Ei Problem, was nur aufgelöst werden kann, wenn die Hardware den ersten Schritt macht.

aufkrawall

2020-09-01, 13:57:48

Die selbe Diskussion gibt es jeder Art von Hardware bei einer Featureset Erweiterung.
Kann mich nicht an eine entsprechende Äußerung Torvalds (oder eines anderen, ähnlich wichtigen Akteurs) bez. AVX2 erinnern.

Der_Korken

2020-09-01, 14:06:39

Bei AVX512 hat Intel auch zusätzlich noch Chaos gestiftet, weil es so viele Subsets von Instruktionen gibt, die nicht von allen Chips unterstützt wird. Irgendwer hat das mal im Zen 3 Thread gepostet, aber google war schneller:

https://twitter.com/InstLatX64/status/969560033922035713/photo/1

Das war für den Support sicher nicht förderlich. Ich denke, AMD wird nicht auf Fullspeed-AVX512 gehen, sondern höchstens Halfspeed. Aber selbst das kostet Transistoren für Register und die komplexere Dekodierung, das werden die sich gut überlegen.

Berniyh

2020-09-01, 14:08:12

könnte damit das aktuelle IO-Die für Zen3 weiterverwendet werden.
Schon, wobei man ja auch immer wieder durchblicken lässt, dass man die IF ständig weiter entwickelt und es ist schon zu erwarten, dass der IO Die für Zen3 zumindest leicht angepasst ist.
Quasi neuere Revisionen, evtl. auch mit besserem Energiemanagement (daran hapert es ja bei Zen 2 in manchen Situationen).
Größere Änderungen wären aber in der Tat eher nicht zu erwarten.

Dass man den IO Die wirklich exakt gleich lässt kann ich mir hingegen nicht so richtig vorstellen.
Klar, man kann das jetzt separat entwickeln, aber warum sollte man Verbesserungen nicht einfließen lassen?

2020-09-01, 14:40:02

Troughput durch separate Vector Einheiten (AVX512) zu realisierten ist supoptimal, weil es DIE Space im Core benötigt. Skylake AVX512 benötigt ca. 10% im Core. Wird aber bei 97,9% der Anwendungen nicht verwendet und ist unnütz.
Deswegen sprach ich auch von derselben Lösung wie bei Zen1. AVX lief 2x auf den den FP4 einheiten. Die ISA rein zu bekommen sollte doch nicht so teuer sein wie Intels Lösung. Soweit ich weiss hat Intel für AVX512 nicht nur die Einheiten aufgestockt, sondern musste Cache Bandbreite verdoppeln und wegen FMA3 die Cache-Read Bandbreite nochmal, nur ISA und Register sind da wohl das kleinste (nehme ich an :redface: )

Wenn AMD AVX512 Sparsam hinbekommen würde, sodass wir erstmal _etwas_ mehr Performance bekommen (wegen mehr Registern), wäre das doch eine billiger Weg das Henne/Ei Problem von "Wird aber bei 97,9% der Anwendungen nicht verwendet" zu lösen.
Denn AVX2 hat sich ja scheinbar gelohnt, und das hat irgendwann auch 98% nicht verwendet. (Und ich mag AVX2 immer noch nicht sonderlich sehr, wegen dem 2x4 Lane-Split, das ist weniger ein Problem bei AVX512.)

Ja, ich will auch lieber mehr Cores. Aber AVX512 hat eine soooviel nettere ISA, das würde ich selbst mit 4x auf FP4 Einheiten nehmen.

basix

2020-09-01, 15:09:52

Dass man den IO Die wirklich exakt gleich lässt kann ich mir hingegen nicht so richtig vorstellen.
Klar, man kann das jetzt separat entwickeln, aber warum sollte man Verbesserungen nicht einfließen lassen?

Ich bin davon überzeugt, das Zen 3 ein neues/überarbeitetes IOD bekommen wird. Im einfachsten Fall ein Microcode Update, siehe spätere Bulldozer Derivate (gleiches Die, neue Features enabled).

Aber ein neues Die wäre auch möglich. Nur schon die IF Verbesserungen bei Renoir sind sehr hilfreich, was Stromverbrauch anbelangt. Und IOD + CCD sind gerade mal 200mm2 Chipfläche, welche zu designen sind. Das EPYC IOD ist dann 4x Desktop IOD. Gesamthaft knapp 600-650mm2 für das ganze Desktop und Server Lineup. Und beim IOD kann man wohl viel wiederverwerten, was es auch einfacher macht (z.B. DDR4 Memory Controller und PHY). Das sollte AMD schon stemmen können.

RLZ

2020-09-01, 16:12:10

Kann mich nicht an eine entsprechende Äußerung Torvalds (oder eines anderen, ähnlich wichtigen Akteurs) bez. AVX2 erinnern.
Für mich is Torvald kein relevanter Akteur für Anwendungen, die von AVX-512 profitieren können. Wobei ich auch lieber etwas wie Tensorcores in den CPUs sehen würde. Das wäre viel relevanter als die nächste Generation an Krüppel GPU.

2020-09-01, 17:32:47

Wobei ich auch lieber etwas wie Tensorcores in den CPUs sehen würde.Bei Intel heisst das VNNI.

Zossel

2020-09-01, 17:40:46

Für mich is Torvald kein relevanter Akteur für Anwendungen, die von AVX-512 profitieren können. Wobei ich auch lieber etwas wie Tensorcores in den CPUs sehen würde. Das wäre viel relevanter als die nächste Generation an Krüppel GPU.

Es geht da wahrscheinlich um die Quirks die der Kernel benötigt damit AVX512 Anwendungen nicht die Gesamtperformance des Systems runter ziehen.

Für die bekannten Taktprobleme versucht der Linuxkernel Prozesse die AVX512 nutzen nur auf Cores zu schedulen die bereits AVX512 genutzt haben. Kontextswitches auf Cores mit AVX512 State dürften auch langsamer sein als ohne.

Linus Torvalds ist sicherlich kein intensiver Nutzer von AVX512 Anwendungen, die Bürde so was performant laufen zu lassen hat er allerdings schon.

Berniyh

2020-09-01, 18:17:21

Es geht da wahrscheinlich um die Quirks die der Kernel benötigt damit AVX512 Anwendungen nicht die Gesamtperformance des Systems runter ziehen.
Nein, es ging ihm definitiv um die Transistoren, die dafür "verschwendet" werden.

RLZ

2020-09-01, 22:48:33

Es geht da wahrscheinlich um die Quirks die der Kernel benötigt damit AVX512 Anwendungen nicht die Gesamtperformance des Systems runter ziehen.
Selbst wenn es so wäre (was nicht seiner Aussage entspricht) soll er seine Klappe und seinen Job machen. Es ist nicht die Aufgabe von einem Kernelteam über solche ISA Erweiterungen zu urteilen.

Berniyh

2020-09-01, 23:25:02

Zossel

2020-09-02, 08:44:22

Selbst wenn es so wäre (was nicht seiner Aussage entspricht) soll er seine Klappe und seinen Job machen. Es ist nicht die Aufgabe von einem Kernelteam über solche ISA Erweiterungen zu urteilen.

and that Intel starts fixing real problems instead of trying to create magic instructions to then create benchmarks that they can look good on.

Fixt du das nächste Intel Problem im Kernel?

eccle

2020-09-25, 00:07:32

basix

2020-09-25, 09:28:28

Sieht gut aus :up:

Bei Raphael könnte man allenfalls noch DDR5 einfügen.

LasterCluster

2020-09-25, 09:48:23

Nach neuesten Infos ist Lucienne ein reiner Renoirrefresh, der zusammen mit Cezanne in der 5000er Reihe auftaucht. Kann man nicht mit Dali vergleichen, sondern eher mit Picasso.

Leonidas

2020-09-30, 09:50:05

Exzellente Arbeit @ eccle :up:

Hammer des Thor

2020-10-04, 01:18:39

Ich habe die Informationen von MebiuW in einem Schaubild zusammengefasst. Unter Cezanne bzw. Renoir habe ich Lucienne bzw. Dali eingefügt.

https://i.ibb.co/MDQsFNS/roadmap-amd.png (https://ibb.co/0jvcHJ2)

Warum Warhol noch mal in 7nm? 6nm wäre doch viel logischer, ein Zen 3 mit etwas höreemm Takt oder niedrigem Stromverbrauch am besten beides. Zen 1 auf Zen+ war auch von 14 nm auf 12 nm!

LasterCluster

2020-10-04, 09:30:50

Warum Warhol noch mal in 7nm? 6nm wäre doch viel logischer, ein Zen 3 mit etwas hörem Takt oder niedrigem Stromverbrauch am besten beides. Zen 1 auf Zen+ war auch von 14 nm auf 12 nm!

Das ist das, was die Leaks sagen. Daraus kann man schließen, dass Warhol nur ein absolutes Minimalupdate zu Vermeer sein wird. Wahrscheinlich wie Lucienne zu Renoir. Darüber hinaus sind die Effizienzgewinne von 6nm für Desktop nicht so wichtig wie für die APUs. Folgendes hört sich nicht an, als wären große Geschwindigkeitsupdates zu erwarten:

N6 is said to provide around 15-20% higher density with improved power consumption compared to N7, albeit no iso-power or speed comparisons where provided.

Quelle: https://fuse.wikichip.org/news/3227/tsmc-q4-7nm-dominates-revenue-preps-5nm-ramp-6nm-by-eoy/

dargo

2020-10-10, 17:25:46

Ich habe die Informationen von MebiuW in einem Schaubild zusammengefasst. Unter Cezanne bzw. Renoir habe ich Lucienne bzw. Dali eingefügt.

https://i.ibb.co/MDQsFNS/roadmap-amd.png (https://ibb.co/0jvcHJ2)

Ui... Zen 4 doch erst 2023?

Edit:
Ah... die Linie soll wohl den Anfang vom Jahr markieren oder wie darf ich das verstehen? Also Zen 4 Mitte 2022?

ianm

2020-10-10, 18:20:41

Laut Zen 3 Roadmap auf jeden Fall vor Ende 2022.

eccle

2020-10-10, 18:49:41

Warum Warhol noch mal in 7nm? 6nm wäre doch viel logischer, ein Zen 3 mit etwas höreemm Takt oder niedrigem Stromverbrauch am besten beides. Zen 1 auf Zen+ war auch von 14 nm auf 12 nm!

Nach dem Erscheinen von Vermeer in N7 wäre ein Warhol in N7P nicht unwahrscheinlich. AMD hatte die Verwendung von N7P angekündigt. Das würde auch erklären, warum man Server mit dieser Generation wieder übergeht.

Berniyh

2020-10-11, 09:39:05

Nach dem Erscheinen von Vermeer in N7 wäre ein Warhol in N7P nicht unwahrscheinlich.
Woher willst du wissen, dass Vermeer in N7 und nicht in N7P produziert wird?
Oder eigentlich wohl sogar eher N7e.

eccle

2020-10-11, 12:25:20

Woher willst du wissen, dass Vermeer in N7 und nicht in N7P produziert wird?
Das hat AMD der Presse gesagt. Pressevertreter haben es in Artikeln zur Vorstellung von Zen3 niedergeschrieben. Hättest du vor der Frage mal recherchieren können.

Oder eigentlich wohl sogar eher N7e

TSMC bietet kein N7e an. N7e ist ein Marketingvehikel um N7 schöner klingen zu lassen.

Berniyh

2020-10-11, 12:46:57

Das hat AMD der Presse gesagt. Pressevertreter haben es in Artikeln zur Vorstellung von Zen3 niedergeschrieben. Hättest du vor der Frage mal recherchieren können.
AMD behandelt doch alles was von N7 abgeleitet wurde mittlerweile als "gleich", da würde ich nichts darauf geben, in dem Sinne dass Zen 3 wirklich unter exakt den gleichen Bedingungen wie Zen 2 prozessiert wird.
TSMC bietet kein N7e an. N7e ist ein Marketingvehikel um N7 schöner klingen zu lassen.
Die Xbox wird aber unbestreitbar unter einem mutmaßlich für AMD weiterentwickelten N7 Prozess namens N7e gefertigt.
Also warum sollte das bei Zen 3 nicht zum Einsatz kommen?

Mindestens die Verbesserungen von N7P gegenüber N7 würde man aber auf jeden Fall mitnehmen. Es gibt einfach keinen Grund das nicht zu tun.

Nur nach außen hin wird man das nicht als "neuen Prozess" kommunizieren, generell hat sich AMD eigentlich nie so wirklich zu spezifischen Prozessen geäußert, sondern nur die grobe Rahmenbedingung angegeben (also z.B. "7nm", dann aber auch mehr als Marketingvehikel).

amdfanuwe

2020-10-11, 12:52:31

Was solls, von den Taktraten her hat sich nicht viel getan. Müssen wir jetzt mal Performance/Watt Ergebnisse abwarten um zu sehen, ob der verwendete Prozess Vorteile bietet.

LasterCluster

2020-10-11, 13:28:03

Laut Zen 3 Roadmap auf jeden Fall vor Ende 2022.

Das wurde offiziell als Produkt für Genoa (Server Zen4) bestätigt. Bei Ryzen gibt es offiziell interssanterweise KEINE Ankündigung was/wann nach Ryzen5000/Vermeer passiert.
Die geleakte, durch MebiuW "bestätigte" Roadmap, sagt Warhol als Zen3 Refresh ca 1J nach Vermmer und Raphael als Zen4 Desktop nochmals n Jahr später.

Viedeocardz hats gut zusammengefasst:
https://videocardz.com/newz/amd-ryzen-2021-2022-roadmap-partially-leaks

Wahrscheinlich läufts dann auf folgendes heraus
DT:
Warhol (Zen3): Q4 21
Raphael (Zen4): Q4 22
Server:
Genoa (Zen4): Q3/Q4 22

eccle

2020-10-11, 13:32:07

AMD behandelt doch alles was von N7 abgeleitet wurde mittlerweile als "gleich"
Das stimmt nicht.

Die Xbox wird aber unbestreitbar unter einem mutmaßlich für AMD weiterentwickelten N7 Prozess namens N7e gefertigt.
Ja sie nennen es so, weil es schöner klingt, sagte ich gerade. Lisa kann weiterhelfen:

(https://www.anandtech.com/show/15344/amd-at-ces-2020-qa-with-dr-lisa-su):

It’s fair to say that all the variants of TSMC’s 7nm share a lot of technology between them, whether that’s N7, N7P, or N7+. The main thing is that we forecast well and plan for success.

Berniyh

2020-10-11, 14:40:52

Das stimmt nicht.
Ach ja? Bist du dir da wirklich 100% sicher, dass wirklich der komplette Gain von Zen 3 ausschließlich durch die Änderungen in der Architektur und nicht teilweise auch durch Prozessoptimierungen kommen?
Nur, wegen dem was in der Präsentation gesagt wurde?
Das war eine Aussage aus Sicht des Marketings um das präsentierte Produkt besser dastehen zu lassen, was aber nicht bedeutet, dass nicht hinter den Kulissen nicht doch signifikante Verbesserungen am Prozess vorgenommen wurden.
Ja sie nennen es so, weil es schöner klingt, sagte ich gerade. Lisa kann weiterhelfen:

(https://www.anandtech.com/show/15344/amd-at-ces-2020-qa-with-dr-lisa-su):

It’s fair to say that all the variants of TSMC’s 7nm share a lot of technology between them, whether that’s N7, N7P, or N7+. The main thing is that we forecast well and plan for success.
Ja, sonst würde man es vermutlich nicht mehr N7* nennen, sondern irgendwie anders. Natürlich gibt es da eine gewisse Verwandtschaft.

Dennoch ist es irgendwo schon naiv zu glauben, dass AMD solche low-hanging fruits nicht mitnehmen würde …

Knuddelbearli

2020-10-14, 10:06:46

Weiss man eigentlich wie es bei GloFo weiter geht? besteht ne Chance das wir bei Zen3+ bzw Zen4 ein IO Chiplet mit kleiner 12nm von GloFo sehen?

HOT

2020-10-14, 10:31:43

Das wurde offiziell als Produkt für Genoa (Server Zen4) bestätigt. Bei Ryzen gibt es offiziell interssanterweise KEINE Ankündigung was/wann nach Ryzen5000/Vermeer passiert.
Die geleakte, durch MebiuW "bestätigte" Roadmap, sagt Warhol als Zen3 Refresh ca 1J nach Vermmer und Raphael als Zen4 Desktop nochmals n Jahr später.

Viedeocardz hats gut zusammengefasst:
https://videocardz.com/newz/amd-ryzen-2021-2022-roadmap-partially-leaks

Wahrscheinlich läufts dann auf folgendes heraus
DT:
Warhol (Zen3): Q4 21
Raphael (Zen4): Q4 22
Server:
Genoa (Zen4): Q3/Q4 22

Das Warhol nur ein Minimalrefresh zu sein scheint (gleiches Zen3-Die, gleiches IOD für AM4), würd ich Zen4 weiterhin Q2-3 2022 sehen.

basix

2020-10-14, 10:40:58

Weiss man eigentlich wie es bei GloFo weiter geht? besteht ne Chance das wir bei Zen3+ bzw Zen4 ein IO Chiplet mit kleiner 12nm von GloFo sehen?

"Kleiner" als 12nm nur indirekt: 12LP+ (Link (https://www.globalfoundries.com/news-events/press-releases/globalfoundries-introduces-12lp-finfet-solution-cloud-and-edge-ai-0)). Vermutlich erst mit Zen 4 und DDR5/PCIe 5.0.

Der IOD soll vor allem günstig und stromsparend sein. Da ist 12LP+ eigentlich perfekt. Alles ab 10nm und darunter ist einfach viel teuerer und I/O skaliert schlecht (Kostenvorteile verpuffen). Ausserdem ist 12LP+ auch auf 2.5D Packaging und HBM ausgelegt, passt also auch (Link (https://www.eejournal.com/industry_news/globalfoundries-and-sifive-to-deliver-next-level-of-high-bandwidth-memory-on-12lp-platform-for-ai-applications/)).

w0mbat

2020-11-06, 16:24:28

Wenn Zen4 nochmal ähnlich bei der IPC drauflegt wie es Zen2 und Zen3 getan haben, sind wir bei Skylake +150%. Ich kann mich noch erinner wie häufig geschrieben wurde, dass mehr IPC einfach nicht wirklich möglich ist :D

Die Frage ist, geht AMD mit Zen4 auf mehr Kerne, oder mehr IPC und Takt? Oder alles zusammen?

16C/32T sollten auch in ein paar Jahren noch mehr als ausreichend sein, wenn es um gaming geht. Da wäre mir ein 5nm Zen4 mit +20% IPC und 5,5GHz all-core lieber. DDR5 wird auch reinhauen, am besten gleich DDR5-6400 mit scharfen timings!

Der_Korken

2020-11-06, 16:54:35

Hab dazu im Review-Thread von Zen 3 schon was geschrieben:

[...]

Was heißt das für Zen 3? Die CPU fühlt sich eher wie eine Intel-CPU als wie eine Zen-2-CPU an. Zen 2 hatte viele exklusive Ressourcen und war so sparsam, dass es immer taktlimitiert durch die µArch war. Die ultimativen Arbeitstiere, die super mit Mehrkenrlast skalieren, sofern diese unabhängig voneinander laufen kann. Intel war dagegen eher weniger "auf Durchsatz optimiert", sondern eher auf gute Latenzen und gute ST-Leistung, dadurch dass z.B. ein Kern immer den gesamten L3 nutzen konnte und die Taktdecke so hoch war, dass man durch mehr reingesteckte Energie auch fast immer mehr Performance bekommen hat. Zen 3 ist irgendwie sowas in der Mitte. Natürlich in MT nicht langsamer als Zen 2 und scheint auch nach wie vor nicht irgendwelche komischen Effekte bei AVX zu schieben (d.h. der Takt implodiert nicht so wie bei Intel), aber bei Teillast wesentlich performanter (und auch durstiger).

Was könnte das für Zen 4 bedeuten? Ich schrieb ja schon, dass ich bei Zen 4 mehr Fokus auf die "Zen 2 Tugenden" erwarte, d.h. mehr Kerne, weniger Verbrauch, mehr pure Rechenleistung pro Kern (mehr FPUs bzw. AVX512, SMT4, 1MB L2, etc.). Für Gamer ist Zen 3 imho die goldene Generation.

Es gilt wie immer das Gesetz des abnehmenden Ertrags. Wenn die IPC stark erhöht wurde, wird es schwieriger sie noch weiter zu erhöhen, weil man all die einfachen Sachen schon gemacht hat und von denen nicht noch ein zweites Mal profitieren kann. Daher würde ich vermuten, dass Zen 4 nicht nochmal so krass nachlegen wird bei ST-/Teillast. Da der Sprung für Anwendungen eher gering ausfiel im Vergleich zu Zen 2, denke ich dass AMD sich bei der nächsten Generation wieder stärker auf genau diese konzentrieren wird. Der 5nm-Prozess kommt gerade recht, denn er senkt den Verbrauch pro Kern, d.h. wir werden sehr wahrscheinlich ein Kern-Upgrade sehen. Im Desktop vielleicht nicht, weil man hier mit 16/32C noch ne ganze Weile auskommen wird, aber bei TR und Epyc sicherlich schon.

Taktsprünge durch den neuen Prozess würde ich nicht erwarten. Die kamen bei 7nm eher daher, dass man zusätzlich von GloFo zu TSMC gewechselt ist. Und selbst damit hat Zen 2 letztlich nicht viel höher getaktet als Zen 1, außer auf dem Papier mit dem ST-Boost. Es wird außerdem gemunkelt, dass es einen Zen 3 Refresh für den Desktop geben soll, was imho darauf hindeutet, dass Zen 4 dort eher uninteressant ist, sondern eher für Server interessant wird.

Was die IPC-Sprünge angeht, muss ich zugeben, dass ich tatsächlich nicht mehr an solche Fortschritte geglaubt habe. Solche Sprünge wie Conroe und Nehalem wird man wohl wirklich nie wieder sehen, aber nachdem die Entwicklung durch Intel zwischenzeitlich quasi eingeschlafen ist, dachte ich, dass man dort einfach mit vertretbarem Aufwand keine nennenswerten Fortschritte mehr erzielen kann. In der Theorie ist es ja auch schwer, denn selbst mit einer 100%igen Branch Prediction, gibt es im Code Datenabhängigkeiten, die sich prinzipbedingt nicht auflösen lassen und somit eine obere Schranke dafür bilden, wieviele Befehle pro Takt überhaupt ausgeführt werden können. Anscheinend hat(te) man die aber noch nicht erreicht.

Zossel

2020-11-06, 18:13:59

DDR5 wird auch reinhauen, am besten gleich DDR5-6400 mit scharfen timings!

Eigentlich hat sich bei den DRAM Latenzen wenig in den letzten Jahrzehnten getan.

w0mbat

2020-11-06, 18:17:26

Nicht nur eigentlich. Aber die Bandbreite steigt enorm mit DDR5.

Zossel

2020-11-06, 18:38:19

Nicht nur eigentlich. Aber die Bandbreite steigt enorm mit DDR5.

Bei "scharfen Timings" von DRAM geht es doch um die Latenzen?

Rooter

2020-11-06, 18:42:28

Die Frage ist, geht AMD mit Zen4 auf mehr Kerne, oder mehr IPC und Takt? Oder alles zusammen?Ich denke auch, IPC war jetzt mit Zen3 dran. Mit der (vermutlich) kleineren Fertigung werden sie auf mehr Kerne und vor allem mehr Takt gehen.

MfG
Rooter

w0mbat

2020-11-06, 18:58:53

Bei "scharfen Timings" von DRAM geht es doch um die Latenzen?
Klar, du willst doch auch immer die besten Latenzen, oder nicht? Ich verstehe deine Frage nicht so ganz :D

Ich hab von DDR5-6400 mit scharfen timings gesprochen, das ist doch genau, wa jeder will. Ich hab nicht davon gesprochen, dass die Latenzen besser werden als mit DDR4.

Der_Korken

2020-11-06, 19:49:02

Die Speicherbandbreite war zumindest bis Zen 2 kein Flaschenhals, denn die Threadripper waren jeweils genauso schnell bis knapp langsamer als ihre gleich getakteten Ryzen-Geschwister. Das kann bei Zen 3 nun natürlich anders sein, aber Wunder würde ich trotzdem keine erwarten.

w0mbat

2020-11-06, 19:55:04

Es ist wichtig für viele Kerne und für APUs.

Zossel

2020-11-06, 20:45:38

Klar, du willst doch auch immer die besten Latenzen, oder nicht? Ich verstehe deine Frage nicht so ganz :D

Nein, nicht um jeden Preis, ich finde Overclocking überflüssig weil ich einen Computer brauche der in allen Lebenslagen möglichst zuverlässig funktioniert, und silent corruption ist das letzte was ich brauchen kann.

Einmal in meinen Leben hatte ich mir so merkwürdiges Kinder/Gamer RAM gekauft: Niemals wieder!

w0mbat

2020-11-06, 20:48:31

Was ist denn "Kinder/Gamer RAM"? Ich will maximale Leistung, also ist RAM OC/Optimierung für mich wichtig.

Zossel

2020-11-07, 10:02:58

Was ist denn "Kinder/Gamer RAM"? Ich will maximale Leistung, also ist RAM OC/Optimierung für mich wichtig.

Im Falle eines Fehlers sinkt die Leistung schlagartig auf 0. Eigentlich wird die Leistung sogar negativ weil man (viel) Zeit verschwendet den Fehler zu finden und falsche Daten zu korrigieren.

Für Kinder und Gamer Aufgaben reichen auch Kinder und Gamer Komponente.

Zergra

2020-11-07, 10:09:03

Bandbreite ist doch gar nicht mehr so wichtig ? Mit den großen Boards und QC hatte man ja zum Teil Nachteile durch die Latenzen im Vergleich zu DC (beim Gaming) Am Ende dürfte DDR5 eine Zeit lang langsamer sein als der schnellste DDR4.

HOT

2020-11-07, 13:21:37

Das neue IOD wird einen Impact haben bei Zen4 und man wird sicherlich die L1$ auf 48kB erhöhen mMn und den L2 auf 1MB. Hinzu kommt noch AMDs Aussage, dass beim L0 noch erhebliches Optimierungspotenzial bestünde (finde das Interview dazu leider nicht wieder), das wird Zen4 sicherlich ausschöpfen. Der Sprung wird vielleicht weniger krass sein, allerdings hat man das bei Zen3 auch schon gedacht... AVX512 und AMX ist evtl. auch bei AMD noch ein Thema, auch das könnte mit Zen4 noch kommen.

Tobalt

2020-11-08, 11:42:29

Was die IPC-Sprünge angeht, muss ich zugeben, dass ich tatsächlich nicht mehr an solche Fortschritte geglaubt habe. Solche Sprünge wie Conroe und Nehalem wird man wohl wirklich nie wieder sehen, aber nachdem die Entwicklung durch Intel zwischenzeitlich quasi eingeschlafen ist, dachte ich, dass man dort einfach mit vertretbarem Aufwand keine nennenswerten Fortschritte mehr erzielen kann. In der Theorie ist es ja auch schwer, denn selbst mit einer 100%igen Branch Prediction, gibt es im Code Datenabhängigkeiten, die sich prinzipbedingt nicht auflösen lassen und somit eine obere Schranke dafür bilden, wieviele Befehle pro Takt überhaupt ausgeführt werden können. Anscheinend hat(te) man die aber noch nicht erreicht.

du schreibst ja schon dass die großen IPC Zuwächse heute durch Verbreiterung also durch Parallelisierung kommen.

Die mögliche Parallelisierung der Ausführung ist durch den Code begrenzt.

Deshalb vermute ich, dass es 2010 halt Zeit war für Conroe, aber damals hatten weitere Verbreiterungen noch keinen Sinn ergeben. Heute ist der Code weiter und daher machen breitere Kerne heute nun Sinn.

Man könnte ja mal heutige gegen 20 Jahre alte Apps testen. Ich denke bei alten Apps wird der IPC zuwachs im Schnitt deutlich kleiner ausfallen zwischen den Architekturen

Der_Korken

2020-11-08, 13:11:42

Deshalb vermute ich, dass es 2010 halt Zeit war für Conroe, aber damals hatten weitere Verbreiterungen noch keinen Sinn ergeben. Heute ist der Code weiter und daher machen breitere Kerne heute nun Sinn.

Man könnte ja mal heutige gegen 20 Jahre alte Apps testen. Ich denke bei alten Apps wird der IPC zuwachs im Schnitt deutlich kleiner ausfallen zwischen den Architekturen

Das wäre tatsächlich mal ein interessanter Vergleich. Allerdings ist dann die Frage inwiefern der Code heute "weiter" ist. Coden die Leute wirklich anders oder sind es die Compiler, der besser parallelisierten Maschinencode erzeugen? Bei number crunshing hilft die Vektorisierung natürlich enorm und da kann man auch als Entwickler mithelfen, aber was ist mit reiner Programmlogik, die viele Branches hat? Im Alder-Lake-Thread hab ich so ähnliche Fragen auch mal gestellt wegen der hohen IPC-Prognosen von Intel.

@w0mbat: Bei den APUs hast du mit DDR5 natürlich recht, die hängen schon sehr stark an der Bandbreite.

Zossel

2020-11-10, 21:59:01

https://www.computerbase.de/2020-11/amd-zen-4-rdna-4-ausblick-rick-bergman/

basix

2020-11-10, 22:59:59

https://www.computerbase.de/2020-11/amd-zen-4-rdna-4-ausblick-rick-bergman/

Dort steht nicht wirklich viel neues drin bis auf folgende zwei Aussagen:

Zen 4 soll eine ähnlich lange Liste an Verbesserungen wie Zen 3 haben
RDNA3 soll ebenso wie RDNA2 aggressiv an Perf/W Verbesserungen arbeiten

Schlussendlich bedeutet das, dass AMD die Pace nicht verringert sondern möglichst beibehält. Aufgrund 5nm hat man bei beiden einen guten Booster, welchen man bei Zen 3 & RDNA2 nicht hatte. Unrealistisch sind die Ziele also nicht.

Allzuviel Gewicht würde ich den Aussagen aber nicht unbedingt geben. AMD wird sicher weitere Verbesserungen anstreben aber Rick Bergmans Aussagen sind halt sehr oberflächlich.

RT_GFX

2020-11-12, 16:48:27

Hab mich extra angemeldet, weil ich gewartet hab bis es jemand evtl. postet und diskutiert.
Nun mach ich es eben selbst :P

Reddit (https://www.reddit.com/r/GamingLeaksAndRumours/comments/jpmejf/amd_zen_4_cpus/)

Good evening.

I'm going to drop tentative information for AMD's Zen 4 CPU's. Source is me being an AMD employee, and just to be up front and transparent I will not be confirming my identity in any possible regard so I cannot confirm anything.I am marking this as [No Source] myself because of this, so feel free to take my information at face value until official details are released.

Secondly, this information is tentative within the company but is a mix of goals, expectations, and what internally we have set as a minimum deliverable.

___

The first thing is the expected release window. Of course this has a wide range of variability but internally Q3 2022 is when business hopes to have it on shelves. I just wanted to quickly put this out there as people seem to believe it will be end of 2021 and I don't know where this belief originated. There is a reason for this late timeframe.

Zen 4 will support DDR5 memory which is already public knowledge. However, internally we are already validating recommended configurations based on what the memory controller will be able to handle. We want to push memory speeds as hard as we can by release. We are working closely with SK Hynix on planned availability and are hard at work to deliver 6600MHz memory be our officially validated and recommended spec. We expect enthusiasts to be pushing 7000MHz as we have been having promising results internally.

Zen 4 is an iterative node shrink release with one MAJOR improvement over Zen 3. You may have wondered why the IMC is virtually indifferent from Zen 2 as far as consumer's are concerned now that we have released the 5000 series. The reason is because our IPC improvements were well above expectations early on in the design and testing phases. Because of this AMD decided to hold our trump card back a generation to deliver our biggest performance jump yet. (We have internal expectations of Intel delivering their own 7nm node in 2022, coinciding with Zen 4. Despite all the hate for Intel, they remain a threatening and significant competitor and they will likely have an impressive release 2022.)

So... what is this trump card? Here is the big reveal. "Infinity Fabric 2.0". I have no idea if this name will stick around for marketing. What it actually is is the culmination of all of our efforts since Zen 1 in architecting a solution to instruction starvation. The IMC this time around will be a 7nm chiplet to enable us to push the fabric clock as far as we absolutely can get. This is why our memory target is 6600MHz, because our real goal is an FCLK of 3300MHz. The package will be surrounded by 4 CCDs (of course 5nm, this is basically publicly known already too) with an absolutely gargantuan pool of L4 cache. Final cache amounts are a long ways off though so no information there. We have heavily leaned into L4 this time around as Radeon has done.

What does this add up to? That's the ultimate question, isn't it. Like I mentioned before, the reason for the late 2022 time frame is to be absolutely sure we will be hitting the memory speeds we set out for ourselves to hit. Instruction starvation is one of the biggest problems we face currently in the industry. We have finally made a significant stride with this. As of now, our total IPC improvement is a staggering 30% - About 4% of this is minor core optimizations and the rest is entirely the result of the IF and memory overhaul. We think by the beginning of 2022 we will be approaching 40% overall IPC improvements.

There you have it.

A few notes:No plan for 4 threads per core even for post-Zen 4 as of now. Sorry.I have zero info on PCI-E 5.0. I wouldn't necessary write it off, but I wouldn't expect it either. Will be determined later in development. All focus is on memory and cache now.The pricing of the Zen 3 chips caught my team off guard a bit. I have no idea what to expect for Zen 4 as prices are determined at the very tail end of everything. Sorry again.I'm obviously an engineer at AMD and that is literally all I can say. Luckily that is such a large pool of people that I will be fine. Sometime in the last 5 years I was denied a promotion that I'm still salty over so I'm deciding to release this info now. Anything more specific and perhaps they could weed out enough people to potentially figure out who I am. Just sharing this small tidbit in case you're wondering why I'd do this.Lastly I am posting this on GamingLeaksAndRumors simply because I read this sub a lot when bored at work. I'm personally very into gaming. Who else is loving Leagues II in OSRS?

Die Sache ist, ohne Verifikation könnten das sich viele sich aus den Fingern saugen und aufschreiben.
Was aber eher unüblich bei fakes ist, dass hier teilweise so genaue Angaben wie 3300mhz IF clock; 4 CCD und prozentuale Angaben, wie sich die IPC Steigerung zusammensetzt.

Ich will nicht sagen, dass es unbedingt echt ist, aber es ist interessant genug, um es mir zu bookmarken.
Wenn in einem Jahr Gerüchte zum FLCK und zu den CCDs auftauchen und es übereinstimmt, wäre ich nicht überrascht.

w0mbat

2020-11-12, 17:30:10

mMn kompletter Unsinn. Wenn er in einer Position wäre wo er so viel wüsste, würde er das nicht leaken.

Großer L4 cache? Macht keinen Sinn, weil DDR5 ähnlich schnell sein wird, sowohl auf Bandbreite als auch Latenz bezogen. Bei Broadwell war der L4 noch schneller als der RAM, aber schon schneller DDR4 schlägt den Broadwell L4. Und je größer der cache, desto schlechter die Latenzen. D.h., ein "gargantuan pool of L4 cache" wäre extrem sinnbefreit.

Zudem macht DDR5-6600 auch keinen Sinn. Bandbreite ist nicht das Problem und die wächst mit DDR5 eh schon überdurchschnittlich, wieso sollte AMD Zeit und Geld darauf verschwenden? Für AMD ist es wichtig, dass alles gut läuft und breit verfügbar ist. DDR5-6600 wäre fatal zum Marktstart von DDR5. Außerdem schau dir mal den bisherigen Verlauf der populärsten Speicherfrequenzen an: DDR-400 -> DDR2-800 -> DDR3-1600 -> DDR4-3200. Merkste was?

30% mehr IPC auf Zen3 wäre enorm, aber nicht unmöglich. 3Q22 macht auch Sinn, wir werden Zen4 sicher nicht vor 2022 sehen. Kannst mit min. 15 Monaten rechnen, das wäre März 2021.

Ich schenke dem Post 0,4% Vertrauen.

PS: willkommen im Forum!

HOT

2020-11-12, 17:33:40

Was aber plausibel klingt ist das 7nm IOD, denn hier kann man ja den L4 dann auch mit maximaler Größe unterbingen, so Infinity-Cache-mäßig. Das IOD lässt sich selbstredend auch mit Zen3 koppeln und wäre sicherlich auch noch mit DDR4 betreibbar.
Der Grund, warum man das nicht jetzt bringt? Kosten! Das alte IOD dürfte nur einen Bruchteil kosten. Solange Intel nicht adäquates bringt ist das neue IOD nicht nötig.

w0mbat
Das wird man nur ausgetestet haben, das heißt doch nicht, dass das auch so kommt. Das wird natürlich mit standard-Takten für DDR5 kommen.
Vor Zen1 gab es ähnlich mißinterpretierte Meldungen für einen DDR3200-Controller. Ja, das packt auch der Zen1-Controller maximal, aber so kam es ja nicht und lief ja auch nicht in der Breite. Dennoch muss der IF-Takt im IOD den Speichertakt auch ertragen können, das Testen ist im Designprozess also durchaus sinnvoll.

Und das Ass im Ärmel ist wäre ja das neue IOD in Warhol, wenn Intel mit Alder Lake zu stark werden sollte. Man darf nicht übersehen, dass in dem Post Sachen durcheinander erzählt wurden. Hier gehts ja nicht nur um Zen4 offensichtlich ;).

Der_Korken

2020-11-12, 17:39:43

Die IPC-Verbesserungen machen mich ehrlich gesagt etwas stutzig. Die 4% aus den Kern-Verbesserungen können hinkommen, denn bei Zen 3 haben die ja schon ziemlich viel am Kern geändert. Diese kleine Zahl impliziert für mich, dass sich an der Anzahl der Execution Ports nichts ändert, denn die würden wohl kaum weitere INT- oder FP-ALUs einbauen, wenn das nur 4% IPC bringt. Nimmt man jetzt aber die 30% IPC, die angeblich durch das Fabric und den Cache kommen sollen, ergäbe das gegenüber Zen 1 irgendwas um die 80% IPC-Uplift ohne dass der Kern verbreitert wurde. Klingt mir nicht sehr einleuchtend.

Wir wissen natürlich noch nicht, wie sich Zen 3 mit RAM-OC schlägt, aber wenn beim Speichersystem so viel Leistung brach liegt, wie im reddit post beschrieben, müsste Zen 3 damit noch krasser abgehen als die vorigen Generationen. Im Moment sieht es aber nicht so wirklich danach aus, zumindest wenn man den Speichertakt selbst anhebt. Anwendungen reagieren so gut wie gar nicht auf schnellen Speicher, weil die meisten davon hauptsächlich im Cache ablaufen (und da war selbst Zen 1 schon relativ gut). Daher frage ich mich wie ein schneller IF-Bus oder ein großer L4 die Performance so krass anheben wollen. Eventuell bezog er sich ausschließlich auf Spiele (er selbst sagt ja, dass er gerne zockt), aber AMD wird wohl kaum ihre Chips jetzt speziell auf Spiele optimieren, wenn das große Geld im Server- und Mobilbereich gemacht wird.

tl;dr: Glaube die Story nicht.

Edit:

Außerdem schau dir mal den bisherigen Verlauf der populärsten Speicherfrequenzen an: DDR-400 -> DDR2-800 -> DDR3-1600 -> DDR4-3200. Merkste was?

30% mehr IPC auf Zen3 wäre enorm, aber nicht unmöglich. 3Q22 macht auch Sinn, wir werden Zen4 sicher nicht vor 2022 sehen. Kannst mit min. 15 Monaten rechnen, das wäre März 2021.

Ja, den krummen Wert von 6600Mhz habe ich ganz vergessen. Warum ausgerechnet 6600? Afaik soll DDR5 auch "nur" bis 6400 gehen. Der Launch 2022 ergibt dagegen wieder Sinn, weil AMD auch mal Zeit zum Entwickeln braucht. Zen 3 hat es mit Ach und Krach noch in 2020 geschafft, da wird Zen 4 nicht schon in 12 Monaten im Regal stehen. Allerdings kommt mit Q3 wieder etwas spät vor, da hätte ich mir vorstellen können, dass sie die Gunst der Stunde (Huawei) bei 5nm nutzen wollen - notfalls zulasten einiger Features im Kern, die man halt auf Zen 5 verschiebt.

Was aber plausibel klingt ist das 7nm IOD, denn hier kann man ja den L4 dann auch mit maximaler Größe unterbingen, so Infinity-Cache-mäßig. Das IOD lässt sich selbstredend auch mit Zen3 koppeln und wäre sicherlich auch noch mit DDR4 betreibbar.
Der Grund, warum man das nicht jetzt bringt? Kosten! Das alte IOD dürfte nur einen Bruchteil kosten. Solange Intel nicht adäquates bringt ist das neue IOD nicht nötig.

Ja, auch die 7nm IOD sind eine logische Entwicklung. Ich frage mich aber, ob sie eventuell den L3 wieder verkleinern, wenn sie noch eine Stufe draufsetzen. 128MB L4 wären ca. 100mm² groß, also bereits so groß wie das IOD von Zen 2/3. Damit dürften 128MB die Obergrenze sein, sonst werden die kleinen Modelle mit einem Chiplet viel zu teuer. Der 5950X hat aber schon 64MB gesamt, da könnte sicherlich die Hälfte von einsparen.

Andererseits steht auf reddit was von vier Chiplets ... also 32 Kerne? Die 12- und 16-Kerner können sich abseits von schweren Anwendungen schon kaum absetzen. Glaube nicht, dass AMD hier so hoch geht im Desktop.

Ein paar Sachen klingen ganz plausibel, andere aber überhaupt nicht. Und vor allem, warum sollte ein Entwickler sowas gezielt leaken und dann noch auf reddit? Sinn? Er kriegt kein Geld, sondern max. 5 Minuten fame und riskiert seinen Job.

HOT

2020-11-12, 17:55:30

Fänd ich absolut plausibel, L3 wieder zu verkleinern oder zumindest nicht zu vergrößern, da der Cache ja in N5 keinen schlagenden Vorteil bringt und einen verschlechternden Kosten/Nutzenfaktor hätte, da die Caches ja nur um 20% wachsen maximal, aber die Kosten > 20% wären für die Fläche des Caches. Also verkleinert den L3 oder vergrößert ihn eben nicht und bringt das lieber als L4 ins 7nm IOD.

w0mbat

2020-11-12, 17:59:47

Und der L4 cache, der im IOD sitzt, soll dann merkbar schneller sein als der RAM?

Linmoum

2020-11-12, 18:06:00

DDR5 ist durch die JEDEC nur bis 6400MHz spezifiziert, also wird AMD auch nichts darüber als offiziell supportet haben.

Den ganzen Post kann man also getrost vergessen, gerade als """AMD Mitarbeiter""" sollte man sowas einfaches wissen.

HOT

2020-11-12, 18:29:31

Und der L4 cache, der im IOD sitzt, soll dann merkbar schneller sein als der RAM?

Alles ist schneller als RAM in dem Bereich. Siehe Broadwell.

Apropos:

https://www.anandtech.com/show/16195/a-broadwell-retrospective-review-in-2020-is-edram-still-worth-it

Schon echt krass... heute noch...

basix

2020-11-12, 18:40:17

6600 MHz = komisch, 6400 MHz wäre plausibler
4 CCDs = komisch, das dann mit max. 32 Cores? 2 CCDs mit 10-12C wäre irgendwie plausibler, 4 CCDs könnte aber allenfalls kosteneffizienter sein je nach Kernanzahl
7nm IOD = könnte sein, aber nicht kosteneffektiv (12LP+ bei GloFo mMn wahrscheinlicher --> WSA)
L4 = kann sein, Umsetzung aber sehr schwammig beschrieben
+40% IPC = wäre sehr krass, nicht unmöglich (siehe Apple M1) aber das glaube ich erst wenn ich es sehe
Timeline = irgendwie komisch beschrieben. Dass man IF 2.0 und ein neues IOD für Zen 3 geplant hatte und dann doch nicht umgesetzt hat hört sich unwahrscheinlich an

Fazit:
Wenn es so kommt, dann nehem ich das gerne. Daran glauben tue ich momentan aber nicht wirklich.

Der_Korken

2020-11-12, 19:00:36

30% IPC-Uplift sind historisch schon sehr selten. Die einzigen Male, wo ich sowas miterlebt habe waren Zen 1 und Conroe (2006), zwei komplette redesigns from scratch. Und in beiden Fällen waren die Vorgänger IPC-schwache Hochtaktdesigns mit mieser Performance. Von 40% brauchen wir gar nicht zu reden. Am ehesten könnte man hier noch Nehalem anführen, der gelegentlich mal auf 30% kam. Dafür hat Intel aber (1) den off-socket Speichercontroller in die CPU integriert, (2) das MCM-Design des Core 2 Quad zu einem monolithischen Quadcore gemacht, (3) SMT eingeführt und (4) die gesamte Cache-Hierachie neu designt. (1), (2) und (3) hat Zen 3 de facto schon (zumindest wenn man die Modelle mit einem Chiplet nimmt) und (4) teilweise auch durch die neuen CCX. Ich sehe einfach nicht wie man von dem hohen Niveau von Zen 3 noch so viel rausholen will in einer einzigen Iteration und nachdem man gerade erst einen großen Schritt nach vorne gemacht hat bei der IPC.

Es könnte natürlich sein, dass er eigentlich von Warhol (bzw. Zen3+) redet, wie w0mbat schon schrieb. Aber im Leak wird ausdrücklich gesagt, dass es Zen 4 sein soll (ein Entwickler wird solche Namen wohl kaum verwechseln) und explizit von 3Q22 gesprochen.

w0mbat

2020-11-12, 19:28:40

Alles ist schneller als RAM in dem Bereich. Siehe Broadwell.

Apropos:

https://www.anandtech.com/show/16195/a-broadwell-retrospective-review-in-2020-is-edram-still-worth-it

Schon echt krass... heute noch...
Wenn du den Artikel, den du verlinkt hast, auch gelesen hättest, wüsstest du, dass der L4 eben nicht mehr schneller als DDR4 ist. Das ist doch mein Punkt. Ein großer L4 wäre langsamer als der RAM.

Zossel

2020-11-12, 19:39:49

Wenn du den Artikel, den du verlinkt hast, auch gelesen hättest, wüsstest du, dass der L4 eben nicht mehr schneller als DDR4 ist. Das ist doch mein Punkt. Ein großer L4 wäre langsamer als der RAM.

eDRAM != SRAM.

w0mbat

2020-11-12, 20:04:58

Also wenn, dann würde ich bei AMDs chiplset Ansatz eDRAM vermuten. Die hauen doch keine 256MB SRAM auf das IOD. Selbst in 5nm wäre das rießig.

Der_Korken

2020-11-12, 21:34:35

"as Radeon has done" klingt aber eher nach SRAM. Wobei man den L4 sowieso erstmal schnell kriegen müsste. eDRAM spart im Grunde nur die Latenz ein, die durch den Sockel und die Komplexität der RAM-Module entsteht (einer vs. viele DRAM-Chips). Bei SRAM würde man noch die Latenz des DRAM-Chips einsparen, wobei z.B. 3200Mhz und CL14 auch gerade mal 4,375ns sind (da könnte die Einsparung von eDRAM gegenüber DRAM fast schon größer sein als SRAM gegenüber eDRAM, denn in Spielen bringen die primären Timings wesentlich weniger als die Subtimings).

Die Latenz im IOD bzw. auf dem Fabric wird man damit trotzdem nicht los. Hier hat Zen 3 übrigens mal eben knappe 10ns rausgeholt durch die verringerte Komplexität des IFs nur auf dem CCD. Da sieht man mal, wo die zusätzliche Latenz im Vergleich zu Intel herkommt. Mit einem optimierten IOD in 7nm würde Zen3 vermutlich unter 50ns liegen bei der Latenz. Gegen eDRAM hätte ich natürlich auch nichts einzuwenden, aber wenn das der heilige Gral wäre, hätten Intel oder AMD den sicher nochmal neu aufgelegt. Gerade Intel hätte so einen kurzfristigen Boost längst umgesetzt, wenn sie sowieso schon auf 14nm Skylake festsitzen und einen Refresh nach dem anderen raushauen müssen. Das wäre billiger gewesen, als ihren SunnyCove nochmal auf 14nm zurückzuportieren.

w0mbat

2020-11-12, 22:34:42

Ich denke halt, mit Zen4 wird wohl eh ein neues IOD kommen und es kommt schneller DDR5 RAM, da noch nen L4 dazwischen zu schalten, bei eh schon sehr großem L3, macht für mich (als Laie) wenig Sinn. Außer der L3 wird, wie HOT schon anmerkte, kleiner und wieder mehr auf Latenz getrimmt. Also L1/L2/L3 klein und schnell und dann viel L4 aufs IOD.

mksn7

2020-11-13, 13:26:09

Instruction starvation is one of the biggest problems we face currently in the industry

Instruction Starvation as in der instructiong fetch ist zu langsam? Also dass die CPU darauf wartet dass instructions aus dem RAM geholt werden? Uh, das wär mir neu. Die ganze instruction fetch und L1I Geschichte kann hier und da in Randfällen mit erratischem rumhüpfenden Code mal ein Problem sein, aber in den allermeisten Fällen gibt es genug locality durch loops dass das meist kein limiter ist.

Ich halte den Post auch für fake. Das Argument für einen späten release wegen dem market timing von DDR5 klänge noch plausibel. Der Rest klingt nach Fantasie.

Tobalt

2020-11-13, 13:28:07

SRAM über das Infinity Fabric anzubinden - ist das nicht Perlen vor die Säue ?

Ist es denn sicher, dass der Radeon Cache SRAM ist ?

robbitop

2020-11-13, 13:29:36

Kann das ggf. auch mit dem Decoder zu tun haben? Dort kommen doch die Instructions in umgewandelter Form her. Wir sitzen in der x86 Welt seit Ewigkeiten auf 4x Decodern herum. Wegen der variablen Instruction Länge von x86 ist die Verbreiterung des Decoders wohl auch recht energieintensiv. Die ensprechenden uOp Caches helfen dabei schon - kann mir gut vorstellen, dass das irgendwann mal zum Bottleneck werden kann.

edit: sehe gerade, dass eher Latenz/Cache gemeint ist.

IMO: +30% ggü Zen 3 mit dem relativ großen L3 halte ich für sehr optimistisch.
L4 SRAM in einem 7 nm IOD mit sagen wir 128 MiB wäre machbar. Aber die IF Anbindung würde das aktuell aus Latenzsicht nicht sinnvoll sein lassen. Damit da richtig was bei rumkommt sollte das <<40 ns sein. Besser <30 ns.
Dazu bräuchte man eine andere ggf. separate Anbindung.

mksn7

2020-11-13, 13:42:12

Kann das ggf. auch mit dem Decoder zu tun haben? Dort kommen doch die Instructions in umgewandelter Form her. Wir sitzen in der x86 Welt seit Ewigkeiten auf 4x Decodern herum. Wegen der variablen Instruction Länge von x86 ist die Verbreiterung des Decoders wohl auch recht energieintensiv. Die ensprechenden uOp Caches helfen dabei schon - kann mir gut vorstellen, dass das irgendwann mal zum Bottleneck werden kann.

Die Breite der Decoder ist auf jeden Fall manchmal ein Limiter, zumindest ein bisschen. Aber der µOp cache kann deutlich mehr instructions absetzen, auch wenn das glaube ich micro vs macro ops sind.

Aber das sind alles in-core Sachen, während der reddit post was von IF und einem großen, weit vom Kern entfernten Cache spricht. Ich kann mir nicht vorstellen dass der instruction fetch an irgendwelche Bandbreitenlimits stößt.

Akkarin

2020-11-13, 13:43:47

Ich bezweifle auch ob es sinnvoll ist L4 in den IOD zu legen, aber das sollte doch immer noch ca. 20ns schneller sein als zum RAM zu gehen ?

HOT

2020-11-13, 14:02:19

SRAM ist immer schneller, das wird auf jeden Fall Performance bringen. Bei Navi haben auch viele bezweifelt, ob das irgendwas bringt und die Zweifler lagen halt falsch. Mal sehen, ob sowas kommt, aber ich finds albern das vorab schon zu verurteilen.

basix

2020-11-13, 14:03:12

Ich bezweifle auch ob es sinnvoll ist L4 in den IOD zu legen, aber das sollte doch immer noch ca. 20ns schneller sein als zum RAM zu gehen ?

Schneller definitiv. Wie viel ist mir aber unklar.

Der_Korken

2020-11-13, 14:15:52

Bei Navi haben auch viele bezweifelt, ob das irgendwas bringt und die Zweifler lagen halt falsch. Mal sehen, ob sowas kommt, aber ich finds albern das vorab schon zu verurteilen.

Naja, es war unklar ob 128MB reichen bzw. ob sich die Zugriffsmuster einer GPU mit der einer CPU vergleichen lassen. "Bringen" tut es natürlich immer was, die Frage ist zu welchem Preis. Bei N21 nimmt der Cache ca. 20% der Die-Fläche ein, da muss er dann auch liefern.

Das mit den Decodern ist mir gestern auch aufgefallen, als ich auf Anandtech ein Blockdiagramm von Apples M1 gesehen habe. Der decodiert 8 Instruktionen pro Takt und hat auch mehr ALUs als Zen 3. Trotzdem sind die Kerne geschätzt (auch 5nm berücksichtigend) deutlich kleiner und sparsamer als von Zen 3. Holt x86 diesen Rückstand von Faktor 2 durch komplexere Instruktionen wieder raus oder ist das langfristig ein Flaschenhals? Nach jahrelanger Quasi-Stagnation bei der IPC legen Zen 3 und die ganzen Cove-Kerne plötzlich los wie die Feuerwehr, finde es schon sehr interessant warum das genau jetzt passiert und nicht schon Jahre davor.

Berniyh

2020-11-13, 17:42:39

Naja, es war unklar ob 128MB reichen bzw. ob sich die Zugriffsmuster einer GPU mit der einer CPU vergleichen lassen. "Bringen" tut es natürlich immer was, die Frage ist zu welchem Preis. Bei N21 nimmt der Cache ca. 20% der Die-Fläche ein, da muss er dann auch liefern.
Bei Navi 21 ist Chipfläche aber auch eher teuer.
Der IOD wird ja in einem etwas älteren Prozess gefertigt und damit ist es nicht ganz so teuer mehr davon rein zu machen.
Aber dennoch will das natürlich gut überlegt sein, keine Frage.
Zumal – sollte die 7nm Geschichte stimmen – auch der Punkt mit dem günstigeren Prozess auch eher hinfällig, denn 7nm @ TSMC wird sicher über Jahre hinweg ziemlich ausgebucht bleiben, zumal die Kapazitäten (zumindest bei den Prozessen mit EUV Anteil) auch nicht größer werden, sondern eher kleiner (da man die EUV Scanner auf neuere Prozesse migrieren wird).

Zossel

2020-11-13, 18:32:47

Das mit den Decodern ist mir gestern auch aufgefallen, als ich auf Anandtech ein Blockdiagramm von Apples M1 gesehen habe. Der decodiert 8 Instruktionen pro Takt und hat auch mehr ALUs als Zen 3. Trotzdem sind die Kerne geschätzt (auch 5nm berücksichtigend) deutlich kleiner und sparsamer als von Zen 3. Holt x86 diesen Rückstand von Faktor 2 durch komplexere Instruktionen wieder raus oder ist das langfristig ein Flaschenhals? Nach jahrelanger Quasi-Stagnation bei der IPC legen Zen 3 und die ganzen Cove-Kerne plötzlich los wie die Feuerwehr, finde es schon sehr interessant warum das genau jetzt passiert und nicht schon Jahre davor.

Höhere Frequenz braucht fettere Transen.

BTW: Ich habe bei dem Ding von Apple keinen µOP-Cache gesehen, ein µOP-Cache verringert die notwendige Breite des Dekoders und die Anforderungen an den Instruktions-L1. Gibt es ARMs mit µOP-Cache?

Zossel

2020-11-13, 18:37:29

Die Breite der Decoder ist auf jeden Fall manchmal ein Limiter, zumindest ein bisschen. Aber der µOp cache kann deutlich mehr instructions absetzen, auch wenn das glaube ich micro vs macro ops sind.

Aber das sind alles in-core Sachen, während der reddit post was von IF und einem großen, weit vom Kern entfernten Cache spricht. Ich kann mir nicht vorstellen dass der instruction fetch an irgendwelche Bandbreitenlimits stößt.

Von ZENx zu ZENx+1 wurde der µOP-Cache grösser und/oder besser gemacht und der Instruktions-L1 kleiner (IMHO allerdings mit besserer Assoziativität).

Zossel

2020-11-13, 18:42:16

Die ganze instruction fetch und L1I Geschichte kann hier und da in Randfällen mit erratischem rumhüpfenden Code mal ein Problem sein, aber in den allermeisten Fällen gibt es genug locality durch loops dass das meist kein limiter ist.

Typische Geschäftslogik ist "erratisch" und "rumhüpfended".

robbitop

2020-11-13, 19:39:52

Höhere Frequenz braucht fettere Transen.

BTW: Ich habe bei dem Ding von Apple keinen µOP-Cache gesehen, ein µOP-Cache verringert die notwendige Breite des Dekoders und die Anforderungen an den Instruktions-L1. Gibt es ARMs mit µOP-Cache?
Das würde mich total wundern, wenn die keine uOp Caches haben.

Another major feature of the new front-end is the introduction of a Macro-Op cache structure. For readers familiar with AMD and Intel’s x86 processor cores, this might sound familiar and akin to the µOP/MOP cache structures in those cores, and indeed one would be correct in assuming they have the similar functions.

https://www.anandtech.com/show/14384/arm-announces-cortexa77-cpu-ip/2

Wenn der A77 sowas hat, wird das sicherlich auch in den Apple ARM CPUs vorhanden sein. A78 und X1 haben den auch und den sogar ausgebaut.

Das Problem ist, dass Apple im Gegensatz zu ARM wenig zu ihren uArchs bekannt gibt.

Zossel

2020-11-13, 20:01:26

Das würde mich total wundern, wenn die keine uOp Caches haben.

Dekoderbreite vs. µOP-Cache könnte ein Design Tradeoff sein.

BoMbY

2020-11-13, 20:29:41

SKYNET

2020-11-13, 21:11:40

robbitop

2020-11-13, 21:23:34

Dekoderbreite vs. µOP-Cache könnte ein Design Tradeoff sein.

uOp Caches haben doch keinen wesentlichen Nachteil und steigern doch eher die Energieeffizienz. Das ist schon lange Stand der Technik.

Brillus

2020-11-14, 01:38:50

denke zen4 wird infinity cache bekommen --> "L4"... 300GB/s, da kommt auch DDR5 nicht mehr mit....
Denk ich nicht zumindest nicht die CPU, die APU kann da anders sein.

Zossel

2020-11-14, 10:25:20

uOp Caches haben doch keinen wesentlichen Nachteil und steigern doch eher die Energieeffizienz. Das ist schon lange Stand der Technik.

Auch bei ARM?

robbitop

2020-11-14, 10:42:49

Ich habe nur herausfinden können, dass A77, A78 und X1 das haben. Damit ist es zumindest etabliert.

Zossel

2020-11-14, 10:46:58

Ich habe nur herausfinden können, dass A77, A78 und X1 das haben. Damit ist es zumindest etabliert.

Wie breit ist da der Dekoder?
Wie fett und schnell ist da der L1I?

robbitop

2020-11-14, 10:58:59

Recherchieren kannst du aber schon selbst? ;)
Ich sehe selbst bei einem besonders breiten Decoder den Nachteil eines uOp Caches nicht. Warum also nicht beides?

S940

2020-11-15, 14:13:21

Das würde mich total wundern, wenn die keine uOp Caches haben.
https://www.anandtech.com/show/14384/arm-announces-cortexa77-cpu-ip/2
Wenn der A77 sowas hat, wird das sicherlich auch in den Apple ARM CPUs vorhanden sein. A78 und X1 haben den auch und den sogar ausgebaut.
Das Problem ist, dass Apple im Gegensatz zu ARM wenig zu ihren uArchs bekannt gibt.
Naja, eben deshalb kann man eben nicht von Team Äpfel auf Team Birnen schließen. Der Instruktionssatz ist der selbe, aber die Designs - samt Design-Teams sind eben total unterschiedlich.

Ein BMW Otto-Motor unterscheidet sich auch wesentlich von nem Toyota-Motor, obwohl beide mit Benzin angetrieben werden.

Ich sehe selbst bei einem besonders breiten Decoder den Nachteil eines uOp Caches nicht. Warum also nicht beides?Weil so ein super-breiter Dekoder Die-Fläche, Powerbudget etc. pp. verschlingt, dessen Wichtigkeit aber mit nem größeren µop-Cache aber sinkt. Kurz: Das wäre kein stimmiges Design mehr.

Nachdem Apple auch nen riesigen L1-I-Cache hat, der mit nem µOp-Cache nun wirklich ganz-sicher überflüssig wäre - siehe AMDs Reduktion beim Zen2 - muss man eher davon ausgehen, dass Apple so was nicht hat.

Das Apple-Design erscheint mir eher ein traditioneller Ansatz nach dem Viel-hilft-Viel-Prinzip zu sein. Klotzen statt kleckern, was man sich durch das eher geringe Taktziel dann auch leisten kann. Richtig innovativ scheint es dagegen aber nicht zu sein.

S940

2020-11-15, 14:46:17

Ich glaube schon dass das Sinn machen könnte, vor allem mit vielen CCD. Im schlimmsten Fall wäre das so wie ein Zugriff von einem CCD auf den Cache von einem anderen CCD, was glaube ich schon möglich sein sollte. Der sollte dann vermutlich wenigstens die Größe vom kombinierten L3-Cache aller CCD haben, besser das doppelte.

SO siehts aus, mit mehrern CCDs macht ein L4 Sinn um die ganzen Datenströme besser koppeln zu können. Datenaustausch über RAM ist es immer eine Tortur.

Nachdem AMD weiter ins Dickschiff-Serversegment vordringen will, würde ein L4 absolut Sinn machen, v.a. auch in "gargantuan" Größe, anders würde der keinen Sinn machen.

Aber den Rest des Postings glaube ich nicht. +40% IPC nur wegen des L4 ist utopisch und 7nm machen auch keinen Sinn. Man hat das IO-Die ja schließlich eingeführt, weil sich die IO-Anschlüsse nicht mehr weiter schrumpfen lassen.

Schaut man mal, was ein anderer GF-Kunde so treibt:
https://fuse.wikichip.org/news/3383/ibm-doubles-its-14nm-edram-density-adds-hundreds-of-megabytes-of-cache/

Dann sieht man dort ~1 GByte EDRAM-Cache in nem 14nm SOI-Prozess. Das ganze auf nem so genannten "System-Control Chip, der quasi 4 Chips (=CCDs) verwaltet - das sieht schon sehr ähnlich aus) Ich denke das wäre plausibler. Das Ganze dann für AMD in 12nm und ~die Hälfte (512 MB) und es käme gut hin.

Bei der Größe könnte man es sich sogar leisten die kompletten L3 in den L4 zu spiegeln, wie es Intel beim L2-Cache im L3 macht. 32 MB mal 4 CCDs wären ja "nur" 128 MB ;)

Und zum Thema DDR5: Da wird doch wieder nur doppelt soviel pro Takt übertragen, die Latenz bleibt weiterhin auf dem gleichen Niveau - da tut sich nichts, ist doch schon seit DDR2 so. Die IF-Taktraten steigen immer nur marginal.

Plausibel wird allerdings das Thema Infinity 2.0, schließlich muss die interne Fabric die doppelte Datenrate von DDR5 weiterleiten können - entweder man verdoppelt dort die Leitungsanzahl, oder man erhöht den Fabric-Takt. Alternativ ne Mischung aus Beidem.

Unter Strich bleibt festzustellen, dass wg. DDR5 ein dickeres Update des IO-Dies nötig ist, von daher wären starke Änderungen nicht überraschend. Ob nun mit oder ohne L4 wird man sehen.

basix

2020-11-15, 14:59:09

Dann sieht man dort ~1 GByte EDRAM-Cache in nem 14nm SOI-Prozess. Das ganze auf nem so genannten "System-Control Chip, der quasi 4 Chips (=CCDs) verwaltet - das sieht schon sehr ähnlich aus) Ich denke das wäre plausibler. Das Ganze dann für AMD in 12nm und ~die Hälfte (512 MB) und es käme gut hin.

Bei der Größe könnte man es sich sogar leisten die kompletten L3 in den L4 zu spiegeln, wie es Intel beim L2-Cache im L3 macht. 32 MB mal 4 CCDs wären ja "nur" 128 MB ;)

256 MB sehe ich als absolutes Maximum an. Selbst wenn die Density verglichen zum IBM nochmals etwas steigt wäre das immer noch um die 100mm2 an L4$. An einen 7nm IOD glaube ich nämlich nicht, eher wird es GloFo 12LP+. Und fällt bei einer kompletten Spiegelung des L3 nicht massiv Bandbreite zwischen CCD und IOD an? Irgendwie kann ich das nicht ganz glauben. Ich tippe eher auf 128 MB L4 und sonstige Optimierungen, dann ist der IOD nur wenig grösser als heute, was die Kosten im Zaum hält.

Plausibel wird allerdings das Thema Infinity 2.0, schließlich muss die interne Fabric die doppelte Datenrate von DDR5 weiterleiten können - entweder man verdoppelt dort die Leitungsanzahl, oder man erhöht den Fabric-Takt. Alternativ ne Mischung aus Beidem.

3. Möglichkeit: PAM-4 oder ähnliche Techniken ;)

Der_Korken

2020-11-15, 16:31:49

Wie geht Zen 3 aktuell damit um, wenn ein Prozess von einem Kern auf einen anderen innerhalb des selben CCDs verschoben wird? Die Daten im L2 (welcher auch die Daten des L1 enthält) sind ja nicht im shared L3, weil dieser ein victim cache ist. Muss der gesamte L2 dann wieder aus dem RAM nachgeholt werden oder kann man über die gespiegelten L2-Tags die Daten innerhalb des Dies wiederherstellen? Bei Intel war das bis Skylake ja relativ einfach, weil der L3 inclusive war.

Für einen L4 ist es sicher auch relevant wie die Verbindung zwischen L2 und L3 aussieht. Wenn man den L3 in den L4 spiegelt, aber den L2 nicht, wird das mit der Kohärenz kompliziert, weil das alles irgendwie so semi-inclusive ist. Ein inklusiver L3 würde das wieder vereinfachen, aber es wird wohl gute Gründe geben, dass Intel nun auch von inclusive zu victim wechselt bei Willow Cove.

basix

2020-11-15, 17:01:13

...aber es wird wohl gute Gründe geben, dass Intel nun auch von inclusive zu victim wechselt bei Willow Cove.

Inclusive limitiert die Grösse des L2, da man nicht beliebig viel des L3 mit dem Inhalt des L2 füllen will.

Nakai

2020-11-15, 17:09:11

denke zen4 wird infinity cache bekommen --> "L4"... 300GB/s, da kommt auch DDR5 nicht mehr mit....

Haben wir doch schon? Wenn du einen L4-Cache im IO-Die meinst, dann bin ich mir nicht sicher, ob das Vorteile bringt. Inter(Die)-Socket-Cache-Coherence wäre zwar der heilige Grahl, aber auch ein riesiger Aufwand...und Cache-Synchronisierung kann auch Nachteile mit sich bringen, wenn die Inter-Socket-Kommunikation etwas länger dauert. :freak:

robbitop

2020-11-15, 18:52:40

Naja, eben deshalb kann man eben nicht von Team Äpfel auf Team Birnen schließen. Der Instruktionssatz ist der selbe, aber die Designs - samt Design-Teams sind eben total unterschiedlich.

Ein BMW Otto-Motor unterscheidet sich auch wesentlich von nem Toyota-Motor, obwohl beide mit Benzin angetrieben werden.

Im Urschleim müssen wir meinetwegen nicht wühlen.

Weil so ein super-breiter Dekoder Die-Fläche, Powerbudget etc. pp. verschlingt, dessen Wichtigkeit aber mit nem größeren µop-Cache aber sinkt. Kurz: Das wäre kein stimmiges Design mehr.
Transistorbudget ist bei Apple kein großes Problem. Ein uOp Cache sollte bei jedem Treffer den Decoder entlasten und Energie sparen. Dank Powergating muss heute der Gleichsatz Transistoren~Leistungsaufnahme nicht mehr sein.
Gerade bei low power macht das mMn Sinn.

Nachdem Apple auch nen riesigen L1-I-Cache hat, der mit nem µOp-Cache nun wirklich ganz-sicher überflüssig wäre - siehe AMDs Reduktion beim Zen2 - muss man eher davon ausgehen, dass Apple so was nicht hat.
Cache Hirarchie gibt es nicht umsonst. Größe und Latenz stehen im Zusammenhang. Der große L1I wird nicht besonders schnell sein verglichen mit konventionellen 32-64kiB. Ein uOp Cache ist ja deutlich kleiner und entsprechend schneller. The right tool for the right job - ansonsten muss man wieder unnötig viele Takte warten bis die Instruktion da ist.

Das Apple-Design erscheint mir eher ein traditioneller Ansatz nach dem Viel-hilft-Viel-Prinzip zu sein. Klotzen statt kleckern, was man sich durch das eher geringe Taktziel dann auch leisten kann. Richtig innovativ scheint es dagegen aber nicht zu sein.
IMO ist diese Aussage aufgrund folgender Hintergründe IMO nicht seriös.

1.) Es gibt so ziemlich keine Informationen zu der uArch selbst. Entsprechend ist das nur sehr beschränkt einschätzbar.
2.) Erreicht man bei erstaunlich wenig Leistungsaufnahme nicht nur relativ zu allen anderen eine enorm hohe IPC und trotz moderatem Takt auch eine sehr hohe Gesamtleistung anscheinend.
3.) Wenn es so wenig innovativ wäre, dann könnte es jeder. Und doch rennt Apple jedem ARM Wettbewerber um Generationen davon. Samsung hat mit ihren Mongoose Kernen einen ähnlichen Ansatz probiert. Breit, viel, tief und das Ergebnis ist unter Leistungsaufnahme kollabiert. Viele hatten eine ARM ISA Lizenz und die meisten haben aufgegeben und sind zu ARM Standardkernen zurückgekehrt.

Das was man in diesem SoC sieht muss schon einiges an sich haben, damit man zu diesem Ergebnis kommt. Warum man so eine Ingenieursleistung nicht anerkennen kann, verstehe ich nicht. Ich finde es aufregend und es wird alle anderen CPU Entwickler sicherlich inspirieren und anstacheln. 2020 ist super interessant.

robbitop

2020-11-15, 18:57:09

SO siehts aus, mit mehrern CCDs macht ein L4 Sinn um die ganzen Datenströme besser koppeln zu können. Datenaustausch über RAM ist es immer eine Tortur.

Nachdem AMD weiter ins Dickschiff-Serversegment vordringen will, würde ein L4 absolut Sinn machen, v.a. auch in "gargantuan" Größe, anders würde der keinen Sinn machen.

Aber den Rest des Postings glaube ich nicht. +40% IPC nur wegen des L4 ist utopisch und 7nm machen auch keinen Sinn. Man hat das IO-Die ja schließlich eingeführt, weil sich die IO-Anschlüsse nicht mehr weiter schrumpfen lassen.

Schaut man mal, was ein anderer GF-Kunde so treibt:
https://fuse.wikichip.org/news/3383/ibm-doubles-its-14nm-edram-density-adds-hundreds-of-megabytes-of-cache/

Dann sieht man dort ~1 GByte EDRAM-Cache in nem 14nm SOI-Prozess. Das ganze auf nem so genannten "System-Control Chip, der quasi 4 Chips (=CCDs) verwaltet - das sieht schon sehr ähnlich aus) Ich denke das wäre plausibler. Das Ganze dann für AMD in 12nm und ~die Hälfte (512 MB) und es käme gut hin.

Bei der Größe könnte man es sich sogar leisten die kompletten L3 in den L4 zu spiegeln, wie es Intel beim L2-Cache im L3 macht. 32 MB mal 4 CCDs wären ja "nur" 128 MB ;)

Und zum Thema DDR5: Da wird doch wieder nur doppelt soviel pro Takt übertragen, die Latenz bleibt weiterhin auf dem gleichen Niveau - da tut sich nichts, ist doch schon seit DDR2 so. Die IF-Taktraten steigen immer nur marginal.

Plausibel wird allerdings das Thema Infinity 2.0, schließlich muss die interne Fabric die doppelte Datenrate von DDR5 weiterleiten können - entweder man verdoppelt dort die Leitungsanzahl, oder man erhöht den Fabric-Takt. Alternativ ne Mischung aus Beidem.

Unter Strich bleibt festzustellen, dass wg. DDR5 ein dickeres Update des IO-Dies nötig ist, von daher wären starke Änderungen nicht überraschend. Ob nun mit oder ohne L4 wird man sehen.

Gute Theorie und das mit der Latenz sehe ich ähnlich. Für viele Anwendungen wichtiger als Bandbreite. Allerdings muss damit das sinnvoll ist die Latenz vom ccd zum iod nochmal stark abnehmen. Unter 30 ns wären gut.

Ist der 14nm SOI Prozess noch von IBM - Herstellung dann in USA? IBM nutzt in den Power CPUs mit ihrem soi Prozess ja schon recht lange edram als L3. Der in Dresden ist ja 22FDX. Der Nachfolgeprozess (12 FDX soll ja noch Jahre in Entwicklung sein).

@basix
S940 meint aber edram. Da kostet jedes Bit einen Bruchteil der Fläche von herkömmliche. 6/8t sram. Geht aber längst nicht mit allen Prozessen. Mit SOI aber wohl möglich. GF hat sowas im Programm.
Für den IO Kram braucht man sowieso nicht den neusten Prozess.

Zossel

2020-11-15, 22:20:09

Ist der 14nm SOI Prozess noch von IBM - Herstellung dann in USA? IBM nutzt in den Power CPUs mit ihrem soi Prozess ja schon recht lange edram als L3. Der in Dresden ist ja 22FDX. Der Nachfolgeprozess (12 FDX soll ja noch Jahre in Entwicklung sein).

IBM geht zu Samsung, TSMC stellt mit seinen Taiwan-only Standorten auch ein nicht unerhebliches Risiko dar. Und die Patente für den EDram den IBM nutzt liegen bei IBM.

Leonidas

2020-11-16, 10:58:58

> Genoa will have 96 cores, PCI-e 5.0 and DDR5.
> A core config of 8 cores per CCD, 12 CCDs per package.
> Zen 4 has four sockets lined up (so far): AM5, SP5, TR5 and SP6.

https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-1415-november-2020

HOT

2020-11-16, 11:47:25

Wir haben eine Sache bisher außer Acht gelassen bei der Betrachtung des I/O-Dies. Das könnte ja durchaus in 12LP+ gefertigt sein und der Cache könnte in einem separaten 7nm-Die gestackt oder zusätzlich sein.

basix

2020-11-16, 11:49:48

8C CCDs machen sehr viel Sinn (auch wenn ich auf 12C CCDs hoffe ;)). Mehr als 16C macht beim Desktop momentan nicht viel Sinn, für den Rest gibt es HEDT. In 5nm sollte das CCD ~55-60mm2 gross werden. Das bedeutet die kosten für ein CCD sollten sinken, trotz des teureren Prozesses.

Vorteil 8C CCDs (ggü. 12C):
- Kleinere Chiplets, höhere Ausbeute
- Feinere Granularität bei Server Chip SKUs, weniger Verschwendung von wertvoller Silizium Fläche (z.B. 4, 6, 8, 10, 12 Chiplets je nach SKU). Produktstack z.B. 16, 24, 32, 48, 64, 80, 96C

Nachteil 8C CCDs:
- >8C benötigt im Desktop-Bereich immer noch 2 CCDs
- 10C SKUs zwar denkbar, aber 5C pro CCD haben wir momentan noch nicht gesehen. Das ginge bei 12C leichter
- Kühlbarkeit der kleinen Chips wird schwieriger

Was ich mich noch bezüglich Genoa frage:
- 12 Channel Speicherinterface oder bleibt man bei 8?

Wir haben eine Sache bisher außer Acht gelassen bei der Betrachtung des I/O-Dies. Das könnte ja durchaus in 12LP+ gefertigt sein und der Cache könnte in einem separaten 7nm-Die gestackt oder zusätzlich sein.
Stacked Die oder MCM mit 7nm Cache könnte sein, steigert aber die Komplexität des Designs stark. Falls man den Cache zum IOD dazuzählt, tendiere ich also stark zu monolitisch. Und ausserdem 12LP+. 7nm (oder eher 6nm) ist vermutlich einfach zu teuer. Der IOD muss vor allem günstig und möglichst stromsparend sein, 12LP+ würde das zum Grossteil erfüllen. Ausserdem hat man immer noch das WSA mit GloFo, welches man bis 2024 verlängert hat.

fondness

2020-11-16, 11:52:31

Naja, eben deshalb kann man eben nicht von Team Äpfel auf Team Birnen schließen. Der Instruktionssatz ist der selbe, aber die Designs - samt Design-Teams sind eben total unterschiedlich.

Ein BMW Otto-Motor unterscheidet sich auch wesentlich von nem Toyota-Motor, obwohl beide mit Benzin angetrieben werden.

Weil so ein super-breiter Dekoder Die-Fläche, Powerbudget etc. pp. verschlingt, dessen Wichtigkeit aber mit nem größeren µop-Cache aber sinkt. Kurz: Das wäre kein stimmiges Design mehr.

Nachdem Apple auch nen riesigen L1-I-Cache hat, der mit nem µOp-Cache nun wirklich ganz-sicher überflüssig wäre - siehe AMDs Reduktion beim Zen2 - muss man eher davon ausgehen, dass Apple so was nicht hat.

Das Apple-Design erscheint mir eher ein traditioneller Ansatz nach dem Viel-hilft-Viel-Prinzip zu sein. Klotzen statt kleckern, was man sich durch das eher geringe Taktziel dann auch leisten kann. Richtig innovativ scheint es dagegen aber nicht zu sein.

Es ist ohnehin nur begrenzt sinnvoll, Decoder bei unterschiedlichen ISAs zu vergleichen. Ich denke man kann sich aber darauf einigen, dass bei keiner CPU sowas triviales wie die Decoder limitieren. :-)

8C CCDs machen sehr viel Sinn (auch wenn ich auf 12C CCDs hoffe ;)). Mehr als 16C macht beim Desktop momentan nicht viel Sinn, für den Rest gibt es HEDT. In 5nm sollte das CCD ~55-60mm2 gross werden. Das bedeutet die kosten für ein CCD sollten sinken, trotz des teureren Prozesses.

Vorteil 8C CCDs (ggü. 12C):
- Kleinere Chiplets, höhere Ausbeute
- Feinere Granularität bei Server Chip SKUs, weniger Verschwendung von wertvoller Silizium Fläche (z.B. 4, 6, 8, 10, 12 Chiplets je nach SKU). Produktstack z.B. 16, 24, 32, 48, 64, 80, 96C

Nachteil 8C CCDs:
- >8C benötigt im Desktop-Bereich immer noch 2 CCDs
- 10C SKUs zwar denkbar, aber 5C pro CCD haben wir momentan noch nicht gesehen. Das ginge bei 12C leichter
- Kühlbarkeit der kleinen Chips wird schwieriger

Was ich mich noch bezüglich Genoa frage:
- 12 Channel Speicherinterface oder bleibt man bei 8?

Stacked Die oder MCM mit 7nm Cache könnte sein, steigert aber die Komplexität des Designs stark. Falls man den Cache zum IOD dazuzählt, tendiere ich also stark zu monolitisch. Und ausserdem 12LP+. 7nm (oder eher 6nm) ist vermutlich einfach zu teuer. Der IOD muss vor allem günstig und möglichst stromsparend sein, 12LP+ würde das zum Grossteil erfüllen. Ausserdem hat man immer noch das WSA mit GloFo, welches man bis 2024 verlängert hat.

Das es bei 8 Cores pro CCD bleibt, könnte auch darauf hindeuten, dass die Cores deutlich wachsen. Ein Chiplet mit <60mm² scheint mir schon fast zu klein bzw. auch nicht unproblematisch was I/O und Kühlung betrifft.