3DCenter Forum - AMD/ATI - Navi 1X (7nm, RDNA1, 2019) & Navi 2X (7nm, RDNA2, 2020)

Locuza · 2020-02-28, 16:00:32

Ich denke nicht das AMD z.B. Multi-GPU Chiplets bauen würde, zumindest nicht mit RDNA1 und RDNA2.
Ebenso denke ich nicht an eine 3-Chip-Lösung, wie I/O-die, GPU-die und CPU-die miteinander auf einem Package.
Eine weitere Möglichkeit wäre GPU und IO auf einem die zu haben und CPU-Chiplets auf einem anderem, was ich vorerst aber auch nicht wahrscheinlich halten würde.
Wenn Van Gogh eine APU ist, dann gibt es davon auch eine Lite-Variante, was soll das dann genau sein?

Wie gesagt, würde man in ähnlicher Art und Weise für Zen2 dokumentieren, hätte man es "Zen2 ISA" genannt.
Aber praktisch ist schon relativ klar, was die ISA an sich definiert und was sie nicht tut.
Bridgman von AMD hat in der Hinsicht selber gesagt, dass man RDNA eher als Mikroarchitektur versteht, welche eine GCN artige ISA verwendet.
Allerdings abseits der Mikroarchitektur-Änderungen, die die wirklich unabhängig von der ISA sind, kann man auch deiner Argumentation folgen, in Hinsicht des Namens.
Wenn man das RDNA-ISA nennen möchte, dann passt es auch.

Es wurde früher auch Navi10 Lite gelistet.
Navi12 Lite, mit der gleichen GFX-ID 1011 wie Navi12, wird noch angezeigt.

Und bei Van Gogh hat man die Nummerierung gegenüber früher geändert:
"VAN GOGH = GFX1033.
(GFX1032 → GFX1033)."

Jetzt mal abseits von neuen oder entfernten Instruktionen, aber GCN2 (Sea Islands) sollte doch völlig abwärtskompatibel mit GCN1-Code (Southern Islands) sein?
Es gab nur ein neues FLAT-Format, mehrere neue Instruktionen und vier hat man entfernt.
GCN3/Volcanic Islands dagegen hat weitreichend Dinge umgestaltet:

Zitat:

Modified many of the microcode formats: VOP3A, VOP3B, LDS, GDS, MUBUF, MTBUF, MIMG, and EXP.
SMRD microcode format is replaced with SMEM, now supporting reads and writes.

Dabei wurden auch mehr Instruktionen entfernt.
Da ist es dann auch eindeutig, dass keine weitreichende Abwärtskompatibilität mehr besteht.
GCN4/Polaris verwendet die gleiche ISA.
Mit GCN5/Vega gab es mehrere Änderungen, erscheinen aber relativ klein:

Zitat:

MIMG Microcode format: removed the R128 bit.
•FLAT Microcode format: added an offset field.
•Removed V_MOVEREL instructions.
•Added control over arithmetic overflow for FP16 VALU operations.
•Modified bit packing of surface descriptors and samplers:
◦T#: removed heap, elem_size, last_array, interlaced, uservm_mode bits.
◦V#: removed mtype.
◦S#: removed astc_hdr field.

Deswegen hatte ich im Kopf, dass GCN1-2 weitgehend identisch ausfallen und dann GCN3-5 (wobei 5 ein paar Dinge geändert hat).

Bei RDNA klingt es erneut nach einem stärkeren Bruch:

Zitat:

Programming Model Changes
•FLAT_SCRATCH and XNACK_MASK are no longer in SGPRsThey are in dedicated hardware registers accessed via S_GETREG_B32 andS_SETREG_B32
•Added a scalar source enum: NULL (reads zero and writes nothing).
•Image operations add a DIMension field
•Memory operations gain DLC bit (Device Level Coherence) to control level-1 caching
•Buffer clamping rules in MUBUF/MTBUF is explicitly controlled by the buffer resource
•Separated dependency counters for vector memory loads from stores
•Moved POPS_PACKER from mode to a hardware register accessed via S_GETREG_B32and S_SETREG_B32
•SGPRs are no longer allocated: every wave gets a fixed number of SGPRs

