@M1ximili1n
nein, nach NVIDIA-Logik wäre es bei AMD weiterhin nur 5120 ALUs. Das liegt am Aufbau der CU bei AMD seit GCN und nun eben RDNA2.
Auch ist es bei NVIDIA kein Trick, wie man nun auf die 10752 Shader beim GA102 kommt, weil diese ALUs sind wirklich vorhanden, genau so wie bei AMD die 5120 ALUs wirklich vorhanden sind.
Es geht hier dabei, wie die ALUs organisiert werden. Bei AMD hatte zu GCN-Zeiten jede CU nominell 64 ALUs, die sich auf 4 Vecktor-ALUs aufgeteilt haben. Jede der 4 Vektor-ALUs konnte 16 Werte aufnehmen (Vec16). Jede dieser Vec16-ALUs konnte dabei mit einem eigenen Befehl angesprochen werde. Zum Beispiel kann bei Vega eine Vec16-Einheit ein ADD auf INT-Werte berechnen, während die zweite Vec16-Einheit ein MUL auf FP-Werte berechnet, die dritte dann ein SUB auf FP-Werte und die Vierte ein ADD auf FP-Werte. Diese Flexibilität hat dazu geführt, dass GCN als ganzes, nur schwer ausgelastet werden konnte. Es gab/gibt zwar alternative "Modi", diese funktionieren aber nicht wirklich. Bei RDNA und nun RDNA2 hat AMD die CU umgebaut und die 4 Vec16-ALUs durch 2 Vec32-ALUs ersetzt. Jede CU kann bei RDNA und RDNA2 zwei voneinander unabhängigen Befehle ausführen. Eine Vec32 berechnet z.B. ein SUB auf INT-Werte, die andere Vec32 ein MUL auf FP-Werte. (Deswegen hat AMD bei GCN stärker von Asynchronen-Shadern profitiert als NVIDIA bis einschließlich Pascal)
NVIDIA war es bisher so, dass auf einer SM nur ein Befehl ausgeführt werden konnte und dieser Befehl sich über alle 128 ALUs (Maxwell und Pascall) erstreckte. Bei Turing hat NVIDIA diese 128 ALUs in zwei Blöcke geteilt a 64 ALUs und dabei einen Pfad »exklusiv« für INT reserviert. Seit Turing kann jede SM zwei voneinander unabhängige Befehle ausführen, aber mit der Fixierung, dass einer der beiden Befehle nur INT-Werte berechnen konnten. Deswegen wurde bei Turing auch nur die 64 Shader pro SM angeben, obwohl es eigentlich immer noch 128 waren. (Deswegen profitierte Turing auch von Async-Shader bereits »besser«).
Bei Ampere hat man nun diesen bisher fixierten INT-Block auch für FP-Berechnungen geöffnet. Bei Ampere kann jede SM - wie bei Turing - 2 Befehle zur gleichen Zeit ausführen. Der erste 64er-Block führt ein SUB auf FP aus, der zweite 64er-Block ein MUL auf FP. Das war bis Ampere eben nicht möglich, wäre so etwa gekommen, hätte alles bis jetzt bei NVIDIA 2 "Takte" benötigt, jetzt gehts eben zusammen.
Oder um dir das vereinfacht darzustellen, was zur gleichen Zeit pro CU oder SM möglich ist:
Operationen | GCN | RDNA | Pascal | Turing | Ampere |
ADD(FP) | Ja | Ja | Ja | Ja | Ja |
ADD(INT) | Ja | Ja | Ja | Ja | Ja |
ADD(FP) + ADD(INT) | Ja | Ja | Nein (2 »Takte«) | Ja | Ja |
ADD(FP) + MUL(FP) | Ja | Ja | Nein (2 »Takte«) | Nein (2 »Takte«) | Ja |
ADD(INT) + MUL(INT) | Ja | Ja | Nein (2 »Takte«) | Ja | Ja |
Der Unterschied einer NVIDIA SM zu einer AMD CU liegt nun daran, wie viele Werte pro Befehl berechnet werden können. Bei AMD können pro Befehl 32 Werte berechnet werden (muss mal den Alternativ-Modus noch testen), bei NVIDIA sind es 64 Werte pro Befehl und da liegt dann auch die Crux etwas begraben für NVIDIA und ist auch der Grund, warum selbst in »FP«-lastigen Engines die GeForce 3080 trotz 100 % mehr Shader und 15 % mehr Takt als die 2080 Ti nicht 100% schneller ist, sondern eben nur die 30 %.
NVIDIA muss nun pro SM 2 Befehle mit je 64 Werten füllen, AMD muss pro CU 2 Befehle mit nur 32 Werten füllen und letzteres ist ein Stück »einfacher«. NVIDIA hat mit Ampere im gewissen Sinn ein »Auslastungsproblem«.
Wadenbeisser schrieb:
Wenn man nur mal auf den Reiter "Home" geht anstatt gleich auf die Seite der Einstellungen zu hopsen ist es sogar noch etwas einfacher, hier mal als Beispiel von einem anderen Rechner.
Danke für den Hinweis, das weiß ich aber selbst:
Teralios schrieb:
Da aber passend Querverweise gesetzt sind, ist die GUI intuitiv zu bedienen.
Ich kenne die Querverweise in den Reitern, womit man sehr schnell zu allen wichtigen Einstellungen kommt.