AMDs FidelityFX Super Resolution 2.0/3.0/4.0 (FSR 2.0, FSR 3.0, FSR 4.0)

[Lurtz]

Ich habe das auch im Remake. Das würde eher dafür sprechen, dass bei mir irgendwas verdreht ist, wüsste aber nicht was.

[aufkrawall]

Tja, seltsam. Ich hatte schon mal das exakt gleiche Fehlerbild mit DLSS via Mod in Skyrim gesehen, da hatten die Bäume vor bestimmten Bereichen der Skybox auch vergleichbar rumgezittert. Und auch an bestimmten Stellen der Spielwelt in HZD.

[Lurtz]

Scheint ein spezifischer Bug zu sein. Passiert offenbar beim Umschalten der Upscaler/Renderauflösung.

Gerade hatte ich es nur mit DLSS Quality, alle anderen Auflösungspresets haben funktioniert. Mit FSR Input lief es einmal mit allen Presets, manchmal geht es aber auch komplett kaputt...

Edit: Im Remake geht DLSS als Input, in Teil 2 nicht. Dafür habe ich beim Umschalten einen neuen Bug ausgelöst, bei bei dem die Vegetation extrem ghostet :ugly: Also irgendwas an der Implementierung der Upscaler ist ganz komisch in dem Spiel :D

[robbitop]

Muss mich korrigieren, laut Radeon Software ist das per default kompatibel mit FSR4.

Mit fakenvapi geht aber auch Optiscaler
Wie kriegst du das hin? Sobald ich Optiscaler installiere blockiert Battleye das Spiel wegen der dxgi.dll. Und ohne Battleye startet das Spiel auch nicht (-nobattleye option in Steam , battleye ausschalten im RS launcher

[Andron]

Wie kriegst du das hin? Sobald ich Optiscaler installiere blockiert Battleye das Spiel wegen der dxgi.dll. Und ohne Battleye startet das Spiel auch nicht (-nobattleye option in Steam , battleye ausschalten im RS launcher

Ich hatte das gleiche Problem allerdings auch mit AMD-GPU (9070 XT):
-nobattleye ist notwendig, allerdings startet GTA dann nicht. wie Lurtz schon schrieb, funktioniert es aber problemlos mit der fakenvapi Mod.

Mit deiner Geforce funktioniert das nicht? Ich kann es erst später auf dem Laptop testen.

[Lurtz]

Wie kriegst du das hin? Sobald ich Optiscaler installiere blockiert Battleye das Spiel wegen der dxgi.dll. Und ohne Battleye startet das Spiel auch nicht (-nobattleye option in Steam , battleye ausschalten im RS launcher
Du musst das vornehmen, dann startet es mit Optiscaler: https://github.com/cdozdil/OptiScaler/wiki/Fakenvapi

Edit:
Sorry, ist noch früh... Mit Geforce ergibt Fakenvapi natürlich keinen Sinn. Könnte ich erst wieder testen, wenn ich die 4070 wieder eingebaut habe. Aber eigentlich braucht man Optiscaler mit Geforce auch nicht, weil da alles ootb läuft :uponder: Höchstens für Optiscaler FG.

[robbitop]

Genau ich wollte das OptiFG testen - fakenvapi macht ja für geforce 3000 eigentlich keinen Sinn - ich wüsste auch nicht was das daran ändern soll, dass Battleye die dll sperrt (und ohne Battleye startet das Spiel nicht -> ergo keine Option). DLSS 4 K ist über den Inspektor erzwungen.

[Lurtz]

Ist das ein Gefrickel, ich liebe es :usweet: Man kann Optiscaler natürlich auch über andere Mods installieren, die temporales Upsampling bereitstellen - zB über die REFramework Mod oder über die temporale Upsampler-Mod für Elden Ring :D Ist natürlich die Frage, ob das dann auch dauerhaft stabil ist...

An RDR2 über Rockstar Launcher beiße ich mir aber die Zähne aus. Als DLL lädt Optiscaler nicht und als asi mit ASI-Loader gibts einen GFX-Error beim Start mit DX12.
Snowdrop (Avatar, Outlaws) crasht leider ingame.
Alan Wake 2 funktioniert theoretisch, bekomme ingame aber nur ein schwarzes Bild, wahrscheinlich geht da mit FG was schief...

Hoffentlich kommt bald eine Vulkan-Version von FSR4...

[robbitop]

RDR2 geht Optiscaler in der Epic und Steam Version. Die Rockstar Version lässt keine Änderungen zu. Aber OptiFG crasht dann sofort bei mir sobald ich es anschalte.
Mit Vulkan in RDR2 startet hingegen Optiscaler nicht - das OSD läd beim Drücken der EINFÜGEN Taste nicht. Egal welche Installationsmethode.

[Lurtz]

Lag am Optiscaler-Build, mit dem Testbuild geht es jetzt in RDR2.

Hier ist FSR4 DLSS K aber deutlich unterlegen. Wesentlich instabiler und dabei unschärfer. RDR2 ist aber auch eines der beeindruckendsten Ergebnisse mit Preset K.
FSR 3.1 ist einfach nur absurd schlecht ;D

AW2 liegt auch daran, da crasht der Testbuild aber den ganzen Treiber.

[raffa]

RDR2 ist ja auch der (TAA) worstcase - Es flimmert ohne wie Hölle, und mit wirds unspielbar blurry :D

Da brauchts entweder Downsampling oder viel KI Magie, damit da wieder ein ordentliches Bild draus wird.

[DrFreaK666]

Was mache ich falsch? Sollte ich nicht einen zusätzlichen Reiter haben, wenn ich oben FSR 3.X wähle?
https://i.postimg.cc/DZ36KQwm/hm.jpg (https://postimg.cc/B8NHTKDG)

[Achill]

Was mache ich falsch? Sollte ich nicht einen zusätzlichen Reiter haben, wenn ich oben FSR 3.X wähle?
https://i.postimg.cc/DZ36KQwm/hm.jpg (https://postimg.cc/B8NHTKDG)

Nach der Auswahl von FSR 3.X auch "Apply" darunter drücken ... die UI ist leider nicht immer gleich im Verhalten. Eine Checkbox hat oft direkt eine Auswirkung, die Buttons muss man i.d.R. drücken, einige wie z.B. das MipMap werden erst nach Neustart / Änderung der Auflösung aktiv,

[Lurtz]

Was mache ich falsch? Sollte ich nicht einen zusätzlichen Reiter haben, wenn ich oben FSR 3.X wähle?
https://i.postimg.cc/DZ36KQwm/hm.jpg (https://postimg.cc/B8NHTKDG)
Wenn es funktioniert muss nach Auswählen von FSR 3.X und drücken auf Apply unten eine Sektion mit FSR-Settings erscheinen.

[w0mbat]

Ich denke du hast die FSR4 .dll nicht im Spiele-Ordner,

[DrFreaK666]

Ich habe natürlich auf Apply gedrückt.
habe tatsächlich keine FSR4-Datei im Ordner. War auch keine in der OptiScaler-Zip.

Hier gibts auch keine FSR4-Dingsbums-Datei
cz2kCCIdLws

[Achill]

Die dll für FSR4 stammt vom AMD 25.3.1 Treiber. Diese Datei muss man im ./Windows Verzeichnis suchern und dann von dort in das Spieleverzeichnis, wo auch OptiScaler ist, kopieren.

Bei der neuen Version muss man im der INI auch noch FSR4 aktivieren und für Win10 auch das nötige Update. Bin aber dann keinen PC, kann also nicht nachschauen ...

[Colin MacLaren]

Was mache ich falsch? Sollte ich nicht einen zusätzlichen Reiter haben, wenn ich oben FSR 3.X wähle?
https://i.postimg.cc/DZ36KQwm/hm.jpg (https://postimg.cc/B8NHTKDG)

Hab es hier zusammengefasst:

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13724401#post13724401

[DrFreaK666]

Bei FF XVI hats sofort funktioniert.
@Colin MacLaren Thanks

[Lurtz]

Für die Hälfte des Preises ist die 9070XT daher imho eine spannende Alternative zur 5080, zur 5070 TI sowieso.

Was halt wirklich fehlt, sind Ray Reconstruction und eine nutzbare Pathtracing-Performance. Ray Reconstrcution soll noch kommen. In Hogwarts Legacy sehe ich hier definitv einen Unterschied, weniger Krisseln im Haar und deutlich detaillierter Reflexionen. Bei Path Tracing kommt es auf die Spiele an und was man selbst bevorzugt. Bei den Pathtracing-Titeln habe ich Cyberpunk schon durch, Alan Wake 2 und Indy interessieren mich nicht, Star Wars Outlaws und Black MYtgh Wukong sind eher weiter hinten in der "Vielleicht"-Ecke des Backlogs.
Dank FSR3 FG und 16 GB VRAM kann sich die Karte mit PT etwas von der 4070 absetzen - aber viel ist es nicht. Außerdem fehlt eben Ray Reconstruction, und das macht PT in Alan Wake 2 zB schon sehr unsauber. Lohnt sich nicht so wirklich.

Aber ja, CP 2077 damit durch, AW2 auch zwei Mal, für Indyd hat der 4070 der VRAM gefehlt und Outlaws und BMW sind ebenfalls irre teuer für zweifelhafte Vorteile. Demnächst kommt dann die HL2-"Techdemo". Die Frage der Relevanz stellt sich da schon...

In RT ist die 9070 XT natürlich deutlich schneller als die 4070.

[aufkrawall]

In GTA V geht der Treiber-Override nicht, gibt keinen grünen Haken im Radeon-Overlay.
Zumindest nicht mit der spieleigenen amd_fidelityfx_dx12.dll ohne AMD-Signatur. Ersetzt man die kurz nach Starten des Spiels im Rockstar-Launcher mit der von AMD/OptiScaler, wird der Haken grün. Es sieht aber weiterhin beschissen aus.
Mit mit dem Trick und OptiScaler FSR 3.1 -> 4 anstatt Treiber-Toggle siehts dann (wirklich) gut aus...

[DrFreaK666]

Das ist ja auf DX12 beschränkt, oder?

[Lurtz]

Nicht zwingend, einige DX11-Titel funktionieren mit FSR3 w/Dx12. Vulkan geht bisher nicht.

[DrFreaK666]

Also bei God of War gings jedenfalls nicht

[robbitop]

In GTA V geht der Treiber-Override nicht, gibt keinen grünen Haken im Radeon-Overlay.

GTA5 hatte iirc auch nur FSR3(.0). Das war doch nicht upgradebar über den Treiber und/oder. Also nicht verwunderlich oder habe ich was verpasst? :)

[aufkrawall]

Ist nur eine einzelne DLL, dürfte entsprechend 3.1 sein. Sieht auch wie mit 3.1 erwartbar grausam matschig aus. Und mit 3.0 würd der Treiber nicht FSR 4 verfügbar melden.

[robbitop]

Aber iirc waren die dlls durch Austausch nicht (sauber?) upgradebar vor 3.1. (hat dann 3.1 gemeldet aber ggf waren Details der Schnittstellen oder Formate anders - würde zumindest den Unterschied mit Optiscaler erklären.)

[Lurtz]

Also bei God of War gings jedenfalls nicht
Geht schon. Muss man halt minimale Mühe investieren und mal in der Wiki (https://github.com/user-attachments/assets/c1abc93c-2727-4985-a2b7-25ed230c20bc) nachlesen...

[DrFreaK666]

Geht schon. Muss man halt minimale Mühe investieren und mal in der Wiki (https://github.com/user-attachments/assets/c1abc93c-2727-4985-a2b7-25ed230c20bc) nachlesen...

Thanks

[aufkrawall]

In Talos 2 scheint definitiv der FSR Q-Input kaputt zu sein, auch bei schnellen Drehungen pixelt das immer mal wieder rein. Ist mit Balanced nicht der Fall. Performance wohl auch nicht, wobei mir das die Vegetation in Bewegung zu sehr vermatscht. Mit 4k Balanced sieht es aber für Nanite-Verhältnisse imho gut aus, kein Vergleich zu TSR oder XeSS.
Keine Ahnung, obs an der Kombi mit OptiScaler liegt. Aber das FSR 3.0 FG funktioniert völlig müllig ruckelig im Vergleich zu OptiFG.

Btw. spooft OptiScaler mittlerweile offenbar unter jedem Dateinamen eine Nvidia-GPU. Würd ich für FSR-Input üblicherweise ändern.

[Relex]

Warum "input"?

Hardware Unboxed hat doch im Video auch schon festgestellt, dass FSR4 im Quality Modus teilweise mehr Probleme macht, als im Balanced Modus. Sieht man im Video auch sehr deutlich, wenn es demonstriert wird.

Scheinbar hat AMD da irgend nen parameter falsch gesetzt oder irgend ein Filter Schritt wird übersprungen. Das wird sicher bald gefixed.



Ansonsten ist der Content (oder was anderes?) in Talos 2 sowie im Teil 1 Remake aber auch ziemlich müll. Kaum ein Upscaler kann die Vegetation, insbesondere die Bäume ordentlich bearbeiten.
Wenn man das mit Avowed vergleicht, dann sind das Welten. In Avowed sieht es sehr ordentlich aus (wenn auch nicht perfekt) und bei Talos hat man überspitzt ausgedrückt selbst mit DLSS3 und DLSS4 im Quality Modus den Eindruck als hätte man FXAA aktiviert. Auch TSR versagt total und selbst nativ TAA ist nicht wirklich "gut".
Das Bild ist zwar mit DLSS okay und sogar noch am schärfsten, aber zufriedenstellend ist was anderes.

Könnte mir vorstellen, dass FSR4 damit sogar recht gut klar kommt (wegen gutem disocclusion handling).

Dass den Entwicklern nicht auffällt, dass das schlecht aussieht... Muss man nicht verstehen.

[aufkrawall]

Wäre sehr seltsam, wenn das etwas mit der Verarbeitung durch FSR 4 selbst zu tun hätte, bei der offensichtlichen Kaputtheit:
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13726042#post13726042

Und ich habe hier mit 4k auch sonst noch nicht gesehen, dass Q schlechter als B und P aussehen würde.

[Relex]

Aber das HUB Video hast du dir angesehen? Da wird es z.B. in Spider-Man gezeigt.

[aufkrawall]

Das ist doch überhaupt nicht vergleichbar. Da gehts um Zäune etc., und nicht völlig zufällig kaputtgehende riesige Bildbereiche.
In der Talos 1-Demo gibts hier das Problem mit Q auch nicht.

[Relex]

Schon klar, aber HUB spricht von Problemen mit feinen Strukturen bei FSR Q die nicht bei Balanced oder Performance auftreten.

Du sprichst von Problemen mit FSR Q bei Gras (ebenfalls feine Strukturen) die bei FSR Q und nicht mit Balanced oder Performance auftreten. Klar, es sieht anders aus, aber trotzdem ein starkes Indiz.


Die Wahrscheinlichkeit, dass es die selbe Ursache ist ist doch offensichtlich sehr hoch. Da brauchste ja nur 1 und 1 zusammenzählen.


Kann natürlich sein, dass es hier zufällig am Spiel liegt und es zufällig NUR FSR4 betrifft und auch NUR im Quality Modus und das nichts mit dem zu tun hat, was HUB festgestellt hat...
Kann sein. Aber warum schließt du die offensichtlichste und wahrscheinlichste Erklärung direkt aus?

[aufkrawall]

Da brauchste ja nur 1 und 1 zusammenzählen.

Auf welches Ergebnis du bei dieser Rechnung kommst, wäre dann noch interessant. :freak:
Es sieht in Talos 1 mit Q eindeutig besser aus in der Vegetation als mit B oder P...

[Lurtz]

Ich teste dann nochmal Hellblade 2 mit Balanced vs Quality. Wenn das mit Balanced besser aussehen sollte, liegt es wahrscheinlich an dem von HWU beschriebenen Bug.

Würde bei Talos dennoch von einem Input Problem ausgehen. Beim Umschalten zwischen Upscalern kommt da wie gesagt noch zu ganz anderen Müll raus teilweise.

[Relex]

Wie gesagt, ich wills ja nichts ausschließen.

Aber ein Fehler wie hier, dass Quality schlechter aussieht, als Balanced ist so spezifisch, "besonders" und seltsam, dass die Wahrscheinlichkeit doch sehr gering ist, dass dieses Problem zweimal auftritt aber zwei völlig unabhängige Ursachen hat.

Erstrecht wenn es nur mit FSR4 auftritt.

[DrFreaK666]

Hab mal bei GoW verschiedene Upscaler getestet.

FSR 2.3.2
https://i.postimg.cc/JDCCjDRq/FSR-2-3-2.png (https://postimg.cc/JDCCjDRq)

FSR 3.1.3
https://i.postimg.cc/Vr9Qgf6c/FSR-3-1-3.png (https://postimg.cc/Vr9Qgf6c)

XeSS
https://i.postimg.cc/4K9TKbRy/XeSS.png (https://postimg.cc/4K9TKbRy)

FSR4
https://i.postimg.cc/SYy0tB2Y/FSR-4-0-0.png (https://postimg.cc/SYy0tB2Y)

[Lurtz]

Relex hat Recht, das scheint der FSR4 Quality-Bug zu sein. Wenn man in Hellblade 2 Quality nutzt, pixelt Gras genau wie in TP2 an manchen Stellen auf bei schnellen Kameradrehungen. Ist mit Native AA, Balanced und Performance komplett weg (FSR3 Input).

[Lurtz]

Btw. spooft OptiScaler mittlerweile offenbar unter jedem Dateinamen eine Nvidia-GPU. Würd ich für FSR-Input üblicherweise ändern.
Welche Option ist das in der INI? Die aktuelle Nightly fragt bei der .bat jetzt, ob man DLSS nutzen will, vermutlich wird es dann wieder deaktiviert?

[Lurtz]

Das Edge-AA von FSR4 ist richtig schlecht in Bewegung in Robocop.

https://s1.directupload.eu/images/250315/ro8v9hn5.jpg

https://s1.directupload.eu/images/250315/ls9mt85y.jpg

[aufkrawall]

Relex hat Recht, das scheint der FSR4 Quality-Bug zu sein. Wenn man in Hellblade 2 Quality nutzt, pixelt Gras genau wie in TP2 an manchen Stellen auf bei schnellen Kameradrehungen. Ist mit Native AA, Balanced und Performance komplett weg (FSR3 Input).
Schon mal mit 4k Output via VSR getestet?

Welche Option ist das in der INI? Die aktuelle Nightly fragt bei der .bat jetzt, ob man DLSS nutzen will, vermutlich wird es dann wieder deaktiviert?
[Spoofing]
; -------------------------------------------------------
; Spoofed GPU name
; Default (auto) is NVIDIA GeForce RTX 4090
SpoofedGPUName=auto

; Enables Nvidia GPU spoofing for DXGI
; true or false - Default (auto) is true
Dxgi=auto

Btw. FSR 3 Input in Aveum sieht aus wie Müll, mit DLSS Input siehts dann gut aus.

In Talos 1 ist der Unterschied so nicht gegeben, aber scheint mit DLSS Input trotzdem etwas stabiler und weniger smeary. Nutzt aber auch weniger negatives Mip Bias als FSR, für Nanite sicherlich klüger.
Sieht so doch erstaunlich gut aus für 1080p Renderauflösung. Längst nicht perfekt, aber smeart etwa auch massiv weniger als Preset E:
https://s1.directupload.eu/images/250316/temp/qopnd9g6.jpg (https://www.directupload.eu/file/d/8860/qopnd9g6_jpg.htm)

(Transparenz von Vegetation sieht in Indy + PT btw. aus wie der letzte Müll im Vergleich... ;D )

Edit: Ich sehe das Problem mit Q jetzt auch, in Remnant 2 mit 4k Target und dem offiziellen Treiber-Toggle. Also stimmt, der Q-Modus ist noch verbugt.

[Lurtz]

Schon mal mit 4k Output via VSR getestet?

Bleibt identisch.

Das Umschalten mit VSR ist echt deutlich schneller bei AMD, allerdings zerschießt es ständig den Desktop oder das Spiel, also letztendlich will man das ebenso wenig wie nVidias Lösung benutzen :ugly:

---

Manche Titel funktionieren einfach nicht mit Optiscaler.
Snowdrop-Engine, Starfield, Dead Space Remake, keine Chance...

[robbitop]

Ggf wird die Kompatibiltät noch besser. Die Entwicklung von Optiscaler ist ja sehr aktiv. Es gibt so gut wie jeden Tag eine neue nightly und der Dialog in github scheint auch ziemlich aktiv.

[Lurtz]

Das ist eben die Frage. Ich habe das Gefühl wenn es an Optiscaler selbst liegt, fixen die beiden (?) Entwickler das immer sehr schnell, aber es scheint einfach Implementierungen zu geben, wo man von außen nicht ran kommt.

[Lurtz]

Finde die Kommunikation von AMD da auch wieder ungenügend. Klar, nVidia sagt auch nicht viel mehr, aber die sind auch Market Leader und erfahren generell viel mehr Unterstützung bei Entwicklern (und ihr Upgrademechanismus ist viel offener). Zudem haben sie immerhin klar gesagt, dass Transformer erstmal als Beta läuft.

Bei FSR4 stellen sich noch ziemlich viele Fragen.

Ist AMD bekannt, dass Quality verbuggt ist? Wie lange könnte es dauern, bis dafür ein Fix kommt?

Wann ist mit einer Vulkan-Version zu rechnen? Unter den angekündigten Titeln ist AFAIK kein einziger Vulkan-Titel.

TLOU2 erscheint Anfang April, soll laut Liste aber erst mit einem Post-Launch-Update FSR4 bekommen?! Warum, wenn selbst der Vorgänger bereits über den Treiber upgradebar ist?

Sind die Titel auf der Kompiliste die einzigen, die in den nächsten Monaten offiziell unterstützt sein werden? Gibts keine Entwickler, die ältere Versionen zumindest auf 3.1 für Treibersupport anheben werden? Werden kommende AAA-Titel wie AC Shadows, Doom The Dark Ages etc. wirklich ohne FSR4-Support erscheinen?

[robbitop]

Das ist eben die Frage. Ich habe das Gefühl wenn es an Optiscaler selbst liegt, fixen die beiden (?) Entwickler das immer sehr schnell, aber es scheint einfach Implementierungen zu geben, wo man von außen nicht ran kommt.

Naja Pure Dark bekommt es bei seinen Mods dann (spielespezifisch) soweit ich weiß schon besser hin. Ggf muss man dann für problematische Implementierungen spielespezifisch was einbauen oder so eine Art „compatibility bits“ :)

[Lurtz]

Das ist aber nicht der generische Ansatz, den Optiscaler verfolgt. Wie viele Titel schafft PureDark so pro Jahr, 4 bis 5? ;)

[Exxtreme]

Das Edge-AA von FSR4 ist richtig schlecht in Bewegung in Robocop.

https://s1.directupload.eu/images/250315/ro8v9hn5.jpg

https://s1.directupload.eu/images/250315/ls9mt85y.jpg

Kann sein, dass das ein Fail im Spiel ist. Es ist so, dass man für TAA-basierendes AA ein sog. "camera jitter" machen muss. Und ausgerechnet das "camera jitter" verkacken so viele Studios, dass es kaum zu glauben ist. Entweder machen sie kein "camera jitter" sondern ein "geometry jitter". Dann werden nur Polygone geglättet und man wundert sich warum Stromleitungen plötzlich schrottig aussehen. Oder sie mixen anscheinend "geometry jitter" mit FXAA oder so. Dann werden auch noch Kanten "übersehen", die nicht genug Kontrast haben.

Und wenn man sich die Content-Fails von Robocop so anschaut dann glaube ich eher, dass das am Spiel liegt.

[TheAntitheist]

Kann sein, dass das ein Fail im Spiel ist. Es ist so, dass man für TAA-basierendes AA ein sog. "camera jitter" machen muss. Und ausgerechnet das "camera jitter" verkacken so viele Studios, dass es kaum zu glauben ist. Entweder machen sie kein "camera jitter" sondern ein "geometry jitter". Dann werden nur Polygone geglättet und man wundert sich warum Stromleitungen plötzlich schrottig aussehen. Oder sie mixen anscheinend "geometry jitter" mit FXAA oder so. Dann werden auch noch Kanten "übersehen", die nicht genug Kontrast haben.

Und wenn man sich die Content-Fails von Robocop so anschaut dann glaube ich eher, dass das am Spiel liegt.
es ist immer camera jitter... und natürlich haben sie es nicht verkackt... also deine Aussagen passen überhaupt nicht, es geht ja mit DLSS und TAA. da ist auch nichts schweres an dem jitter, das sind nur leichte bewegungen nach links und rechts damit man 2 positionen hat fürs AA. Nein das verkacken die Devs NICHT

[aufkrawall]

Solche Probleme gibt es gerne mal, wenn zusätzlich zum Upsampling noch irgendwas mit reduzierter Auflösung ala VRS läuft.
In RotTR gibts das etwa mit dem Gras im Geothermal Valley, ohne den Weichspüler von Preset E fällt das mit K in Bewegung ziemlich auseinander.

[gedi]

Das Edge-AA von FSR4 ist richtig schlecht in Bewegung in Robocop.

https://s1.directupload.eu/images/250315/ro8v9hn5.jpg

https://s1.directupload.eu/images/250315/ls9mt85y.jpg

Ein Spiel aus 1999? Sorry, aber das Image was du gepostet hast, erinnert mich an, als die Bilder laufen lernten ... Wenn wirklich FSR4 am Start war, dann sehen die Kanten mal echt scheiße aus, aber würde es mich in dem Spiel interessieren? Warum braucht es in dem Krempel überhaupt einen Upscaler?

[Lurtz]

GTA V Enhanced soll seit dem letzten Patch FSR4 können. Das Overlay zeigt es beim Start auch an, aber ingame behauptet er dann, FSR wäre nicht aktiviert.

It just works... :uup:

Ein Spiel aus 1999? Sorry, aber das Image was du gepostet hast, erinnert mich an, als die Bilder laufen lernten ... Wenn wirklich FSR4 am Start war, dann sehen die Kanten mal echt scheiße aus, aber würde es mich in dem Spiel interessieren? Warum braucht es in dem Krempel überhaupt einen Upscaler?
:facepalm: (https://www.pcgameshardware.de/RoboCop-Rogue-City-Spiel-73395/Tests/Test-Spielzeit-Benchmarks-1433085/)

[Tesseract]

es ist immer camera jitter... und natürlich haben sie es nicht verkackt... also deine Aussagen passen überhaupt nicht, es geht ja mit DLSS und TAA. da ist auch nichts schweres an dem jitter, das sind nur leichte bewegungen nach links und rechts damit man 2 positionen hat fürs AA. Nein das verkacken die Devs NICHT

der jitter ist ein sparse grid muster über zig frames hinweg und alles was sich nicht mit subpixelgenauigkeit verschieben lässt bzw. verschoben wird macht potenziell probleme.

[TheAntitheist]

Ein Spiel aus 1999? Sorry, aber das Image was du gepostet hast, erinnert mich an, als die Bilder laufen lernten ... Wenn wirklich FSR4 am Start war, dann sehen die Kanten mal echt scheiße aus, aber würde es mich in dem Spiel interessieren? Warum braucht es in dem Krempel überhaupt einen Upscaler?
wenn man sich die screenshots mal anguckt, sieht jeder geistig normale Mensch, das diese niemals von 1999 sein können ;D

[Exxtreme]

es ist immer camera jitter... und natürlich haben sie es nicht verkackt... also deine Aussagen passen überhaupt nicht, es geht ja mit DLSS und TAA. da ist auch nichts schweres an dem jitter, das sind nur leichte bewegungen nach links und rechts damit man 2 positionen hat fürs AA. Nein das verkacken die Devs NICHT

Diese Problematik hat DLSS in Robocop auch:

https://i.ibb.co/YFd1JL4q/Screenshot-2025-03-17-003859.png (https://ibb.co/gLWfQRbB)

[TheAntitheist]

Diese Problematik hat DLSS in Robocop auch:

https://i.ibb.co/YFd1JL4q/Screenshot-2025-03-17-003859.png (https://ibb.co/gLWfQRbB)
sieht doch viel besser aus?

[Exxtreme]

OK, ich habe die Stelle gefunden:
https://i.ibb.co/RTd1chzK/Screenshot-2025-03-17-061532.png (https://ibb.co/23Hwd8gr)

Sieht mit DLSS4 auch übel aus. Von daher bleibe ich dabei, die Devs haben Mist gebaut.

[aufkrawall]

Ja, woher soll das AA auch herhaben. Das interpoliert ja nur Durchschnittswerte, Problem logischerweise schon im Input vorhanden.
Dieses ganze Spiel sieht komplett furchtbar aus. Keine Ahnung, obs an Lumen-Reflexionen liegt, aber etwa nasser Asphalt sieht in dem Spiel auch aus wie ein gigantischer Grafikfehler. Komplett unerträglich anzuschauen.

[robbitop]

War Robocop nicht UE4? :) (iirc gab es in UE4 noch kein Lumen)

[Lurtz]

War Robocop nicht UE4? :) (iirc gab es in UE4 noch kein Lumen)
Ist UE5. Und ja, hat IQ-technisch viele Probleme. Edge-AA, der Noise auf nassem Asphalt ist extrem, DoF wird auch ganz schlecht von DLSS/FSR behandelt.

[robbitop]

Ach krass. Hatte ich falsch abgespeichert. Danke :)