Instruction Changes
•DS_PERMUTE/DS_BPERMUTE are limited to 32-lane permutation
•DPP (renamed to DPP16) is limited to 16-lane access
•VALU ops can use two SGPR inputs instead of just one
•VALU VOP3 format can use a literal constant
•VALU V_CMPX writes only EXEC, not also an SGPR
•VALU Add & Sub instructions have change names to clarify carry-in and carry-out
•VALU all float-16 math uses FMA instead of MAD
•T# and V# (resource constants) have some bit changes
•Added SALU ops to quickly set float round & denormal modes
•Removed:◦S_SET_GPR_IDX family of instructions (use V_MOVREL for GPR indexing)◦CBRANCH_FORK and CBRANCH_JOIN◦All non-reverse VALU V_SHIFT opcodes◦VSKIP◦Removed non-volatile instruction control

@danarcho

Das hast du schon mehrmals erwähnt, wo ist das Encoding wieder näher bei der v6/7 ISA, gegenüber den späteren?
Hat das in dem Fall überhaupt eine signifikante Bedeutung?

gravitationsfeld · 2020-02-28, 16:53:42

Ich vermute immer noch, dass das naehere Encoding an Southern Islands ein Beiprodukt der Abwaertskompatibilitaet der neuen Konsolen ist. Aber das ist reine Spekulation

danarcho · 2020-02-28, 21:52:35

Zunächst: keine Generation ist 100% abwärtskompatibel. In jeder Generation gab es Änderungen, die das unmöglich machen. Es kann zwischen SI und CI sowie VI und Vega sein, dass einzelne shader funktionieren, aber nicht im allgemeinen.

Soll ich jetzt die einzelnen Formate aufzählen?

Zitat:

Modified many of the microcode formats: VOP3A, VOP3B, LDS, GDS, MUBUF, MTBUF, MIMG, and EXP

Das ist halt nicht die einzige Änderung. Zusätzlich wurden die Opcodes der meisten Instruktionen leicht verändert und Navi macht einen großen Teil davon wieder Rückgängig. Eine Übersicht über alle Opcodes findest du zB hier.

Entweder das oder sie haben aus Versehen das falsche Repo geforkt

2Ms · 2020-02-29, 16:08:07

Ahhh !!!

Nun wird mir klar, warum Wolfenstein The Old Blood auf Tahiti tadellos lief, aber auf Polaris total versagte, Ruckeln und Stocker zeigte. Das Spiel wurde demnach nie an Polaris angepasst.

aufkrawall · 2020-02-29, 16:47:08

Die Spiele sind noch OpenGL, ist wahrscheinlich hauptsächlich auf Nvidia bzw. deren Treiber optimiert und der AMD OpenGL-Treiber für Windows der letzte Müll.

2020-02-29, 16:53:57

Mal folgendes mit ob und No getestet?

https://steamcommunity.com/app/35008...4928858134876/

robbitop · 2020-02-29, 17:34:47

Da sitzt doch aber noch eine High Level API und ein Shadercompiler dazwischen.

Locuza · 2020-02-29, 18:18:53

Jetzt mal spezieller, nur eine kurze Darstellung, warum nicht der meiste SI-Code auch direkt unter CI laufen sollte?
Instruction formats und opcodes sind nahezu alle gleich?

Das Spiel lief (läuft noch?) völlig miserabel auf einer Tonga (GCN3).
Lustigerweise aber nicht bei der Fury X bzw. Fiji (GCN3) mit prinzipiell gleicher Technologiestufe.
Bei Polaris(GCN4) lief es auch richtig schlecht, aber bei der PCGH war der "Übeltäter" das Skylake-System, mit Haswell gab es zumindest Tahiti-Performance und nicht die Hälfte davon:
https://www.pcgameshardware.de/AMD-C...laris-1204234/

