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

Interessant ist vor allem auch das hier aus dem Patch:

Code:
+     {"znver1", PROCESSOR_ZNVER1, CPU_ZNVER1,

+	PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
+	| PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1
+	| PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX | PTA_AVX2
+	| PTA_BMI | PTA_BMI2 | PTA_F16C | PTA_FMA | PTA_PRFCHW
+	| PTA_FXSR | PTA_XSAVE | PTA_XSAVEOPT | PTA_FSGSBASE
+	| PTA_RDRND | PTA_MOVBE | PTA_MWAITX | PTA_ADX | PTA_RDSEED
+	| PTA_CLZERO | PTA_CLFLUSHOPT | PTA_XSAVEC | PTA_XSAVES
+	| PTA_SHA | PTA_LZCNT | PTA_POPCNT},

SSE 1, 2, 3, 4a, 4.1, 4.2

AVX 1 und 2

Und auch Intel SHA extensions sowie RdRand anscheinend.
 
Leider fehlt FMA4 - nur weil Intel es
1. selbst vorgeschrieben hatte (AVX-Spec)
aber
2. es nicht gebacken bekommt

Schade dass AMD diese Intel Schmach nicht weiter ausbaut
 
Sieht immer noch so aus wie der "Insider"-Kram, bis auf den separat aufgeführten L/S-Scheduler.

Wollte ich auch gerade sagen *chatt* Im originalen Bulldozer-Bild hatte AMD die zwei ALUs und zwei AGUs ja als vier "Pipelines" eingetragen, in den angeblich gefälschten Folien stehen sechs "Pipelines" und es sollen vier ALUs und zwei AGUs sein. Vierfach-Decoder scheint auch zu passen, ebenso wie die beiden 256 Bit-FMACs und die Cache-Größe. Huch.
 
Bei den 256b AVX FMA steht:
znver1-double,(znver1-fp0+znver1-fp3)|(znver1-fp1+znver1-fp3)
Also eine Kombination von von FP Pipe: 0+3 oder 1+3
Das heißt es sollte nur eine FMA Instruktion pro Takt möglich sein.
256b AVX ADD:
znver1-double,znver1-fp2|znver1-fp3
Es ist eine double Instruktion, die auf Pipe 2 oder 3 möglich ist.
256b AVX MUL:
znver1-double,(znver1-fp0|znver1-fp1)*3
Multiplikation ist also Pipe 0 oder 1, aber nur alle 3 Takte möglich.

Es kann also nur eine Add Pipe als Akku für FMA benutzt werden, während beide Mul mögliche Ports sind. Entsprechend müsste man das Blockschaltbild nochmals anpassen.


Bei den AGUs:
+(define_cpu_unit "znver1-agu0" "znver1_agu")
+(define_cpu_unit "znver1-agu1" "znver1_agu")
+(define_reservation "znver1-agu-reserve" "znver1-agu0|znver1-agu1")
+(define_reservation "znver1-load" "znver1-agu-reserve")
+(define_reservation "znver1-store" "znver1-agu-reserve")
Bedeutet denke ich das beide AGUs load und store können. Bei Bobcat z.b. gibts ja nur je 1load + 1store.
Und die AGUs sind auch für FP load/store zuständig, sollten demnach genauso 128bit breit sein, wie die FP units.

Vielen Dank auf alle Fälle für die neuen Infos Dresdenboy . ;D
 
Heute bin ich nicht so schnell wieder am PC. Aber kurz: Es kommt ja noch Zen+. Da gibt es vllt. 256b units.

Die AGUs machen nur Adressen (64b Zeug). Daten wandern vermutlich, auf 128 bit Pfaden.

Die Fake-Slides setzten vielleicht ja etwas Durchgesickertes um oder versuchten einfach etwas Plausibles darzustellen.
 