[Raff]

Ach krass. Hatte ich falsch abgespeichert. Danke :)

Lies dir am besten mal das durch und schau die Bilder an. :)

https://www.pcgameshardware.de/RoboCop-Rogue-City-Spiel-73395/Tests/Test-Spielzeit-Benchmarks-1433085/

MfG
Raff

[aufkrawall]

In Talos 1 scheint Opti FSR 4 + Nukem FG gut zu funktionieren. Skaliert ziemlichst nett mit 80% in 4k.
StreamLine scheint auch auf Radeon ins CPU Frame Pacing involviert zu sein, mit 2.7 sieht der Frame Time Graph besser aus. Ggf. der Grund, weshalb es in Witcher 3 mit dessen steinalten StreamLine-DLLs nicht richtig läuft. Talos fühlt sich aber eh einfach immer unrund an, wobei es FG eher besser als schlechter macht. Insbesondere mit Reflex off erzwungen.

[Hakim]

zSaFFQAsWYM

[aufkrawall]

Mit FsrNonLinearSRGB=true gibts weniger Hang zu dunklerer Verrechnung und Vegetation kommt filigraner rüber (y) :
https://s1.directupload.eu/images/250318/temp/27xk6th9.jpg (https://www.directupload.eu/file/d/8862/27xk6th9_jpg.htm) https://s1.directupload.eu/images/250318/temp/b63gmruu.jpg (https://www.directupload.eu/file/d/8862/b63gmruu_jpg.htm)

[aufkrawall]

In Stalker 2 sieht es mit dem FSR 3.1 Input zum Kotzen aus, mit XeSS-Input via OptiScaler wesentlich besser. :rolleyes:
Das geditherte Schrott-LOD für die Vegetation (warum kein Nanite...) steckt DLSS deutlich besser weg, aber gut genug mit Balanced in 4k.
Mit FSR 3.1 FG (was sich hier offenbar problemlos mit OptiScaler kombinieren lässt?) lässt das die 4070S bez. flüssige Bildausgabe schon ziemlich alt aussehen, die in dem Spiel auch allgemein deutlich schlechtere Frame Times hatte. FSR FG skaliert mal wieder mit 80% bei Basis 4k 75fps.

[robbitop]

Wie sieht es mit DLSS Input (via fakenvapi) ausin Bezug auf BQ? Noch besser?

[aufkrawall]

Sieht nicht danach aus. Das Hauptproblem ist das ekelhafte Rauschen der AO in der Vegetation. Das hatte auch mit DLSS genervt, aber weniger gematscht.
Das Spiel sieht entsetzlich aus vs. Talos 1 Remake...

[Achill]

Wie sieht es mit DLSS Input (via fakenvapi) ausin Bezug auf BQ? Noch besser?

Sieht nicht danach aus. Das Hauptproblem ist das ekelhafte Rauschen der AO in der Vegetation. Das hatte auch mit DLSS genervt, aber weniger gematscht.
Das Spiel sieht entsetzlich aus vs. Talos 1 Remake...

Forciert mal die MipMap Basis für FSR3 Input auf die Werte die bei XeSS oder DLSS genommen werden, insb. bei DLSS habe ich in letzter Zeit hohe neg. Werte wie -1.5 in Spielen selbst für das Quality Preset gesehen.

Bei AMD ist laut Docs für z.B. Quality ein Wert von -0.58.. empfohlen und war bis FSR3 ja wichtig, um Übersteuerung und damit Flickern & Moore zu vermeiden.

Da FSR4 jetzt damit besser klar kommt, kann man natürlich die Werte von XeSS oder DLSS wählen, würde mich nicht wundern wenn einige optischen Unterschied auch daher kommen können. Denn Faktisch wird mit der Verschiebung von schnell eine MipMap-Stufe anstatt einer MipMap mit der Auflösung von 1024x1024 eine 2048x2048 Auflösung verwendet, das hat dann schnell mehr Details. Insb. Texturen mit Alpha-Kanal sollten davon profitieren (z.B. die ekligen Bäume in Stalker 2 im PCGH Video - k.a. wie man dies in einen "Blind"-Test aufnehmen kann wenn dies offensichtlich kaputt ist).

[aufkrawall]

Wird in dem Fall nicht daran liegen, das sieht ganz komisch kaputt aus. Bzw. so wie GTA V mit Treiber-Toggle anstatt OptiScaler.

[Lurtz]

Optiscaler läuft soweit in AC Shadows, wenn mal das Menü erscheint. Klappte bei mir erst nach Aktivieren von FSR FG (bei FSR Input). Manchmal fliegt auch ein D3D-Error.

Edit:
Freezt permanent mit Optiscaler, ohne Treiber-Reset... Ich glaube ich spare auf eine 5070 Ti oder versuche noch eine 4070 Ti Super irgendwo zu bekommen, dieses Optiscaler-Gefrickel ist einfach sinnlos auf Dauer. Und ohne FSR4 oder DLSS4 zu spielen ist komplett sinnlos geworden. FSR 2/3, XeSS und TAAU sind absurd schlecht im Vergleich.

[DrFreaK666]

Kommt halt davon wenn man verwöhnt ist :freak:

[aufkrawall]

In GTA V geht es auch mit den "Flimmerzonen" kaputt, wenn man manche Optionen in OptiScaler durchschaltet. Konnte auch Auto-Exposure gar nicht mehr deaktivieren.
Da sollte man also während des Zockens eher keine Änderungen vornehmen bzw. danach das Spiel neu starten.

Neues Commit "Tried to fix VMem leak when using FSR inputs": https://github.com/cdozdil/OptiScaler/commit/6eb2a67b5aa6ec9721748403e1bb5e13352f339a
Wär schon noch schön, wenn das mit FSR Input in mehr Spielen gehen würde. Hoffentlich ein Schritt dahin.

[robbitop]

Wie bekommt ihr denn Optiscaler mit GTA 5 Enhanced zum Laufen? Bei mir greift beim Start schon Battleye mit einer Fehlermeldung ein. Egal ob STEAM oder Epic Version. Die Rockstarversion erlaubt gar keine fremden Dateien und setzt es wieder zurück (und ja ich hab das Spiel 3x X-D).
-nobattleye als launch option in Steam funktioniert auch nicht - dann startet das Spiel nicht. Selbst wenn ich im Rockstar Socialclub Gedöhns Battleye deaktiviere startet es einfach nicht. Es scheint Battleye unbedingt zu wollen um zu starten und Battleye scheint Optiscaler nicht zu mögen (das letzte mal dass ich das getestet hab ist aber schon 1,5 Wochen her mit der damaligen Nightly build).