Da kann das Spiel aber wenig machen, denn wir redeten von der internen Maschinensprache der GPUs, als Spielentwickler auf dem PC kann man die gar nicht direkt verwendet.
Man verwendet eine API wie DX11/12, OpenGL/Vulkan und eine High-Level-Shader Sprache wie HLSL oder GLSL.
Der Plattform- oder Treibercompiler übersetzt dann den High-Level-Code zur nativen Maschinensprache.

Das einzige was man als Spielentwickler machen könnte, ist mit Glück das Problem zu identifizieren und mit ein paar Code-Anpassungen könnte man möglicherweise die Treiber/Compiler-Probleme umgehen, wenn nicht, dann hat man eben ultimativ Pech gehabt.

danarcho · 2020-02-29, 20:22:31

Würde wohl, aber who cares? Die 3 opcodes, die entfernt wurden, sind recht selten. Aber der shader compiler 'weiß' eh für welche Hardware er gerade kompiliert. Wir haben zB außer FLAT und 1-2 workarounds keinen speziellen Code für SI im Compiler. Die allermeisten shader sind also für SI und CI 100% identisch.

pixeljetstream · 2020-02-29, 20:38:30

Selbst die low-level sprachen wie dxil oder spir-v werden übersetzt. Am PC gibt es nix was nicht vom Treiber abhängt. Afaik kann man nur cuda "legal" binary shippen, was dann aber auf neuerer HW nicht laufen wird, weswegen das nur im Enterprise oder HPC Bereich gemacht wird.

danarcho · 2020-02-29, 20:47:10

OpenCL auch schon seit Ewigkeiten, gibt auch einen Haufen offline Compiler, aber gleiches Problem.

Edit: Bei AMD kann man sogar assembly kernel schreiben, was auch für etherium und konsorten gemacht wurde

gravitationsfeld · 2020-02-29, 21:35:38

pixeljetstream · 2020-02-29, 22:31:02

Okay. Allerdings auch nur offiziell dann für CL oder? Mir fällt bei Grafik nur das inoffizielle "Hacking GCN via OpenGL" ein.
http://h3.gd/

horn 12 · 2020-03-01, 10:28:22

Leistung soll duchwachsen sein,- Ähnlich Vega - Radeon VII
Stromverbrauch zwar besser aber so wirklich gut soll auch RDNA 2 nicht sein.

Preis aber wirklich Top und wird NVIDIA das halbe Jahr zum Handeln zwingen.
Erste Karten sind ab 18.ten März im Handel zu finden.

Infos kommen am 05 März.

danarcho · 2020-03-01, 11:05:24

Naja, man braucht clEnqueueNativeKernel oder etwas entsprechendes in der API, und das haben halt nur die compute APIs. Da bei Nvidia die ISA ja größtenteils reverse-engineered wurde, müsste es eigentlich auch easy sein einen Assembler dafür zu schreiben. Aber keine Ahnung, ob der Treiber noch eine Signatur checkt oder so.

2020-03-01, 11:06:50

Da verarscht dich jemand hart.

Linmoum · 2020-03-01, 11:19:59

Hat ja lange gehalten, nichts mehr schreiben zu wollen.

reaperrr · 2020-03-01, 11:25:29

Völlig unabhängig davon, ob da jetzt was von stimmt:
Wenn die Unterschiede zwischen RDNA1 und 2 größer wären als 1-2 neue Features und leichte Effizienz-/IPC-Optimierungen (und 7nm+), würden die kommenden Chips nicht mehr Navi heißen.

Das Verbrauchs-Optimierungs-Team um Suzan Plummer ist erst Ende 2017 nach Raja's Abgang vom Ryzen-Team zur RTG gewechselt. Um zwischen Navi1x und 2x noch gravierende Verbesserungen vorzunehmen dürfte es da schon zu spät gewesen sein, man darf nicht unterschätzen, wie lang die Vorlaufzeiten für sowas sind.
Die Früchte der Arbeit werden wir IMO frühestens mit RDNA3 sehen, weil das die erste Ausbaustufe sein dürfte, bei der sie genug Zeit hatten, um tiefgreifendere Optimierungen vorzunehmen.

