News Windows und Linux: FSR 4 läuft dank Leak auf RX 7000, 6000 und GeForce RTX

[DoedelFIX]

DoedelFIX teilt Erfahrungen mit Intel Arc A750: XeSS und FSR 4 sind in seinem Test (Hell of Us) ebenbürtig.

Jan, wer kennt das Spiel nicht Richtig "Hell is US".

 

[Yazzwing]

@Mystery1988
Hattest du das mit der modifizierten .dll nachträglich überschrieben?

Download:
https://gofile.io/d/NkQU5X

Was Du noch ausprobieren könntest, das du DLLS anwählst und das darüber spoofst. Woran es liegt, das es bei dir nicht so will - weiß ich leider nicht :/

Eine "Idee" bzw. Ansat wäre noch, das der AMD Treiber in jedem Fall der aktuelle aus September sein sollte. Vermute aber mal das du den schon drauf hast?

 

[DITTY]

Die Ausführung eines kompatiblen Modells auf Basis von INT8 kostet i.d.R. persé nicht mehr Leistung als das gleiche auf Basis von FP8.

INT-Datentypen sind sogar grundlegend performanter, da keine Floating-Point-Arithmetik nötig ist.
INT-Datentypen oder hier eher -Tensoren weißen aber oftmals mehr Ungenauigkeiten gegenüber ihren FP-Pendants auf, genauer gesagt schlägt sich das im Vergleich auf die Accuracy und Precision des KI-Modells nieder. Das wäre aber egal, wenn man das Modell derartig trainieren lässt und mit Daten füttert oder hinter optimiert, dass die Accuracy und Precision bzw. Kreuzvalidierung, also insgesamt die Zuverlässigkeit des INT8-Modells sich nicht groß von den Metriken des gleichen mit FP8 trainierten Modells unterscheidet.

Wenn das Modell mit FP8 trainiert wurde oder dafür optimiert ist, kann der Einsatz von INT8 ohne neue Trainings und Modell-Optimierungen zu Ungenauigkeiten führen, die anderweitig in Software ausgeglichen werden müssen. Denn das Modell liefert dann einfach ungenauere Ergebnisse und manche Anwendungen dessen müssen erneut angestoßen werden, bis ein zutreffenderes Ergebnis heraus kommt. Diese zusätzlichen Anwendungen kosten bei der Inferenz Zeit und somit insgesamt Leistung (weniger Frames etc.). Die Ungenauigkeiten wiederum sorgen für Grafikfehler.

Auch bietet nicht jede GPU nativen, d.h. hardwarebeschleunigten Support für INT8- oder FP8-Tensoren an. Diese müssen dann aus anderen Tensor-Typen (z.B. INT16 und FP16, etc.) zusammengesetzt und / oder in Software nachgebildet werden, was (a) unnötigen Speicherbedarf bedeutet und (b) mehr Rechenzyklen erfordert im Vergleich zu einer nativen hardwarebeschleunigten INT8- und / oder FP8-Tensoren-Ausführung. Aber dann mangelt es an dieser Stelle an der Hardware, weniger der Software-Unterstützung.
Auch können TypeCasts von FP8 zu INT8 Performance kosten, sollten sie angewandt werden.

Und genau deshalb erscheint es hier, dass die INT8-Modell-Ausführungen Performance kosten. Es liegt aber nicht am Vergleich der Tensor-Typen, wie hier behauptet oder zumindest suggeriert, sondern an den Hardware-Einschränkungen älterer Generationen, ihren Treiber-APIs, ihren SDK-APIs und womöglich an mangelnden (Re-)Trainings und Modelloptimierungen für INT8 des bestehenden Modells. Denn nur durch Neukompilierung alleine, wird kein Modell trainiert und / oder optimiert. Daher mag ein Neukompilat zu einer neuen DLL ohne Modelltraining und / oder Modellanpassung und diese dann einfach zu ersetzen zwar irgendwie funktionieren, aber zu Lasten der Performance und Zuverlässigkeit, je nach Use Case und erforderlicher Use Case-Zuverlässigkeit.