Mir geht das mittlerweile (als Single Player Spieler) total auf den Sack von irgendwelchen Kopierschutz und DRM und AntiCheat Mist belästigt zu werden, den ich nicht brauche. Als junger Student habe ich damals noch Kekse benutzt und hab damit aufgehört als ich Geld verdient habe. Und ich fühle mich total benachteiligt obwohl ich brav Geld rüberschiebe - bei manchen Spielen sogar mehrfach X-D

Braucht es für Optiscaler und GTA5 einen Keks? ^^

[aufkrawall]

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13726696#post13726696

[robbitop]

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13726696#post13726696
Danke - aber das ist schon eine unpragmatische Lösung oder? Muss man dann ja bei jedem Spielstart neu machen. Aber ja so könnte das ggf. bei mehr Spielen funktionieren. Wäre cool wenn der Optiscalertyp ein Tool bauen würde wie damals mit dem DLSS Enhancer (oder so) was automatisiert mitbekommt, wann das Spiel startet, die dlls tauscht und wenn das Spiel beendet wurde den Urzustand wieder setzt. So konnte ich damals mit der Rockstarversion von RDR2 DLSS auf 2.5.1 upgraden ^^

[aufkrawall]

Das ging bei RDR2 mit einem einfachen bat-Script, sollte nicht das Problem sein.
Hab das Spiel auch in Epic, damit passiert das nervige Ersetzen nicht und er nutzt zum Glück die gleichen Savegames wie RGL.

Hatte bei Stalker wohl was verbockt, indem ich die Game-Config noch von GeForce-Experimenten schreibgeschützt hatte. Wenn ich das Spiel direkt mit FSR 3.1 aktiv und 4 Treiber-Override starte, sieht es jetzt auf den ersten Blick deutlich besser (aber trotzdem nicht so gut wie mit DLSS Input?) aus. OptiScaler hatte mir jetzt mit FSR Input nur noch Crashes verursacht, warum auch immer.
Du liebe Güte, lief das auf der 4070S mies und langsam im Vergleich. :freak:
Da ist das Gummiband an der Maus durch fehlenden Anti-Lag 2 Support wirklich das weitaus geringere Übel...

[robbitop]

Kann optiscaler nicht Reflex in AL2 ummappen? ^^

[Lurtz]

Du liebe Güte, lief das auf der 4070S mies und langsam im Vergleich. :freak:
Da ist das Gummiband an der Maus durch fehlenden Anti-Lag 2 Support wirklich das weitaus geringere Übel...
Dabei läuft das laut CB nur 10% schneller auf der 9070 :uponder:

Die Crashes in Shadows sind mit DLSS Input/FG deutlich geringer. Meckert zwar wegen nicht passendem Treiber, aber augenscheinlich funktioniert dennoch alles.
Kann es sein dass man abseits von Fehlern am besten einfach immer DLSS Inputs nutzt? :ugly:

[aufkrawall]

fakenvapi kann das. Aber, wie schon mehrfach erwähnt, kann das Spoofen einer NV-GPU Probleme machen. Kann problemlos laufen, muss aber nicht. Brauch die schlechteren Frame Times mit Reflex/A-L2 in SP-Games auch nicht unbedingt.

Dabei läuft das laut CB nur 10% schneller auf der 9070 :uponder:

FG hatte halt damals voll kacke auf der 4070S in 4k skaliert. Vielleicht 45%? Vs. 80% mit FSR auf der 9070...
DLSS 4 wäre nun zumindest etwas besser, aber einige berichten ja auch von mehr Ghosting damit gegenüber 3 (oder lustigen Crashes :D )...

[Lurtz]

Das stimmt, FSR FG ist echt der Knaller was die Skalierung angeht. Dagegen stinkt auch die neue DLSS FG ab.

[Relex]

Das neue DLSS FG skaliert schon ganz ok in 4K.

z.B. von 50 auf 92 FPS (+84%)
oder von 82 auf 140 FPS (+71%)

Also ganz so kacke ist es nicht mehr. :D

[robbitop]

...
Der quote ist von aufkrawall aber in deinem Post steht dass der von mir wäre. Müsstest du mal korrigieren :)

[Gast]

Das stimmt, FSR FG ist echt der Knaller was die Skalierung angeht. Dagegen stinkt auch die neue DLSS FG ab.

Dafür ist die Qualität Müll, such dir aus was dir besser gefällt...

[DrFreaK666]

Hat schon jemand Native-FSR4 gegen Optiscaler-FSR4 getestet?

[aufkrawall]

Dafür ist die Qualität Müll, such dir aus was dir besser gefällt...
Die Qualität ist, neben den ganzen Stabilitätsproblemen, mit DLSS 4 FG auch regressed :uclap::
https://forums.guru3d.com/threads/info-zone-gengines-ray-tracing-ai-dlss-dlaa-dldsr-tsr-fsr-xess-directsr-and-mods-etc.439761/page-211#post-6319327

[robbitop]

Dafür ist die Qualität Müll, such dir aus was dir besser gefällt...

Hatten wir oft genug und das ist völlig übertriebene Polemik. Wenn FSR FG mit einem vernünftigen Upscaler gemischt wird (FSR4 oder DLSS4) ist das total in Ordnung. Ich nutze es mit meiner 3080 (kombiniere DLSS4 K mit FSR3.1 FG via optiscaler und kann sogar reflex nutzen) selbst ständig und kenne auch DLSS FG. Wenn FSR FG mit FSR 3.1 oder niedriger kombiniert wird hingegen ist es qualitativ unschön weil sich die Artefakte aufschaukeln. Ich habe aber den Eindruck dass die Meinung bei vielen noch aus der Zeit stammt wo es mit altem FSR kombiniert wurde.

Und das ist keine Einzelmeinung. Das sehen auch reviews bis dato so. Und es gab seitens HWUB extra einen Vergleich mit FG mit FSR3.1 und 4.0 wo explizit verglichen wurde in Bewegung und da kam genau obiges bei raus.

Ist DLSS FG qualitativ besser? Ja. Aber Müll? Sorry aber das ist Polemik.

[Gast]

@robbitop Du kannst garnicht mitreden, wenn du den Vergleich nicht hast. Also bitte...

[Gast]

Die Qualität ist, neben den ganzen Stabilitätsproblemen, mit DLSS 4 FG auch regressed :uclap::
https://forums.guru3d.com/threads/info-zone-gengines-ray-tracing-ai-dlss-dlaa-dldsr-tsr-fsr-xess-directsr-and-mods-etc.439761/page-211#post-6319327

Das liegt ja stets am Nutzer selbst, man kann die FG-Versionen ja in sekundenschnelle wechseln.

[Platos]

Wie viele Spiele gibts eig., die AMD's Framegen unterstützen, aber nicht nvidia's Framegen?

[Banshee18]

Wie viele Spiele gibts eig., die AMD's Framegen unterstützen, aber nicht nvidia's Framegen?
Avatar fällt mir da spontan ein.

[robbitop]

@robbitop Du kannst garnicht mitreden, wenn du den Vergleich nicht hast. Also bitte...

Doch ich kenne DLSS FG persönlich natürlich auch. Weiterhin gibt es dazu auch professionelle Reviews (mit Leuten die das beruflich machen) die es genauso sehen. Wenn es kompletter „Müll“ wäre (wie du hier übertreibst) würde sich das dort auch wiederspiegeln. Und wer bist du? Jemand der hier anonym polemische völlig übertriebene Inhalte postet. Also bitte…

[Gast]

Wie viele Spiele gibts eig., die AMD's Framegen unterstützen, aber nicht nvidia's Framegen?

Assassins Creed Shadows lässt bei mir nur FSR3 FG aktivieren, und es ist ziemlich unbrauchbar, total kaputtes Framepacing.

[aufkrawall]

Das liegt ja stets am Nutzer selbst, man kann die FG-Versionen ja in sekundenschnelle wechseln.
Ja, cool. Gibt dann damit aber auch wieder mitunter grottenschlechte 45% Skalierung mit 4k Target auf einer 4070S, während FSR FG auf RDNA4 mal eben 80% raushaut. :freak:

[Lurtz]

Wenn Spiele mit Optiscaler beim Übernehmen von FSR4 crashen, dann wahrscheinlich wegen statisch gelinkter d3d12-DLLs. Leider ist aktuell kein Fix dafür absehbar:
Potato suspects it's related to Control using statically linked d3d12 files and FSR4 requires its own newer files or something like that. Optiscaler doesn't manage to inject FSR4 at the appropriate time, so the upgrade process ends up crashing the game. Control isn't the only game, so if this were to be fixed, it would most likely fix FSR4 crashes for all other games.

Unfortunately, this isn't looking as easy to fix so will probably require time, no promises.
https://github.com/cdozdil/OptiScaler/issues/248#issuecomment-2745582310

[basix]

Wenn Spiele mit Optiscaler beim Übernehmen von FSR4 crashen, dann wahrscheinlich wegen statisch gelinkter d3d12-DLLs. Leider ist aktuell kein Fix dafür absehbar:

https://github.com/cdozdil/OptiScaler/issues/248#issuecomment-2745582310

Kann man das denn überhaupt von extern fixen?

[Achill]

Da es Software ist, geht dies theoretisch immer. Ob jemand den Aufwand bezahlen / übernehmen will, ist die entsprechende Frage.

[w0mbat]

Als der OptiScaler vor zwei Wochen so viel Aufmerksamkeit bekommen hat, haben sich anscheinend direkt FSR-Entwickler zur Unterstützung gemeldet. Ich denke AMD wäre extrem dumm, wenn sie die Chance nicht nutzen würden.

Genial wäre eine "one-size-fits-all" Lösung. Man startet OptiScaler einfach im laufenden Spiel und injiziert FSR4 direkt in FSR3/DLSS/XeSS. Ohne dll swap, ohne files kopieren, etc. Wenn sie das hingebkommen, wäre RDNA4 nochmal deutlich besser.

Dass AMD das nicht "offiziel" via Treiber machen kann verstehe ich. Deshalb ist der OptiScaler ja eine so gute Option.

[robbitop]

Wenn AMD ihr FSR4 so umbauen kann, dass es nicht unbedingt die neueren dx12 dlls braucht, würde das schon helfen. Wenn das nicht geplant ist ginge ggf. ein kleiner wrapper.

[derF]

Genial wäre eine "one-size-fits-all" Lösung. Man startet OptiScaler einfach im laufenden Spiel und injiziert FSR4 direkt in FSR3/DLSS/XeSS. Ohne dll swap, ohne files kopieren, etc. Wenn sie das hingebkommen, wäre RDNA4 nochmal deutlich besser.

Dass AMD das nicht "offiziel" via Treiber machen kann verstehe ich. Deshalb ist der OptiScaler ja eine so gute Option.
Problematisch ist es aber auch dann noch in Multiplayer-Games, wegen Anticheat. Ich würde es gerne in Forza Motorsport ausprobieren und mal den Vergleich zwischen nativ und injiziert in Space Marine 2 machen, aber trau mich nicht. :redface:

[raffa]

MSFS2024 ist gestern Abend in die SU2 Betaphase eingetreten.

Mit am Start: FSR3.1 FG (und DLSS4 + (M)FG)
Ersteindruck ist gut, besser als vorher via Optiscaler.

[crux2005]

https://www.youtube.com/watch?v=cz2kCCIdLws&t=573s

Die Stelle wo er aus dem Wagen aussteigt und die Kiste öffnet, bzw. danach wo er das Motorrad ruft. Sind die Texturen im Spiel wirklich so niedrig aufgelöst oder ist das ein Resultat des Optiscaler/FSR4 Mod?

Für mich sieht es so aus als ob das LOD total kaputt wäre (mit FSR4 balanced via Mod).

[Colin MacLaren]

Ohne Texturmod ist CP wirklich nicht so pralle. Ich fand das auch nie soooo optisch beeindruckend, wie alle immer tun.

[Relex]

Bei Pathtracing sind recht starke denoiser aktiv, die natürlich Texturdetails zerstören. Ganz besonders wenn man upscaling nutzt.

Deswegen ist sowas wie Ray Reconstruction ja auch so wichtig. Ohne RR ist PT ziemlich sinnfrei und selbst mit RR sind die Texturen nicht ganz so scharf wie ohne PT.

[Achill]

https://www.youtube.com/watch?v=cz2kCCIdLws&t=573s

Die Stelle wo er aus dem Wagen aussteigt und die Kiste öffnet, bzw. danach wo er das Motorrad ruft. Sind die Texturen im Spiel wirklich so niedrig aufgelöst oder ist das ein Resultat des Optiscaler/FSR4 Mod?

Für mich sieht es so aus als ob das LOD total kaputt wäre (mit FSR4 balanced via Mod).

Man muss sich nur 30s ab der Zeitmarke ab anhören und weiß doch gleich was Sache ist, da wird der Standard Stuss aus dem Netz wiedergegeben. Den Input hat AMD nicht unter Kontrolle, egal bei welchem Spiel - wenn dieser schlecht/schlechter/anders als im Vergleich zu DLSS ist, dann kommt auch etwas anderes Raus. Und danach kann der Upscaler natürlich noch eine Rolle spielen ...

Bei 1:45 sieht man, dass er OptiScaler mit FSR3 Input nutzt, und wie wir alle Wissen (u.a. durch die vielen DF Videos), sieht die Umsetzung von FSR3 in CP2077 bescheiden aus. Wenn der Input schlecht ist, dann kann auch FSR4 nichts retten ...

[aufkrawall]

Die Frage ist nur, warum der Input mit FSR oft Müll ist, und das bei Stalker selbst mit FSR 3.1 via UE5 Plug-In der Fall ist vs. DLSS -> FSR 4 OptiScaler.

[The_Invisible]

Wenn der Input schlecht ist, dann kann auch FSR4 nichts retten ...

Ist das jetzt ein neues Fass, dass wegen FSR4 aufgemacht wurde mit "schlechten" Input? Hätte ich bei DLSS nie gehört das schlechte Inputs schuld wären wenn die BQ mal schwankt.

[aufkrawall]

Erinnerungs-Olaf? Natürlich gab es auch bei DLSS schon diverse Implementierungs-Fails, die nicht direkt am Algorithmus lagen.
Nur scheint das bei DLSS unterm Strich seltener oder mit geringerer Schwere vorzukommen, sodass der DLSS-Input in OptiScaler eigentlich nie schlechter, sondern oft eher besser ist.

[Exxtreme]

Ist das jetzt ein neues Fass, dass wegen FSR4 aufgemacht wurde mit "schlechten" Input? Hätte ich bei DLSS nie gehört das schlechte Inputs schuld wären wenn die BQ mal schwankt.

Das ist kein neues Fass sondern schon seit Ewigkeiten bekannt. Es ist so, für TAA-basierende Verfahren braucht man sog. camera jitter damit TAA/FSR/DLSS/TSCMAA etc. überhaupt temporale Informationen hat. Und dann braucht man sog. velocity buffers um Ghosting zu minimieren. Velocity buffers sind Zusatzinformationen in denen man herauslesen kann in welche Richtung sich Pixel bewegen.

Und mindestens eins von beiden Dingern verkacken die Spieleentwickler sehr oft.

[Achill]

Die Frage ist nur, warum der Input mit FSR oft Müll ist, und das bei Stalker selbst mit FSR 3.1 via UE5 Plug-In der Fall ist vs. DLSS -> FSR 4 OptiScaler.

Weil Nvidia clever ist und aktuell (und schon eine Weile) die Marktmacht hat für entsprechende Nutzungsbedingungen hat:


[..]

6. SDK Terms.
6.1 Over the Air Updates. By installing or using the SDK you agree that NVIDIA can make over-the-air updates of the SDK in systems that have the SDK installed, including (without limitation) for quality, stability or performance improvements or to support new hardware.

6.2 SDK Integration. If you publicly release a DLSS integration in an end user game or application that presents material stability, performance, image quality, or other technical issues impacting the user experience, you will work to quickly address the integration issues. In the case issues are not addressed, NVIDIA reserves the right, as a last resort, to temporarily disable the DLSS integration until the issues can be fixed.

[..]


=> Mit 6.1 stellt NV sicher, dass ein Austausch einer ihrer SDKs (also i.d.R. DLLs bei Spielen/Anwendungen) immer gehen muss - also kompatibel zu Anti-Cheat und Kopierschutzmaßnahmen sein muss.
=> Mit 6.2 wird das Studio/Publisher verpflichtet, bei fehlerhafter oder schlechter Integration diese zu beheben oder anderseits kann NV die Nutzungslizenz entziehen.

Setzt man dies in Context zur Marktstellung, dann ist die Gefahr des Entzugs der Lizenz (was ggf. nicht nur ein Spiel betreffen muss) und damit Verbunden der Unzufriedenheit von Käufern wahrscheinlich immer Unbefriedigender ist als ein nachträglichen Aufwand etwas im Spiel zu korrigieren (für DLSS und ggf. ein anderes NV SDK wie RTX*, Streamline, ...).

[Gast]

Und mindestens eins von beiden Dingern verkacken die Spieleentwickler sehr oft.

Ohne Kamera-Jitter hättest du gar kein Antialiasing, da das kann man nicht verkacken ohne dass es sofort auffällt.

Und die Bewegungsvektoren können gar nicht in jeder Situation korrekt sein. Beispielsweise bei Transparenzen ist es unmöglich korrekte Bewegungsvektoren zu liefern, gleiches gilt für Schatten, wobei diese in der Regel beim Antialiasing nicht betrachtet werden und damit außen vor sind.

[The_Invisible]

Weil Nvidia clever ist und aktuell (und schon eine Weile) die Marktmacht hat für entsprechende Nutzungsbedingungen hat:



=> Mit 6.1 stellt NV sicher, dass ein Austausch einer ihrer SDKs (also i.d.R. DLLs bei Spielen/Anwendungen) immer gehen muss - also kompatibel zu Anti-Cheat und Kopierschutzmaßnahmen sein muss.
=> Mit 6.2 wird das Studio/Publisher verpflichtet, bei fehlerhafter oder schlechter Integration diese zu beheben oder anderseits kann NV die Nutzungslizenz entziehen.