Ja ich glaube auch, dass das mit der nächsten oder übernächsten Generation auf 256b FP Pipes geht. War mit K8 zu K10 ja quasi genauso.
Dann kann auch gleich AVX 512 also double Instruction ausgeführt werden.

Und mit 128b meinte ich natürlich den Datenpfad. :)
 
Die FMA-Kombination mit fp3 für Adds ist vllt. ein copy-paste-Fehler. Oder es reicht aus, falls die fp0/fp1 pipes wirklich niedrigeren fpmul Durchsatz haben.
 
Bei den 256b AVX FMA steht:
znver1-double,(znver1-fp0+znver1-fp3)|(znver1-fp1+znver1-fp3)
Also eine Kombination von von FP Pipe: 0+3 oder 1+3
Das heißt es sollte nur eine FMA Instruktion pro Takt möglich sein.
256b AVX ADD:
znver1-double,znver1-fp2|znver1-fp3
Es ist eine double Instruktion, die auf Pipe 2 oder 3 möglich ist.
256b AVX MUL:
znver1-double,(znver1-fp0|znver1-fp1)*3
Multiplikation ist also Pipe 0 oder 1, aber nur alle 3 Takte möglich.

Es kann also nur eine Add Pipe als Akku für FMA benutzt werden, während beide Mul mögliche Ports sind. Entsprechend müsste man das Blockschaltbild nochmals anpassen.
Danke, das hatte ich mir gerade auch angesehen .. was mich noch wunderte ist:
mmx_add:
znver1-direct,znver1-fp0|znver1-fp1|znver1-fp3

Wieso können fp0 & fp1 bei MMX plötzlich auch ADD, obwohl es bei AVX nur auf fp2 und fp3 geht?
Müssen dann wohl extra MMX-Pipes an den beiden Ports sein.
Bleibt dann nur noch die Frage, wieso es auch an FP3 geht, aber nicht an FP2, aber eventuell hat das ja mit der FMA-Sache zu tun, die auch nur auf Port 3 läuft.
Bei den 256b AVX FMA steht:
znver1-double,(znver1-fp0+znver1-fp3)|(znver1-fp1+znver1-fp3)
Also eine Kombination von von FP Pipe: 0+3 oder 1+3
Das ginge dann aber nur, wenn 0+1+3 FMA-Pipes hätten, oder? Da kommt ja nur ne "Double" an ...
 
Eine FMA Pipe in dem Sinne, dürfte es als eigene Pipe vermutlich nicht geben, sondern wohl eher ein Zusammenschluss der MUL und einer ADD. Dresdenboy hat eine solche "bridged FMA" ja auch in seinem blog verlinkt.
Vlt. läuft das auf makro ebene ja dann so ähnlich:
MUL (Pipe 0) // 1. Takt mul 1
MUL (Pipe 1) // 2. Takt delay mul 1, 1. Takt mul 2
ADD (Pipe 3) // 3. Takt add 1 , 2. Takt delay mul 2
ADD (Pipe 3) // 4. Takt delay add 1, 3. Takt add 2
wb reg // 5. Takt wb add 1 , 4. Takt delay add 2
wb reg // - , 5. Takt wb add2

Damit ist der Durchsatz von FMA zwar genauso groß wie bei getrennten MUL und ADD Befehlen, man spart aber eine x86 Befehl und wahrscheinlich einen Takt Latenz am Ende vom Mul. Also nur 5 statt zweil mal 3 Takte. Ein zusätzlicher ADD Port ist damit für FMA also nicht notwendig.

Damit eine double Instruktion für 256b FMA reicht, müssten die MUL und ADD Pipes mit einer makro Instruktion gleichzeitig gesteuert werden können, aber das sollte denke ich auch kein Problem sein. Eventuell geht ein möglicher add slot für das umschalten zu fma verloren, aber das sollte man auch kaum merken und man hat ja auch noch einen 2. ADD Port übrig. :D
 