INT an sich gewinnt aber in den allermeisten Fällen immer vor FP, wenn es um Performance geht. Außer man braucht zwingend mehr Genauigkeiten für bestimmte Use Cases. Dann kommt man aber mit 8-Bit alleine nicht weiter. Dann wird man entweder aus 8-Bit-Typen höher-bittige Typen zusammensetzen und mit Funktionalitäten ergänzen müssen oder aber man nimmt native höherbittige Tensor-Typen wie INT16/FP16, INT32/FP32 oder INT64/FP64. Deren Ausführung und Speicherbedarf sind aber immer leistungshungriger als nieder-bittige Tensor-Typen. Und nicht immer braucht man dieses Mehr an Genauigkeiten. Genau deshalb hat man im späteren Verlauf zunächst in Software abgebildet INT8/FP8 entwickelt und bereitgestellt und dann diese später nativ in Hardware bei neueren Generationen integriert.

 

[Andy4]

Heißt also: Wir haben keine Lust, so viel nachzuarbeiten. Das gibt unsere mögliche Arbeitskapazität nicht her?

 

[Czk666]

Die geleakte Fsr 4 Version soll eine ältere sein?
Das sollte vielleicht noch dazu erwähnt werden.

 

[mario_mendel34]

Die geleakte Fsr 4 Version soll eine ältere sein?

Optiscaler zeigt 4.0.2 an, das ist die aktuelle.

 

[Northstar2710]

Die geleakte Fsr 4 Version soll eine ältere sein?

? es ist 4.02. gibt es etwas neueres?

 

[Yazzwing]

Gibt tatsächlich 2 Versionen. Eine aus dem Leak und eine aus dem SDK.

Dürfte aber für die meisten RDNA3 Besitzer (unter Windows) - zumindest derzeitig - eher von irrelevanter Natur sein.

Die aus dem SDK wurde u.a für den FP8-on-FP16-Hack genutzt; die zurückgebaute aus dem Leak für die INT8.

 

[Northstar2710]

Gibt tatsächlich 2 Versionen

und wie unterscheiden sie sich? Ausser das die eine für RDNA3 ist und die andere für RDNA4 war? Denn der Leak des SDK war nur 2std online, danach kam das bereinigte SDK online. Und die jetzige dll beruht wohl auf den Dateien des Leaks.

 

[frames p. joule]

Wer hätte das gedacht, vielleicht verlängert das das Leben meiner 6900XT

 

[Windell]

@frames p. joule Leider nicht, da es auf RDNA2 nicht gut funktioniert.

 

[xpad.c]

Der Vorwurf lautet, dass man sehr wohl weiß das FSR4 auch auf älteren Karten läuft, die Funktionalität bei AMD verfügbar ist aber man Anfangs behauptet hat diese FUnktionalität wäre technisch garnicht möglich, nach einem Shitstorm dann zurückgerudert hat und rumdruckste, keine Versprechungen machen wollte etc.

Nichts davon wurde behauptet. Sie haben es offen gelassen und weder dementiert noch bestätigt.

Und jetzt stellen wir fest dass es relativ unproblematisch funktioniert. Das ist halt unsaubere Kommunikation und schlichtweg Kundentäuschung. Die technischen Gründw warum FSR4 nicht laufen würde, gibt es nicht. Und man braucht mir nicht erzählen das AMD das nicht von Anfang an gewusst hätte.

Meine Güte, geht es eine Nummer kleiner? Lies diesen Artikel, der legt detailliert dar, dass FP8 nicht "relativ unproblematisch funktioniert", sondern eine erhebliche Menge Würgarounds (ja, mit ü und g) erfordert und daher NICHT klar ist, ob man das "einfach so" offiziell rausgeben kann.