Setzt man dies in Context zur Marktstellung, dann ist die Gefahr des Entzugs der Lizenz (was ggf. nicht nur ein Spiel betreffen muss) und damit Verbunden der Unzufriedenheit von Käufern wahrscheinlich immer Unbefriedigender ist als ein nachträglichen Aufwand etwas im Spiel zu korrigieren (für DLSS und ggf. ein anderes NV SDK wie RTX*, Streamline, ...).

Alter was für Verschwörungstheorien mal wieder lol

[Exxtreme]

Ohne Kamera-Jitter hättest du gar kein Antialiasing, da das kann man nicht verkacken ohne dass es sofort auffällt.


SQEX: hold my beer. :)
https://forum.square-enix.com/ffxiv/threads/502124


Und ja, das liegt am fehlenden camera jitter weil es Mods gibt, die das fixen:
https://github.com/rootdarkarchon/XIVJitterFix

[Gast]

SQEX: hold my beer. :)
https://forum.square-enix.com/ffxiv/threads/502124


Und ja, das liegt am fehlenden camera jitter weil es Mods gibt, die das fixen:
https://github.com/rootdarkarchon/XIVJitterFix

Inwiefern widerspricht mir das jetzt?

[Exxtreme]

Inwiefern widerspricht mir das jetzt?

Weil man es eben doch verkacken kann obwohl es auffällt.

[Gast]

Weil man es eben doch verkacken kann obwohl es auffällt.

Jetzt ließ noch mal genau nach was ich geschrieben habe.

[Tesseract]

Ohne Kamera-Jitter hättest du gar kein Antialiasing


natürlich hätte man das, nur nicht so effizient.

[Relex]

Für AntiAliasing brauchst du mehr samples als das nativ gerenderte Bild hat. Daher auch klassisch multisampling oder supersampling genannt.


Bei einem temporalen Verfahren wie TAA oder FSR/DLSS bekommst du diese zusätzlichen samples bzw. Informationen, indem die Szene mehrfach und immer leicht anders abgetastet wird. Das geschieht über Zeit (mehrere Frames) indem die Kamera in bewegung ist (was der Fall ist, sobald du die Kamera im Spiel bewegst) oder aber wenn das Bild still steht über einen künstlichen Kamera Jitter.


Bleibt die Kamera still und ohne jitter kann die Szene nicht mehrfach bzw. feiner abgetastet werden, weil nunmal jedes Sample und damit in dem Fall jedes Pixel im nächsten Frame exakt den gleichen Farbwert annimmt, wie im vorherigen. Es findet also absolut gar kein Informationsgewinn über Zeit statt, der für ein AntiAliasing nutzbar wäre.

Das einzige, was man ohne Mehrfachabtastung der Szene tun kann, wäre ein Edge Smoothing via FXAA/SMAA. Aber sonst ist man komplett machtlos.


TAA und alles was darauf basiert braucht also zwingend Bewegung im Bild, sonst ist es völlig nutzlos.
Ohne Bewegung fütterst du den Algo mit den immer gleichen Daten des selben Frames. Das Prinzip der temporalen akkumulation funktioniert aber nur, wenn die Daten immer leicht anders sind. Nur so sammeln sich über Zeit zusätzliche Informationen aus der dargestellten Szene an. Idealerweise fügt jedes neue Frame neue Informationen hinzu, der in den vorherigen Frames noch nicht enthalten waren. Je feiner der Jitter desto mehr feine Details kann man so über Zeit gewinnen.

[Achill]

Ohne Kamera-Jitter hättest du gar kein Antialiasing, da das kann man nicht verkacken ohne dass es sofort auffällt.


Das geht schon, den Upsamplern DLSS, FSR und Xess muss natürlich auch die Jitter-Sequenz und der aktuelle Index mitgegeben werden, da kann sich theoretisch schon ein Bug zwischen den verschiedenen Integrationen einschleichen (z.B. wenn das Studio erst später andere Upscaler integriert). Oder z.B. das Flag falsch setzten, ob die Motion-Vectors Jittered sind oder nicht ...


Und die Bewegungsvektoren können gar nicht in jeder Situation korrekt sein. Beispielsweise bei Transparenzen ist es unmöglich korrekte Bewegungsvektoren zu liefern, gleiches gilt für Schatten, wobei diese in der Regel beim Antialiasing nicht betrachtet werden und damit außen vor sind.

Darum müssen Transparente Bereiche für FSR in die Transparency & Composition Mask geschrieben werden, sowie Reaktive Bereiche wie Animierte Texturen ohne Bewegungsvektoren in die Reaktive Mask - soweit mein Wissen von lesen ... Wenn dies weg gelassen wird oder eben fehlerhaft ist, dann sah/sieht es halt entsprechend aus.

---
natürlich hätte man das, nur nicht so effizient.

Nope, ohne Jitter gibt es bei TAA und Temp. Upscaling als eine Sonderform kein AA, da die Zusatzinformation über die Zeit durch den leichten x- & y-offset gewonnen wird. Die Informationen sind aber nicht ehwig gültig, weswegen die Jitter-Sequenz sich wiederholt und deren länge bei Upsampleren vom Upcaling-Verhältnis abhängt. Je höher das Upscaling-Verhältnis, desto länger die Sequenz ... zumindest sollte dies bei FSR so sein. Hier kann sich DLSS natürlich auch anders verhalten oder eine andere Länge voraussetzen, was wieder für Abweichungen sorgen kann.

[Tesseract]

Nope, ohne Jitter gibt es bei TAA und Temp. Upscaling als eine Sonderform kein AA

doch, gibt es. jede form von "bewegung", von objekttransformationen über RT noise bis zu klassischen animierten (shader)effekten erzeugt zusätzlichen sampleinput. außerdem haben sowohl CNN regional als auch transformer global zugriff auf nachbarwerte und können daraus zusätzlich rekonstruieren.

wo man mit TAA ohne jitter natürlich kein AA hätte wäre in einer komplett statischen, rasterisierten szene mit 90er jahre effektpipeline.

[crux2005]

Man muss sich nur 30s ab der Zeitmarke ab anhören und weiß doch gleich was Sache ist, da wird der Standard Stuss aus dem Netz wiedergegeben. Den Input hat AMD nicht unter Kontrolle, egal bei welchem Spiel - wenn dieser schlecht/schlechter/anders als im Vergleich zu DLSS ist, dann kommt auch etwas anderes Raus. Und danach kann der Upscaler natürlich noch eine Rolle spielen ...

Bei 1:45 sieht man, dass er OptiScaler mit FSR3 Input nutzt, und wie wir alle Wissen (u.a. durch die vielen DF Videos), sieht die Umsetzung von FSR3 in CP2077 bescheiden aus. Wenn der Input schlecht ist, dann kann auch FSR4 nichts retten ...

Ich habe primär nach RX 9070 XT in CP77 + FSR4 gesucht. Habe danach noch das Video von Ancient Gameplays geschaut und der erklärt das mit den Inputs. Wollte eigentlich nur paar Videos schauen wie gut das Spiel läuft und wie es aussieht. Und in der Hinsicht sind mehr Quellen = mehr Stellen im Spiel besser als weniger.

Das mit den Texturen ist mir einfach aufgefallen und wollte wissen oder das die MOD + upscaling verursachen oder nicht.
Wenn ich mir die Vergleiche im HD Texture Mod anschaue dann sind manche Vanilla Texturen echt schlecht: https://www.nexusmods.com/cyberpunk2077/mods/7652 Dazu das denoising mit PT. Kommt dann grob hin auch wenn "gute Inputs" benutzt werden.

[Gast]

doch, gibt es. jede form von "bewegung", von objekttransformationen über RT noise bis zu klassischen animierten (shader)effekten erzeugt zusätzlichen sampleinput.

Bewegung innerhalb der Szene erzeugt keinen zusätzlich verwertbaren Input sondern ist im Gegenteil sogar Kontraproduktiv für das Ergebnis, weshalb auch die Bewegungsvektoren benötigt werden um Bewegung innerhalb der Szene relativ zu den Samplepositionen zu kompensieren zu können.

Wenn du TAA verwendest, und die ganzen Upsamplers sind nichts anderes als TAA bei dem ein Teil des Oversamplings anstatt für Antialiasing für Upsampling verwendet wird, und du vergisst auf den Jitter ist das das Äquivalent zu SSAA, bei dem jedes einzelne Sample in der Pixelmitte abgetastet wird.

[Tesseract]

Bewegung innerhalb der Szene erzeugt keinen zusätzlich verwertbaren Input sondern ist im Gegenteil sogar Kontraproduktiv für das Ergebnis, weshalb auch die Bewegungsvektoren benötigt werden um Bewegung innerhalb der Szene relativ zu den Samplepositionen zu kompensieren zu können.

motion vectors sind pinzipbedingt nicht perfekt und erzeugen eine art random-jitter über frames hinweg; jede transformation erzeugt andere winkel, verzerrungsfaktoren, neue textursamples, shaderoutputs etc. was alles zusatzinformation ist; kanten werden in bewegung in einem CNN/transformer deutlicher.
es gibt neben dem aktiven jitter sehr viel mehr passive information in der szene.

ist das das Äquivalent zu SSAA, bei dem jedes einzelne Sample in der Pixelmitte abgetastet wird.

nein, ist es nicht, da wären alle samplebuffer zu 100% mathematisch identisch. bei TAA ohne jitter nach den motion vectors mit bewegung in der szene ist das absolut nicht der fall, ganz besonders dann nicht wenn monte carlo basiertes PT im spiel ist.

[Achill]

motion vectors sind pinzipbedingt nicht perfekt und erzeugen eine art random-jitter über frames hinweg; jede transformation erzeugt andere winkel, verzerrungsfaktoren, neue textursamples, shaderoutputs etc. was alles zusatzinformation ist; kanten werden in bewegung in einem CNN/transformer deutlicher.
es gibt neben dem aktiven jitter sehr viel mehr passive information in der szene.
[..]


Sry Tesseract, aber das klingt wie eine Aneinanderreihung von Begriffen. Ich bin selbst kein DX12/VK Entwickler sondern lese Blogs und Papers immer nur aus Interesse, würde von mir also niemals behaupten das ich immer richtig liege sofern versuche daher mit Fakten oder Zitaten zu begründen.

Meines erachten wird hier TAA sehr gut beschrieben: https://www.elopezr.com/temporal-aa-and-the-quest-for-the-holy-trail/

Und es geht hervor, dass das Jitter Grundlage für TAA und damit auch Upsampler ist und halt etwas anderes als Motion Vektors und wofür diese benötigt werden.

[Tesseract]

was ist unklar?

[Gast]

motion vectors sind pinzipbedingt nicht perfekt und erzeugen eine art random-jitter über frames hinweg;


Das bringt aber keine zusätzlichen nutzbaren Informationen, und damit kein Antialiasing. In Bewegung könnte dadurch höchstens ein grundsätzlich unerwünschter Motion-Blur entstehen, und alles was statisch ist hat immer noch kein Antialiasing wenn man komplett auf den Jitter vergisst.

Das deckt sich im übrigen auch mit den von Extreme verlinkten Beschreibungen, dort glauben die Leute ja DLSS ist deaktiviert, auch wenn es real immer noch aktiv nur mangels Jitter wirkungslos ist.

[Tesseract]

Das bringt aber keine zusätzlichen nutzbaren Informationen, und damit kein Antialiasing.
wenn sich die samplepositionen relativ zur objektoberfläche jeden frame etwas (pixelbruchteile) verschieben hat das eine ähnliche wirkung wie jitter. der effekt vom jitter ist natürlich viel stärker da systematisch, global, mit optimalen werten und einem dem NN bekannten schema. mit einem negativ mipmap bias kommen da trotzdem schnell mal sehr unterschiedliche samples raus die im downsamplingschritt den detailgrad erhöhen.

und alles was statisch ist hat immer noch kein Antialiasing wenn man komplett auf den Jitter vergisst.
wie gesagt: wenn, wie in den 90ern, jeder statische frame exakt gleich ist natürlich nicht. wenn z.B. durch RT/PT die inputs noisy sind sehr wohl.

[Gast]

wenn sich die samplepositionen relativ zur objektoberfläche jeden frame etwas (pixelbruchteile) verschieben hat das eine ähnliche wirkung wie jitter.


Nur ist der komplett random, und zentriert um das Pixelzentrum. Damit Antialiasing funktioniert muss der Jitter zu den Bewegungsvektoren passen, alles andere erzeugt nur random blur/noise. Und für ordentliches Antialiasing müssen die Samples über das ganze Pixel verteilt werden und nicht nur ein bisschen ums Zentrum wandern.



wie gesagt: wenn, wie in den 90ern, jeder statische frame exakt gleich ist natürlich nicht. wenn z.B. durch RT/PT die inputs noisy sind sehr wohl.

Das betrifft aber nur Raytracing/Pathtracing Effekte und nicht die Geometrie. Ohne Ray Recontstruction werden diese sowieso extra behandelt.

[Tesseract]

Nur ist der komplett random, und zentriert um das Pixelzentrum.

warum sollte sich das im pixelzentrum häufen? die erwartung über mehere frames hinweg wäre eher ein streak in bewegungsrichtung.
zur veranschaulichung ein eindimensionales beispiel mit 8 frames: objekt bewegt sich z.B. 4.123 pixel pro frame. pixelzentren sind x.5
screenspacepositionen: 0.0 , 4.123, 8.246, 12.369, 16.492, 20.615, 24.738, 28.861, 32.984
relative offsets zur pixelmitte: 0.5, 0.377, 0.254, 0.08, -0.115, -0.238, -0.361, -0.484

im trivialfall statisches bild liegen sie natürlich alle übereinander.

[Achill]

Ich verstehe es nicht, AMD und NV schreiben in ihren Developer Docs was benötigt wird für die FSR/DLSS integration.


[..]

2.2 Rendering Engine Requirements
The DLSS algorithm builds a high-resolution output buffer from information gathered over a series of
frames. This document details what is needed to properly integrate DLSS and should be read in its
entirety. As a summary, for DLSS to function with a high image quality, the rendering engine must:
- DirectX11, DirectX 12, or Vulkan based
o Additional note for Vulkan: The Vulkan path of DLSS expects the application to run on a
Vulkan version 1.1 or later.
- On each evaluate call (i.e. each frame), provide:
o The raw color buffer for the frame (in HDR or LDR/SDR space).
o Screen space motion vectors that are: accurate and calculated at 16 or 32 bits per-pixel;
and updated each frame.
o The depth buffer for the frame.
o The exposure value (if processing in HDR space).
- Allow for sub-pixel viewport jitter and have good pixel coverage with at least 16 jitter phases (32
or more is preferred).
- Initialize NGX and DLSS using a valid ProjectID (See Section 5.2.1).
- The ability to negatively bias the LOD for textures and geometry.
To allow for future compatibility and ease ongoing research by NVIDIA, the engine can also optionally
provide additional buffers and data. For information on these, see section 9.4.

[..]

3.7 Sub-Pixel Jitter
DLSS includes several temporal components in its anti-aliasing, feature enhancement and upscaling
algorithm. To achieve high image quality, DLSS emulates a higher sample rate by having the rendering
engine generate a subset of the desired sample locations each frame and temporally integrating them to
produce the final image. The renderer provides the additional samples by applying sub-pixel jitter to the
viewport or main camera view so to vary the rasterized frame over time.
Put another way, if we had four or more frames of rendered and rasterized pixels with no motion, the
image DLSS produces should be identical to a 4x super-sampled image. This is the goal for DLSS but is
not always achievable in practice.

[..]
(geht dann noch weiter und behandelt z.B. die Anforderung an die Sequenz um ein gute Subpixel-Verteilung zu erreichen)

Wie wahrscheinlich ist es, das es einen anderen Weg gibt (als der empfohlene) und AMD sowie NV diesen übersehen haben?

[Tesseract]

welcher andere weg? natürlich gehört der jitter implementiert für optimale resultate - hat nie jemand was anderes behauptet. mein punkt ist dass der jitter alleine nicht 100% des "spreadings" ausmacht (außer im trivialfall völliges standbild) sondern "nur" einen großteil.

[aufkrawall]

Der FSR 3.1 Input von GTA 5 für OptiScaler scheint einwandfrei zu sein, auch DoF scheint weiterhin gut auszusehen.
Zwar kein direkter Vergleich, aber imho matschen weit entfernte Autos/NPCs in Bewegung weniger als mit DLSS Preset K (4k Performance):
https://s1.directupload.eu/images/250405/temp/32ywropu.jpg (https://www.directupload.eu/file/d/8880/32ywropu_jpg.htm)
Smearing tendiert auch gegen 0. Allerdings wird es hinter Gitterzäunen in Bewegung ziemlich unscharf.

[Relex]

Just for fun als Vergleich mit DLSS Preset K (Performance), falls es wen interessiert.

-->https://imgsli.com/MzY2OTc4

https://i.ibb.co/YsHSdnN/gta.png (https://ibb.co/mWfKyZR)

[robbitop]

Der FSR 3.1 Input von GTA 5 für OptiScaler scheint einwandfrei zu sein, auch DoF scheint weiterhin gut auszusehen.
Zwar kein direkter Vergleich, aber imho matschen weit entfernte Autos/NPCs in Bewegung weniger als mit DLSS Preset K (4k Performance):
https://s1.directupload.eu/images/250405/temp/32ywropu.jpg (https://www.directupload.eu/file/d/8880/32ywropu_jpg.htm)
Smearing tendiert auch gegen 0. Allerdings wird es hinter Gitterzäunen in Bewegung ziemlich unscharf.

Wie hast du FSR3.1 Input bekommen? Das Spiel hat ja eigentlich nur FSR3(.0)
:)

[DrFreaK666]

Mit Optiscaler kann man den Input ändern, oder nicht!?

[robbitop]

Optiscaler leitet den vorhandenen Input um. Also kann aus fsr3 oder dlss3.7 (die in gta5 enhanced) vorhanden sind dann fsr3.1 oder 4 machen. Aber fsr3.1 Input ist dadurch trotzdem nicht da.