Außerdem scheint Navi21 der internen ID nach zu urteilen eher RDNA1.8 oder so zu sein, denn das ist der einzige Navi2x mit einer gfx102x ID. Navi1x sind alle gfx101x, die anderen Navi2x und kommende Navi-APUs sind schon gfx103x (bzw. eine APU sogar schon gfx1040), was weitere Verbesserungen impliziert (mglw. noch mehr Optimierungen durch Plummer&Team, die Aussage "Nvidia-Killer" fiel ja auch mal im Zusammenhang mit Navi23, nicht 21).

Berniyh · 2020-03-01, 11:53:07

Nein. Navi21 Lite ist gfx102x. Navi21 (ohne Lite) ist gfx1030.
Zumindest laut Komachi.

reaperrr · 2020-03-01, 12:51:30

Ah, ok. Hab ich überlesen, danke für die Klarstellung.

2020-02-28, 16:00:32	#6721 (im Thread / einzeln)
Locuza Admiral Member Registriert: 2010-11-13 Beiträge: 2.879	Re: Navi 1X (7nm, 2019) & Navi 2X (7nm+, 2020) Zitat von HOT Hm... Verschiedene Chiplets?! Ich denke nicht das AMD z.B. Multi-GPU Chiplets bauen würde, zumindest nicht mit RDNA1 und RDNA2. Ebenso denke ich nicht an eine 3-Chip-Lösung, wie I/O-die, GPU-die und CPU-die miteinander auf einem Package. Eine weitere Möglichkeit wäre GPU und IO auf einem die zu haben und CPU-Chiplets auf einem anderem, was ich vorerst aber auch nicht wahrscheinlich halten würde. Wenn Van Gogh eine APU ist, dann gibt es davon auch eine Lite-Variante, was soll das dann genau sein? Zitat von Complicated Deswegen veröffentlicht AMD ein Dokument mit dem Titel "RDNA Insctruction Set Architecture". Können wir bei den Angaben von AMD bleiben und die eigenen Meinungen an die Realität anpassen? Die Diskussion dreht sich im Kreis, da du keinerlei Argument hast für diese Sichtweise. Nun jemand muss ja definieren wie es genannt wird. IMHO ist das AMD und daran kann man sich orientieren. Eine bessere Alternatvie sehe ich hier nicht. Und ich sagte ja bereit es sind Iterationen und Erweiterungen. Ist etwas sowohl ISA als auch Microarchitektur, dann sehe ich keinen Grund zu sagen es sei keine ISA weil es beides ist. Das "Entweder, Oder" muss man ja nicht auf die Spitze treiben. Schon gar nicht in dem Abstraktionlevel auf dem wir hier im Forum damit umgehen wollen. Eine RDAN ISA wurde definiert - wollen wir diese nun ignorieren, weil sie der GCN-ISA zu 90% ähnelt? Wie viel Ähnlichkeit hat x64 mit x86? Es wird dennoch alles mit x86 bezeichnet. Wie gesagt, würde man in ähnlicher Art und Weise für Zen2 dokumentieren, hätte man es "Zen2 ISA" genannt. Aber praktisch ist schon relativ klar, was die ISA an sich definiert und was sie nicht tut. Bridgman von AMD hat in der Hinsicht selber gesagt, dass man RDNA eher als Mikroarchitektur versteht, welche eine GCN artige ISA verwendet. Allerdings abseits der Mikroarchitektur-Änderungen, die die wirklich unabhängig von der ISA sind, kann man auch deiner Argumentation folgen, in Hinsicht des Namens. Wenn man das RDNA-ISA nennen möchte, dann passt es auch. Zitat von Berniyh [...] Das ist wohl wahr. Dachte ursprünglich, dass es sich um mobile Varianten handelt, aber die Navi1x Chips untermauern das nicht unbedingt. Wobei es bei Navi1x glaube ich auch keine Lite Labels gab? Könnte aber auch sein, dass man bei Navi1x keine derartigen Änderungen zwischen den Desktop- und Mobile-Chips hat, als dass man Code-Branches (und damit ein dediziertes Label) brauchte. [...] Es wurde früher auch Navi10 Lite gelistet. Navi12 Lite, mit der gleichen GFX-ID 1011 wie Navi12, wird noch angezeigt. Und bei Van Gogh hat man die Nummerierung gegenüber früher geändert: "VAN GOGH = GFX1033. (GFX1032 → GFX1033)." Zitat von gravitationsfeld Gab zwischen allen Revisionen zumindest kleinere Aenderungen. Aber ja, auch sonst: Southern Islands, Sea Islands, Volcanic Islands, GFX9 (Vega), GFX10 (Navi). Okay, es wurde vier Mal geaendert, wenn man die erste Revision nicht mit zaehlt. Zitat von danarcho Das Witzige ist doch, dass die RDNA ISA wieder näher and SI ist als an Vega, was das Encoding angeht Man könnte also sagen, die ISA dreht sich genauso im Kreis wie die Diskussion hier Jetzt mal abseits von neuen oder entfernten Instruktionen, aber GCN2 (Sea Islands) sollte doch völlig abwärtskompatibel mit GCN1-Code (Southern Islands) sein? Es gab nur ein neues FLAT-Format, mehrere neue Instruktionen und vier hat man entfernt. GCN3/Volcanic Islands dagegen hat weitreichend Dinge umgestaltet: Zitat: Modified many of the microcode formats: VOP3A, VOP3B, LDS, GDS, MUBUF, MTBUF, MIMG, and EXP. SMRD microcode format is replaced with SMEM, now supporting reads and writes. Dabei wurden auch mehr Instruktionen entfernt. Da ist es dann auch eindeutig, dass keine weitreichende Abwärtskompatibilität mehr besteht. GCN4/Polaris verwendet die gleiche ISA. Mit GCN5/Vega gab es mehrere Änderungen, erscheinen aber relativ klein: Zitat: MIMG Microcode format: removed the R128 bit. •FLAT Microcode format: added an offset field. •Removed V_MOVEREL instructions. •Added control over arithmetic overflow for FP16 VALU operations. •Modified bit packing of surface descriptors and samplers: ◦T#: removed heap, elem_size, last_array, interlaced, uservm_mode bits. ◦V#: removed mtype. ◦S#: removed astc_hdr field. Deswegen hatte ich im Kopf, dass GCN1-2 weitgehend identisch ausfallen und dann GCN3-5 (wobei 5 ein paar Dinge geändert hat). Bei RDNA klingt es erneut nach einem stärkeren Bruch: Zitat: Programming Model Changes •FLAT_SCRATCH and XNACK_MASK are no longer in SGPRsThey are in dedicated hardware registers accessed via S_GETREG_B32 andS_SETREG_B32 •Added a scalar source enum: NULL (reads zero and writes nothing). •Image operations add a DIMension field •Memory operations gain DLC bit (Device Level Coherence) to control level-1 caching •Buffer clamping rules in MUBUF/MTBUF is explicitly controlled by the buffer resource •Separated dependency counters for vector memory loads from stores •Moved POPS_PACKER from mode to a hardware register accessed via S_GETREG_B32and S_SETREG_B32 •SGPRs are no longer allocated: every wave gets a fixed number of SGPRs Instruction Changes •DS_PERMUTE/DS_BPERMUTE are limited to 32-lane permutation •DPP (renamed to DPP16) is limited to 16-lane access •VALU ops can use two SGPR inputs instead of just one •VALU VOP3 format can use a literal constant •VALU V_CMPX writes only EXEC, not also an SGPR •VALU Add & Sub instructions have change names to clarify carry-in and carry-out •VALU all float-16 math uses FMA instead of MAD •T# and V# (resource constants) have some bit changes •Added SALU ops to quickly set float round & denormal modes •Removed:◦S_SET_GPR_IDX family of instructions (use V_MOVREL for GPR indexing)◦CBRANCH_FORK and CBRANCH_JOIN◦All non-reverse VALU V_SHIFT opcodes◦VSKIP◦Removed non-volatile instruction control @danarcho Das hast du schon mehrmals erwähnt, wo ist das Encoding wieder näher bei der v6/7 ISA, gegenüber den späteren? Hat das in dem Fall überhaupt eine signifikante Bedeutung?

