mastermc51 schrieb:
Bitte bewirb dich bei der Redaktion oder notfalls der Konkurrenz
Selten so Texte von jemand gelesen der versteht um was es geht...
(das ist ERNST GEMEINT!)
Danke für die Blumen, aber mein aktueller Job - in dem ich die Teile halt programmiere - füllt mich da doch ganz gut aus ^^
(Ich war mir erst unsicher, ob ich es erwähnen sollte, weil sicher nicht der beliebteste Job hier ... aber ich programmiere halt Mining-Software - da muss man sehr nahe dran an den Hardware-Architekturen sein um etwas zu reißen ^).
Insgesamt halte ich Aufgrund der vorliegenden Informationen AMDs Darstellung durchaus für realistisch, dass man FSR 4 halt auf Matrix Arithmetik (vermutlich viel int4) aufgebaut hat und diese bei Grafik-Ausgabe gut nebenher ackern muss, um die Zwischen-Frames zu erzeugen. Wenn nun RDNA 4 in genau dem Bereich einen Sprung zu RDNA 3 macht, dann erklärt das sehr gut, wieso es am Anfang nur exklusiv für die neuen Karten kommt.
Wie gesagt, RDNA 2 und 3 waren in dem Bereich absolut nicht schlecht oder langsam - die Rohleistung war durchaus da, aber man konnte sie halt nicht neben normaler Raster-Arithmetik laufen lassen, so dass die neuen RDNA 4 Instruktionen nun entweder echt parallel laufen oder aber sehr viel schneller sein müssen als bei RDNA 3.
Interessant wird, ob man das ganze - wenn es denn auf den High End RDNA3 Karten läuft - auch irgendwie auf RDNA 2 zum laufen bekommen kann. Denn die Rohleistung (int4) ist wie gesagt pro Compute Unit die Gleiche - was sich ändert ist aber der Datenstrom - wenn man je Shader eine Matrix-Zeile verarbeitet, muss man über die Skalar-Register die Spalten der zweiten Matrix zuführen (bei RDNA 2... nicht so bei RDNA 3). Es würde also wieder ein neuer Code werden, ob man sich die Arbeit am Ende macht bleibt abzuwarten. Anders sieht es bei der Rohleistung in fp32 aus, da können die dual-ops bei RDNA 3 das doppelte durchsetzen als bei RDNA 2 - wenn man denn die Restriktionen alle auf die Kette bekommt.
Dies ist leider ein kleines AMD Problem im Generellen. Diese Karten haben allesamt recht gute Featuresets und insbesondere eine brutale Rohleistung - aber nur wenn alles passt. Leider schaffen es die meisten standard-Codes durch den LLVM Compiler gejagt nicht immer das auch alles auszunutzen - man braucht immer recht viel Handarbeit / Inline Assembler um alles raus zu holen. Daher hat man hier aber auch so viele Release-Treiber, die dann bei beliebten Spielen die Leistung noch mal deutlich anheben - dort kommen die meisten Shader ja als Quelltext beim Compiler and und der macht dann erstmal. Die späteren Treiber tauschen diese Shader dann aber gegen optimierte aus dem Treiber aus und die laufen oftmals viel besser.
Das ist der eine Punkt, den Nvidia leider besser im Griff hat - aus einem einfach gehaltenen Standard-Code einen ordenltichen GPU Code zu kompilieren, der dann schon sagen wir 95% der möglichen Performance bietet. Zur Nutzung der Tensoren muss man aber auch hier selber Hand anlegen, insgesamt ist es aber einfacher schnell auf Speed zu kommen - bei AMD reift die Software gerne mal etwas länger von Release zu Release.