Eine FMA Pipe in dem Sinne, dürfte es als eigene Pipe vermutlich nicht geben, sondern wohl eher ein Zusammenschluss der MUL und einer ADD. Dresdenboy hat eine solche "bridged FMA" ja auch in seinem blog verlinkt.
Jojo, das ist schon klar, hatten wir hier ja vor ~4 Jahren diskutiert.

Aber:
Damit eine double Instruktion für 256b FMA reicht, müssten die MUL und ADD Pipes mit einer makro Instruktion gleichzeitig gesteuert werden können, aber das sollte denke ich auch kein Problem sein.

Naja ein Double reicht doch nur für die Hälfte, also 128 bit ... so wars bisher, 256bit FMA wurden in 2 x 128bit FMA-Doubles aufgespalten.
Bei BD gabs nur FMA-Pipes, die konnten die 2 FMA-µOps der aufgesplitteten Double dann ohne Probleme entgegennehmen. Aber die Bridge-FMA hat 2 Inputs, ADD+MUL, ergo müsste der FP-Scheduler die µOps nochmal aufsplitten in Mul+Add, also 4 µOps und dann muss auch irgendwo zwischengespeichert werden, dass die ganzen Instruktionen ursprünglich mal nur zu einem 256bit-Befehl gehörten ...

Ok möglicherweise machbar, aber so einfach stell ichs mir jetzt nicht vor.
 
FMA3 wird definitiv unterstützt, bei FMA4 gab es Unklarheiten, ob der Support mit Zen rausfliegt.
http://www.phoronix.com/scan.php?page=news_item&px=AMD-Zen-CPU-Znver1

Im Einleitungstext steht kein Support für FMA4, aber der patch selber soll anscheinend FMA4 zurückgeben, wobei ich nicht sehe wie und wo.
Jedenfalls erwarte ich das was im Einleitungstext steht, kein Support für FMA4.
 
Zuletzt bearbeitet:
FMA3 wird definitiv unterstützt, bei FMA4 gab es Unklarheiten, ob der Support mit Zen rausfliegt.
http://www.phoronix.com/scan.php?page=news_item&px=AMD-Zen-CPU-Znver1

Im Einleitungstext steht kein Support für FMA4, aber der patch selber soll anscheinend FMA4 zurückgeben, wobei ich nicht sehe wie und wo.
Jedenfalls erwarte ich das was im Einleitungstext steht, kein Support für FMA4.
Das betrifft nur den Patch für den Compiler, FMA4 ist bei AMD Grundsätzlich vorhanden sobald FMA3 unterstüzt wird, weil FMA4 vor FMA3 implementiert wurde.

+ "Cpu186|Cpu286|Cpu386|Cpu486|Cpu586|Cpu686|CpuSYSCALL|CpuRdtscp|Cpu387|Cpu687|CpuFISTTP|CpuNop|CpuMMX|CpuSSE|CpuSSE2|CpuSSE3|CpuSSE4a|CpuABM|CpuLM|CpuFMA|CpuFMA4|CpuBMI|CpuF16C|CpuCX16|CpuClflush|CpuSSSE3|CpuSVME|CpuSSE4_1|CpuSSE4_2|CpuAES|CpuAVX|CpuPCLMUL|CpuLZCNT|CpuPRFCHW|CpuXsave|CpuXsaveopt|CpuFSGSBase|CpuAVX2|CpuMovbe|CpuBMI2|CpuRdRnd|CpuADX|CpuRdSeed|CpuSMAP|CpuSHA|CpuXSAVEC|CpuXSAVES|CpuClflushOpt|CpuCLZERO" },
Quelle: https://sourceware.org/ml/binutils/2015-03/msg00078/znver1.tar
 
FMA4 ist dabei, XOP, LWB und TBM fehlen aber wie in der Einleitung beschrieben.
Also interessant wäre es, wenn AMD FMA4 weiterhin behalten möchte.
 