Weiterhin: wie kriegt ihr mit gta5denn Optiscaler zu laufen? Ich hab die steam, die epic und die rockstar version. Und immer blockiert battleye den Start wenn Optiscaler installiert ist. Und Battleye ausschalten bringt auch nix. Braucht man dafür einen Keks? ^^

Meine Vermutung ist wenn man Kekse nutzt gibt es grundsätzlich viel weniger Ärger weil die ganze Anti Cheat und TPM Scheisse dazwischen funkt. Als Zahlender haste sozusagen nur Nachteile ^^

[aufkrawall]

Wie hast du FSR3.1 Input bekommen? Das Spiel hat ja eigentlich nur FSR3(.0)
:)
Ich hatte dir schon mal mitgeteilt, dass es 3.1 ist.
Und auch, wie man es ohne Keks zum Laufen bekommt. Du liebe Güte...

[robbitop]

Schade dass es so unfreundlich ausgedrückt ist. Meine Intention war nicht, dich zu verärgern.
Ich muss dein Posting übersehen oder vergessen haben. Ich bin auch nur ein Mensch.

[aufkrawall]

Hat nichts mit unhöflich zu tun. Da grenzt schon an Täglich grüßt das Murmeltier:
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13726696#post13726696
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13726847#post13726847
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13729667#post13729667

"Übersehen". :freak:

[robbitop]

Ah ok - Ich erinnere mich wieder. Sorry ich habe es dann wohl vergessen (ich schrieb ja auch „übersehen ODER vergessen“ :)). Es gibt im Leben noch eine ganze Menge mehr als das Forum - anstrengender Job, 2 Kleinkinder usw. Irgendwas fällt dann mal offenbar raus. Passiert mir sonst nicht so krass… Ich bitte vielmals um Entschuldigung. Wie gesagt geht es mir nie darum hier jemanden zu verärgern. :)

[aufkrawall]

Das ist natürlich vollkommen ok, Kudos fürs Kinder Aufziehen. Einfach cool bleiben. :)

[robbitop]

BTT:
Schon komisch dass Rockstark nicht „3.1“ im Menü schreibt.

Jedenfalls würde diese komplizierte Art Optiscaler zum Laufen zu kriegen (wobei eine bat datei auch handelbar ist - aber ist halt noch ein Schritt mehr und es gibt auch Spiele wo man dann wieder mit anderen Ansätzen rumfrickelnmüsste) mit Keks wahrscheinlich nicht nötig sein.

Ich glaube so lange ich meine 3080 noch hab experimentiere ich mal bei den Spielen rum wo es nicht geht mit Keks mal rum (ich hab ja dafür bezahlt). Wenn es dann immer geht -> hab ich einen Grund mich zu ärgern nicht die 9070xt genommen zu haben (wäre ja 150€ fast billiger) weil das ein Hauptgrund war. Wenn Optiscaler immer geht hat man ja immer FSR4. Ich kaufe eh immer alle Spiele ehrlich - dann kann ich sie auch ohne Gewissensbisse „keksen“

[aufkrawall]

BTT:
Schon komisch dass Rockstark nicht „3.1“ im Menü schreibt.

Jedenfalls würde diese komplizierte Art Optiscaler zum Laufen zu kriegen mit Keks wahrscheinlich nicht nötig sein.

Mit Epic/Steam ist es ja nicht komplizierter als sonst.
Btw. kann man in OptiScaler auch die Inputs für FSR 2/3.0 abschalten und nur Inputs für FidelityFX API (FSR 3.1) aktiviert lassen, womit es in GTA funktioniert. Ziemlich eindeutig.

[DrFreaK666]

... Wenn Optiscaler immer geht hat man ja immer FSR4...

Das geht halt leider nicht immer

[aufkrawall]

Richtig, gibt noch ein Problem in Spielen mit hardgelinkter D3D12-Runtime wie Control. FSR 3.1 geht da, 4.0 nicht.
Ob sich das noch ändern wird, steht wohl immer noch nicht fest. Dürfte aber nicht unplausibel sein, dass sich nach FSR 4-Release auf GitHub noch manche Dinge verbessern werden. Irgendwelche Problemfälle wirds halt immer geben.

[robbitop]

Eigentlich total schade wenn man bedenkt, dass das Verfahren wirklich wettbewerbsfähig ist und es die gleichen Inputs wie DLSS braucht.
Man hätte etwas eher das Verfahren so bauen müssen dass es sauber upgradebar ist, dann würde es ihnen heute nicht so auf die Füße fallen. Aber was soll’s - zu spät ist es nie.
Mit der HW und SW hat man die Lücke ja echt deutlich verkleinert. Jetzt muss man aber hoffentlich nachlegen und dranbleiben. Dann wird es mit der Verbreitung deren SW und mit dem Erfolg auch was.

[Gast]

Eigentlich total schade wenn man bedenkt, dass das Verfahren wirklich wettbewerbsfähig ist und es die gleichen Inputs wie DLSS braucht.


Wie schade dass man seit Jahren aus Eitelkeit Streamline ignoriert.

[crux2005]

1DbM0DUTnp4

GN meint das FSR4 ein CNN ist und durch die Kollaboration mit Sony entstanden ist ("co-developed by Sony"). Basierend auf dem PS5 Pro Video von Cerny soll PSSR eine umbenannte FSR4 Version sein. Das ist eine wilde Interpretation. :freak:

[robbitop]

AMD hat gesagt es ist ein Hybrid und es gibt ein Paper was einen Hybrid aus Transformer und CNN beschreibt. Das ist eher eine serielle Verschaltung von CNN und Transformer. Nutzt FP8.
Hier in dem Video geht ein Dev durch das Paper und schaut sich auch an wie man so aus FSR4 ein FSR4 lite für RDNA3 machen könnte.
https://www.youtube.com/watch?v=X51DEwAhMqU

PSSR ist nur CNN und nutzt INT8.

[Gast]

GN meint das FSR4 ein CNN ist und durch die Kollaboration mit Sony entstanden ist ("co-developed by Sony"). Basierend auf dem PS5 Pro Video von Cerny soll PSSR eine umbenannte FSR4 Version sein. Das ist eine wilde Interpretation. :freak:

Zumindest dass es ein Co-Development von Sony und AMD ist, ist ja bestätigt.

Wie genau das "Verwandschaftsverhältnis" aussieht wird man von außen wohl schwer beurteilen können.

[aufkrawall]

Talos Reawakened hat nun FSR 3.1 + Anti-Lag 2. Gibt noch keinen Treiber-Toggle für FSR 4, aber es scheint mit OptiScaler einwandfrei zu funktionieren.
Der Sprung von FSR 3.1 mit Nanite und Lumen/VSM ist so krass, es ist kaum in Worte zu fassen.

Edit: Das nativ implementierte FG mit Anti-Lag 2 skaliert wieder mit 80% mit 4k 60fps Basis.

[Lurtz]

Talos Reawakened hat nun FSR 3.1 + Anti-Lag 2. Gibt noch keinen Treiber-Toggle für FSR 4, aber es scheint mit OptiScaler einwandfrei zu funktionieren.
Der Sprung von FSR 3.1 mit Nanite und Lumen/VSM ist so krass, es ist kaum in Worte zu fassen.
Wie verhält sich FSR4 bei Strafing vor den Eisengittern, pixelt Content dahinter auch auf?

[Relex]

SWTot0wwaEU

[dargo]

Breaking News... Upscaling ist bei einer höheren Auflösung noch besser. :freak:

[aufkrawall]

Wie verhält sich FSR4 bei Strafing vor den Eisengittern, pixelt Content dahinter auch auf?
FSR 4 wird bei so etwas eher ziemlich unscharf/ghosty. Wobei es sonst im Grunde ~gar nicht ghostet.

[basix]

Breaking News... Upscaling ist bei einer höheren Auflösung noch besser. :freak:

Keine Breaking News aber ein paar interessante Dinge hat es trotzdem drin. Zum Beispiel, dass Q in 4K nicht mehr instabiler ist wie B.

Bin auf zwei Dinge gespannt:
- Das nächste FSR4 Update
- 1080p Tests. Für mich mehr akademischer Natur, Stressetst für die Technik. Für Mobile- / iGPU-Gaming allenfalls von Interesse.

[aufkrawall]

Kannst es ja als AA für 1080p nutzen, oder mit OptiScaler mit irgendeinem anderen Wert zwischen 66-100%.

[basix]

Habe keine RDNA4 Karte, deswegen schwierig zum Testen ;)

[Lurtz]

Breaking News... Upscaling ist bei einer höheren Auflösung noch besser. :freak:
Finde es schon bemerkenswert. AMD hat DLSS im ersten AI-Upscaling-Versuch im Grunde geschlagen. Es ist besser als DLSS3, was wohl kaum jemand wirklich erwartet hat, und solange DLSS4 in Beta ist und deutliche Regressionen zeigt, arguably gerade der ausgewogenste Upscaler überhaupt.

Und das ganz ohne dass man seinen tollen Supercomputer-Machine-Learning-Cluster beworben hat :ugly:

Die Verbreitung bleibt halt ein Problem, insbesondere weil AMD ja bereits bewiesen hat, dass man nicht in der Lage ist, selbst Spiele, die es prinzipiell supporten würden, zeitnah im Treiber freizuschalten.
Die Begründung mit dem Test der Qualität ist da ja auch reine Augenwischerei wenn FSR 4 Performance Optiscaler mit FSR 3 Quality Ingame-Implementierung den Boden aufwischt.

[aufkrawall]

Ist jedenfalls mit Nanite auch gut am Limit bei Bewegung von Objekten vor anderen, gibt einiges an Ghosting-Smearing/Disocclusion-Blur.

[Exxtreme]

Angeblich arbeitet AMD an einer FSR4-Implementierung für RDNA3-Grafikkarten:

rrLgahCIgtk

Edit: Hier mit TS: https://youtu.be/rrLgahCIgtk?t=1237

[aufkrawall]

FSR FG bzw. HAGS ist wirklich kaputt auf RDNA4. :freak:
In Talos Reawakened sieht das auf der 3060 (mit reduzierten Details) mit FSR 3.1 ~komplett flüssig aus, während auf der 9070 die reale Bildausgabe komplett unsauber war und sogar meinen IPS-Monitor zum Flackern gebracht hatte. :freak:
Mit der 7800 XT sah FG im letzten Sommer noch erstklassig flüssig aus, auf der 9070 ist es quasi nutzlos. Haben sie wieder mal schön hingekriegt. :facepalm:

[3D-User]

Angeblich arbeitet AMD an einer FSR4-Implementierung für RDNA3-Grafikkarten

Wäre echt super, auch wenn es vermutlich nicht dasselbe Ergebnis wie auf einem RDNA 4 Chip liefern können wird, aber wer weiß? :wink:

[dildo4u]

FSR Redstone für RDNA4 angekündigt

https://www.computerbase.de/news/grafikkarten/fsr-redstone-amd-legt-mit-upgrades-fuer-fsr-4-1-auf-rdna-4-nach.92758/

[basix]

Wenn AMD mit RR das wiederholt, was man qualitativ mit FSR4 SR geschafft hat, wäre das ziemlich nice.

Ein verbessertes Framegen ist auch schön und MFG wäre höchstens noch ein nice-to-have.

Was mMn fehlt:
RDNA3 Support für zumindest SR und FG.

[Relex]

Oh wow, die AMD Ingenieure haben sich wohl kürzlich die Nvidia Paper durchgelesen? :idea:

[DrFreaK666]

...RDNA3 Support für zumindest SR und FG.

Das programmieren die sicherlich erst, wenn FSR 4.5 (oder wie das am Ende heißen wird) fertig ist.
Ich bin jedenfalls gespannt :smile:

Oh wow, die AMD Ingenieure haben sich wohl kürzlich die Nvidia Paper durchgelesen? :idea:
Bei GPUOpen gibts AMD-eigene Paper

[Lurtz]

https://s1.directupload.eu/images/250521/r3fcqsvd.jpg

[The_Invisible]

Bei Nvidia hätte es schon wieder Youtube Videos gegeben das ihnen die Besitzer älterer Karten schei*egal sind :D

[Exxtreme]

Womöglich kann RDNA3 und kleiner kein FSR4 in annehmbarer Geschwindigkeit. Upscaling macht keinen Sinn wenn es langsamer läuft als TAA.

[aceCrasher]

FSR Redstone für RDNA4 angekündigt

https://www.computerbase.de/news/grafikkarten/fsr-redstone-amd-legt-mit-upgrades-fuer-fsr-4-1-auf-rdna-4-nach.92758/
Sehr sehr gute Narichten. AMD ist endlich auf dem richtigen Weg. FSR4 war der erste Schritt, das hier ist der logische nächste.

Die große Hürde stellt jetzt nur noch die Verbreitung da. Die besten Technologien bringen einem nichts wenn sie nicht breit verfügbar sind. Sollte dass in ein paar Jahren der Fall sein, könnte ich mir sogar vorstellen nach meiner 4090 wieder eine AMD Karte zu kaufen.

[Ex3cut3r]

Bei Nvidia hätte es schon wieder Youtube Videos gegeben das ihnen die Besitzer älterer Karten schei*egal sind :D

This. Wo sind denn nun die ganzen YouTuber wie bei Nvidia, die jeden Furz kritisieren? ;D

Ach, es bringt nicht so viele Klicks/Geld wie wenn Nvidia in der Überschrift ist? Ach dann, lass mal stecken....

[DrFreaK666]

Bei Nvidia hätte es schon wieder Youtube Videos gegeben das ihnen die Besitzer älterer Karten schei*egal sind :D

Bei Nvidia? Nvidia hätte die Videos also selbst erstellt :biggrin:
Du lebst anscheinend sowieso in einer anderen Realität.
In jedem FSR4-Test wurde gesagt, dass es nur auf RDNA4 läuft

This. Wo sind denn nun die ganzen YouTuber wie bei Nvidia, die jeden Furz kritisieren? ;D

Ach, es bringt nicht so viele Klicks/Geld wie wenn Nvidia in der Überschrift ist? Ach dann, lass mal stecken....
Dass RX9060XT auch mit 8GB kommt, wurde schon im Vorfeld kritisiert :rolleyes:
Im neuen Video von Hardware Unboxed wird die 8GB-Version als "bad version" bezeichnet

[Ex3cut3r]

Geht jetzt nicht um 8GB, sondern das RDNA 3 und tiefer kein FSR 4 bekommen. Bei Nvidia bekomst du DLSS Transformer runter auf die 2060. Eine Karte von 2018. :freak:

[DrFreaK666]

Geht jetzt nicht um 8GB, sondern das RDNA 3 und tiefer kein FSR 4 bekommen. Bei Nvidia bekomst du DLSS Transformer runter auf die 2060. Eine Karte von 2018. :freak:
Schön für Besitzer der 6GB-Karte.
Dir passt es eher nicht, dass AMD wieder aufschließt.

Kann mich auch an kein Video erinnern, in dem es deswegen einen Rant gab. Aber du kennst sicherlich einige und kannst sie hier aufzählen

[OgrEGT]

Geht jetzt nicht um 8GB, sondern das RDNA 3 und tiefer kein FSR 4 bekommen. Bei Nvidia bekomst du DLSS Transformer runter auf die 2060. Eine Karte von 2018. :freak:
Warum nicht auch auf Pascal?

[Ex3cut3r]

Schön für Besitzer der 6GB-Karte.
Dir passt es eher nicht, dass AMD wieder aufschließt.


Ja genau. Das wird es sein. Pack deine Verschwörungen wieder ein. Und ruf mich an, wenn der AMD Top Dog schneller ist als Nvidia Top Dog. Was dieses Jahrzehnt nicht mehr passieren wird. Kann ich dir jetzt schon sagen.

Warum nicht auch auf Pascal?

Keine Tensor Cores.

[DrFreaK666]

Geht jetzt nicht um 8GB, sondern das RDNA 3 und tiefer kein FSR 4 bekommen.
ruf mich an, wenn der AMD Top Dog schneller ist als Nvidia Top Dog.
Geht hier nicht um Nvidia! Auch nicht um Top Dogs

[OgrEGT]

(...)

Keine Tensor Cores.
Siehst du... es gibt einen technischen Grund... den gibt es bei RDNA3 zu RDNA4 eben auch... umso mehr wäre es erfreulich wenn FSR4 auch für RDNA3 kommt auch wenn es sehr wahrscheinlich sehr hohe Leistungseinbußen geben wird...

[The_Invisible]

Schön für Besitzer der 6GB-Karte.
Dir passt es eher nicht, dass AMD wieder aufschließt.


Rennt doch auf der 2060 gut dank DLSS: https://www.youtube.com/watch?v=2SjqahVBg-c

Wie rennt es auf AMD von diesem Zeitraum? Aso die haben ja nicht mal RT Hardware damit das Game überhaupt startet :freak:

[Relex]

Womöglich kann RDNA3 und kleiner kein FSR4 in annehmbarer Geschwindigkeit. Upscaling macht keinen Sinn wenn es langsamer läuft als TAA.


XeSS schaft es doch auch, besser als FSR3.1 zu sein und dabei in sachen performance sinnvoll zu bleiben. Gerade mit Raytracing lohnt sich upscaling immer, da man da über die Auflösung viel performance zurück gewinnt. Da kann der Algo auch teuer sein.

AMD wäre also eigentlich unter Zugzwang.

Ich kann mir aber auch vorstellen, dass man sich denkt, dass die Spieler dann eben einfach XeSS nutzen sollen, weil AMD es auf RDNA3 wohl auch nicht viel besser hinbekommen würde. So spart man sich wieder kosten.

[Exxtreme]

Xess ist nicht grundsätzlich besser als FSR 3.1. Xess ist in etwa eine matschigere Version von DLSS 2. Und schon die simplere Dp4a-Variante von Xess kostet ordentlich Leistung auf den Radeons. Aber ja, die könnten sowas eventuell einbauen so als Placebo.

[Ex3cut3r]

Siehst du... es gibt einen technischen Grund... den gibt es bei RDNA3 zu RDNA4 eben auch... umso mehr wäre es erfreulich wenn FSR4 auch für RDNA3 kommt auch wenn es sehr wahrscheinlich sehr hohe Leistungseinbußen geben wird...