Ich bin einigermaßen sicher, dass Leute wie Du genau die Allerersten wären, die dann am Ende ein (anderes) Fass aufmachen würden, wenn es offiziell unterstützt würde und es plötzlich irgendwo Probleme gäbe. Also mal den Ball bisschen flach halten.

xpad.c

 

[LukS]

Mit The Finals und einer Vega56 probiert, Game ist gcrasht und hat erstmal validiert^^

Sollte logisch sein, weil Finals ein ziemlich agressives Anticheat implementiert hat.
Außerdem riskierst du damit einen Ban.

 

[cietho]

The Last Of Us Part II in 4K mit FSR4 und einer 7900XTX läuft unter Linux butterweich und sieht top aus 😍

 

[SavageSkull]

Ältere Generationen erhalten aber nicht alle DLSS4 Features.

Upscaling DLSS schon. Nur keine Fake Frames und sonstiges.

 

[MaW85]

Habe jetzt mal Warhammer 40K Darktide mal durchgetestet und mir kommt es so vor, das die hohen Qualitätseinstellungen sehr gut Skalieren, gerade FrameGeneration dazu funktioniert echt gut, was ich sonst immer bemängelt habe. Ja es gibt noch einige Ghostings durch FSR4, aber nur vereinzelnt, aber es stört nicht, gerade weil das Spiel so schnell ist.
4K Hohe Einstellungen und LOD 5(kein Raytracing) mit FG, sieht schon echt sehr gut aus. Das Bild ist echt sehr scharf und die Kantenglättung/Scalierung funktioniert super.
Das Spiel hat ja Probleme die GPU richtig auszulasten, da hängt man meist bei 80% auch wenn die Welt brennt.
Jetzt fast meist über 95%

XeSS Qualität

Vs.FSR4 Qualität

FSR4 Qualität (man beachte die Gitter)

 

[T-Horsten]

The Last Of Us Part II in 4K mit FSR4 und einer 7900XTX läuft unter Linux butterweich und sieht top aus 😍

Unter Windows 11 auch. Bei Star Wars Outlaws funzt es ebenfalls, wird aber noch als FSR3 in den Einstellungen angezeigt.

 

[Czk666]

Böses AMD.

"FSR Redstone was developed using AMD ML2CODE (Machine Learning to Code), a research project from ROCm. The core part of the neural rendering technology is converted into optimized Compute Shader code by utilizing ML2CODE. This means that FSR Redstone's neural rendering core can also run on GPUs made by other companies."

https://wccftech.com/amd-fsr-redstone-might-not-just-be-limited-to-radeon-gpus/

 

[Raptor85]

Denke, nach so viel Wirbel würde es AMD schaden, FSR 4 am Ende zumindest für RDNA 3 zu sperren, wenns eigentlich ganz gut läuft (auch wenn gewisse Spiele ggf. nicht so gut performen).

Man verliert ja nicht wirklich was dadurch, das dann offiziell verfügbar zu machen.
Wer jetzt noch ne 7900 XT oder XTX hat, wird wohl so oder so nicht auf RDNA 4 wechseln.
Und bei Neukauf würde ich auch die neuere Architektur vorziehen. Und wer mehr VRAM braucht, wird dann wohl bald eher zu einer 5070 Ti Super greifen als zu ner gebrauchten 7900 XTX nur wegen einem ordentlich, aber nicht perfekt laufenden FSR 4.

Also AMD, macht es offiziell. Frickellösung ist okay, aber direkt per Treiber ist besser.

 

[Yazzwing]

Mist das ich heute früh Linux dahingehend schon von der Festplatte geworfen habe.

Bin aber auch ganz froh drüber. War eine sehr interessante Zeit, aber leider auch teilweise ein übelstes Gefrickel. Die Windows Lösung gefällt mir um einiges mehr.

Im Nachhinein betrachtet wäre ein Bildvergleich zwischen der INT8 Version und der FP8-on-FP16 echt interessant gewesen.

@DITTY
Uff, krasse Erläuterung ! (Im positiven Sinne)