dafür gibt es aber neue Sachen: "CpuADX|CpuRdSeed|CpuSMAP|CpuSHA|CpuXSAVEC|CpuXSAVES|CpuClflushOpt|CpuCLZERO" Als unbedarfter Laie erkenne ich da SHA und vermute eine entsprechende Krypto-Beschleunigung, aber der Rest? *noahnung* Gibt's irgendwo ne Seite, wo diese ganzen Flags erklärt werden?

übrigens habe ich zufällig eine Info ergoogelt (https://en.wikipedia.org/wiki/Talk:FMA_instruction_set#AMD_Zen_and_FMA4_support letzte Zeile), die interessant sein dürfte:
I emailed the programmer (Ganesh at AMD) about the FMA4 confusion. He said CpuFMA4 was incorrectly specified in the patch.
jedoch keine Ahnung, ob das noch zutrifft, diese Zeile stammt ja von Juni.
 
Wenn der größte Desktop-Zen wirklich als 8-Kerner kommt, dann könnte der also wenigstens 8 256bit FP-Operationen gleichzeitig durchführen - das sollte eigentlich reichen. Man muss nur aufpassen zwei solcher Operationen nicht per SMT auf den gleichen physischen Kern geschickt werden, um das Optimum raus zu holen. 128bit Operationen könnten auf allen 16 Threads gleichzeitig laufen. Wenn man einen Kern mit 256bit belegt, dann sollte man auf dem anderen Thread natürlich auch keine 128bit Operationen gleichzeitig ausführen. Die Frage ist, wie gut die OS-Kernel diese Aufteilung unterstützten, oder ob man sich als Programmierer selbst darum kümmern muss?
 
Naja, das ist auch nur das, was ich im Artikel schrieb:
Widersprüchlich ist die Unterstützung der FMA4-Befehle. In der Patcherklärung schreibt der Programmierer, dass auch dies gestrichen werden würde, im Patchcode ist es aber noch enthalten.
Im Zweifelsfall gilt aber der Kommentar, nicht der Quellcode, denn beim Kommentar macht der Entwickler normalerweise keine Copy/Paste-Fehler ;-)

Ergo geh ich nicht von FMA4 aus. Braucht keiner mehr. Wär zwar irgendwie ganz niedlich, aber Intel ist der Boss, keiner wird FMA4 je nutzen, außerdem spart man sich etwas Debugging. Was man nicht anbietet, muss man auch nicht testen. Außerdem sieht man ja an der FPU, dass FMA bei AMD keine hohe Priorität mehr hat.
 
Ein paar BOINC-Projekte gibt es mit FMA4-Patch. Die gehen ganz gut ;)
 
Aber nur weil AVX da nicht so einschlägt wie ab Haswell.

Aber grundsätzlich kann man doch sagen, eben weil der Patch eingereicht wurde, dass ZEN wirklich fertig ist.
 
Naja, das ist auch nur das, was ich im Artikel schrieb:

Im Zweifelsfall gilt aber der Kommentar, nicht der Quellcode, denn beim Kommentar macht der Entwickler normalerweise keine Copy/Paste-Fehler ;-)

Ergo geh ich nicht von FMA4 aus. Braucht keiner mehr. Wär zwar irgendwie ganz niedlich, aber Intel ist der Boss, keiner wird FMA4 je nutzen, außerdem spart man sich etwas Debugging. Was man nicht anbietet, muss man auch nicht testen. Außerdem sieht man ja an der FPU, dass FMA bei AMD keine hohe Priorität mehr hat.
Also ich mische da nicht mit, und wenn es nicht dabei ist stört mich das auch nicht weiter.
Ich dachte nur das man FMA4 implementiert und dann FMA3 ausführen kann, besser mehr Register als zu wenig. ;)
Wenn es der Compiler dann ausblendet, kann man es zumindest mit einem Patch reaktivieren.

Danke für die News!
 
Das basiert auch nur auf dem Patch, den Dresdenboy ausgegraben hat ;)
 
Zurück
Oben Unten