RDNA 3 verfügt zwar über sogenannte Tensor Cores, deren genaue Funktion jedoch bislang unklar ist. Für ältere Architekturen wie RDNA 2 oder früher wäre es sinnvoll, eine Art Fallback-Lösung anzubieten – diese würde zwar nicht die KI-Qualität von RDNA 4 erreichen, könnte aber dennoch bessere Ergebnisse liefern als FSR 3.1.

[Relex]

Habs gestern erst in Doom ausprobiert. XeSS sieht um Welten besser aus als FSR.
Aber gut, mag nicht für jedes Spiel gelten...

[DrFreaK666]

FSR 4.5 ist für AMD vermutlich von höherer Priorität als FSR 4 für RDNA3. Möglicherweise arbeitet derzeit nur ein kleines Team daran, oder sie kümmern sich erst später darum.

[Ex3cut3r]

FSR 4.5 ist für AMD vermutlich von höherer Priorität als FSR 4 für RDNA3. Möglicherweise arbeitet derzeit nur ein kleines Team daran, oder sie kümmern sich erst später darum.

Viele deiner Argumente wirken wie Ausreden oder spekulative Aussagen. FSR 3 überzeugt nicht. Interessanterweise liefert XeSS im sogenannten „Fallback-Modus“ auf AMD-Grafikkarten teils bessere Ergebnisse als FSR 3 – was durchaus bemerkenswert ist. Das lässt sich schwer schönreden. Zudem scheint alles unterhalb von RDNA 3 keine Rolle mehr zu spielen, nach dem Motto: „Das ist uns egal.“

[Exxtreme]

Habs gestern erst in Doom ausprobiert. XeSS sieht um Welten besser aus als FSR.
Aber gut, mag nicht für jedes Spiel gelten...

Das mag in Doom vielleicht so sein. Es gibt aber auch andere Beispiele. Hier mal ein Vergleich:
https://www.techspot.com/review/2860-amd-fsr-31-versus-dlss/

[DrFreaK666]

Viele deiner Argumente wirken wie Ausreden oder spekulative Aussagen. FSR 3 überzeugt nicht. Interessanterweise liefert XeSS im sogenannten „Fallback-Modus“ auf AMD-Grafikkarten teils bessere Ergebnisse als FSR 3 – was durchaus bemerkenswert ist. Das lässt sich schwer schönreden. Zudem scheint alles unterhalb von RDNA 3 keine Rolle mehr zu spielen, nach dem Motto: „Das ist uns egal.“
Wo hab ich FSR3 erwähnt? :freak:

[Gast]

Was mMn fehlt:
RDNA3 Support für zumindest SR und FG.

RDNA3 Käufer sind selbst schuld. Bei Turing konnte man noch Verzeihen, wenn ein Käufer AI-Beschleuniger als "Gimmick" betrachtet, aber spätestens seit DLSS2 war das enorme Potential offensichtlich. Wer sich danach noch freiwillig für eine Grafikkarte ohne AI-Beschleuniger entschieden hat dem kann man nicht mehr helfen.

[basix]

Der simpelste Weg wäre für AMD, FSR4 einfach als FP16 Fallback anstatt FP8 anzubieten. Klar, ein paar Performance-Optimierungen gehören da noch dazu, aber man kann die ja auf moderatem Aufwand halten.

Eine 9060XT liefert knapp 200 TFLOPS FP8. Eine 7700XT 70 TFLOPS FP16 und hat eine höhere Speicherbandbreite. Beide sind in Raster-Games in etwa gleich schnell. Dazu der Fakt, dass das DNN einen eher kleinen Teil von der gesamten Ausführungszeit ist (kennen wir von DLSS2+ und wurde bei FSR4 ebenfalls aufgezeigt). Ich sehe da also keinen Showstopper.

Dito, wenn man bei den APUs die NPU mit Block-FP16 zu Hilfe nimmt. Sind doch immerhin 50 TFLOPS bei meistens niedriger Auflösung und nur 12...16 CU.

RDNA3 Käufer sind selbst schuld. Bei Turing konnte man noch Verzeihen, wenn ein Käufer AI-Beschleuniger als "Gimmick" betrachtet, aber spätestens seit DLSS2 war das enorme Potential offensichtlich. Wer sich danach noch freiwillig für eine Grafikkarte ohne AI-Beschleuniger entschieden hat dem kann man nicht mehr helfen.
Auch RDNA3 hat AI-Beschleunigung drin ;) Verglichen mit z.B. Nvidia Ampere steht man dort nichtmal so schlecht da, solange man nur FP16 FLOPS anschaut (was DLSS2 & DLSS3 sowie DLSS3 RR & FG waren).

Und das was bei Turing und dann 2 Jahre später mit DLSS2 geschehen ist, wusste 2018 noch niemand. Das war mehr "Glück" für die Käufer als etwas, was man erwarten konnte.

[Relex]

Nutzt XeSS denn FP16?

Ich stell mir halt die Frage, wie RDNA3 mit solchen KI workloads umgeht, wenn gleichzeitig Grafik berechnet wird. Nvidia hat die Tensor Cores, die dediziert sind und die volle Leistung bereitstellen können. AMD muss dafür entsprechend Rechenzeit für die restliche Rastergrafik opfern, weil die Compute Units sowohl das DNN als auch die Grafikberechnungen durchführen.

Aber wenn das bei XeSS schon genauso funktioniert, dann spricht da ja in der Tat nichts dagegen.

[basix]

Wie immer: Async Compute.

Und auch wenn Nvidias Tensor Cores parallel laufen können, wird denoch L1$ sowie Register-File belegt. Und soweit ich beurteilen kann, läuft während der DNN-Ausführung von DLSS2+ nicht viel parallel. Und selbst wenn, wären die <1ms "GPU-Lock" fürs DNN kein Beinbruch (DLSS2...4 benötigt auf einer RTX4090 ~0.25ms mit ca. 50% Load auf den Tensor Cores). Dann hat man halt nur noch 90fps anstatt 100fps. Dafür aber das viel bessere SR. Guter Trade.

[Der_Korken]

Womöglich kann RDNA3 und kleiner kein FSR4 in annehmbarer Geschwindigkeit. Upscaling macht keinen Sinn wenn es langsamer läuft als TAA.

So langsam, dass man es nicht sinnvoll nutzen kann, wird es schon nicht sein. Die Qualität von FSR4 ist so viel besser, dass FSR4 Balanced besser aussieht als FSR3 Quality. Selbst wenn das Upscaling so viel Leistung frisst, dass Balanced nur noch auf Quality-Performance kommt (was ich nicht glaube), wäre es immer noch ein Gewinn für RDNA3. Bei RDNA2 und kleiner könnte es schon eher problematisch werden, weil da nicht nur die Einheiten, sondern auch die Instruktionen fehlen.

[Troyan]

Auch RDNA3 hat AI-Beschleunigung drin ;) Verglichen mit z.B. Nvidia Ampere steht man dort nichtmal so schlecht da, solange man nur FP16 FLOPS anschaut (was DLSS2 & DLSS3 sowie DLSS3 RR & FG waren).

Und das was bei Turing und dann 2 Jahre später mit DLSS2 geschehen ist, wusste 2018 noch niemand. Das war mehr "Glück" für die Käufer als etwas, was man erwarten konnte.

Nichts war Glück an DLSS 2. 2018 war man längst im Bilde zu was ML bei der Bildbetrachtung möglich macht.

[basix]

Nichts war Glück an DLSS 2. 2018 war man längst im Bilde zu was ML bei der Bildbetrachtung möglich macht.

Klar, erzähl mir mehr. Oder hast du DLSS1 vergessen, was damals SotA war? Das war kaum besser wie CAS von AMD.

So Sachen wie Stable Diffusion gibt es auch erst seit 2022.

Man konnte erahnen, dass ML/AI immer besser wird. Aber das Potential hat man als Non-Experte sicher nicht vollumfänglich erfassen können. Transformer waren auch gerade erst nigelnagelneu. Ich rede ja nicht davon, dass DLSS2 als Technik an sich Glück war. Nvidia weiss schon, was sie da machen (DLSS1 war allerdings kein Heilsbringer). Sondern dass ein Turing Käufer 2018 kaum erahnen konnte, dass DLSS2 Mitte 2020 erscheinen und so viel besser als DLSS1 sein wird. Deswegen Glück für den Käufer. Der hat die Karte mit hoher Wahrscheinlichkeit nicht wegen den Tensor Cores gekauft. Seit DLSS2 / Ampere sieht das natürlich etwas anders aus. Da ist DLSS definitiv ein Mehrwert gewesen.

[Relex]

Wie immer: Async Compute.

Und auch wenn Nvidias Tensor Cores parallel laufen können, wird denoch L1$ sowie Register-File belegt. Und soweit ich beurteilen kann, läuft während der DNN-Ausführung von DLSS2+ nicht viel parallel. Und selbst wenn, wären die <1ms "GPU-Lock" fürs DNN kein Beinbruch (DLSS2...4 benötigt auf einer RTX4090 ~0.25ms mit ca. 50% Load auf den Tensor Cores). Dann hat man halt nur noch 90fps anstatt 100fps. Dafür aber das viel bessere SR. Guter Trade.


Deswegen frag ich. Du kennst dich da viel besser aus.
Was du schreibst ist mir aber auch klar, aber ich stelle mir trotzdem die Frage, ob XeSS bereits äquivalent zu einem FSR4 port funktionieren würde.

Die Frage ist, haben wir bereits ein Anwendungsbeispiel bei dem ein DNN mit FP16 auf RDNA3 neben der Grafikberechnung läuft? Vermutung wäre XeSS, aber ich weiß eben nicht, ob das vergleichbar wäre.


Spekulieren kann man natürlich immer, aber ein vergleichbares Beispiel wäre da schon handfester.

Vielleicht gibts ja doch irgend nen Falschenhals der da Probleme macht, sonst hätte AMD FSR4 doch längst für RDNA3 angekündigt, meinetwegen für Ende des Jahres. Nachdem Nvidia DLSS4 für alle RTX GPUs freigegeben hat, stehen sie doch eh schon unter zugzwang. Dass da nichts offizielles kommt ist in der Situation mMn. schon merkwürdig.

[w0mbat]

RDNA 3 verfügt zwar über sogenannte Tensor Cores, deren genaue Funktion jedoch bislang unklar ist. Für ältere Architekturen wie RDNA 2 oder früher wäre es sinnvoll, eine Art Fallback-Lösung anzubieten – diese würde zwar nicht die KI-Qualität von RDNA 4 erreichen, könnte aber dennoch bessere Ergebnisse liefern als FSR 3.1.
RDNA3 hat eben keine Tensor Cores, die hat erst RDNA4.

[Troyan]

Klar, erzähl mir mehr. Oder hast du DLSS1 vergessen, was damals SotA war? Das war kaum besser wie CAS von AMD.

So Sachen wie Stable Diffusion gibt es auch erst seit 2022.

Man konnte erahnen, dass ML/AI immer besser wird. Aber das Potential hat man als Non-Experte sicher nicht vollumfänglich erfassen können. Transformer waren auch erst gerade nigelnagelneu. Ich rede ja nicht davon, dass DLSS2 als Technik an sich Glück war. Nvidia weiss schon, was sie da machen (DLSS1 war allerdings kein Heilsbringer). Sondern dass ein Turing Käufer 2018 kaum erahnen konnte, dass DLSS2 Mitte 2020 erscheinen und so viel besser als DLSS1 sein wird. Deswegen Glück für den Käufer. Der hat die Karte mit hoher Wahrscheinlichkeit nicht wegen den Tensor Cores gekauft. Seit DLSS2 / Ampere sieht das natürlich etwas anders aus. Da ist DLSS definitiv ein Mehrwert gewesen.

Weil der erste Versuch ML für Upscaling nicht der große Wurf war, war alles andere daran Glück. Aha.

AMD hat zwei Jahre länger für FSR 2 benötigt als nVidia von DLSS 1 zu DLSS 2. nVidia hat früh DLSS 1 aufgegeben und weiter geforscht. Deswegen gab es im Janaur 2020 DLSS 2 schon in Wolfenstein YB und Deliver us the Mars.

Aber hey, offensichtlich hatte AMD nicht zuviel Glück mit ML FSR. Die brauchten ja nur fünf Jahre seit DLSS 2. ;D

[basix]

Du verstehst auch nur das, was du verstehen willst, nicht?

Also nochmals, damit du es hoffentlich auch kapierst:
- DLSS1 war Kacke (aber SotA von 2018)
- DLSS2 war gut und kein Glück von Engineering Seite (SotA 2020)
- DLSS2 war glücklich für die Turing Käufer, weil man das als Consumer 2018 nicht erwarten konnte

Und dass AMD länger als Nvidia gebraucht hat ist auch klar:
- AMD ist eine kleinere Firma mit deutlich geringerem Budget
- AMD hatte die HW noch nicht ready (weswegen ML/AI nur begrenzt Sinn gemacht hätte -> FSR2 sollte zudem auf den Konsolen laufen) -> HW-Entwicklungszeiten sind 3-4 Jahre
- ML/AI ist Nvidias Zugpferd (Expertise, Umsätze)
- Deswegen sucht sich Nvidia aktiv Konkurrenzvorteile mit Hilfe von ML/AI -> Entsprechende Technologie wird gepusht

[Gast]

Auch RDNA3 hat AI-Beschleunigung drin ;)



Hat sie nicht, sie kann lediglich kleinere Datenformate, die für AI gebraucht werden, schneller ausführen als Full Precision.


Verglichen mit z.B. Nvidia Ampere steht man dort nichtmal so schlecht da, solange man nur FP16 FLOPS anschaut (was DLSS2 & DLSS3 sowie DLSS3 RR & FG waren).


Und genau das ist der Fehler. FLOPs vergleichen hat quasi 0 Aussagekraft. Bei Nvidia und auch Intel stehen die Tensor bzw. XMX OPS zusätzlich zur Verfügung.
Bei AMD hast du vielleicht schöne Peak FP16 FLOPs, aber gleichzeitig 0 FP32 FLOPs.


Und das was bei Turing und dann 2 Jahre später mit DLSS2 geschehen ist, wusste 2018 noch niemand. Das war mehr "Glück" für die Käufer als etwas, was man erwarten konnte.

2018 gab es noch kein RDNA3. Wie gesagt 2018 war es vielleicht noch verständlich eine Grafikkarte ohne dedizierter AI-Hardware zu kaufen, spätestens ab 2020 nicht mehr.

[Gast]

Selbst wenn das Upscaling so viel Leistung frisst, dass Balanced nur noch auf Quality-Performance kommt (was ich nicht glaube), wäre es immer noch ein Gewinn für RDNA3.

Das ist sogar sehr wahrscheinlich, beim besten Praxisbeispiel was wir aktuell XeSS, und dafür braucht man auf RDNA regelmäßig eine Qualitätsstufe niedriger um auf die Performance von FSR2/3 zu kommen. Bzw. Intel hat sogar die Bezeichnung ihrer Qualitätsstufen so angepasst, dass nun vergleichbar schnelle gleich heißen, und nicht jene welche die selbe Auflösung verwenden.

Da FSR4 aller Wahrscheinlichkeit aufwändiger als XeSS ist, ist das wohl das Maximum was FSR4 an Performance erreichen könnte, mich würde nicht wundern wenn man sogar 2 Qualitätsstufen niedriger verwenden müsste.

[Gast]

Der simpelste Weg wäre für AMD, FSR4 einfach als FP16 Fallback anstatt FP8 anzubieten.


WTF soll das? Nur weil eine Hardware FP8 nicht schneller kann ist sie damit doch nicht langsamer. Im worst case ist man mit FP8 gleich schnell, evtl. noch immer etwas schneller, schließlich spart man auch ohne schnellere FP8 Berechnung immer noch Platz und Bandbreite zu Caches/Register etc..


Klar, ein paar Performance-Optimierungen gehören da noch dazu, aber man kann die ja auf moderatem Aufwand halten.


Mich würde mal interessieren auf welcher Grundlage du dies beurteilen kannst.

[basix]

Hat sie nicht, sie kann lediglich kleinere Datenformate, die für AI gebraucht werden, schneller ausführen als Full Precision.

WMMA Instruktionen = Acceleration. Damit kann man die FLOPS auch auslasten. FP16 mit FP32 Accumulate läuft auf RDNA3 sogar deutlich schneller als auf Ampere (FP16 mit FP16 Accumulate etwa gleich)


Und genau das ist der Fehler. FLOPs vergleichen hat quasi 0 Aussagekraft. Bei Nvidia und auch Intel stehen die Tensor bzw. XMX OPS zusätzlich zur Verfügung.
Bei AMD hast du vielleicht schöne Peak FP16 FLOPs, aber gleichzeitig 0 FP32 FLOPs.
Hast du dir mal ein paar ML/AI Benchmarks angeschaut? Vermutlich nicht. Selbst RDNA3 sieht nicht so schlecht aus. Nicht überall, aber oft: https://www.computerbase.de/artikel/grafikkarten/nvidia-geforce-rtx-5060-ti-16-gb-test.92119/seite-7

Und ich habe mir DLSS via Nsight schon ein paar mal angeschaut (wie gesagt ~0.25ms und 50% Auslastung auf einer RTX 4090 mit 330 TFLOPS FP16 -> 4K Output). Der Anteil von FP16 Tensor ist also ziemlich gering, ca. 30...40 GFLOPS pro Frame in 4K. Nehmen wir die selben 50% Auslastung und 120 TFLOPS FP16 einer 7900XTX und dass 0% anderes parallel gemacht werden kann: Die GPU wäre für 0.67ms vom DNN belegt. Selbst bei 150fps in 4K wäre das eine Performanceverringerung auf lediglich 135fps. Extrem tragisch, doch ;)



2018 gab es noch kein RDNA3. Wie gesagt 2018 war es vielleicht noch verständlich eine Grafikkarte ohne dedizierter AI-Hardware zu kaufen, spätestens ab 2020 nicht mehr.
Ob die HW dediziert ist oder nicht, ist egal. Die Anwendungsperformance ist entscheidend.

[Gast]

Wie immer: Async Compute.