2020-02-28, 16:53:42	#6722 (im Thread / einzeln)
gravitationsfeld Admiral Member Registriert: 2017-04-09 Beiträge: 2.011	Re: Navi 1X (7nm, 2019) & Navi 2X (7nm+, 2020) Ich vermute immer noch, dass das naehere Encoding an Southern Islands ein Beiprodukt der Abwaertskompatibilitaet der neuen Konsolen ist. Aber das ist reine Spekulation

2020-02-28, 21:52:35	#6723 (im Thread / einzeln)
danarcho Silver Member Registriert: 2016-06-23 Beiträge: 369	Re: Navi 1X (7nm, 2019) & Navi 2X (7nm+, 2020) Zitat von Locuza @danarcho Das hast du schon mehrmals erwähnt, wo ist das Encoding wieder näher bei der v6/7 ISA, gegenüber den späteren? Hat das in dem Fall überhaupt eine signifikante Bedeutung? Zunächst: keine Generation ist 100% abwärtskompatibel. In jeder Generation gab es Änderungen, die das unmöglich machen. Es kann zwischen SI und CI sowie VI und Vega sein, dass einzelne shader funktionieren, aber nicht im allgemeinen. Soll ich jetzt die einzelnen Formate aufzählen? Zitat: Modified many of the microcode formats: VOP3A, VOP3B, LDS, GDS, MUBUF, MTBUF, MIMG, and EXP Das ist halt nicht die einzige Änderung. Zusätzlich wurden die Opcodes der meisten Instruktionen leicht verändert und Navi macht einen großen Teil davon wieder Rückgängig. Eine Übersicht über alle Opcodes findest du zB hier. Zitat von gravitationsfeld Ich vermute immer noch, dass das naehere Encoding an Southern Islands ein Beiprodukt der Abwaertskompatibilitaet der neuen Konsolen ist. Aber das ist reine Spekulation Entweder das oder sie haben aus Versehen das falsche Repo geforkt