Async-Compute zaubert nicht plötzlich zusätzliche Hardware her.
Async-Compute kann nur Bubbles füllen die andere Aufgaben hinterlassen, und solche Bubbles existieren nur wenn die Ausführung einer Aufgabe ineffizient läuft.

Um mal mit einer zugegebenermaßen eher schlechten Analogie zu kommen, Async-Compute ist sowas wie SMT bei CPUs, dedizierte echte Hardware sind dagegen zusätzliche Cores.

[Gast]

Hast du dir mal ein paar ML/AI Benchmarks angeschaut? Vermutlich nicht. Selbst RDNA3 sieht nicht so schlecht aus. Nicht überall, aber oft: https://www.computerbase.de/artikel/grafikkarten/nvidia-geforce-rtx-5060-ti-16-gb-test.92119/seite-7


Erstens genau die selbe falsche Interpretation wie stumpfe FLOP-Vergleiche. In einem reinen AI-Benchmark, wenn man keinerlei Grafik nebenher berechnen muss, kann man die Peak-FLOPs natürlich viel besser auszutzen.

Und zweitens weiß ich auch nicht was du mit diesen Benchmarks zeigen willst, selbst mit dieser falschen Interpretation, die Ergebnisse sind selbst in diesem Best-Case für alles von AMD vor RDNA4 sehr bescheiden.

[basix]

Async-Compute zaubert nicht plötzlich zusätzliche Hardware her.
Async-Compute kann nur Bubbles füllen die andere Aufgaben hinterlassen, und solche Bubbles existieren nur wenn die Ausführung einer Aufgabe ineffizient läuft.

Um mal mit einer zugegebenermaßen eher schlechten Analogie zu kommen, Async-Compute ist sowas wie SMT bei CPUs, dedizierte echte Hardware sind dagegen zusätzliche Cores.
Nein das nicht. Ich habe aber jetzt bereits mehrmals rechnerisch dargelegt, dass zusätzliche HW selbst im Worst Case (0% andere Tasks parallel, RDNA3 ohne dedizierte Matrix-Cores) kein Beinbruch sind. Und da eine GPU selten zu 100% ausgelastet ist, finden sich dort immer ein paar Lücken, wodurch Async Compute effektiv werden kann.

Erstens genau die selbe falsche Interpretation wie stumpfe FLOP-Vergleiche. In einem reinen AI-Benchmark, wenn man keinerlei Grafik nebenher berechnen muss, kann man die Peak-FLOPs natürlich viel besser auszutzen.

Und zweitens weiß ich auch nicht was du mit diesen Benchmarks zeigen willst, selbst mit dieser falschen Interpretation, die Ergebnisse sind selbst in diesem Best-Case für alles von AMD vor RDNA4 sehr bescheiden.

Siehe oben:
Man kann es anhand einiger Rechenbeispiele abschätzen. Und anhand den Daten sieht man ja, dass RDNA3 sowie RDNA4 FLOP-Technisch ziemlich wie erwartet mit FP16 WMMA-Instruktionen skaliert. Egal ob da dedizierte Matrix-Cores vorhanden sind oder nicht. Ja, Nvidia skaliert noch besser. Und? Im Falle von DLSS und einem Bruchteil einer Millisekunde sind selbst 1.5x schlechtere Auslastung kein Showstopper.

Also lasst bitte diese Scheinargumente. Liefert lieber ein paar belastbare Daten als nur "keine Tensor Cores = Geht nicht".

[aceCrasher]

Keine Tensor Cores.
Das gleiche Argument gilt für RDNA3.

[Gast]

Also lasst bitte diese Scheinargumente. Liefert lieber ein paar belastbare Daten als nur "keine Tensor Cores = Geht nicht".

Niemand sagt keine Tensorcores = geht nicht.

Sehr wohl aber keine Tensorecores = mehr Performanceverlust.

Und damit muss AMD eben abwägen ob es sich auszahlt darin Ressourcen zu investieren.

Nur AMD kann wirklich sagen ob der Performanceverlust sich im akzeptablen Rahmen bewegen würde.

Aber einige Indizien die wir auch als Außenstehende haben:
FSR4 kostet auch auf RDNA4 merklich Performance, zwar nicht viel und im ähnlichen Rahmen wie bei Nvidia Transformer, aber es ist nicht "for free" wie XeSS und DLSS-CNN auf nativer Hardware. --> Performanceverlust auf RDNA < 4 wahrscheinlich deutlich höher.
Mit XeSS haben wir aktuell den einzig cross-hardware kompatiblen NN-basierten Upscaler. Intel sah es als notwendig an die Qualität für nicht native Hardware deutlich sichtbar zu reduzieren, und trotzdem ist der Performanceverlust deutlich. Vor allem aber verliert speziell RDNA-basierte Hardware besonders viel Performance. Warum genau kann man natürlich schwer sagen, es kann aber durchaus sein, dass RDNA ganz unabhängig von irgendwelchen FLOP-Zahlen derartige workloads einfach "nicht liegen", weil sie vielleicht viel Cache-Thrashing erzeugen.

Es deutet jedenfalls sehr viel darauf hin, dass FSR4 in der Form für RDNA < 4 zumindest nicht durchgehend schnell genug ist.

Vielleicht wäre es für eine 7900 noch akzeptabel, aber was ist mit einer 7600?

AMD hätte also die Wahl, FSR4 as it is mit deutlich geringerer Performance, in einer Welt in der Balkenlängen in Reviews viel mehr zählen schlechter dasteht. Insbesondere wird es zum Bumerang was AMD mit FSR2-3 noch geholfen hat, dass die meisten Reviews mit gleicher Renderauflösung anstatt gleicher Qualität testen, selbst wenn man also das Verhältnis von Performance/Qualität verbessern würde, profitiert man davon nicht.

FSR4 in einer abgespeckten Version, mit höchstwahrscheinlich optischen Abstrichen. Das würde zwar die Performanceverluste minimieren, aber das gerade erst aufgebaute gute Image von FSR4 torpedieren. Man könnte das natürlich auch als etwas ganz neues bringen, dann hätte man aber nicht nur die Entwicklungs- sondern auch Marketingkosten.

Es gibt insgesamt eben sehr wenig Gründe für AMD noch großartig darin zu investieren.

[basix]

Ja, keine Tensor Kerne sind ein Nachteil.

Aber AMD sollte es mMn schon schaffen, FSR4 auf RDNA3 zu portieren (siehe die letzten paar Posts). Bei RDNA2 ist es deutlich fraglicher, da deutlich geringere FLOPS wie auch keine WMMA-Instruktionen.

[The_Invisible]

Aber AMD sollte es mMn schon schaffen, FSR4 auf RDNA3 zu portieren (siehe die letzten paar Posts).

Fraglich ob da Zeit bleibt wenn sie gerade versuchen featuremäßig auf Nvidia aufzuschließen (NRC, DLSS-RR, DLSS4-FG) und sie es auch irgendwie in Games bekommen wollen.

Zweites Halbjahr soll es kommen, wenn es 2026 wird kann man RDNA3 eh schon langsam vergessen

[basix]

Ach komm. Den selben Algorithmus von FP8 auf FP16 umzustellen ist verhältnismässig wenig Aufwand. Was allenfalls etwas Zeit kostet, sind Performanceoptimierungen. Und wenn es selbst ein Hobby-Entwickler bereits auf RDNA3 zum laufen gekriegt hat (sogar Vulkan) kann es wohl nicht ein riesiges Hexenwerk sein ;)
https://www.pcgameshardware.de/FidelityFX-Super-Resolution-Software-277617/News/FSR-4-unter-Linux-auch-auf-RDNA-4-1470407/

[w0mbat]

Soweit ich weiß kann RDNA3 WMMA gar kein FP8.

[robbitop]

Oh wow, die AMD Ingenieure haben sich wohl kürzlich die Nvidia Paper durchgelesen? :idea:

Sicherlich auch Früchte von Ametyst (Kolaboration mit Sony).

[Exxtreme]

Soweit ich weiß kann RDNA3 WMMA gar kein FP8.

Wenn man FP16 kann dann kann man auch FP8. :)

[aufkrawall]

Jetzt, wo AMD eine KI-Firma ist, machen sie endlich mal Geld für Entwicklung von so etwas locker, und dann geht es sogar voran.
Da kann man sich als Enthusiast mit den Auswirkungen auf die PS6 nur freuen. Gut, im 3DC gibt's natürlich stattdessen idiotische Grabenkämpfe...

[robbitop]

Bei Nvidia hätte es schon wieder Youtube Videos gegeben das ihnen die Besitzer älterer Karten schei*egal sind :D
Ich finde man muss das ganzheitlich sehen.
AMD arbeitet doch an FSR4 für RDNA3. Das ist etwas kompleziert, weil RDNA3 keine Matrixcores hat und ohne Matrix cores wäre FSR4 gar nicht in der Form möglich gewesen (und genau das brauchte AMD aber um nicht unterzugehen - insofern war das IMO nicht die falsche Entscheidung). Die Vermutung ist, dass man jetzt den Transformer Teil des Verfahrens entfernt.
Analog dazu wurde bei der Einführung von DLSS2 (was Tensorcores mit mind Turing Level brauchte - also Volta war raus) Pascal komplett im Regen stehen gelassen. Und da hat niemand an der Portierung von einer Art DLSS2 lite für Pascal gearbeitet.


Geht jetzt nicht um 8GB, sondern das RDNA 3 und tiefer kein FSR 4 bekommen. Bei Nvidia bekomst du DLSS Transformer runter auf die 2060. Eine Karte von 2018. :freak:
Als DLSS2 rauskam, war Turing das neuste was es bei Nvidia gab und dessen Vorgänger Pascal hat bis heute kein DLSS2 bekommen. AMD arbeitet immerhin an einem Port von FSR4. Und immerhin gibt es 3.1 für die Vorgänger. Für Pascal hat es von Nvidia nicht mal das gegeben (also den Vorgänger - der ja DLSS1 war).


Keine Tensor Cores.
So wie RDNA3. ;)
Man hätte ja wie Intel mit XeSS einen dp4a Pfad anbieten können mit verringerter Qualität. An sowas (allerdings WMAA) arbeitet AMD immerhin für RDNA3.

IMO ist das Vorgehen das bestmögliche gewesen was man aus der Situation hat machen können. Ohne die alten Zöpfe abzuschneiden hätte es FSR4 nicht in der Form gegeben und das war nötig. Hätte man mit dem Release gewartet bis eine lite Version für RDNA3 fertig ist, wäre der so dringend notwendige RDNA4 launch wesentlich schlechter gelaufen. Immerhin arbeitet man daran FSR4 für RDNA3 zu porten - was nicht trivial ist, da RDNA3 keine Matrix HW hat und man die Version so umstricken muss, dass es noch gut läuft und nicht zu viele BQ Abstriche hat.

[aufkrawall]

Gab aber etwa schon TAAU in UE4. FSR 3.1 ist bei 50% für 4k so schlecht, das kann man eigentlich nicht als Option mitzählen. Würde jedenfalls kein Spiel damit spielen und es so lange weglegen, bis ich bessere Hardware hätte.

[robbitop]

Na ich meine ein Upsampling direkt vom Vendor. Auf 3rd Party kann man natürlich immer verweisen - das Argument könnte man dann auch für RDNA3 sehen: es gibt TSR und XeSS (zusätzlich zu FSR3.1 - von anderen halt). Das zählt in der Diskussion IMO nicht.
Und ja FSR3.1 ist nach heutigem Standard schlecht. Aber verglichen mit dem was es 1st Party für Pascal gibt immer noch weit vorn.

Geht hier nicht um Nvidia! Auch nicht um Top Dogs
This. Der Massenmarkt braucht Preis Leistung. Insbesondere in dem Preisbereich, bei dem nicht jegliche Bodenhaftung verloren wurde.
Enthusiasten, die egal was es kostet, das schnellste kaufen, sind natürlich eine andere Sache.

Du verstehst auch nur das, was du verstehen willst, nicht?

Also nochmals, damit du es hoffentlich auch kapierst:
- DLSS1 war Kacke (aber SotA von 2018)
- DLSS2 war gut und kein Glück von Engineering Seite (SotA 2020)
- DLSS2 war glücklich für die Turing Käufer, weil man das als Consumer 2018 nicht erwarten konnte

Und dass AMD länger als Nvidia gebraucht hat ist auch klar:
- AMD ist eine kleinere Firma mit deutlich geringerem Budget
- AMD hatte die HW noch nicht ready (weswegen ML/AI nur begrenzt Sinn gemacht hätte -> FSR2 sollte zudem auf den Konsolen laufen) -> HW-Entwicklungszeiten sind 3-4 Jahre
- ML/AI ist Nvidias Zugpferd (Expertise, Umsätze)
- Deswegen sucht sich Nvidia aktiv Konkurrenzvorteile mit Hilfe von ML/AI -> Entsprechende Technologie wird gepusht
Diskussion mit Troyan sind verschwendete Zeit. Der bias ist einfach zu stark. ;)

[robbitop]

XeSS schaft es doch auch, besser als FSR3.1 zu sein und dabei in sachen performance sinnvoll zu bleiben.

Wobei man sagen muss, dass XeSS mit dp4a Pfad eine ganz andere Nummer von der computational load ist als FSR4. Intel hat ja nicht umsonst das dp4a Model deutlich reduziert.
Aber was ähnliches muss AMD auch für den WMMA Pfad von FSR4 machen. Entweder das Modell deutlichh reduzieren und/oder den Transformerteil entfernen. Dazu gab es bereits ein interessantes Video zu einem paper: https://www.youtube.com/watch?v=X51DEwAhMqU&pp=ygUKZnNyNCByZG5hMw%3D%3D

[robbitop]

Ach komm. Den selben Algorithmus von FP8 auf FP16 umzustellen ist verhältnismässig wenig Aufwand. Was allenfalls etwas Zeit kostet, sind Performanceoptimierungen. Und wenn es selbst ein Hobby-Entwickler bereits auf RDNA3 zum laufen gekriegt hat (sogar Vulkan) kann es wohl nicht ein riesiges Hexenwerk sein ;)
https://www.pcgameshardware.de/FidelityFX-Super-Resolution-Software-277617/News/FSR-4-unter-Linux-auch-auf-RDNA-4-1470407/

Naja zum Laufen kriegen ist nicht unbedingt die Frage. Es muss auch noch sinnvoll schnell genug laufen.
Wäre mal interessant nachzumessen wie schnell FSR4 unter Linux läuft ohne die RDNA4 Matrix HW. Bis dato liest man nur, dass es geht. Ich vermute, wäre es der große Durchbruch (also dass es sinnvoll schnell läuft) würde es längst erste Schlagzeilen geben und dann wäre es auch schon portiert. Aber nur eine Vermutung :)

[basix]

Da kann man sich als Enthusiast mit den Auswirkungen auf die PS6 nur freuen
Ja, das ist sehr erfreulich:
- 4K Output ist wohl fix (keine 8K Fernseher in Sicht), deswegen wohl guter Performance-Sprung
- FSR4/5 wird gut sein, damit wird Renderauflösung wohl bei ~900...1080p liegen, evtl. sogar 720p
- Neural Denoiser & Ray Reconstruction sollte ready sein
- Frame Generation wird mindestens als FG x2 ziemlich gut sein und wohl auch für x3 taugen -> 40/60fps gerendert -> 120fps Output
- Low Latency Fokus beim Input (Reflex, AntiLag, ...)
- Raytracing HW wird einen deutlichen Sprung machen
- Generell werden einige Technologien erwachsen (RT, SR, RR, FG, Meshlets/Nanite, SSD-Streaming, ...) und auch PS5 und Co. unterstützen die Kerntechnologien, entsprechend verbesserte Umsetzungen in Game-Engines

Oben drauf gibt es noch weitere Dinge wie Frame Extrapolation & Framewarp, welche einen grossen Benefit bringen könnten. Evtl. allerdings nicht zum Start der neuen Konsolen. Dann noch Immersions-Heber wie ML basierte Animationen, Gestik und Mimik inkl. Lokalisierung etc.

Momentan sind schon ein paar coole Sachen im Gange ;)

[aufkrawall]

Jup, und PS5 war leider nur eine Zwischen-Gen. Die Grafik aktuell (abseits von Nanite & Lumen) sieht eigentlich immer noch aus wie Frostbite 2015/16 (Mirror's Edge & Battlefront) + etwas Spar-RT. :freak:
Würd da auch RDNA nicht zu sehr bashen, wir sind auch auf dem PC inkls. Nvidia in einem krassen Software-Limit. Da beginnen sich gerade erst die Knoten zu lösen.

[Lurtz]

Wird die PS6 im Kern nicht jetzt schon finalisiert? Kann mir gar nicht vorstellen, dass das alles schon "konsolenfertig" vorhanden sein soll.

So gesehen ist eh jede Konsolen-Generation eine "Zwischen-Gen" :)

[aufkrawall]

Ich denke nicht, dass die jetzt schon finalisiert wird/ist, wenn gerade erst RDNA4 erschienen ist und die nächste Gen eigentlich ohne "volles" UDNA/RDNA5 unvorstellbar ist. Und das wird halt massiv bessere RT/ML-Fähigkeiten haben als die PS5 Pro, sodass die Software dafür endlich mal von Grund auf ausgelegt sein dürfte. Also in UE5.x dann etwa eine Art "Megalights+", was quasi wie PT aussieht.

[basix]

Ich denke die groben Züge und Features der HW werden bereits definiert sein. Ein paar kleinere Dinge könnten sich noch ändern und sicher die Komposition der HW (wie viele CPU Cores, wie breit die GPU). Grössere Änderungen an der darunterliegenden IP dürfte es mMn nicht mehr geben. Weil eigentlich ist ziemlich klar, wohin die Reise geht und RDNA5 die Basis sein wird:
- Mehr TFLOPS
- Schnellere CPU Cores (und evtl. mehr davon)
- Deutlich verbessertes HW-RT
- Deutlich ausgebaute und generalisiertere Matrix-TFLOPS/TOPS
- Möglichst effiziente Auslastung der HW (dynamic reordering etc.)
- Schnellere SSD
- Mehr DRAM (evtl. 8-ch LPDDR6?)

Alleine das dürfte ein schönes Upgrade sein. Aber über SW und Algorithmen dürfte fast noch mehr gehen bis hin zu Pathtracing.

[robbitop]

https://youtu.be/6QtYL40jMIY?si=NCw8A47fdQYC16f_

Hier hat jemand FSR4 auf Nobera 42 getestet mit einer 7900xt (fp8 emulation). Läuft anscheinend aber deutlich langsamer. Zusätzliche 3-3,5 ms ggü FSR3.1 (er sagt das processing ist ca 5x schneller auf einer 9070xt).

—————

Beim ML FG von Redstone vermute ich geht es nicht nur um bessere BQ des generierten Frames selbst - die war IMO (upscalernormiert!) jetzt nicht so schlecht. Aber das könnte nötig sein um mehr als 1 generiertes Frame machen zu wollen weil dann ja die Zeitdauer der generierten Frames vs echte Frames steigt und damit die BQ der generierten Frames wichtiger wird. Ich kann mir sehr gut vorstellen, dass wir hier früher oder später auch ein Mit freundlichen Grüßen Äquivalent sehen werden. Wichtig ist dass sie auch das Framepacing dann sicher stellen können (flip metering?).
Ggf geht AMD ja noch einen Schritt weiter und bringt adaptive frame generation (analog zu LSFG3). Oder sogar mGPU processing.
Es bleibt spannend :)

[Exxtreme]

Auch wieder interessant, dass Modder Sachen hinbekommen für die der Hersteller offenbar unfähig ist. Das ist so dämlich.

[Relex]

Klar "unfähig". Sie entwickeln den kompletten Algorithmus, sind aber dann "unfähig" es auf RDNA3 laufen zu lassen. :rolleyes:

Es ist doch offensichtlich, dass sie das so nicht veröffenltichen können. Soll ja auch auf low end RDNA3 Karten laufen.

[jorge42]

das kommende FSR4.5 (wenn es denn so heißen wird) macht die 9070XT für mich noch interessanter...und dann fällt mir auf, dass so wenig games nativ FSR 2/3 unterstützen (geschweige denn FSR4) und dass meine 6900XT eigentlich für alle Spiele aktuell reicht in UWQHD...

[robbitop]

Auch wieder interessant, dass Modder Sachen hinbekommen für die der Hersteller offenbar unfähig ist. Das ist so dämlich.
IMO ist das kurzgedacht und polemisch.
Schauen wir mal etwas differenzierter auf die Sache:

(1) Machbarkeit

ist ja ein Kriterium. ja

(2) Computational cost und Nutzwert

Das ist ein wichtiges Kriterium für einen Upscaler, der ja Performance (ggü native) einsparen soll.
FSR3.1 kostet ungefähr 2...3 ms. Wenn jetzt weitere 3...3.5 ms drauf kommen an computational cost sind wir irgendwo bei insgesamt 5-6 ms. Auf N31 XT(!) Man bedenke da gibt es deutlich schwächere SKUs bis hin zu APUs wo die Kosten noch weiter steigen (proportional zur Rechenleistung und Auflösung).
Bei einer Framerate von 60 fps wären das 31-37% des Frametimebudgets für das upsampling. Bei 120 fps wären das 60-72% usw.
Bedeutet, dass es zwar läuft aber aus Performancegründen richtig schlecht darstehen würde. Ein wenig wie FSR2 auf Vega. Und es müsste performancenormiert dann wahrscheinlich ein Performance Preset von FSR4 gegen ein native preset von FSR3.1 antreten was den Vorteil erodiert.

Damit die Leute keine faulen Tomaten werfen, muss man ein gutes Produkt liefern und nicht nur etwas über den Zaun werfen, was grundsätzlich läuft aber aus dem Nutzbarkeitaspekt kaum noch was bringt.

Und genau deshalb investiert AMD die Zeit, die computational cost von FSR4 für RDNA3 zu senken. Genau das gleiche passiert auch für die PS5PRO mit einem Port von FSR4 (den wir dann ggf als PSSR2 sehen werden).

Man muss sich bei all der Kritik immer objektiv die Frage nach opportunen Szenarien stellen um die jeweilige Entscheidung auch sinnvoll bewerten zu können.

Szenario 1 (so wie es geschehen ist):
man bringt FSR4 direkt zum RDNA4 launch mit best möglicher Qualität (aber auch hoher computational cost). Aufgrund hoher computational cost braucht es, damit es sinnvoll läuft Matrix HW. Und diese wurde nun einmal erst mit RDNA4 eingeführt.
Man arbeitet danach an einer lite Version, die auch sinnvoll auf RDNA3 laufen kann. RDNA3 Kunden müssen zwar warten haben aber die Chance ein sinnvolles Produkt zu bekommen.

Szenario 2:
Man schmeißt gleichzeitig FSR4 mit FP8 Emulation über den Zaun (nicht sinnvoll nutzbar). Ist das wirklich etwas, dass AMDs Kundschaft erfreuen würde oder würde das (mal wieder) ihrem Ruf schaden?

Selbst wenn man später nochmal eine optimierte Version von FSR4 lite bringen würde, wäre der Ersteindruck ggf. ersteinmal ruiniert. (man bedenke: die Masse sind keine hoch informierten Nerds aus Foren - da zählen hauptsächlich launch reviews)

Szenario 3:
Man verzögert FSR4 für RDNA4 weil man erst einmal die lite Variante für RDNA3 fertig stellen will und beides gleichzeitig releasen will.

Konsequenz: der RDNA4 launch wird deutlich schwächer und der Erfolg dieser Generation und die Nutzung der Chance von dem was Blackwell als Scharte hinterlässt wird geschwächt. Weiterhin: RDNA4 Käufer haben erstmal kein FSR4

Szenario 4:
Einfach so machen wie Nvidia es mit DLSS1/2 gemacht hat. Gar nicht mehr an einer Lösung für Legacy arbeiten. Immerhin gibt es FSR3.1 und XeSS und TSR

Ich würde sagen, dass wenn man die Randbedingungen bedenkt, AMD mit Szenario 1 objektiv nicht die schlechteste Entscheidung getroffen hat. Aber es gilt wie immer: man kann es nicht jedem Recht machen.


Es ist doch offensichtlich, dass sie das so nicht veröffenltichen können. Soll ja auch auf low end RDNA3 Karten laufen.
So ist es. 5-6ms auf N31 ist ein vielfaches auf Strix Point oder N33.

[Exxtreme]

Das ist ein wichtiges Kriterium für einen Upscaler, der ja Performance (ggü native) einsparen soll.
FSR3.1 kostet ungefähr 2...3 ms. Wenn jetzt weitere 3...3.5 ms drauf kommen an computational cost sind wir irgendwo bei insgesamt 5-6 ms. Auf N31 XT(!) Man bedenke da gibt es deutlich schwächere SKUs bis hin zu APUs wo die Kosten noch weiter steigen (proportional zur Rechenleistung und Auflösung).


Das ist korrekt. Andererseits reden wir hier von einem Hack von Hobby-Entwicklern + auch noch massiv viel Overhead, welcher durch die DirectX -> Vulkan-Umsetzung daherkommt. Und da sollte man keinerlei Wunder bezüglich Performance erwarten.

[robbitop]

Schau dir mal den Overhead an, der grundsätzlich durch Proton (durch das Überführen von DX -> VK) zustandekommt (Benchmarks aktueller AMD GPUs in Nobera vs Windows oder Steam Deck Steam OS vs Windows). Das ist nahezu vernachlässigbar. Und ansonsten wird FP8 einfach auf FP16 umgewandelt. Ich denke nicht, dass einfach nur durch rein bessere Umsetzung ohne Änderung des Verfahrens als solches da große Potenziale (die die Gesamtaussage wirklich bedeutungsvoll verändern!) schlummern. Aus Spaß gibt es das separate Projekt FSR4 (wahrscheinloch ohne Transformer) auf prä RDNA4 zu portieren. Sowohl bei AMD auf RDNA3 (dann wahrscheinlich mit FP16 als Zielformat) als auch bei Sony für die PS5 (INT8).

[Gast]

Das ist korrekt. Andererseits reden wir hier von einem Hack von Hobby-Entwicklern + auch noch massiv viel Overhead, welcher durch die DirectX -> Vulkan-Umsetzung daherkommt.


Wenn der Overhead so groß wäre könnte kein Steamdeck existieren.

Und diese "Hobby-Entwickler" sind nicht unbedingt schlechter als die "richtigen" von AMD, oder bezeichnest du jetzt jeden der an einem Open Source Projekt wie dem Linux Kernel mitgearbeitet hat despektierlich als "Hobby Entwickler"?

[robbitop]

Wenn der Overhead so groß wäre könnte kein Steamdeck existieren.
So ist es. Der Overhead ist erstaunlich gering. Vernachlässigbar würde ich sagen. :)


Und diese "Hobby-Entwickler" sind nicht unbedingt schlechter als die "richtigen" von AMD, oder bezeichnest du jetzt jeden der an einem Open Source Projekt wie dem Linux Kernel mitgearbeitet hat despektierlich als "Hobby Entwickler"?
Sehe ich auch so. Immerhin gibt es als Indiz, dass FSR2/DLSS2 Mods oft nicht schlechter (oder gar zT besser) implementiert sind als von den nativen Devs.

Ohne hohen FP8 Durchsatz ist FSR4 einfach nicht so richtig sinnvoll. Das ist einfach so. Ungünstig, dass AMD erst so spät entsprechende HW verbaut hat. Aber es ist wie es ist und basierend auf dem musste man halt eine Entscheidung treffen. Und ich denke es war nicht die schlechteste. :)

[Exxtreme]

Und diese "Hobby-Entwickler" sind nicht unbedingt schlechter als die "richtigen" von AMD, oder bezeichnest du jetzt jeden der an einem Open Source Projekt wie dem Linux Kernel mitgearbeitet hat despektierlich als "Hobby Entwickler"?

Hobby-Entwickler war jetzt nicht abwertend gemeint. Es ist aber so, dass diese wohl kaum Informationen über RDNA3-Interna haben. Und lassen deshalb tendenziell Optimierungspotential liegen.

[raffa]

https://themaister.net/blog/2025/05/09/conquering-fidelityfx-fsr4-enabling-the-pretty-pixels-on-linux-through-maniacal-persistence/

Hans-Kristian Arntzen über den Prozess FSR4 in die linux Welt zu holen, inkl. RDNA3 portierung.

"RDNA3?

RDNA3 is not officially supported at the moment, but given I already went through the pain of emulating FP8, there’s no reason it cannot work on RDNA3. Given the terrible performance I got in FP16 emulation, I can understand why RDNA3 is not supported though … FSR 4 requires a lot of WMMA brute force to work, and RDNA3’s lesser WMMA grunt is simply not strong enough. Maybe it would work better if a dedicated FP16 model is designed, but that’s not on me to figure out."

[robbitop]

Hobby-Entwickler war jetzt nicht abwertend gemeint. Es ist aber so, dass diese wohl kaum Informationen über RDNA3-Interna haben. Und lassen deshalb tendenziell Optimierungspotentiel liegen.
Ich vermute, da ist nicht viel Optimierungspotenzial. Ohne das Verfahren selbst zu ändern musst du FP8 emulieren. Bedeutet du füllst die ALUs halt mit FP16 Werten und musst halt mit dem FP16 Durchsatz leben weil es für 8 bit Genauigkeit kein speedup gibt (und im Gegensatz zur PS5PRO GPU und RDNA2 oder GPUs wie Pascal gibt es nicht mal einen INT8 Durchsatz speedup - nutzt bei FSR4 nicht viel - hätte aber ggf was für ein rein CNN basiertes NN Upsampling was gebracht). Da gibt es leider nicht viel zu machen. Zumal vieles auch über den Shadercompiler läuft.

[w0mbat]

Ich denke, FSR4 würde auf RDNA3 ohne TC einfach so langsam laufen, dass es keinen Sinn ergibt. Klar, möglich ist es. Aber wenn man 20% Leistung braucht um diese dann durch Upscaling wieder zu zurück zu holen, kann man es auch gleich bleiben lassen.

[robbitop]

Wie gesagt 5-6 ms in 1440p auf N31 XT - reines processing für FSR4 (~Faktor 5 zu N48). Auf kleineren SKUs nochmal langsamer. Also ja: zu langsam :)

[Exxtreme]

Ich vermute, da ist nicht viel Optimierungspotenzial. Ohne das Verfahren selbst zu ändern musst du FP8 emulieren. Bedeutet du füllst die ALUs halt mit FP16 Werten und musst halt mit dem FP16 Durchsatz leben weil es für 8 bit Genauigkeit kein speedup gibt (und im Gegensatz zur PS5PRO GPU und RDNA2 oder GPUs wie Pascal gibt es nicht mal einen INT8 Durchsatz speedup - nutzt bei FSR4 nicht viel - hätte aber ggf was für ein rein CNN basiertes NN Upsampling was gebracht). Da gibt es leider nicht viel zu machen. Zumal vieles auch über den Shadercompiler läuft.

Ja. Aber das ist auch wiederum eine "High-Level"-Sicht auf die Hardware. Man weiss nicht sehr exakt welche Möglichkeiten die Hardware so wirklich hat. Kann ja sein, dass man so eine Art "dual issue" mit 2 FP8-Werten durchführen kann etc. Solche Optimierungsmöglichkeiten hat man dann auf Treiber-Ebene bzw. im Shader-Compiler. Eine weitere Möglichkeit wäre ein Model zu machen, welches auf FP16 optimiert ist. Sowas kann aber echt fast nur AMD implementieren.

[robbitop]

Wenn es sowas gibt ist es dokumentiert. RDNA4 kann das. RDNA2/3 kann das für FP16 vs FP32. Aber für FP8 ist es nicht vorgesehen.

[Gast]

Hobby-Entwickler war jetzt nicht abwertend gemeint. Es ist aber so, dass diese wohl kaum Informationen über RDNA3-Interna haben. Und lassen deshalb tendenziell Optimierungspotential liegen.

Und wie schaffen es dann professionelle Spieleentwickler die auch nicht mehr Informationen haben?

[Gast]

https://themaister.net/blog/2025/05/09/conquering-fidelityfx-fsr4-enabling-the-pretty-pixels-on-linux-through-maniacal-persistence/



Der Entscheidende Satz:
With this, RDNA 3 can do FSR 4 on vkd3d-proton if you’re willing to take a massive dump on performance.

Deshalb gibt es kein FSR4 für RDNA3 und wird es ohne Änderungen an FSR4 auch nicht offiziell geben.

[Der_Korken]

Wie gesagt 5-6 ms in 1440p auf N31 XT - reines processing für FSR4 (~Faktor 5 zu N48). Auf kleineren SKUs nochmal langsamer. Also ja: zu langsam :)

FSR3 ist ja auch schon nicht kostenlos. Wenn ich mal die Zahlen hier aus den Postings aufgreife und 2ms für FSR3 und 6ms für FSR4 ansetze, dann wären die Auswirkungen auf die fps in etwa wie folgt:

40fps -> 34,5fps
60fps -> 48,4fps
80fps -> 60,6fps
100fps -> 71,4fps
120fps -> 81,1fps

Bei hohen fps ist das natürlich der Killer, aber bei niedrigen fps (also da, wo man FSR am meisten braucht) sieht das imho noch OK aus. Ich mein, wenn ich vorher FSR3 Quality mit 60fps genutzt habe könnte ich mit FSR4 Balanced die gleiche Performance bekommen, aber mit wahrscheinlich massiv besserer Bildqualität.

Für die 7800er Karten wird es natürlich schon kritisch und die 7600 ist komplett raus.

[Exxtreme]

Und wie schaffen es dann professionelle Spieleentwickler die auch nicht mehr Informationen haben?

Spieleentwickler kommen damit gar nicht in Berührung. Sie implementieren FSR oder DLSS gar nicht selbst sondern nutzen fertige Bibliotheken in Form von DLLs. Sie müssen die Daten nur mit camera jitter und velocity buffers anreichern.

[robbitop]

FSR3 ist ja auch schon nicht kostenlos. Wenn ich mal die Zahlen hier aus den Postings aufgreife und 2ms für FSR3 und 6ms für FSR4 ansetze, dann wären die Auswirkungen auf die fps in etwa wie folgt:

40fps -> 34,5fps
60fps -> 48,4fps
80fps -> 60,6fps
100fps -> 71,4fps
120fps -> 81,1fps

Bei hohen fps ist das natürlich der Killer, aber bei niedrigen fps (also da, wo man FSR am meisten braucht) sieht das imho noch OK aus. Ich mein, wenn ich vorher FSR3 Quality mit 60fps genutzt habe könnte ich mit FSR4 Balanced die gleiche Performance bekommen, aber mit wahrscheinlich massiv besserer Bildqualität.

Für die 7800er Karten wird es natürlich schon kritisch und die 7600 ist komplett raus.
die 5-6ms inkludieren bereits FSR3.1 Kosten. Im Video sagt er 3-3,5 ms extra vs FSR3.1

[Gast]

Spieleentwickler kommen damit gar nicht in Berührung. Sie implementieren FSR oder DLSS gar nicht selbst sondern nutzen fertige Bibliotheken in Form von DLLs.


Aber sie implementieren Shader, und FSR4 ist auch nichts anderes als ein Shader. Also entweder würde jeder der Shader implementiert mangels Dokumentation massiv Performance liegen lassen, oder aber die öffentlich verfügbare Dokumentation reicht aus womit nicht viel zu holen wäre.

[Exxtreme]

Aber sie implementieren Shader, und FSR4 ist auch nichts anderes als ein Shader. Also entweder würde jeder der Shader implementiert mangels Dokumentation massiv Performance liegen lassen, oder aber die öffentlich verfügbare Dokumentation reicht aus womit nicht viel zu holen wäre.

Das mag ja sein. Trotzdem ist es so, dass die Spieleentwickler FSR nicht selbst implementieren. Die lassen alles die Spieleengine bzw. von AMD gelieferte Bibliotheken machen.