2020-02-29, 16:08:07	#6724 (im Thread / einzeln)
2Ms Gold Member Registriert: 2016-07-06 Ort: Souterrain schwarz-gelb Beiträge: 701	Re: Navi 1X (7nm, 2019) & Navi 2X (7nm+, 2020) Zitat von gravitationsfeld GCN ist definitiv keine ISA im Sinne von x86, sonst haette sich das Instruction-Encoding zwischen Tahiti und Navi nicht rund fuenf mal geaendert. Der Assembly-Code sieht aehnlich aus zwischen den verschiedenen Chips aber das war's auch schon. Man kann nicht mal Tahiti-Code auf Polaris laufen lassen. Voellig anderes und inkompatibles Encoding. Selbst Instructions werden zwischen den Chips entfernt oder gaendert. Ahhh !!! Nun wird mir klar, warum Wolfenstein The Old Blood auf Tahiti tadellos lief, aber auf Polaris total versagte, Ruckeln und Stocker zeigte. Das Spiel wurde demnach nie an Polaris angepasst. Die rosaroten Brillengläser sind geborsten. Nun liegen die blitzenden Scherben im totgrauen Schmutz, und der Staub der Erinnerung brennt in den Augen

2020-02-29, 16:47:08	#6725 (im Thread / einzeln)
aufkrawall Fanatic Member Registriert: 2015-12-12 Ort: Gottuser-Olymp Beiträge: 27.161	Re: Navi 1X (7nm, 2019) & Navi 2X (7nm+, 2020) Die Spiele sind noch OpenGL, ist wahrscheinlich hauptsächlich auf Nvidia bzw. deren Treiber optimiert und der AMD OpenGL-Treiber für Windows der letzte Müll.