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

[ChaosTM]

Wir können doch froh sein, dass wir Kunden nun einen echten DLSS Konkurrent haben, der auch noch auf allen (halbwegs aktuellen) Grafikkarten läuft.


Erzähl das mal troyan ;)

[DrFreaK666]

hm, vielleicht ist FSR tatsächlich noch etwas buggy. Würde erklären wieso die nächsten Spiele nicht schon in den nächsten Wochen erscheinen

[Gast]

https://www.computerbase.de/forum/threads/fidelityfx-super-resolution-im-test-fsr-2-0-laesst-1-0-weit-hinter-sich-doch-dlss-haelt-dagegen.2085100/post-26901453

https://www.computerbase.de/forum/threads/fidelityfx-super-resolution-im-test-fsr-2-0-laesst-1-0-weit-hinter-sich-doch-dlss-haelt-dagegen.2085100/post-26901242

Eure Szene wirkt hier fehlerhaft, genau wie von aufkrawall ein paar Seiten vorher beschrieben: Grobpixeliger, als würde nicht auf Ausgabeauflösung skaliert werden. Das würde evtl. auch die deutlich unterschiedlichen Eindrücke zwischen den einzelnen Tests teilweise erklären.

Schaut eher aus als hätte es da jemand mit dem Schärferegler übertrieben.
Die DLSS Ansicht ist ja auch viel Schärfer, ja schon überschärft und FSR toppt das ganze nochmal.

[aufkrawall]

Lol... ich rieche hier Bugs in der Applikation. Daraus dürften die unterschiedlichen Eindrücke zu FSR 2.0 entstehen. :tongue: Zumindest solange eine Geforce RTX im System steckt. Ansonsten dürfte der Bug den aufkrawall hier genannt hat gar nicht erst aufkommen da DLSS bei non RTX nicht zur Verfügung steht. Oder anders formuliert... bei RTX Karten muss man bestimmte Sachen beim Umschalten der Upscaling-Methoden beachten damit FSR 2.0 korrekt arbeitet.
Ich hatte es auch schon bei TXAA -> FSR 2.0 festgestellt. Habs auch schon vorläufig auf Video festgehalten:
ZAdi-rlvv8w
Wenn die YT-Verarbeitung fertig ist, sollte man erkennen, dass es im ersten FSR 2.0 Abschnitt die ganze Zeit fies jittert und das Bild allgemein viel detailärmer und gröber ist. Nach dem FSR 1.0-Toggle ist es dann viel flimmerärmer und schärfer.

Noch besseres Video mit TXAA und DLSS ist in Planung.

[MadManniMan]

Es ist absolut irre, mit welcher Vehemenz und mit wie wenig konkreten Nachweisen hier Diskussionen geführt werden. Abwägungen finden kaum statt und Urteile sind überwiegend gaaanz weit "in einem Lager".

Möglicherweise war das schon immer so, aber ich hätte vom Technolgie-Subforum(!!!) deutlich mehr erwartet.

[ChaosTM]

Es ist absolut irre, mit welcher Vehemenz und mit wie wenig konkreten Nachweisen hier Diskussionen geführt werden. Abwägungen finden kaum statt und Urteile sind überwiegend gaaanz weit "in einem Lager".

Möglicherweise war das schon immer so, aber ich hätte vom Technolgie-Subforum(!!!) deutlich mehr erwartet.


War schon immer ähnlich, aber im Zuge der allgemeinen Polarisierung der Gesellschaft nimmt das doch etwas zu :)

[Lurtz]

Kommentar von mir zum DF-Test: https://forums.guru3d.com/threads/info-zone-gengines-ray-tracing-dlss-dlaa-tsr-fsr-xess-dldsr-etc.439761/page-23#post-6017098
Einfach nur völlig biased und teilweise (bewusst?) irreführend.
Dass Digital Foundry nVidia biased sind, kann man leider schwer wegdiskutieren. Ist nicht das erste Beispiel.

Oder man möchte seine Meinung jetzt nicht grundlegend ändern, nachdem man DLSS 2.0 in den letzten zwei Jahren eigentlich immer als sehr gut beschrieben hat. AFAIR sind ihnen nicht mal die extremen Nachschärfungs-Artefakte in God of War aufgefallen oder sie haben sie unter den Tisch fallen lassen.

[robbitop]

Eher mittelprächtig.
Das Steamdeck krankt leider massiv an CPU Leistung, und da hilft FSR auch nicht viel weiter. Quality bringt zwar noch einen netten Sprung, die niedrigeren Settings bringen aber so gut wie gar nichts mehr, weil die CPU bei ca. 45FPS Schluss macht.

Es könnte in Deathloop evtl. reichen um von einigermaßen stabilen 30FPS auf einigermaßen stabile 40FPS zu kommen, 60FPS sind leider trotz FSR außer Reichweite.

Von den 15W an Powerlimit die dem SoC zustehen braucht der CPU Cluster auf den max. 3,5GHz schon 12-13W unter realistischer Last.
Gleiches gilt für den GPU-Cluster bei den max 1,6GHz.
In synthetischen Benchmarks die nur das eine oder andere auslasten sieht das ja noch ganz gut aus. In realen Spielen welche die GPU auslasten kommt dann die CPU oft kaum über 2GHz und 2GHz Zen2 sind eben nicht so prall.

Es ist wirklich schade zu sehen was für ein Potential ein derartiges Gerät hätte, wenn anstatt einer AMD APU ein Apple M1 drinnen stecken würde.

Naja die 15 W sind ja für den ganzen SoC. Wenn die GPU Last reduziert wird (z.B. dank FSR 2.0), sollte mehr Spielraum für die CPU da sein. Und natürlich umgekehrt. Die Senkung des FPS Targets macht TDP für die GPU frei.
Für 15W ist das Ergebnis schon gar nicht schlecht. Aber der M1 würde wahrscheinlich mehr herausholen.

Es gibt wahrscheinlich auch mehr als genug Spiele bei denen ein 2-2,5 GHz Zen 2 mit 4C/8C für mehr als 45 fps reicht.

Aus meiner Sicht ist das jetzige Steamdeck ein klares 1st Gen Produkt. Rembrandt ist der erste x86 SoC, der das schafft, was man im Steamdeck mit 15 W sieht. Kommende SoCs werden noch nette Sprünge machen. Die uArch der GPU und CPU macht ja im Moment bei so ziemlich allen IHVs jährlich enorme Sprünge. Wenn man auch noch ordentlich Cache für CPU und GPU dazu tun würde (was man dank Stacking sicherlich irgendwann tun kann), kann man die Energieeffizienz sicherlich nochmal ordentlich steigern, da Speicherzugriffe viel viel günstiger (aus energetischer Sicht) werden.

In Punkto Cache und uArch darf man von den folgenden Generationen der Steamdeck SoCs einige Fortschritte erwarten. Gen 1 war erst der Anfang. :)

Beim M1 darf man ein paar Dinge nicht vergessen:
1.) 5 nm vs 7 nm
2.) TBDR GPU -> alle Framebufferzugriffe laufen über den Tilecache und verbauchen super wenig Bandbreite und somit auch viel weniger Energie
3.) 24 MiB Last Level Cache - das hilft sowohl der CPU als auch der GPU ordentlich die Datenlokalität zu erhöhen - das spart Energie und steigert die Performance
4.) Riesige L1 und L2 Caches für die CPU Cores - bringt nochmal das Gleiche

DLSS verursacht smearing wegen der unpräzisen Berechnung und Rundungsfehler durch int8 Einheiten. Diese Grafikfehler sind schwerwiegend und beeinträchtigen die Bewegungsqualität beträchtlich.

Für was genau soll das Datenformat INT8 verwendet werden bei DLSS 2.x? Für das Neuronale Netzwerk?

[Gast]

Oder man möchte seine Meinung jetzt nicht grundlegend ändern, nachdem man DLSS 2.0 in den letzten zwei Jahren eigentlich immer als sehr gut beschrieben hat.

Wenn FSR2.0 gut sein soll (was es ohne Zweifel ist) dann muss logischerweise DLSS2.0 auch immer gut gewesen sein.

[DrFreaK666]

Wenn FSR2.0 gut sein soll (was es ohne Zweifel ist) dann muss logischerweise DLSS2.0 auch immer gut gewesen sein.

Auf Makel von FSR 2.0 hinzuweisen ist auch in Ordnung, im gleichen Atemzug Makel von DLSS 2.0 zu verschweigen allerdings nicht. Man sollte schon fair sein

[dargo]

Ich hatte es auch schon bei TXAA -> FSR 2.0 festgestellt. Habs auch schon vorläufig auf Video festgehalten:
https://youtu.be/ZAdi-rlvv8w
Wenn die YT-Verarbeitung fertig ist, sollte man erkennen, dass es im ersten FSR 2.0 Abschnitt die ganze Zeit fies jittert und das Bild allgemein viel detailärmer und gröber ist. Nach dem FSR 1.0-Toggle ist es dann viel flimmerärmer und schärfer.

Noch besseres Video mit TXAA und DLSS ist in Planung.
Wird die YT-Quali noch besser? In der 1080p Grütze von YT kann man kaum was erkennen. Also im Video selbst konnte ich keinen Unterschied ausmachen. Erst auf Screenshots fielen mir die Unterschiede auf.
https://abload.de/thumb/zwischenablage011yj8l.jpg (https://abload.de/image.php?img=zwischenablage011yj8l.jpg) https://abload.de/thumb/zwischenablage02a5jiq.jpg (https://abload.de/image.php?img=zwischenablage02a5jiq.jpg)

Man sieht, dass dein zweiter Versuch mit FSR 2.0 (nachdem du vorher auf FSR 1.0 gewechselt bist) mehr feine Details zeigt. Interessanterweise sieht der erste FSR 2.0 Versuch aber einen Tick schärfer aus.

[aufkrawall]

Ist jetzt besser. Ich hatte auch schon PNGs gepostet, das Video "beweist" nur den Workaround-Part mit dem FSR 1.0-Toggle. Vor dem Switch sieht es nach fieser Lanczos-Vergewaltigung aus, danach Gräser sogar feiner als mit DLSS (ohne jedes Sharpen).

[Gast]

Auf Makel von FSR 2.0 hinzuweisen ist auch in Ordnung, im gleichen Atemzug Makel von DLSS 2.0 zu verschweigen allerdings nicht. Man sollte schon fair sein

Die Makel von DLSS wurden die letzten Jahre genug durchgekaut, da muss man nicht auch noch dafür Zeit verschwenden, in einem Video in dem es um FSR2.0 geht.

[dargo]

Ah... jetzt in brauchbarer Quali wird der Unterschied noch deutlicher.
https://abload.de/thumb/zwischenablage03n3kn4.jpg (https://abload.de/image.php?img=zwischenablage03n3kn4.jpg) https://abload.de/thumb/zwischenablage04x0klw.jpg (https://abload.de/image.php?img=zwischenablage04x0klw.jpg)

[iamthebear]

Das ergibt für mich einfach keinen Sinn. CB kann das auch nicht bestätigen.
https://www.computerbase.de/2022-05/amd-fsr-2.0-deathloop-test/2/

1440p + FSR 2.0:
RX 6700XT --> Nativ = 100%, Quality = 155%, Balanced = 174%, Performance = 192%

RX 6800XT --> Nativ = 100%, Quality = 151%, Balanced = 170%, Performance = 191%

Diese kleinen Unterschiede fallen bei mir schon unter Messschwankungen, insbesondere bei dem mickrigen 1% @Performance.

CB hatte 33fps, HWU über 60fps bei 4K Native.
Ich habe mittlerweile das Gefühl dass das von Szene zu Szene bzw. unterschiedlichen Einstellungen stark schwankt und hier wurde offensichtlich ganz was anderes getestet.

[DrFreaK666]

Die Makel von DLSS wurden die letzten Jahre genug durchgekaut, da muss man nicht auch noch dafür Zeit verschwenden, in einem Video in dem es um FSR2.0 geht.

Dann hätte man DLSS mit keiner Silbe erwähnen sollen

[dargo]

CB hatte 33fps, HWU über 60fps bei 4K Native.

Bitte im Link auf 1440p klicken, darauf hatte ich mich auch bezogen. ;)

Edit:
Ich kann dir aber auch gerne die 4k Werte auflisten. Dort ändert sich gar nichts zwischen RX 6700XT vs. RX 6800XT. Nur der FPS-Zuwachs ist dann logischerweise mit FSR 2.0 größer.

2160p + FSR 2.0:
RX 6700XT --> Nativ = 100%, Quality = 165%, Balanced = 188%, Performance = 224%

RX 6800XT --> Nativ = 100%, Quality = 164%, Balanced = 190%, Performance = 219%

[hmmm]

Wieso schaut niemand auf das Anti Aliasing? Ich meine DLSS und FSR 2.0 sollen doch auch genau dies (TAA) ersetzen? Einige Beispiele wirken ja so als sei das FSR 2.0 AA = Ultra und das DLSS AA = Normal. Können die SpieleEntwickler das DLSS-AA so einstellen wie das Nachschärfen bei FSR 2.0 oder können die da nichts machen?

[dargo]

Wieso schaut niemand auf das Anti Aliasing? Ich meine DLSS und FSR 2.0 sollen doch auch genau dies (TAA) ersetzen? Einige Beispiele wirken ja so als sei das FSR 2.0 AA = Ultra und das DLSS AA = Normal.
Guten morgen. ;)
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13003816&postcount=208

[aufkrawall]

Z_0ljJvJwhM

Weniger Jittering und Blur mit FSR 2.0 vs. DLSS Balanced.

[ChaosTM]

Und ich seh wieder mal genau keinen Unterschied ..
Ich sollte mal einen Optiker aufsuchen

[aufkrawall]

Das Jittering wird durch die YT-Kompression deutlich weggefiltert. Das betrifft auch die größeren Pflanzen, mit diesen DLSS-Versionen sind die dauerhaft etwas unruhig. Das Pixel Locking ist mit FSR 2.0 wirklich gut gelungen, diese Bereiche mit dünnen Linien sind damit im Standbild wirklich ~komplett ruhig. Ist sehr angenehm, wenn man auf Bewegungen durch Gegner achtet. Ich hätte das so gerne in Fortnite... :redface:

[dargo]

Und ich seh wieder mal genau keinen Unterschied ..
Ich sollte mal einen Optiker aufsuchen
Du bist nicht der Einzige, ich sehe da im Video auch keinen Unterschied. ;D

[DrFreaK666]

Ihr macht es auch falsch. Ihr müsst 10x reinzoomen

[/Locutus oB]

wenn mann ohne zoomen nichts sieht ist doch alles paletti :)

[basix]

Also dass das DLSS das Gras unten links im Bild etwas mehr blurrt als FSR, wenn man nicht noch mit CAS nachschärft, das sieht man auch ohne Zoom und mit YT Kompression ;)

Gross ist der Unterschied hier aber nicht.

Sobald man sich als Spieler bewegt passiert aber folgendes:
- FSR bleibt praktisch gleich
- DLSS blurrt nochmals stärker

Das ist mMn der grosse Unterschied, der mir bei FSR einfach besser gefällt. Und das durch das in-built CAS Texturdetails deutlich besser ersichtlich sind (auch ohne Überschärfung ;))

[Dampf]

Also dass das DLSS das Gras unten links im Bild etwas mehr blurrt als FSR, wenn man nicht noch mit CAS nachschärft, das sieht man auch ohne Zoom und mit YT Kompression ;)

Gross ist der Unterschied hier aber nicht.

Sobald man sich als Spieler bewegt passiert aber folgendes:
- FSR bleibt praktisch gleich
- DLSS blurrt nochmals stärker

Das ist mMn der grosse Unterschied, der mir bei FSR einfach besser gefällt. Und das durch das in-built CAS Texturdetails deutlich besser ersichtlich sind (auch ohne Überschärfung ;))

Ist das nicht des fehlenden Sharpenings bei DLSS geschuldet?

Was passiert, wenn man DLSS mit CAS auf eine ähnliche Schärfestufe wie FSR bringt, blurred es dann immer noch mehr als FSR in Bewegung?

Nicht vergessen, CAS beim Testen von FSR wieder auszuschalten. Ist ja einfach mit Reshade möglich.

[Troyan]

Ich sehe keine großartigen Unterschiede in Bewegung. Nervig ist einzig das Ghosting von FSR2.0, wenn Objekte sich überlagern. Und da man DLSS nicht nachschärfen kann, ist es sowieo kein wirklich fairer Vergleich.

[DrFreaK666]

Ich sehe keine großartigen Unterschiede in Bewegung. Nervig ist einzig das Ghosting von FSR2.0, wenn Objekte sich überlagern. Und da man DLSS nicht nachschärfen kann, ist es sowieo kein wirklich fairer Vergleich.

Nur der DAU kann nicht nachschärfen ;).

Ich denke unsere kleine Truppe hat schon mal mit Reshade und/oder früher mit sweetfx hantiert. Habe aber einen Freund, der beides nicht kennt und eine 3090 hat

[Troyan]

Sollte trotzdem Ingame angeboten werden. nVidias NIS ist seit Monaten quelloffen.

[basix]

Ist das nicht des fehlenden Sharpenings bei DLSS geschuldet?

Was passiert, wenn man DLSS mit CAS auf eine ähnliche Schärfestufe wie FSR bringt, blurred es dann immer noch mehr als FSR in Bewegung?

Nicht vergessen, CAS beim Testen von FSR wieder auszuschalten. Ist ja einfach mit Reshade möglich.

Da ich es nicht aus dem Stand mit Sicherheit beantworten konnte, habe ich Reshade für Deathloop installiert. Testing:
- 1440p, 4K Output via DLDSR, P und Q Modi
- Vergleich DLSS 2.3 vs. FSR 2.0
- DLSS + CAS: CAS = Contrast 0.5, Sharpening 0.7 (ist leicht schärfer als FSR mit in-built Sharpening Slider = 10)
- Updaam, gleich am Anfang
- Geradeaus laufen und ohne Seitwärtsbewegung
- Dadurch bewegen sich die Kabel "über" die Gebäudewand, was den Blur verstärkt (Worst Case!)
- Screenshot mit PrtScr machen (Finger dabei stur auf der W-Taste halten)
- Bildernamen: FSR = FSR; DLSS = DLSS; P1/P2 = Performance Mode (2x Bilder); Q1/Q2 = Quality Mode (2x Bilder); DLSS & "incl"/"and" = CAS enabled (die Bildernamen hat es beim Upload etwas verhunzt)

https://abload.de/thumb/deathloopdlss_p_incl_upjhx.png (https://abload.de/image.php?img=deathloopdlss_p_incl_upjhx.png) https://abload.de/thumb/deathloopdlss_p1jwkvp.png (https://abload.de/image.php?img=deathloopdlss_p1jwkvp.png) https://abload.de/thumb/deathloopdlss_p2e1j7m.png (https://abload.de/image.php?img=deathloopdlss_p2e1j7m.png) https://abload.de/thumb/deathloopdlss_q_and_cclk3l.png (https://abload.de/image.php?img=deathloopdlss_q_and_cclk3l.png) https://abload.de/thumb/deathloopdlss_q_and_c0qjk4.png (https://abload.de/image.php?img=deathloopdlss_q_and_c0qjk4.png) https://abload.de/thumb/deathloopdlss_q1i3kc4.png (https://abload.de/image.php?img=deathloopdlss_q1i3kc4.png) https://abload.de/thumb/deathloopdlss_q2k6kke.png (https://abload.de/image.php?img=deathloopdlss_q2k6kke.png) https://abload.de/thumb/deathloopfsr2_p1r4j4q.png (https://abload.de/image.php?img=deathloopfsr2_p1r4j4q.png) https://abload.de/thumb/deathloopfsr2_p20jj1h.png (https://abload.de/image.php?img=deathloopfsr2_p20jj1h.png) https://abload.de/thumb/deathloopfsr2_q1ddkz7.png (https://abload.de/image.php?img=deathloopfsr2_q1ddkz7.png) https://abload.de/thumb/deathloopfsr2_q2nzks9.png (https://abload.de/image.php?img=deathloopfsr2_q2nzks9.png) https://abload.de/thumb/deathloopfsr2_standbi2bjge.png (https://abload.de/image.php?img=deathloopfsr2_standbi2bjge.png)

Fazit:
- Siehe Screenshots, was ich mit "Temporal Blur" meine. Das letzte Bild ist ein Standbild mit FSR (Referenz)
- Stärkeres Temporales Blurring von DLSS ist eindeutig bestätigt. Kann mit CAS abgemildert werden, verstärkt aber andere Probleme, da z.B. Ghosting besser ersichtlich ist
- FSR blurrt auch, aber so gering dass es eben nur auffällt, wenn man sich stark darauf konzentriert. Bei DLSS fällt es auch so auf
- DLSS hat in diesem Aspekt keine Chance gegen FSR. Auch nicht mit CAS und DLSS Q vs. FSR P
- FSR ist nicht fehlerfrei und erzeugt andere Artefakte bei Trailing Texturen. Das fällt verglichen mit dem DLSS Blur aber nicht auf
- Dafür sieht man bei FSR fast kein Ghosting am Kabel

Den genau gleichen Effekt kann man auch auf normalen Texturen wie Häuserfronten oder Felswänden erkennen, wo keine Kabel davor hängen, einfach weniger stark. Oder eben bei Gräsern, welche im Wind wiegen. Sehr extrem bei Büschen in Metro Exodus ersichtlich, etwas besser aber immer noch ersichtlich bei Gräsern in HZD. Ist also nicht ein Deathloop Thema. Umso feiner die Gräser, Büsche usw. desto mehr werden die Details geblurrt.

Bei DLSS kann man mit CAS etwas dagegenwirken (hatte ich bei HZD auch schon so gemacht), aber das einzige was wirklich hilft ist eine höhere Outputauflösung, z.B. 2880p DLSS-P mit DSR 4x. Doch dazu muss die GPU-Leistung vorhanden sein und wenn ich sehe, das FSR 2.0 in 1440p Output (ohne DLDSR) mit FSR-P den deutlich besseren Job macht, sehe ich FSR in dieser Hinsicht eindeutig im Vorteil.

Edit:
Typos gefixt

Edit 2:
Für Convenience beim Vergleich siehe: https://imgsli.com/MTA3OTU2

Ich würde FSR Performance vs. DLSS Q + CAS noch insgesamt als leicht besser einschätzen. Gegen FSR Q hat DLSS dann keinen Stich mehr.

[Troyan]

Naja, was sagst du dann zu FSR 2.0 erst: https://imgsli.com/MTA3OTU3/0/1

FSR ghostet wie nichts. Der Unterschied ist, dass es eben nicht probiert in Bewegung vernünftig zu glätten. Aber jede überdeckende Bewegung führt zum Zusammenbruch des Upscalings. Je geringer die Output-Auflösung ist, umso störender ist es.

Aber hey, konzentrieren wir uns auf schwarze Linien auf weißen Hintergrund.

[basix]

Diese Argumentationstechnik :freak:

1. Ein Argument mit einem anderen Gegenargument zu widerlegen funktioniert nicht (Blur vs. Ghosting).
2. Lade deine Screenshots bitte mit entsprechenden Beschreibungen auf. Ratespiele bringen nichts.

Edit:
Und in meinen Screeshots ghosted DLSS mehr, auch wenn nicht vor dem Himmel sondern bei der Steinmauer. In meinen Screenshots kann ich dir noch viele andere Stellen zeigen, wo DLSS mehr ghosted. Ist immer szenenabhängig. Oder von der DLSS Version. Welche hast du verwendet? Bei mir war es die standardmässige von Deathloop (was wohl 2.3 ist)

[DrFreaK666]

Sollte trotzdem Ingame angeboten werden. nVidias NIS ist seit Monaten quelloffen.

Ja, sowas sollte es in Spielen geben. Gibt auch einige prominente Beispiele, die Gebrauch von FidelityFX CAS machen

[Troyan]

Diese Argumentationstechnik :freak:

1. Ein Argument mit einem anderen Gegenargument zu widerlegen funktioniert nicht (Blur vs. Ghosting).
2. Lade deine Screenshots bitte mit entsprechenden Beschreibungen auf. Ratespiele bringen nichts.

Edit:
Und in meinen Screeshots ghosted DLSS mehr, auch wenn nicht vor dem Himmel sondern bei der Steinmauer. In meinen Screenshots kann ich dir noch viele andere Stellen zeigen, wo DLSS mehr ghosted. Ist immer szenenabhängig. Oder von der DLSS Version. Welche hast du verwendet? Bei mir war es die standardmässige von Deathloop (was wohl 2.3 ist)

Ich habe 2.3.9, was minimal weniger ghostet. Mit der mitgelieferten DLSS sieht es kaum schlechter aus. Gerade getestet.

Hier mal 2.3.0 und FSR 2.0 Performance bei überdeckender Geometrie: https://imgsli.com/MTA3OTY1

Mit einem LCD-Bildschirm sind die im Best-Case Schärfeunterschiede auch irrelevant dank Sample and Hold und Pixelgeschwindigkeit. Aussagen, dass FSR schärfer wäre, ist ebenfalls auch vollkommen falsch. Außer man nimmt das obere Beispiel, weil FSR 2.0 in vielen Bereich kaum noch vernünftig glättet. :eek:

[basix]

Mit einem LCD-Bildschirm sind die im Best-Case Schärfeunterschiede auch irrelevant dank Sample and Hold und Pixelgeschwindigkeit.

Sorry, ich sehe es mit meinen eigenen Augen am Schirm. Live in Bewegung beim Spielen. Das Argument kannst du dir also stecken lassen. Ich hätte eher bedenken, dass der wahrgenommene Unterschied auf einem OLED sogar noch schlimmer und zuungunsten von DLSS ist.

Und weisst du, wieso der Blur so stark auffällt? Weil er sich in Bewegung die ganze Zeit ändert. Entweder weil sich Gegenstände relativ zu einem anderen Objekt bewegen oder man die Fortbewegungsgeschwindigkeit oder Richtung ändert. Das menschliche Auge ist darauf trainiert, sich verändernde Situationen wahrzunehmen (Evolution und so).

Und nochmals:
Labele deine Bilder auf Imgsli...

[aufkrawall]

Sorry, ich sehe es mit meinen eigenen Augen am Schirm. Live in Bewegung beim Spielen.
DF komischerweise gar nicht. :D

[Troyan]

Siehst du, dass ist ja das fazierende an dir: Du siehst die Probleme angeblich nicht bei FSR 2.0, trotzdem die immer bei jeder Bewegung vorhanden sind. Das ist mir als alles erstes aufgefallen. Ich musste nichtmal suchen. Im Gegensatz zu DLSS, wo man erstmal eine schwarze Linie auf weißen Hintergrund finden muss.

Hier mal ein paar weitere nette Beispiele für die Qualität von FSR, wenn Geometrie sich überlappt:
https://imgsli.com/MTA3OTc5/4/5

Und als Vergleich ein Bild, wo DLSS an Objektkanten schliert: https://imgsli.com/MTA3OTgx

Und du redest davon, dass FSR 2.0 besser ist? Selbst beim Schlierbild ist FSR 2.0 nicht besser. Und der Worst-Case geht klar an FSR 2.0...

[DrFreaK666]

Gut. FSR2.0 ist bei X schlechter, DLSS bei Y.
Riecht ungefähr nach einem Patt

[Ex3cut3r]

Finde die Diskussion nach Fehler suchen mit der Lupe auch arg lächerlich.

Aber, ey wenn Sie Spaß haben, und sich nicht beleidigen, von mir aus. :biggrin:

[aufkrawall]

Ich habe 2.3.9, was minimal weniger ghostet. Mit der mitgelieferten DLSS sieht es kaum schlechter aus. Gerade getestet.

Doof nur, dass ich schon den CapFrameX-Tweet verlinkt hatte, wo 2.3.0 massiv stärker smeart.
Und auch nicht nur an der dort gezeigten Stelle, sondern auch mit Gräsern oder Geländern vorm Level-Hintergrund etc.
Hast du schon mal schlecht getestet.

[OpenVMSwartoll]

Die Diskussion an sich ist schon interessant, lese mit großem Interesse. Wenn man Pixel zählen muss, kann FSR gar nicht so übel sein. Dass jemand sich mit Händen und Füßen wehrt, die AMD Lösung gut zu finden, hatte ich mir fast erhofft.

[basix]

Siehst du, dass ist ja das fazierende an dir: Du siehst die Probleme angeblich nicht bei FSR 2.0, trotzdem die immer bei jeder Bewegung vorhanden sind. Das ist mir als alles erstes aufgefallen. Ich musste nichtmal suchen. Im Gegensatz zu DLSS, wo man erstmal eine schwarze Linie auf weißen Hintergrund finden muss.

Hier mal ein paar weitere nette Beispiele für die Qualität von FSR, wenn Geometrie sich überlappt:
https://imgsli.com/MTA3OTc5/4/5

Und als Vergleich ein Bild, wo DLSS an Objektkanten schliert: https://imgsli.com/MTA3OTgx

Es gibt auch etliche Beispiele, wo DLSS auch anderswo schliert. Und ich habe niemals behauptet, das FSR nicht schliert. Es fällt mir in den meisten Fällen einfach weniger auf.
Die Gitterstangen ghosten im ersten Vergleich wirklich stark. Konnte ich so aber noch nirgends selbst beobachten.

Edit:
Und danke fürs labeln ;)


Und du redest davon, dass FSR 2.0 besser ist? Selbst beim Schlierbild ist FSR 2.0 nicht besser. Und der Worst-Case geht klar an FSR 2.0...
Du legst mir Worte in den Mund. Mir fällt das Blurring von DLSS einfach deutlich stärker auf als die Artefakte von FSR. Und das ist subjektiv. Worst Case ist ausserdem äusserst stark von der Szene abhängig. Bei der von mir gezeigten Szene geht der Worst-Case ganz klar an DLSS ;)

Gut. FSR2.0 ist bei X schlechter, DLSS bei Y.
Riecht ungefähr nach einem Patt
Bingo ;)

Soll jeder einfach das nehmen, was einem besser gefällt.

Finde die Diskussion nach Fehler suchen mit der Lupe auch arg lächerlich.
Naja, da gibt es zwei Aspekte:

Mir fallen einige Dinge auch ohne Zoom und Lupe und direkt im Spielgeschehen negativ auf. Ist das lächerlich, wenn ich das aufzeige? Ich sage nur, dass DLSS bei weitem nicht perfekt ist und im Hinblick auf Deathloop gefällt mir FSR 2.0 besser. Persönliche Meinung.
Aus technisher Perspektive ist "Pixel Peeping" natürlich interessant. Da ist es Blur, Ghosting, Schärfeartefakte usw. welche bei DLSS und FSR nicht optimal sind. So kann man aufzeigen was wo noch nicht passt. Und allenfalls in Zukunft beheben, vielleicht bekommen die Entwickler bei AMD, Nvidia, Intel und den Spielestudios diese Diskussionen ja mit ;)


Aber, ey wenn Sie Spaß haben, und sich nicht beleidigen, von mir aus. :biggrin:
Richtig :D Solange meine eigene intrinsische Motivation mich diese Vergleiche machen lässt (ergo "Spass", wenn man das hier so nennen will) und man respektvoll diskutiert, ist doch alles i.O. ;)

Wenn man Pixel zählen muss, kann FSR gar nicht so übel sein
Das ist doch mal die richtige Einstellung

[Tesseract]

bedenkt ihr, dass bei temporalen algorithmen (und das ist schon seit TAA so) die framerate einen wesentlichen einfluß auf die qualität hat? mehr fps bedeutet günstigere motion vektoren bedeutet potenziell bessere qualität und wenn man verschiedene algorithmen vergleicht können sich vor- und nachteile so leicht verschieben oder aufschaukeln.

[Andron]

Das Lustige an Troyan ist, dass er DLSS 1.X und die ersten Iterationen von DLSS 2.0 in den Himmel gelobt hatte und jetzt gegen ein objektiv deutlich besseres FSR 2.0 schießt. Wie das zusammen passt, weiß wohl nur er selbst.
Was passiert wohl, wenn AMD mit dem nächsten Update evtl. noch das ein oder andere Problem abstellt, welches FSR in Deathloop hat?

Das größte Problem von FSR ist dabei mit Sicherheit nicht die Qualität, sondern die leider noch enttäuschende Liste mit zukünftig unterstützten Titeln. Da wäre Kritik viel eher angebracht, denn AMD hat hier einiges aufzuholen und weitere Konkurrenz in Form von XeSS ist schon auf dem Weg. Was nützt die breite Nutzbarkeit von FSR 2.0 wenn es kaum in großen Titeln genutzt wird.

[basix]

bedenkt ihr, dass bei temporalen algorithmen (und das ist schon seit TAA so) die framerate einen wesentlichen einfluß auf die qualität hat? mehr fps bedeutet günstigere motion vektoren bedeutet potenziell bessere qualität und wenn man verschiedene algorithmen vergleicht können sich vor- und nachteile so leicht verschieben oder aufschaukeln.

Sehe ich hier nicht als Problem an, da DLSS und FSR 2.0 von der Performance her faktisch gleichwertig sind. Oder sind jetzt 74 zu 71 fps ein Problem? ;)

Das gilt natürlich nur bei der gleichen Testszene. Ändern sich Szenen und die FPS sagen wir mal von 60 auf 100: Ja, da könntest du recht haben. Neben den FPS wird aber auch die dargestellte Szene / der dargestellte Content einen grossen Einfluss haben.

[ChaosTM]

Man sollte den Troyaner einfach ignorieren. Von ihm kommt nur NV Werbung.
Er wird entweder bezahlt, oder er ist einfach nur sehr "ignorant".

[aufkrawall]

bedenkt ihr, dass bei temporalen algorithmen (und das ist schon seit TAA so) die framerate einen wesentlichen einfluß auf die qualität hat? mehr fps bedeutet günstigere motion vektoren bedeutet potenziell bessere qualität und wenn man verschiedene algorithmen vergleicht können sich vor- und nachteile so leicht verschieben oder aufschaukeln.
Das hat auf die Schlieren von DLSS aber keinen Einfluss, ich sehe das in Fortnite mit 138fps genau so wie in Deathloop mit 70.
Gleiches gilt für das Jittering dünner Linien oder den Motion Blur. Ich hab subjektiv mit 138fps in Fortnite mit DLSS kaum oder gar nicht weniger Motion Blur (oder gar mehr) als mit FSR 2.0 in Deathloop bei 70.

Mit Quality vs. Quality anstatt Balanced vs. Balanced verschiebt sich meine Favorisierung sogar noch weiter zu ungunsten von DLSS. Der hohe, aber immer noch natürlich wirkende Schärfegrad von FSR 2.0 vs. DLSS ist einfach der Wahnsinn. Das ist vom Bildeindruck quasi wie mit Postprocessing kollidierendes erzwungenes Treiber-4xSGSSAA vs. einen extrem hohen OGSSAA-Faktor (sagen wir mal 16x) mit entsprechend knackscharfem Ergebnis im Vergleich.

[OpenVMSwartoll]

Man sollte den Troyaner einfach ignorieren. Von ihm kommt nur NV Werbung.
Er wird entweder bezahlt, oder er ist einfach nur sehr "ignorant".

Ganz im Gegenteil: Je engagierter er agiert, desto mehr stelle ich fest, dass er sich mit Händen und Füßen dagegen wehren muss, nicht zu sagen: "Für die erste Implementierung gar nicht übel, AMD." Sein Engagement ist für mich eine Bestätigung.

[Tesseract]

Sehe ich hier nicht als Problem an, da DLSS und FSR 2.0 von der Performance her faktisch gleichwertig sind. Oder sind jetzt 74 zu 71 fps ein Problem? ;)

es geht nicht um DLSS vs FSR sondern darum, dass einer sagt er sieht A und der andere er sieht B aber wenn A auf 150fps und B und 50fps läuft kommt am ende ein anderes bild raus auch bei gleicher auflösung da die input-samples andere sind.

[basix]

Das größte Problem von FSR ist dabei mit Sicherheit nicht die Qualität, sondern die leider noch enttäuschende Liste mit zukünftig unterstützten Titeln. Da wäre Kritik viel eher angebracht, denn AMD hat hier einiges aufzuholen und weitere Konkurrenz in Form von XeSS ist schon auf dem Weg. Was nützt die breite Nutzbarkeit von FSR 2.0 wenn es kaum in großen Titeln genutzt wird.
Ich hoffe inständigst, dass AMD schaut, dass möglichst viele Spiele mit bestehender DLSS 2.0 Implementation ein Update mit FSR bekommen.

Oder mit Nvidias Streamline zusammenarbeitet, wo dann DLSS, XeSS und FSR drin ist.
- Nvidia Karten können DLSS und FSR gleich gut, XeSS vermutlich etwas langsamer
- AMD Karten können FSR gut, XeSS vermutlich etwas langsamer
- Intel Karten können gut XeSS und vermutlich auch gut FSR
- Inkl. Sharpening Slider für alle drei Technologien

Der Nutzer hat dann mindestens die Wahl zwischen zwei Temporal Upsampling Verfahren. Und anhand der Auflistung sieht man auch, wieso Nvidia an Streamline interessiert ist: Sie sind die einzigen, die alle drei Technologien anbieten können und falls sie XeSS via DP4a auch schnell ausführen, nirgends einen wesentlichen Performancenachteil haben.

es geht nicht um DLSS vs FSR sondern darum, dass einer sagt er sieht A und der andere er sieht B aber wenn A auf 150fps und B und 50fps läuft kommt am ende ein anderes bild raus auch bei gleicher auflösung.
Klar, dem stimme ich bei. Ich neige aber dazu zu behaupten, dass die FPS weniger viel ausmachen als die entsprechende Szene/Content. Oftmals ist auch der Betrachtungswinkel sehr entscheidend. Zumindest bei den jetzigen Implementationen und bei Frameraten >60fps. Sobald man runter geht, sagen wir mal 30fps, dann werden viele der Artefakte derfinitiv deutlich ausgeprägter, da sie länger persistent sind.

Beispiel:
DLSS Q vs. P hat mehr Pixel, dafür weniger FPS. DLSS Q wird bezüglich Artefakten jedoch immer besser abschneiden. Dito bei FSR. Momentan scheint die spatiale Auflösung für das Resultat also eindeutig wichtiger zu sein als die temporale Auflösung. Bei sehr feinen Geometrien macht das auch Sinn, da die Bewegungswektoren afaik in 3x3 Pixel Auflösung vorliegen. Im Falle von 4K wäre das 720p für die Bewegungsvektoren. Und soweit ich weiss, hängt das an der Renderauflösung, also sind Bewegungsvektoren bei 4K DLSS/FSR Performance mit gerademal 360p aufgelöst.

Bin mir nicht sicher, ob das an einem positiven Feedback Loop liegt. Bei FSR wird der Output Buffer der vorhergehenden Frames reingefüttert. Ist hier bereits ein Fehler vorhanden, kann sich der dadurch verstärken. Bei DLSS und Co. wird das vermutlich ähnlich sein. Aber die Leute bei AMD und Nvidia sind nicht auf den Kopf gefallen und werden das sicher wissen. Ist nur die Frage, wie man damit umgeht und die Fehler behebt.

[aufkrawall]

es geht nicht um DLSS vs FSR sondern darum, dass einer sagt er sieht A und der andere er sieht B aber wenn A auf 150fps und B und 50fps läuft kommt am ende ein anderes bild raus auch bei gleicher auflösung da die input-samples andere sind.
Dieser Effekt ist völlig überbewertet, das spielt quasi keine Rolle vs. Renderauflösung.

[Ex3cut3r]

Dieser Effekt ist völlig überbewertet, das spielt quasi keine Rolle vs. Renderauflösung.

Beim Standbild ja, in Bewegung spielt es aber sehr wohl ne Rolle. Mit jedem Monitor der über 60HZ/60 FPS liefert.

Ich hatte glaub ich 110 FPS in 4K mit DLSS Q/ FSR Q, du 60/70FPS in 1440p. Das ist am ende eben in Bewegung ein gravierender Unterschied.

[aufkrawall]

Ich habe schon gesagt, dass das in Fortnite DLSS mit 138fps ziemlich genau so blurt, ghostet und jittert wie in Deathloop bei weniger als der Hälfte der fps. Eher fällt das durch weniger Hold Type Motion Blur bei höheren fps noch stärker ins Gewicht.

[Troyan]

es geht nicht um DLSS vs FSR sondern darum, dass einer sagt er sieht A und der andere er sieht B aber wenn A auf 150fps und B und 50fps läuft kommt am ende ein anderes bild raus auch bei gleicher auflösung da die input-samples andere sind.

Ja, je geringer die Frames, umso stärker das Ghosting bei FSR 2.0. Und umso stärker auch das Zerbröseln der Grafik bei überlappender Geometrie.

Je geringer die Output-Auflösung, umso großflächiger der Bereich bei überlappender Geometrie und umso sichtbarer auch das Ghosting.

Ghosting ist ein fundamentales Problem von FSR 2.0 und wird durch das Zerbröseln von überlappender Geometrie noch verstärkt. Selbst in den totkomprimierten 1080p Vorschauvideos von Google Drive muss man ein Flatearthler sein, um das nicht sehen zu können:
1440 FSR 2.0 P:https://drive.google.com/file/d/1cZU-GCvS33mQLmQjhX1xFvqpWfajqV2g/view
1440p DLSS P: https://drive.google.com/file/d/1pt7kJi9kTyK8yeU3DMv6Y__eXwAMW5Mi/view

2160p FSR P: https://drive.google.com/file/d/1pd-j4LTZFsd6yauStTOF5f3Evuy5XzYZ/view
2160p DLSS P: https://drive.google.com/file/d/1pyr1_pT5bQvhFH-SfFwE9whBwBXjaU-n/view

Und bewegende Objekte sind eben auch so ein Nogo: https://imgsli.com/MTA4MDEx

[basix]

Ja, je geringer die Frames, umso stärker das Ghosting bei FSR 2.0. Und umso stärker auch das Zerbröseln der Grafik bei überlappender Geometrie.

Je geringer die Output-Auflösung, umso großflächiger der Bereich bei überlappender Geometrie und umso sichtbarer auch das Ghosting.

Das ist vom Prinzip her bei jedem temporalen Ansatz so. Bei FSR wie auch DLSS und TSR kann man das beobachten. Bei normalem TAA ebenfalls.

[Ex3cut3r]

Ich habe schon gesagt, dass das in Fortnite DLSS mit 138fps ziemlich genau so blurt, ghostet und jittert wie in Deathloop bei weniger als der Hälfte der fps. Eher fällt das durch weniger Hold Type Motion Blur bei höheren fps noch stärker ins Gewicht.

Ok, hast mich überzeugt, habs auch mal getestet @ 1440p mit FPS Limiter, sonst bin ich bei 150 FPS avg. :freak:

Scheint tatsächlich vollkommen egal zu sein, welche Output FPS man besitzt, das schmiert mit 30 FPS genau so, wie mit 150 FPS.

Allerdings liefert die 2.3.9 bessere "Werte" die Ausgangs Dll ist schlimmer. Oder einfach ein uraltes 60HZ VA Panel kaufen, dann fällt das gar nicht mehr auf. ;D ;)

[Troyan]

Das ist vom Prinzip her bei jedem temporalen Ansatz so. Bei FSR wie auch DLSS und TSR kann man das beobachten. Bei normalem TAA ebenfalls.

AMD verstärkt den Effekt künstlich, weil man eben nicht die Rechenleistung aufbringen oder aber in Bewegung massiv blurren will.

Schlussendlich resultiert dies in Artefakten bei bewegender und überlappender Geometrie und Effekte. Hier mal Beispielvideo bei Raucheffekten:
FSR P: https://drive.google.com/file/d/1Fj66mnapw68Lb_uSKKqt_DUAUN8_z1Dh/view
DLSS P: https://drive.google.com/file/d/1lwcFOzrraMMoxmzQHIj-V-sIw1lJxhDg/view?usp=sharing

Sobald also irgendwo Geometrie sich überlappt, fällt das ganze auf native Inputauflösung zurück. Das ist in Bewegung der Figur nicht problematisch, aber bei Stillstand eben ein massives Problem.

[Andron]

AMD verstärkt den Effekt künstlich, weil man eben nicht die Rechenleistung aufbringen oder aber in Bewegung massiv blurren will.


Das ist eine reine Behauptung ohne jeglichen Beweis. Es ist die allererste Version von FSR 2.0 und du suchst krampfhaft die wenigen Negativaspekte (die zweifelslos da sind) und lässt Sie bei DLSS mal wieder gekonnt unter den Tisch fallen. Gib doch einfach zu, dass du komplett überrumpelt von FSR 2.0 wurdest und es deine Erwartungen in jeder Hinsicht übertroffen hat. Gestern hast du dich noch über unfaire Vergleiche bezüglich Nachschärfen etc. ausgeheult, aber FSR darf in der ersten Iteration schon komplett nieder gemacht werden, ohne mal ein, zwei Updates abzuwarten, die ggf. noch das ein oder andere Problem fixen.

DLSS bleibt mMn. unter dem Strich die minimal robustere Lösung, was ohne direkten Vergleich aber nicht wirklich auffällt. Wenn man auf Bildschärfe (auch in Bewegung) Wert legt, kann es schon jetzt anders aussehen.

Die wenigen Vorteile werden aber durch andere Nachteile erkauft, wie man an den unterschiedlichen Versionen erkennen kann (Stichwort Ghosting, Smearing, Motion-Blur...). Unter dem Strich mach der sagenumwobene ML-Ansatz keine allzu gute Figur mehr, wenn man die geringen Unterschiede betrachtet. Wenn AMD an den noch sichtbaren Problemen arbeitet, könnten die letzten Vorteile von DLSS in jetziger Form auch schnell Geschichte sein oder zumindest so gering werden, dass es überhaupt niemanden interessiert.

[aufkrawall]

Ok, hast mich überzeugt, habs auch mal getestet @ 1440p mit FPS Limiter, sonst bin ich bei 150 FPS avg. :freak:

Scheint tatsächlich vollkommen egal zu sein, welche Output FPS man besitzt, das schmiert mit 30 FPS genau so, wie mit 150 FPS.

Allerdings liefert die 2.3.9 bessere "Werte" die Ausgangs Dll ist schlimmer. Oder einfach ein uraltes 60HZ VA Panel kaufen, dann fällt das gar nicht mehr auf. ;D ;)
Danke fürs Testen. Ja, finde auch, dass 2.3.9 der bessere Kompromiss ist, und das sehen in Foren ja viele so. Von daher kann man schon ruhig diese Version testen imho.
2.2.6 smeart zwar wirklich teilweise noch weniger, ist dafür in Bewegung aber auch unruhiger.

FSR 2.0 hat tatsächlich auch unter Ghosting in gewissen Situationen zu leiden, die Tunnel-Türen scheinen so ein Kandidat zu sein. Allerdings schmiert es halt nicht so konstant und unscharf.
Der Gegnner hinterm Zaun zieht mit DLSS einen Farbschleier hinter sich her (fiel in Bewegung deutlicher auf als auf dem Screenshot, man sollte hier etwas reinzoomen), mit FSR 2.0 nicht:
https://abload.de/thumb/deathloop_2022_05_15_iwjom.png (https://abload.de/image.php?img=deathloop_2022_05_15_iwjom.png) https://abload.de/thumb/deathloop_2022_05_15_dyk5b.png (https://abload.de/image.php?img=deathloop_2022_05_15_dyk5b.png)

Kann mit FSR 2.0 auch ähnlich passieren, wenn etwa entfernte Gegner hinter einem Laternenpfahl hervorkommen. Allerdings sind das eher Ausnahmesituationen, mit DLSS smearen die häufig konstant über die ganze Bewegung vor wesentlich mehr Hintergründen.
Wie schon gesagt, bin ich wirklich mal auf ein Spiel gespannt, wo mit FSR 2.0 sich viele (entfernte) Dinge vor der Skybox bewegen. Wenn sich das deutlich geringere Smearing damit so bestätigt, wär das wirklich ein großer Vorteil.

[blaidd]

Lol... ich rieche hier Bugs in der Applikation. Daraus dürften die unterschiedlichen Eindrücke zu FSR 2.0 entstehen. :tongue: Zumindest solange eine Geforce RTX im System steckt. Ansonsten dürfte der Bug den aufkrawall hier genannt hat gar nicht erst aufkommen, da DLSS bei non RTX nicht zur Verfügung steht. Oder anders formuliert... bei RTX Karten muss man bestimmte Sachen beim Umschalten der Upscaling-Methoden beachten damit FSR 2.0 korrekt arbeitet.

Das DLSS geht auch kaputt, wenn man zwischenzeitlich die Framerate umschaltet oder Vsync (de-)aktiviert. Das schliert dann übelst. Hier, das ist FSR 2.0 vs DLSS mit jeweils Quality (WQHD, Ausschnitt).
EDIT, gewissermaßen als Bilderklärung: Die Figur da hat eine Bierflasche in der Hand, torkelt damit herum und spult dabei immer wieder die gleiche, vielleicht 20-30 Sekunden lange Idle-Animation ab - das kann man ziemlich gut abpassen und damit sind die Ansätze gut vergleichbar.

FSR 2.0
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=79358&stc=1&d=1652709781

DLSS 2.x
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=79357&stc=1&d=1652709781

Da scheint es generell noch ein paar Bugs zu geben.

[aufkrawall]

Das hatte ich schon mal während des Spielens vor ein paar Monaten zu sehen bekommen, in meinen ganzen letzten Tests allerdings nicht. Das ist natürlich ein unschöner Extremfall, den es nicht geben sollte, aber das "normale" Smearing mit DLSS betrifft das nicht.

[basix]

An was das wohl liegt?

Hier wäre Nvidias Streamline allenfalls auch von Vorteil, wenn sich solche Fehler damit vermeiden würden (zentrale Lösung des Problems denkbar).

[Achill]

An was das wohl liegt?

Hier wäre Nvidias Streamline allenfalls auch von Vorteil, wenn sich solche Fehler damit vermeiden würden (zentrale Lösung des Problems denkbar).

Sehe ich nicht so, es ist der alte NV Weg (wie schon früher) mit Extensions frühzeitig seine Lösung in den Markt zu bringen. Mit diesen Ansatz hat NV die Kontrolle über die Inputs für die temp. Rekonstruktion und kann:

1. Ohne Absprache diese selbst anpassen/erweitern, die anderen Lösungen müssen dann immer nachziehen und sind damit automatisch immer langsamer aka hier im Forum als schlechter ...

2. Andere Lösungen können keine weiteren Inputs selber einbringen sondern NV muss diese "freigeben" ...

Ich bin der Meinung dies führt zu einer Stagnation der Entwicklung bzw. NV hat damit die Kontrolle. Der einzige Vorteil für Studios wäre der "One-API" Ansatz mit den verbunden wenigeren Aufwänden.

[Gast]

1. Ohne Absprache diese selbst anpassen/erweitern, die anderen Lösungen müssen dann immer nachziehen und sind damit automatisch immer langsamer aka hier im Forum als schlechter ...


Genauso wie alle anderen auch.


2. Andere Lösungen können keine weiteren Inputs selber einbringen sondern NV muss diese "freigeben" ...


Natürlcih kann auch der Rest seine jeweiligen Lösungen verbessern/anpassen, ganz ohne NV, das ist ja der Sinn einer derartigen Schnittstelle.

Abgesehen davon ist die Schnittstelle selbst OS und kann damit von jedem angepasst werden.


Ich bin der Meinung dies führt zu einer Stagnation der Entwicklung bzw. NV hat damit die Kontrolle.


Genau das Gegenteil, es führt zu einem Wettbewerb wer nun die beste Upscaling Lösung anbieten kann, und das ohne dass die Spieleentwickler ständig nachbessern müssen.

[basix]

Das Streamline SDK soll Open Source sein. Kann jeder so anpassen wie man will, auch AMD und Intel ;) Oder die Spieleentwickler, wenn sie was anderes haben wollen.

Ob das dann ein Branch, Fork oder Upstream wird, ist was anderes.

Bei der "zentralen Lösung des Problems" habe ich daran gedacht, die dümmsten Fehler zu vermeiden. Beispielsweise die History Buffer clearen wenn man zwischen den Modi wechselt, sonstige States initialisieren usw.
Die sind dann nicht mehr Aufgabe der Engine sondern innerhalb von Streamline geregelt. Das ist ein grosser Dienst an den Spieleentwicklern. Die Spiele-Engines müssen dann nur brav die Input-Daten im richtigen Format abliefern und können anschliessend das Resultat wieder abholen. Alles palletti.

Will man Streamline mit einem neuen Interface oder neuer Funktionalität beglücken: Darf jeder machen. Und da es Upstream geschaltet werden kann: Hey, die anderen Hersteller oder auch Spieleentwickler können relativ schnell nachziehen. Innovation oder zumindest Verbesserungen auf breiter Front könnte sogar gefördert werden, da man gemeinsam am selben Problem arbeitet ;)

[aufkrawall]

An was das wohl liegt?

Könnte auch ein Bug in der DLSS-Version sein. Würde erklären, weshalb ich das mit neueren Versionen in dem Spiel noch nicht gesehen hab. Kann natürlich auch ganz anders sein.

[Gast]

Bei der "zentralen Lösung des Problems" habe ich daran gedacht, die dümmsten Fehler zu vermeiden. Beispielsweise die History Buffer clearen wenn man zwischen den Modi wechselt, sonstige States initialisieren usw.


Das wird in den seltensten Fällen helfen, das SDK kann nicht wissen wann dieser zu clearen ist, das muss immer noch von der Gameengine ausgeführt werden.

[hmmm]

AMD wird wohl versuchen das "Game eigene" TAA zu ersetzen, FSR 2.0 ist dafür doch der einzig in Frage kommende Ansatz. Es ist free/ OS und leicht-gewichtiger als die beiden Konkurrenten und funktioniert auch als "onlyAA"
Warum sollte ein Entwickler dann noch ein eigenes TAA supporten?

[dildo4u]

Benches mit RX480,Vega56,980TI,1070,6800XT,3090.

https://www.pcgameshardware.de/FidelityFX-Super-Resolution-Software-277617/Specials/FSR20-Test-vs-dlss-1394934/2/


In UHD perfromt FSR 2.0 dort erstaunlich gut jeweils schneller als FSR 1.0.
Nutzt 2.0 weniger Basis Auflösung?

[Andron]

In UHD perfromt FSR 2.0 dort erstaunlich gut jeweils schneller als FSR 1.0.
Nutzt 2.0 weniger Basis Auflösung?

FSR 2.0 nutzt die gleichen Ausgangsauflösungen und ist auch immer etwas langsamer als die jeweiligen FSR 1.0 Stufen. Der Ultra Quality Modus von FSR 1.0 hat eine deutlich höhere Ausgangsauflösung, ist bei FSR 2.0 aber nicht vorhanden. Daher ist FSR Ultra Quality in den Benchmarks meistens am langsamsten.

Edit: Im Gegensatz zum DF-Test gewinnt hier RDNA 2 sogar mehr Leistung durch FSR 2.0 als Ampere, was sich auch mit Computerbase deckt. RDNA 2 dürfte beim Leistungsgewinn also etwa auf DLSS@Ampere Niveau liegen. Was hat Digital Foundry denn da getestet? Oder ist es evtl. Treiberabhängig und DF hat noch nicht den Preview-Treiber verwendet?

[Raff]

Jo, das ist die ganze Erklärung. :) FSR 1.0 Q erreicht auf allen Karten etwas höhere Fps als 2.0 Q, was nicht verwunderlich ist (zumal 2.0 mehr VRAM benötigt).

+41 Prozent Leistung auf der 6800 XT durch FSR 2.0 Q ist sehr nett, zumal das sogar besser aussieht als das maue TAA des Spiels.

MfG
Raff

[Andron]

Hey Raff,

Ist es möglich, folgendes kurz gegenzuchecken:

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13004227&postcount=246

[Raff]

Das habe ich bereits gecheckt - "leider" gibt's keinen Fehler im PCGH-Video. Das Spiel warnt beim Wechsel von DLSS auf FSR und rät zu einem Neustart (anders herum nicht). Das habe ich stets beherzigt, also zuerst FSR und dann DLSS aufgenommen.

Die Unterschiede beim Nachstellen hängen somit a) von der Basis-Auflösung und b) vom eingestellten Sharpening ab. Deathloop setzt das Post-Sharpening bei FSR bei jedem Spielstart zurück auf 10, was einfach übertrieben ist.

MfG
Raff

[Andron]

Danke. Habe da einfach lieber die "offizielle" Bestätigung, als mit irgendwelchen Vergleichsbildern aus Foren hausieren zu gehen. Kann es selbst leider nicht gegentesten.

[Raff]

Gern. :) Wird einige Individuen nicht davon abhalten, weiter an eine giftgrüne Verschwörung zu glauben. Als Kritiker, der alles Gute gut findet und alles Schlechte auch so benennt, schreibt man im Laufe der Jahre einfach sehr viele Dinge und tritt damit jeder Fraktion mal auf die Füße. ;)

Ich bin jedenfalls sehr gespannt auf weitere Spiele mit FSR 2.0, denn trotz aller Diskussionen und erhellenden Ergebnisse ist das eben nur eine einzige Stichprobe. Ich würde den Algo ja gerne mal in einem UE4-Spiel oder Cyberpunk 2077 sehen. Gerne auch in AC Valhalla und Doom Eternal. Das sind allesamt Titel mit gutem TAA, was man von Deathloop nicht behaupten kann.

MfG
Raff

[Gast]

In UHD perfromt FSR 2.0 dort erstaunlich gut jeweils schneller als FSR 1.0.
Nutzt 2.0 weniger Basis Auflösung?

Wo? FSR2.0 Q ist meistens gerade mal so schnell wie FSR1.0 UQ

[Andron]

Werde das mit dem Lagerdenken nie verstehen. Nutze momentan auch hauptsächlich AMD Hardware, aber das kann sich ggf. beim nächsten Aufrüsten schon wieder ändern. Was bringt es einem, Fanboy einer Firma zu sein, außer eine noch schmalere Auswahl beim nächsten Kauf zu haben.

Weshalb sollte ich z.B. DLSS schlecht finden und niedermachen, nur weil ich es momentan nicht nutzen kann? Trotzdem sollte ja Kritik an den offensichtlichen Nachteilen erlaubt sein, Genau wie bei FSR & Co.

Ganz bei Dir bin ich bei den hoffentlich bald erscheinenden, weiteren FSR 2.0 Beispielen. Deine Auswahl an Titeln fände ich gut, plus Unreal 5. Hier wäre der Vergleich in der City Demo mit TSR und DLSS spannend. Ersteres macht hier insgesamt einen guten Job, versagt mMn. aber leider bei der Rekonstruktion der feinen Details um den Spielcharakter vor hellem Hintergrund. Das wäre eine Situation, wo FSR 2.0 zeigen kann, ob es sich von anderen heuristischen TAAU-Verfahren abheben kann.

[DrFreaK666]

... Edit: Im Gegensatz zum DF-Test gewinnt hier RDNA 2 sogar mehr Leistung durch FSR 2.0 als Ampere, was sich auch mit Computerbase deckt...

Da hat Raff wohl einen Fehler gemacht, denn DF ist unfehlbar ;)

... Ich würde den Algo ja gerne mal in einem UE4-Spiel oder Cyberpunk 2077 sehen. Gerne auch in AC Valhalla und Doom Eternal...
MfG
Raff

Ich dachte das Spiel nutzt die UE4.
Hatte id Tech 6 Doom kein gutes TAA?

[DrFreaK666]

Bei CB gibt es Tests von langsameren Karten ohne RT. Auch hier heißt es, dass Radeons stärker von FSR profitieren
https://www.computerbase.de/2022-05/amd-fsr-2.0-deathloop-test/2/#abschnitt_benchmark_in_full_hd_und_wqhd_mit_alten_gpus_update

Liest Alex hier mit? Wohl kaum

[Ex3cut3r]

Das ist aber ohne RT.

Hat DF nicht mit RT getestet? Ich weiß es leider nicht mehr.

[Gast]

Edit: Im Gegensatz zum DF-Test gewinnt hier RDNA 2 sogar mehr Leistung durch FSR 2.0 als Ampere, was sich auch mit Computerbase deckt. RDNA 2 dürfte beim Leistungsgewinn also etwa auf DLSS@Ampere Niveau liegen. Was hat Digital Foundry denn da getestet? Oder ist es evtl. Treiberabhängig und DF hat noch nicht den Preview-Treiber verwendet?

DF versuchte die Kosten von FSR2.0 abzuschätzen, nicht den Leistungsgewinn einer bestimmten Szene.

Die Kosten von FSR2.0 sollten wie bei allen derartigen Verfahren konstant sein und einzig von den verwendeten Auflösungen abhängen.

Das bedeutet logischerweise auch, dass der Geschwindigkeitsgewinn höher ist, je niedriger die Framerate ist, und die Geforce ist hier von haus aus deutlich schneller als die Radeon, wodurch sie selbst bei schnellerer FSR-Ausführungszeit möglicherweise weniger an Performance gewinnen kann.

[Gast]

Die Unterschiede beim Nachstellen hängen somit a) von der Basis-Auflösung und b) vom eingestellten Sharpening ab. Deathloop setzt das Post-Sharpening bei FSR bei jedem Spielstart zurück auf 10, was einfach übertrieben ist.



Schaut auch so aus als würde einfach ein anderes Sharpening/kein zusätzliches Sharpening verwendet werden. Dass das Upscaling grundsätzlich nicht funktioniert kann man jedenfalls eindeutig ausschließen.

Wenn man sowas nicht mal erkennt muss man der Person leider jegliche Kompetenz zur Beurteilung der Bildqualität absprechen.

[nairune]

Bei den alten Karten gibt es doch eh kein RT...

[Andron]

Das ist aber ohne RT.

Hat DF nicht mit RT getestet? Ich weiß es leider nicht mehr.

Computerbase hat sowohl mit als auch ohne RT getestet, PCGH ebenfalls mit RT im Falle von RDNA 2 / Ampere.

RT on sollte AMD bei der Skalierung sogar helfen, da die Strahlenanzahl deutlich mit der Eingangsauflösung reduziert wird, was die schwächere RT-Leistung stärker in den Hintergrund rücken lässt. Im CB-Test wird das in den RT-On Benchmarks auch sichtbar, hier profitieren die 6700XT/6800XT sogar stärker von FSR als die Geforce-Konkurrenz von DLSS.

[aufkrawall]

Gern. :) Wird einige Individuen nicht davon abhalten, weiter an eine giftgrüne Verschwörung zu glauben.
So weit würde ich nicht gehen. Dass das Schnee-Gestöber der Worst Case für FSR 2.0 in dem Spiel ist, ist aber auch ein Fakt.
Btw. sehr pixelakkurat ausgerichtete Kamera über die Spielneustarts hinweg mit allen drei Varianten, muss man ohne Savegames nach Spiel-Neustarts erst mal hinkriegen. ;)

[hmmm]

Aber so richtig schlau wird man wegen der "kosten" für FSR2.0 immer noch nicht. Ist die Genauigkeit @FSR2.0 aller GPUs auch wirklich gleich?
Bei FSR 2.0 vs DLSS 2x kommt für FSR 2.0 ja noch CAS obendrauf, macht nicht viel aber etwas.

[Gast]

Hatte id Tech 6 Doom kein gutes TAA?

Gut ja, aber meilenweit von DLSS entfernt.

Gibt sogar ein Entwicklerinterview, indem sie erzählt haben, dass sie vor dem DLSS-Einbau eigentlich das eigene TAA zum Upscaling verwenden wollten, aber qualitativ einfach nicht mithalten konnten.

[robbitop]

Ich bin nicht überrascht darüber, dass FSR 2.0 auf Ampere gut performt. Man hat immerhin sehr viel mehr Floating Point Rohleistung (von der sicherlich in einigen Spielen ein guter Teil brach liegt) als RDNA2.

[Gast]

Ich bin nicht überrascht darüber, dass FSR 2.0 auf Ampere gut performt. Man hat immerhin sehr viel mehr Floating Point Rohleistung (von der sicherlich in einigen Spielen ein guter Teil brach liegt) als RDNA2.

Vor allem kann man FP16 „for free“ und FSR2.0 verwendet bekanntermaßen viel FP16

[DrFreaK666]

Aber so richtig schlau wird man wegen der "kosten" für FSR2.0 immer noch nicht. Ist die Genauigkeit @FSR2.0 aller GPUs auch wirklich gleich?
Bei FSR 2.0 vs DLSS 2x kommt für FSR 2.0 ja noch CAS obendrauf, macht nicht viel aber etwas.

genau. Wie viel kostet das Sharpening bei FSR 2.0? Ist es for free?

[Raff]

Nichts, absolut gar nichts, ist für frei. Relevant sind die dafür aufgewendeten Nanosekunden ;) aber nicht.

MfG
Raff

[Ex3cut3r]

genau. Wie viel kostet das Sharpening bei FSR 2.0? Ist es for free?

CAS per Reshade, kostet hier 1-2 FPS. Kann man vernachlässigen.

So weit würde ich nicht gehen. Dass das Schnee-Gestöber der Worst Case für FSR 2.0 in dem Spiel ist, ist aber auch ein Fakt.
Btw. sehr pixelakkurat ausgerichtete Kamera über die Spielneustarts hinweg mit allen drei Varianten, muss man ohne Savegames nach Spiel-Neustarts erst mal hinkriegen. ;)

Also, das frage ich mich jetzt aber auch, wie schafft man es nach einen Neustart, pixelgenau die Kamera wieder an der selben Stelle auszurichten @ Raff? ^^

EDIT: Achso, vom Wechsel auf DLSS muss man nicht neu starten, kapiert. Sry.

Trotzdem tretet doch dann der Bug auf, wenn man von FSR 1 auf 2.0 hochschalten will, das ebend 2.0 nicht richtig übernommen wird. Sondern weiterhin 1.0 läuft, obwohl in den Optionen 2.0 steht. Das meinten glaube ich viele.

IHMO hätten die 1.0 einfach aus dem Spiel entfernen sollen. Niemand interessiert sich für 1.0 sobald 2.0 im Spiel integriert wurde.

[hmmm]

Nichts, absolut gar nichts, ist für frei. Relevant sind die dafür aufgewendeten Nanosekunden ;) aber nicht.

MfG
Raff
Normales CAS liegt zb bei einer 6900XT @4k bei ~ 0,3ms - 0,8ms (ist sehr inhaltsabhängig!)
^^ Das ist ja auch nicht so das "Problem", das Problem ergibt sich erst wenn man die "Zuwächse" (FSR2.0 vs DLSS oder FSR2.0 mit und ohne CAS) in Prozent angibt.
Obwohl es lediglich ein paar ms sind, kann auf dem FPS Tacho mal 2-4 FPS (mehr oder weniger) stehen.
Beispiel:
60FPS nativ ->FSR2+CAS -> 100FPS ~ 66% Steigerung
60FPS nativ ->FSR2 -> 102FPS ~ 70% Steigerung

[DrFreaK666]

Ich habe das RSR-Sharpening getestet. Ob mit 0% oder 100% macht keinen Unterschied. Kann natürlich sein, dass mit 0% auch was berechnet wird

[mironicus]

FSR 2.0 wird in dem Video auch auf dem Steam Deck getestet.
Der größte Vorteil ist hier aber nicht die Performance-Steigerung (42 FPS->47 FPS stille Szene), sondern die verbesserte Bildqualität die selbst bei der geringen Auflösung von 1280x800 bemerkbar ist.

j35bFcTo6gk

[basix]

Ich bin nicht überrascht darüber, dass FSR 2.0 auf Ampere gut performt. Man hat immerhin sehr viel mehr Floating Point Rohleistung (von der sicherlich in einigen Spielen ein guter Teil brach liegt) als RDNA2.

Jo, überrascht mich auch gar nicht. Was mich mehr überrascht ist, dass die 2060 so schlecht performt.

[Andron]

Vor allem kann man FP16 „for free“ und FSR2.0 verwendet bekanntermaßen viel FP16

Warum sollten FP16 Berechnungen auf Ampere "for free" sein? Ampere hat durch die pseudo-verdoppelten ALUs eine Menge Rohleistung, was sich in den FSR Benchmarks auch zeigt, "for free" ist aber gar nichts. Nicht einmal DLSS, das teilweise von den Tensor Cores beschleunigt wird. Letztere können FSR überhaupt nicht beschleunigen, da es auf Matrix-Multiplikationen spezialisierte Fixed-Function-Einheiten sind.

EDIT2: Da Ampere keinen doppelten FP16-Durchsatz auf den ALUs unterstützt, ist FP16 (abseits von Matrixmultiplikationen auf den Tensor Cores) sogar relativ langsam, verglichen mit Turing und allem von AMD ab Vega. Die theoretisch verdoppelte FP32-Leistung fängt das zwar in der Theorie etwas auf, in der Praxis ist ein Teil der ALUs aber auch mit INT32-Berechnungen beschäftigt und die reale FP32-Leistung in Spielen liegt immer unter dem theoretisch angegebenen Wert.

Ich bin nicht überrascht darüber, dass FSR 2.0 auf Ampere gut performt. Man hat immerhin sehr viel mehr Floating Point Rohleistung (von der sicherlich in einigen Spielen ein guter Teil brach liegt) als RDNA2.

Laut Tabelle von CB hat Ampere gar keinen doppelten Durchsatz bei FP16 auf den normalen ALUs. Das würde genau zu den Ergebnissen von PCGH und CB passen, in denen die 6800 XT (37,1 TFLOPS FP16) prozentual etwas mehr Leistung durch FSR hinzugewinnt, als die 3080/3090 (29,8/35,7 TFLOPS FP16). Natürlich eine Milchmädchenrechnung und nicht 1 zu 1 vergleichbar, aber die grobe Richtung stimmt. Berücksichtigt man das insgesamt höhere Leistungsniveau von Ampere in den Benchmarks, sind die absoluten Zugewinne sogar wirklich etwas größer als auf RDNA 2.

Jo, überrascht mich auch gar nicht. Was mich mehr überrascht ist, dass die 2060 so schlecht performt.

Passt aber auch in etwa ins Bild, die RTX 2060 bietet lediglich 7,2 14,4 TFLOP FP16 über die ALUs. Die CB-Werte sind trotzdem noch etwas enttäuschend, aber auch DLSS gewinnt erstaunlich wenig Leistung hinzu. Evtl. liegt es auch am knappen VRAM, Deathloop soll diesen wohl ab und zu zum überlaufen bringen.

Edit: Turing sollte doch deutlich stärker profitieren, da die ALUs doppelten FP16 Durchsatz unterstützen.

[Raff]

Ampere hat definitiv keinen doppelten FP16-Durchsatz via ALUs, das ist 1:1 zu FP32, bestätigt von Nvidia. Daher sind FP16-Kalkulationen eigentlich ein "Pro-AMD-Workload", denn RDNA 2 stemmt hier Faktor 2.

MfG
Raff

[Gast]

Warum sollten FP16 Berechnungen auf Ampere "for free" sein?


Weil Ampere dedizierte FP16 Einheiten hat, manche sagen auch Tensorcores dazu. Diese Dinger können nicht nur Tensorberechnungen, sondern auch ganz normale FP16-Vektoren berechnen, und das parallel zu den FP32/INT32 Einheiten.

RDNA2 kann zwar FP16 mit doppelter Geschwindigkeit, aber dann kein FP32 gleichzeitig.


Letztere können FSR überhaupt nicht beschleunigen, da es auf Matrix-Multiplikationen spezialisierte Fixed-Function-Einheiten sind.


Das haben viele eben immer noch nicht verstanden, es sind nicht "nur" fixed function Einheiten für einen bestimmten Zweck und sonst gar nichts. Alles was FP16 ist wird in Nvidias SM von den Tensorcores abgehandelt.



Laut Tabelle von CB hat Ampere gar keinen doppelten Durchsatz bei FP16 auf den normalen ALUs.


Ja, weil die Tensorcores nicht verdoppelt wurden.
1 Tensorcore kann FP16 mit dem doppelten Durchsatz eines FP32 Blocks, da es aber bei Ampere 2 FP32 Blöcke (bzw. genauer 1 FP32, und der INT/FP32 Kombiblock) gibt ist der reine theoretische Durchsatz gleich groß.

Das entscheidende ist aber, dass es bei Ampere kein entweder/oder ist sondern beides gleichzeitig geht.




Edit: Turing sollte doch deutlich stärker profitieren, da die ALUs doppelten FP16 Durchsatz unterstützen.

Jein, Turing verhält sich hier gleich zu Ampere. FP16 wird mit den Tensorcores verarbeitet, FP32/INT32 bleibt dabei frei. Da es aber pro SM nur die halben FP32 bei gleich vielen Tensorcores gibt, ist der reine Durchsatz von FP16 doppelt so hoch als von FP32.

Das gilt aber so wohl bei Ampere als auch bei Turing immer nur wenn man FP16 und FP32 getrennt betrachtet. Bei beiden geht beides parallel, und nachdem die Shader-Anforderungen in der Regel einen starken Überhang an FP32 aufweisen sind es normalerweise diese Operationen welche die Performance limitieren, und FP16 gibt es quasi gratis dazu.

[Gast]

Ampere hat definitiv keinen doppelten FP16-Durchsatz via ALUs, das ist 1:1 zu FP32, bestätigt von Nvidia. Daher sind FP16-Kalkulationen eigentlich ein "Pro-AMD-Workload", denn RDNA 2 stemmt hier Faktor 2.


Bei AMD sind es aber entweder FP32 + 2x FP16. Bei Nvidia sind es FP32 + FP16 gleichzeitig, der AMD Vorteil ergibt sich nur wenn man lediglich FP16 rechnet, bzw. die FP16 Operationen überwiegend eingesetzt werden.

In realen Shadern werden aber FP32 mit Abstand am meisten eingesetzt, damit ist Nvidia vom Vorteil, da ihnen FP16 eben nichts an FP32 Durchsatz kostet.

[vinacis_vivids]

Bei AMD kannst du die shader stages dank async compute gleichzeitig fp32 + 2xfp16 ausführen, und das mit einer extrem niedrigen Latenz. Zudem gibt es doch SAM, wo die CPU direkten Zugriff auf den Speicher/Cache bekommt.

Das ist u.a. der Grund wieso eine 6700XT mit einer RTX3090 gleichziehen kann. RDNA uArch setzt extrem viel und extrem schnelle CPU-Leistung um.

https://abload.de/img/rdna2ga1021qkgk.png

6700 XT: max. 14 fp32 Tflop/s
RTX 3090: max. 38 fp32 Tflop/s

Die 3090 hat bei fp32 zwar 171% Mehrleistung, kann davon leider nicht viel umsetzen.

Bei zusätzlicher FSR 2.0 Umsetzung wird die 3090 womöglich noch von der 6700XT überholt.

[ChaosTM]

Gurken CPU mit Lahmarsch RAM vs Highendiger CPU mit ebensolchem Speicher. Das scheint mir jetzt nicht überzogen fair zu sein.. ;)

K.a. wie stark die CPU in dem Fall limitiert

[Gipsel]

Bei AMD kannst du die shader stages dank async compute gleichzeitig fp32 + 2xfp16 ausführen, und das mit einer extrem niedrigen Latenz. Zudem gibt es doch SAM, wo die CPU direkten Zugriff auf den Speicher/Cache bekommt.Bitte wirf nicht jeden Kram durcheinander! Auf einer vALU gehen FP32 und FP16 natürlich nicht gleichzeitig. Und SAM ist in dem Zusammenhang ziemlich irrelevant.

[Gast]

Bei AMD kannst du die shader stages dank async compute gleichzeitig fp32 + 2xfp16 ausführen, und das mit einer extrem niedrigen Latenz.

Da hat jemand ja das richtig tolle technische Verständnis.

Eine ALU kann zu jeder Zeit immer nur eine Aufgabe ausführen.

Async Compute ist ein reines Softwarekonstrukt. Die Grafikpipeline muss zu einem gewissen Grad In-Order ausgeführt werden. Bestes Beispiel dafür sind Transparenzen, die erst gerendert werden dürfen, wenn das was dahinter liegen soll fertig ist. Oder das Postprocessing was erst starten kann wenn das "Rohbild" fertig ist.

Mit Async Compute kannst der Entwickler Shader definieren, bei denen er explizit sagt "mir ist wurscht wann das gemacht wird". Und weil es compute heißt, sagt das übrigens nichts darüber aus ob irgendwas von der Grafik berechnet wird, in den meisten Fällen wird auch mit Async Compute Grafik berechnet.
Damit können Lücken gefüllt werden die in der Grafikpipeline entstehen weil irgendwas auf was anderes warten muss.

Async Compute erzeugt nicht irgendwie auf magische weise zusätzliche Rechenleistung, es ermöglicht lediglich die vorhandene besser auszulasten, und das geht nur wenn die Pipeline nicht eh schon ausgelastet ist.

Deshalb hat in der Regel auch GCN wesentlich mehr von Async Compute profitiert als es nun RDNA(2) macht, ganz einfach weil GCN notorisch schlecht ausgelastet war, was bei RDNA enorm verbessert wurde.

[Gast]

Der größte Vorteil ist hier aber nicht die Performance-Steigerung (42 FPS->47 FPS stille Szene), sondern die verbesserte Bildqualität die selbst bei der geringen Auflösung von 1280x800 bemerkbar ist.

https://youtu.be/j35bFcTo6gk

Der hat aber im "native" screen gar kein AA aktiv, da ist es kein Wunder, dass das FSR-Bild wesentlich stabiler ist.
Wobei auch so das FSR-Bild wesentlich besser als das TAA ist, und auf dem kleinen Bildschirm ist nicht mal das übertriebene Default-Sharpening (was sich verringern lässt) so schlimm.

Wobei es dem Steamdeck leider an CPU-Leistung fehlt, und sich der Performancegewinn wie gezeigt in Grenzen hält. 2GHz Zen2 sind eben nicht gerade das Gelbe vom Ei. Da wären ja sogar 4x Icestorm besser und die brauchen fast gar nix an Strom.

[Andron]

Weil Ampere dedizierte FP16 Einheiten hat, manche sagen auch Tensorcores dazu. Diese Dinger können nicht nur Tensorberechnungen, sondern auch ganz normale FP16-Vektoren berechnen, und das parallel zu den FP32/INT32 Einheiten.

Hast recht was das angeht, Im Turing-Whitepaper hatte ich gestern nichts auf anhieb dazu gefunden, im Ampere-Whitepaper wird es dann aber erwähnt (auch für Turing).


Ja, weil die Tensorcores nicht verdoppelt wurden.
1 Tensorcore kann FP16 mit dem doppelten Durchsatz eines FP32 Blocks, da es aber bei Ampere 2 FP32 Blöcke (bzw. genauer 1 FP32, und der INT/FP32 Kombiblock) gibt ist der reine theoretische Durchsatz gleich groß.

Das entscheidende ist aber, dass es bei Ampere kein entweder/oder ist sondern beides gleichzeitig geht.

Ampere kann zwar Tensor-Cores und ALUs parallel rechnen lassen, aber da sich beide Einheiten Scheduler, Cache, Speicheranbindung sowie Power-Budget etc. teilen, dürften die Zugewinne doch weit von der theoretischen Rechenleistung entfernt sein, zumal Ampere durch die Verdopplung der FP32-fähigen ALUs schon schwieriger auszulasten ist. Dass es unter dem Strich Zugewinne gibt, hat ja DLSS auf Ampere vs. Turing gezeigt, kostenlos ist DLSS aber nicht einmal auf einer 3090 in niedrigen Auflösungen.

FSR 2.0 zeigt ja ebenfalls eine ähnliche Skalierung zwischen Ampere und RDNA 2, mit leichten Vorteilen für die Radeons. Da müsste bei Ampere dann schon etwas die parallele FP32/FP16 Berechnung limitieren.

[Gast]

Ampere kann zwar Tensor-Cores und ALUs parallel rechnen lassen, aber da sich beide Einheiten Scheduler, Cache, Speicheranbindung sowie Power-Budget etc.


Grundsätzlich natürlich richtig. Aber die benötigten Ressourcen sind bei reiner FP16 Vektorrechnung wesentlich geringer als wenn die Matrixfunktionen verwendet werden, und da diese bekanntermaßen auch parallel abgearbeitet werden können, sollte die sich die Zusatzbelastung in Grenzen halten.


teilen, dürften die Zugewinne doch weit von der theoretischen Rechenleistung entfernt sein, zumal Ampere durch die Verdopplung der FP32-fähigen ALUs schon schwieriger auszulasten ist.


Ampere hat kein Problem seine Einheiten Auszulasten, Turing hat das Problem weil es so gut wie immer gar nicht genügend INTs gibt.

In realen Spielen beträgt der INT-Anteil ca. 30-50% der FP-Operationen. Die zu erwartende Mehrleistung von Ampere pro SM beträgt also ca. 30-50%, und genau in diesem Bereich befindet man sich großteils.

Die Mär vom nicht ausgelasteten Ampere kommt von der falschen Erwartungshaltung, dass Ampere doppelt so viele Recheneinheiten pro SM hätte.
Das ist aber nicht der Fall, Ampere hat genau gleich viele Recheneinheiten pro SM, diese sind aber flexibler und daher besser/leichter auslastbar wie jene von Turing, bei denen es nur mit perfektem Codemix überhaupt möglich wäre.

[mksn7]

Ampere kann zwar Tensor-Cores und ALUs parallel rechnen lassen, aber da sich beide Einheiten Scheduler, Cache, Speicheranbindung sowie Power-Budget etc.

Grundsätzlich natürlich richtig. Aber die benötigten Ressourcen sind bei reiner FP16 Vektorrechnung wesentlich geringer als wenn die Matrixfunktionen verwendet werden, und da diese bekanntermaßen auch parallel abgearbeitet werden können, sollte die sich die Zusatzbelastung in Grenzen halten.


Die benötigten Ressourcen beim scheduler sind genau gleich. Ein Takt in dem eine tensor instruction gescheduled wird (wenn wir mal annehmen dass die tensor cores wirklich dazu verwendet werden können um FP16 vector ops auszuführen, kann schon sein), ist ein Takt in dem keine FP32 instruction gescheduled wird.

Also, das eine oder das andere. Wenn auf einer Ampere SM der volle, maximale FP32 Durchsatz ausgenutzt wird, also durchgängig pro scheduler alle 2 Takte 2 FP32 Instruktionen, dann kann nichts, absolut gar nichts mehr anderes ausgeführt werden. Kein int, kein load, kein store, kein branch, kein sonstiger ALU Kram, keine tensor core instructions, kein special function kram...

Es kann einfach nicht mehr geissued werden. Mal abgesehen davon dass die Registerbandbreite das auch noch bremsen würde, und selbst bei manchen Kombinationen von FP32 Instruktionen schon zu knapp ist.

[Gast]

Bei Ampere können alle Teile parallel arbeiten.

https://g3f4h2w2.rocketcdn.me/wp-content/uploads/2020/09/NVIDIA-GeForce-RTX-30-Tech-Session-00036_657EBA0F93174506B1741A4533873B0D.jpg

[Gipsel]

Bei Ampere können alle Teile parallel arbeiten.

https://g3f4h2w2.rocketcdn.me/wp-content/uploads/2020/09/NVIDIA-GeForce-RTX-30-Tech-Session-00036_657EBA0F93174506B1741A4533873B0D.jpgDie Grafik ist in diesem Zusammenhang unaussagekräftig, da es um die Fähigkeiten der Scheduler in den SMs geht. Die erste Grafik zu Ampere entspricht völlig der von Turing, nur eben mit höherer Performance. Die zweite Grafik zu Ampere visualisiert, daß Grafik, RT und Tensorcores gleichzeitig ausgeführt werden können, bedeutet aber nicht, daß diese Dinge in einem einzigen Takt von einem einzigen Scheduler kommen müssen. Ist ein ähnlicher Einwand wie oben zur Bemerkung von vinacis_vivids mit der gleichzeitigen Ausführung von fp32 und fp16 dank Async Compute (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13007433#post13007433) (was ja auch nicht bedeutet, daß ein Scheduler beides in einem Takt absetzen kann). ;)
Ja, neuere nV-GPUs sind flexibler in dem Sinne, daß nicht mehr der ganze Chip quasi zwischen verschiedenen Betriebsmodi umgeschaltet werden muß. SMs einzeln umzuschalten hilft schon etwas und Ampere könnte hier langsam beim Stand von AMD angekommen sein (müßte mal nachsehen, weiß das gerade nicht so genau), wo schon seit GCN verschiedene Shader(typen) concurrent auf einer CU laufen können. Und mehr sagt Deine Grafik leider in dem Zusammenhang nicht.

Ansonsten hat mksn7 das schon richtig beschrieben:
Die benötigten Ressourcen beim scheduler sind genau gleich. Ein Takt in dem eine tensor instruction gescheduled wird (wenn wir mal annehmen dass die tensor cores wirklich dazu verwendet werden können um FP16 vector ops auszuführen, kann schon sein), ist ein Takt in dem keine FP32 instruction gescheduled wird.

Also, das eine oder das andere. Wenn auf einer Ampere SM der volle, maximale FP32 Durchsatz ausgenutzt wird, also durchgängig pro scheduler alle 2 Takte 2 FP32 Instruktionen, dann kann nichts, absolut gar nichts mehr anderes ausgeführt werden. Kein int, kein load, kein store, kein branch, kein sonstiger ALU Kram, keine tensor core instructions, kein special function kram...

Es kann einfach nicht mehr geissued werden. Mal abgesehen davon dass die Registerbandbreite das auch noch bremsen würde, und selbst bei manchen Kombinationen von FP32 Instruktionen schon zu knapp ist.
Jeder der vier Scheduler in einem GA10x-SM hat nur einen einzigen issue-Port. Es kann also nur eine Instruktion (für einen Warp) pro Takt abgesetzt werden. Das ist eine harte Durchsatzlimitierung. Es bedeutet allerdings nicht, daß die eigentliche Ausführung nicht überlappen kann (bzw. es meist auch tut). ;)

[vinacis_vivids]

Bei RDNA uArch hat sich Async Compute schon weiterentwickelt zu Async Compute Tunnelling:

https://abload.de/thumb/2022-05-1914_32_21-rdh3k2p.png (https://abload.de/image.php?img=2022-05-1914_32_21-rdh3k2p.png)

Graphik und Compute Aufgaben sind nun besser ausbalanciert als in vorherigen uArch, wo die Ressourcen vom Command Prozessor eher Compute Aufgaben bevorzugt wurden (Vega uArch).

Die Vega uArch ist in Compute Tasks brute-Force (wie ETH-Mining) nach wie vor sehr weit vorne.

Warum FSR 2.0 so schön in der Bildqualität und auch so schnell bei RDNA`?

Hier ist die Antwort:

https://abload.de/thumb/2022-05-1914_45_31-rdjukyu.png (https://abload.de/image.php?img=2022-05-1914_45_31-rdjukyu.png)

Die Ergebnisse der 16bit Vektor Multiplikation werden in 32bit Format gespeichert. Viele neue Spiele nutzen nun den Vorteil der Mixed-Precision.

Am besten wäre es natürlich im AMD-Treiber einen RSR-Schalter einzubauen und für alle Spiele FSR 2.0 zu implementieren. Das ist allerdings nicht ohne Arbeit möglich, weil Spiele unterschiedliche Ressourcen verlangen.

Auch alle zusätzlichen Instructions werden in 32bit Format gespeichert. Das Reduziert die Fehlerrate und verbessert somit die Präzision.

https://abload.de/thumb/2022-05-1914_51_39-rdc5jfs.png (https://abload.de/image.php?img=2022-05-1914_51_39-rdc5jfs.png)

Jede FSR 2.0 Implementierung, die fp16 als HDR-Color Texturing genutzt wird, wird in voller Farbpracht erstrahlen und Fett an Geschwindigkeit zulegen, ab RNDA uArch. Die älteren GCN uArch begnügen sich mit sehr guter BQ und etwas niedrigeren Framegewinn.

Für Konsolen und Mitteklasse GPUs wird FSR 2.0 eine Schlüsseltechnik sein um mit wenig Ressourcen als auf dem teuersten PC hervorragende Grafikpracht inkl. Ray-Tracing in hoher Auflösung (4K) rauszuholen.

4K@144hz + Ultra-RT wird somit möglich dank RDNA uArch und FSR 2.0. Hoffe viele Entwickler kapieren es und bringen das unter, kann nur gut sein für die Gaming-Industrie.

[Gipsel]

@v_v:
Dein AMD-Shilling hilft hier keinem weiter. Das ist ein Thread im Technologie-Unterforum.

AC hat maximal sehr am Rande mit dem Thema zu tun. Mixed precision FMAs sind nett und ersparen die eine oder andere Formatkonversion. Aber die sind für FSR 2 auch nur am Rande interessant (und es ist ja nicht so, als wenn nV-GPUs nicht auch in der einen oder anderen Weise mixed precision könnten [die Tensor Cores können es; meines Wissens aber momentan nicht für die "normalen" fp16-Shaderinstruktionen, die an die TCs gehen], DLSS kann aber durchaus mixed precision nutzen; analog gilt das auch für einen I8/I32 Mix).
https://developer.nvidia.com/blog/wp-content/uploads/2019/01/Tensor-Core-Matrix.png
I4 geht seit Turing übrigens auch.
Und den Schrott mit "voller Farbpracht" und so kannst Du Dir gleich klemmen. :wink:

[aufkrawall]

Und den Schrott mit "voller Farbpracht" und so kannst Du Dir gleich klemmen. :wink:
Ist auch wirklich völliger Dünnschiss. Ich hab schon Screenshot-Vergleiche in Szenen mit Banding gemacht und mit DLSS wurde es, logischerweise, kein bisschen schlimmer.

[Ex3cut3r]

Vor allem erwähnt er RDNA2 und RT in einem Satz, dumm nur das eine 3070 mit RT schneller als eine 6900XT ist. ;D

[Gipsel]

Am besten kommen wir mal wieder zum Thema: FSR 2.0

[Andron]

Vor allem erwähnt er RDNA2 und RT in einem Satz, dumm nur das eine 3070 mit RT schneller als eine 6900XT ist. ;D

Abseits von Spezialfällen wie Cyberpunk ist das nicht mal ansatzweise der Fall:

https://www.computerbase.de/2022-05/amd-radeon-rx-6650-xt-6750-xt-6950-xt-review-test/2/#abschnitt_benchmarks_mit_und_ohne_raytracing_in_full_hd

Selbst wenn man die AMD-freundlichen Titel Far Cry 6 und RE:V weglässt, liegt die 3070 knapp vor einer 6800 Non-XT. Mit FSR 2.0 dürfte sich das sogar noch etwas weiter verschieben, da die Strahlenlast sinkt, was RDNA2 natürlich stärker zu Gute kommt, als Ampere mit ihrer insgesamt zweifelslos höheren RT-Leistung.

[Ex3cut3r]

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13002091&postcount=4541

[aufkrawall]

Abseits von Spezialfällen wie Cyberpunk ist das nicht mal ansatzweise der Fall:

So "spezial" ist das nicht. Guck dir mal die 0,2% low in Spielen in 1440p an, in denen RT, sagen wir mal, "zu bemerken" ist: Doom Eternal, Guardians of the Galaxy, Deathloop, CyberPunk (hat CB gar nicht mit RT getestet, aber wir wissen es ja), Riftbreaker. Auch nicht im Test, aber bei WD Legion, Control und sicherlich noch anderen Titeln sieht es ähnlich aus. RT ist mit RDNA2 in der Praxis ständig völlig unbrauchbar. Sei es wegen allgemein niedriger Performance, FSR 2.0 bislang nur in einem Titel, schlechten Frametimes oder Grafikfehlern.

[DrFreaK666]

Back to topic!?

[Lurtz]

Hitman 3 bekommt mit dem Raytracing-Update DLSS 2.0 und... FSR 1.0 :facepalm: So wird das nichts mit der Verbreitung, AMD.

https://ioisupport.zendesk.com/hc/en-us/articles/6245169762577-PC-Requirements-for-Ray-Tracing-and-Supersampling

[Andron]

@ DrFreaK666 und Gipsel

So ganz Off Topic ist die Diskussion bis auf ein paar wenige Beiträge gar nicht, auch wenn FSR nicht in jedes Mal explizit erwähnt wurde:

Für eine breite Akzeptanz von FSR 2.0 ist es neben der Qualität eben auch wichtig, dass die Performance auf z.B. Nvidia-Hardware konkurrenzfähig ist. Wenn deren Hardware von FSR 2.0 dank parallelem FP16 quasi optimal oder zumindest sehr gut ausgelastet werden kann, ist das technisch gesehen schon ein großer Pluspunkt für FSR 2.0.

So "spezial" ist das nicht. Guck dir mal die 0,2% low in Spielen in 1440p an, in denen RT, sagen wir mal, "zu bemerken" ist: Doom Eternal, Guardians of the Galaxy, Deathloop, CyberPunk (hat CB gar nicht mit RT getestet, aber wir wissen es ja), Riftbreaker. Auch nicht im Test, aber bei WD Legion, Control und sicherlich noch anderen Titeln sieht es ähnlich aus. RT ist mit RDNA2 in der Praxis ständig völlig unbrauchbar. Sei es wegen allgemein niedriger Performance, FSR 2.0 bislang nur in einem Titel, schlechten Frametimes oder Grafikfehlern.

Alles richtig, ich weiß, dass es da einige Beispiele gibt, in denen AMD baden geht, konnte es selbst testen. Allerdings schrieb Ex3 pauschal, dass eine 3070 mit RT auf 6900XT Niveau ist, was ich in der Breite nicht bestätigen kann. Ich betrachte da weder nur den Best Case (FC6, Dirt5, RE:V etc.) noch die von Dir aufgezählten Worst Case Beispiele, sondern einen Durchschnitt inkl. ordentlich laufenden Titeln wie Metro Exodus, Tomb Raider, F1 2021 oder Hellblade in realistischen Einstellungen. Mit teilweise reduzierten RT-Einstellungen, die mindestens 60 FPS auf einer 3070 ermöglichen, holen die Radeons ebenfalls etwas auf.

Übrigens: Ehemalige Negativbeispiele wie Control laufen sogar vergleichsweise gut auf meiner 6800XT, weitaus besser als in den alten Benchmarks. Keine Ahnung, ob das an den neueren Treibern liegt. RT auf Radeons ist zwar nach wie vor keine Offenbarung, mit den richtigen Einstellungen aber dennoch öfter Nutzbar, als es hier oft dargestellt wird.

Der Elefant im Raum ist aber natürlich nach wie vor fehlendes temporales Upscaling, die Liste mit kommenden FSR 2.0 Titeln enttäuscht mich nach wie vor, hätte da mit mehr Ankündigungen kurz nach dem Release in Deathloop gerechnet. Das Hitman 3 RT Update mit FSR 1.0 stimmt einen da nicht positiver.

[Gast]

Übrigens: Ehemalige Negativbeispiele wie Control laufen sogar vergleichsweise gut auf meiner 6800XT, weitaus besser als in den alten Benchmarks. Keine Ahnung, ob das an den neueren Treibern liegt. RT auf Radeons ist zwar nach wie vor keine Offenbarung, mit den richtigen Einstellungen aber dennoch öfter Nutzbar, als es hier oft dargestellt wird.

Der Elefant im Raum ist aber natürlich nach wie vor fehlendes temporales Upscaling, die Liste mit kommenden FSR 2.0 Titeln enttäuscht mich nach wie vor, hätte da mit mehr Ankündigungen kurz nach dem Release in Deathloop gerechnet. Das Hitman 3 RT Update mit FSR 1.0 stimmt einen da nicht positiver.

So ist es, Raytracing auf den Radeons ist grob auf Turing Niveau, AMD ist also ca. 1 Generation hinten nach.

Und Raytracing auf Turing ist gut nutzbar, zumindest wenn auch DLSS verfügbar ist, was bei fast allen Raytracing Titeln der Fall ist.

Insofern ja, ob Raytracing bei AMD mittelfristig brauchbar ist/bleibt liegt in erster Linie daran ob die Spiele auch eine vernünftige Upsampling-Technologie integrieren.

[mksn7]

Jeder der vier Scheduler in einem GA10x-SM hat nur einen einzigen issue-Port. Es kann also nur eine Instruktion (für einen Warp) pro Takt abgesetzt werden. Das ist eine harte Durchsatzlimitierung. Es bedeutet allerdings nicht, daß die eigentliche Ausführung nicht überlappen kann (bzw. es meist auch tut). ;)

Zumindest wenn der Durchsatz geringer ist als 1 Instruktion / Takt.

Bei z.B. den Tensor Cores würde aber tatsächlich schon einiges rumkommen, HMMA (Tensor Core Instruktion) hat wohl einen Durchsatz von 1/8, da kann in 6 von 8 cycles (wahrscheinlich nur 6 wegen Registerbandbreite) noch was anderes gescheduled werden. Ich vermute aber eher nicht aus dem gleichen warp, weil die HMMA Instruktionen immer sehr viel die .reuse flags verwenden, die durch andere Instruktionen geclobbered werden könnten.

Gibts eigentlich RT instructions? Die offizielle SASS Liste kennt die nicht. Es würde keinen Sinn machen, die RT Cores in den SMs zu verbauen wenn die nicht irgendwie mit normalen shaderprogrammen kommunizieren können. Die RT instructions hätten nämlicher sicher auch einen geringen Durchsatz.

[basix]

Hitman 3 bekommt mit dem Raytracing-Update DLSS 2.0 und... FSR 1.0 :facepalm: So wird das nichts mit der Verbreitung, AMD.

https://ioisupport.zendesk.com/hc/en-us/articles/6245169762577-PC-Requirements-for-Ray-Tracing-and-Supersampling

FSR 2.0 Source Code wurde noch nicht veröffentlicht. Q2/2022 ist die Ansage.

[Lurtz]

Das heißt man kann FSR 2.0 aktuell nur in Kooperation mit AMD implementieren?

[basix]

Richtig.

Und da Hitman 3 bereits mit Intel für XeSS eine Kooperation eingegangen ist, müssen wir wohl noch ein wenig auf die Veröffentlichung von FSR 2.0 warten.

[vinacis_vivids]

Bei FSR 2.0 geht es u.a. auch um crossplattform. Also für Konsolen, Handhelds, Notebooks, Smartfones usw. Am PC ist es mehr technischer top-notch showcase.

Die Eingriffe in den Depth Buffer, Motion Buffer und Color Buffer sollte möglichst sauber gemacht werden. Die Performancesprünge und Energieeinsparungen sind insbesondere für Smartfones und mobile Geräte interessant und entscheidend für die Effizienz und längere Laufzeiten.

Bin gespannt ob bspw. die schöne Frostbite Engine von DICE eine FSR 2.0 inkl. RT Update bekommen wird. Da sind sicherlich 4K@144fps Ultra, inkl RT drin mit aktueller Hardware.

[Andron]

Und da Hitman 3 bereits mit Intel für XeSS eine Kooperation eingegangen ist, müssen wir wohl noch ein wenig auf die Veröffentlichung von FSR 2.0 warten.


FSR 2.0 Source Code wurde noch nicht veröffentlicht. Q2/2022 ist die Ansage.

Hatte die Intel Partnerschaft ganz verdrängt, war da noch auf dem Stand von Hitman 2. AMD sollte den Source Code so schnell wie möglich zur Verfügung stellen, damit zu Release von RDNA 3 auch eine ernstzunehmende Zahl an FSR 2.0 Titeln verfügbar sind.

[DrFreaK666]

@ DrFreaK666 und Gipsel

So ganz Off Topic ist die Diskussion bis auf ein paar wenige Beiträge gar nicht, auch wenn FSR nicht in jedes Mal explizit erwähnt wurde:

Für eine breite Akzeptanz von FSR 2.0 ist es neben der Qualität eben auch wichtig, dass die Performance auf z.B. Nvidia-Hardware konkurrenzfähig ist. Wenn deren Hardware von FSR 2.0 dank parallelem FP16 quasi optimal oder zumindest sehr gut ausgelastet werden kann, ist das technisch gesehen schon ein großer Pluspunkt für FSR 2.0...

Natürlich ist das off topic, denn die aktuelle Hardware steht schon und alles andere gehört in den Spekulations-Thread

[ChaosTM]

Idealerweise würde ein perfektes System dieser Art einfach so "out of the Box" in jedem Spiel funktionieren. Im schlimmsten Fall mit einer kurzen "Trainingsphase".
Gibts da schon Hinweise für etwas in der Art ?

[basix]

Was stellst du dir darunter vor?

[ChaosTM]

Dass DLSS oder FSR einfach ohne aufwendige Implementierung "funktioniert". Laienhaft ausgedrückt.

[aufkrawall]

Tut es ja, wenn der Entwickler von Anfang an auf TAA achtet und anstatt sein eigenes einfach FSR 2.0 nehmen würde.

[hmmm]

Tut es ja, wenn der Entwickler von Anfang an auf TAA achtet und anstatt sein eigenes einfach FSR 2.0 nehmen würde.
Endlich mal normale Leute. ;)

[DrFreaK666]

Igors später Test
https://www.igorslab.de/pixelbeschleunigung-dank-upscaling-amd-legt-nach-und-schickt-fsr-2-0-ins-rennen-fsr-2-0-vs-fsr-1-0-vs-dlss-2-3-im-deathloop-praxistest-teil-1-performance-check/

habs noch nicht durch

[aufkrawall]

Was sieht besser bzw. weniger schlimm aus?


1)
https://abload.de/thumb/deathloop_2022_05_23_0cjh4.png (https://abload.de/image.php?img=deathloop_2022_05_23_0cjh4.png)

2)
https://abload.de/thumb/deathloop_2022_05_23_1ij08.png (https://abload.de/image.php?img=deathloop_2022_05_23_1ij08.png)

[Raff]

Uäh. Bewegung nach rechts, DLSS 2.3 (Smearing) vs. FSR 2.0 (Sharpen-Brösel): beides kacke, aber FSR etwas erträglicher.

Dafür rekonstruiert DLSS Feinheiten besser, etwa das Metallgeländer. Mit was hast du die Bilder geschärft?

Läuft gut auf der RTX 3060. :D

MfG
Raff

[aufkrawall]

Kurioserweise ist das Bewegung nach links, das TAAU ghostet hier offenbar "invertiert". Kann natürlich auch am bescheuerten Head Bobbing liegen, wobei das schon auf Minimum steht.
DLSS hat aber nicht nur mit Smearing zu kämpfen, sondern hat auch deutlich mehr Aliasing. Das Gras auf Entfernung ist generell auch vermatschter.
FSR 2.0 mag den Randbereich nicht, interpoliert ohne Daten aus dem Screen Space offenbar recht bröselig. Das fällt in Bewegung aber häufig eher wenig auf.
Ist DLSS Quality 2.4.3 mit CAS 1.2, FSR 2.0 Quality CAS 1.0.

Ich finds ziemlich peinlich für DLSS. Genau u.a. dieses Artefaktbild nervt mich in Fortnite vs. FSR2.0 in Deathloop. Ich erwarte, dass Nvidia nachbessert. Ansonsten stinkt es nach Arbeitsbeschaffungsmaßnahme für die TCs, ähnlich sinnvoll wie die vom Amt...


Läuft gut auf der RTX 3060. :D

Ironie? Das läuft mit dem kaputten Maus Input gefühlt eh immer wie Müll. Ich hoffe, die Engine stirbt und es kommt wieder ein Dishonored, mit UE5...

[DrFreaK666]

Basiert es nicht auf einer stark modifizierten Doom 2016 Engine?
Vielleicht steigen die auf die Doom Eternal Engine um.
MS scheint es nicht wichtig zu sein welche Engine man nutzt, jedenfalls habe ich dazu noch nichts gehört

[aufkrawall]

Sie nennen das Void-Engine und es hat mal auf idTech 5 basiert. Vielleicht kommen daher die idiotischen Timer-Probleme für den Maus-Input, weiß der Geier.
Es ist verbugt und zu langsam. Wenn sie schlau sind, schmeißen sie es weg. Ihr bestes Spiel war mit der UE, sollte ihnen zu denken geben...

[robbitop]

Die idtech 5 Engine (das war die mit Megatextures) - die war richtig schön kaputt. Man versuche mal Wolfenstein The New Colossos Order oder the old blood zu spielen. Läuft wie ein Sack Nüsse.
Ab idtech 6 ist wieder alles schick. :)

[Mr. Lolman]

Wolfenstein The New Colossos läuft doch mit idTech6

[robbitop]

Ich meinte the new order. Ich verwechsle die Titel immer. Ich meine Teil 1 ;)

[DrFreaK666]

Die idtech 5 Engine (das war die mit Megatextures) - die war richtig schön kaputt. Man versuche mal Wolfenstein The New Colossos Order oder the old blood zu spielen. Läuft wie ein Sack Nüsse.
Ab idtech 6 ist wieder alles schick. :)

Ach die Engine war das. Oh Gott

[Gast]

Ab idtech 6 ist wieder alles schick. :)

idtech6 hatte doch auch Megatexture, die sind wenn ich mich recht erinnere erst mit idtech7 Geschichte.

Wobei man sich fragt warum, gerade wenn Unreal mit Nanite sogar schon den nächsten Schritt geht und quasi Megatexture für Geometrie einführt.

[DrFreaK666]

läuft auch auf einer GTX960

5fkRqikytOg

[Raff]

... aber mit Ansage holprig, weil weder Speicher noch Rechenleistung vorhanden sind. :ugly: Da ist FSR 1.0 vielleicht die bessere Wahl. Hässlich ist's so und so mit dieser Grafikkarte, welche schon zu ihrem Release nicht übermäßig geil war.

MfG
Raff

[aufkrawall]

Das läuft vermutlich auf jeder GPU, auf der D3D11-Spiele starten. Also vermutlich selbst einer Radeon HD 5770 von 2009, oder gar noch älter mit D3D11 Feature Level 10.

[DrFreaK666]

Wer mag es testen? :D

[Raff]

Ich rieche Treiber-Probleme. Mit den ersten DX11-Karten kriegt man nur Legacy-Code - das macht bei neuen Spielen mit Ansage Probleme. Was nicht bedeutet, dass es nicht auch gut gehen kann ... ;)

MfG
Raff

[Dampf]

https://twitter.com/Radeon/status/1529161593434554370

YOOO! FSR 2.0 in Farming Simulator 2022. Das Teil ist im GamePass und wird natürlich gerade mit Full-Speed runtergeladen as we speak!

Bin mega hyped!

[Raff]

Ah, das erste UE4-Spiel. Spannend, weil da nicht so ein TAA-Rotz drin ist wie bei Deathloop - sondern ALLE Modi zum Vergleich.

MfG
Raff

[Dampf]

Blöd. Bei mir gibts nur FSR 1.0.

Scheinbar wurde die Game Pass Version noch nicht aktualisiert?

Ist es nicht möglich, die Grafikeinstellungen in real time zu wechseln? Finde im Spiel keine Option für die Grafikeinstellungen, erst wenn ich aus dem Spiel gehe.

[Raff]

Dafür muss man immer zurück ins Menü, was etwas lästig ist.

MfG
Raff

[DrFreaK666]

Blöd. Bei mir gibts nur FSR 1.0.

Scheinbar wurde die Game Pass Version noch nicht aktualisiert?
...

"Playstation & Xbox will be available later today"

Bekommst sie wahrscheinlich frühestens wenn die Xbox-Version online ist.

Es sollte möglich sein, manche Effekte per Hotkeys aktivieren bzw. deaktivieren zu können. Bei RSR geht das z.B., mir ist aber kein Spiel bekannt, das sowas bietet

[Wiseman]

Farming Simulator 22. Hab ich doch auch. Also den FSR 2.0 Patch drauf und gleich mal überprüft. Mir ging es dabei überhaupt nicht ums Pixelzählen, sondern um die Frage, ob ich FSR 2.0 so wie FSR 1.0 auch jenseits von 4k, also in 5k oder 6k betreiben kann.

Und geht FSR 2.0 beyond 4k? Ja, es geht. I am ... relieved.

Ich hänge 3 Screenshots an:
- Screenshot mit Grafikeinstellungen
- Srceenshot in 4k, maxed out, FSR 2.0 Quality
- Screenshot in 6k, maxed out, FSR 2.0 Quality

Also ich bin zufrieden mit der Bildqualität in 5760x3240, maxed out und FSR 2.0 Quality. Andererseits bin ich überzeugt, dass unsere Pixelzählexperten sicher etwas zum Kritisieren finden werden. Wo kämen wir da hin? :biggrin:

[robbitop]

Richtig interessant ist der Vergleich zwischen Rekonstruktionsverfahren, wenn es schwierig wird. Also wenig Input und Outputresolution. Dort trennt sich die Spreu vom Weizen. Zum Beispiel 1440p Performance.

Wenn jetzt schon sowas wie der Farmsimulator FSR 2.0 bekommt, ist das ein gutes Zeichen. Ich vermute mal, dass sich FSR 2.0 dann doch schnell verbreiten wird.

[DrFreaK666]

Wichtig ist eigentlich (Fast) nur der Vergleich zwischen TAA und FSR2.0. NV-Jünger greifen zu DLSS weil das von Nvidia ist (kenne solche Fälle).
Bin gespannt auf den Tenor.
Ich tippe auf: im Durchschnitt gleichwertig, mit Vorteilen für DLSS was Performance angeht

[dargo]

Richtig interessant ist der Vergleich zwischen Rekonstruktionsverfahren, wenn es schwierig wird. Also wenig Input und Outputresolution. Dort trennt sich die Spreu vom Weizen. Zum Beispiel 1440p Performance.

Nö... sehe ich nicht so. Anwender abhängig. ;)

Wenn ich schon FSR 2.0 verwenden möchte dann will ich durchgehend bessere BQ vs. nativ ohne Kompromisse. Und das geht bei meinem 1440p Bildschirm nur mit VSR + FSR 2.0. Zum Beispiel 4k + FSR 2.0 Quality. Dann lande ich bei 1440p Renderkosten + etwas FSR 2.0 Overhead. Die 1440p Renderkosten meiner Karte kenne ich bereits.

@Wiseman
Screenshote bitte mal im Simulator 22 einmal 4k + FSR 2.0 Quality (Vsync und/oder Framelimit natürlich bitte off) und einmal nativ 1440p. Mich würden die Kosten von FSR 2.0 Q interessieren wie hoch die ausfallen.

PS: wenns geht bitte 2-3 verschiedene Szenen um einen besseren Schnitt zu bekommen.

[robbitop]

Ja anwenderabhängig. Ich finde dennoch rein analytisch interessant, wie sich Verfahren im Bottleneck verhalten. So wie CPUs im CPU Limit testen (was selten vorkommt).

Anwendungsfälle gibt es - da hast du Recht eine Vielzahl.

1.) Verlängerung der Lebenszeit einer GPU
2.) Ermöglichung von Framerate/Auflösungskombination zu der eine GPU sonst nicht in der Lage ist
3.) Deutliche Qualitätssteigerung durch besonders hohe Auflösung und ggf. downsampling, was sonst nicht praktikabel wäre
4.) Erreichen von besonders hohen Frameraten (e sports)
5.) Energie sparen bei mobilen Geräten
usw

Am Ende bestimmt die Qualität des Verfahrens im Bottleneck allerdings auch bei hohen Zielauflösungen wie weit runter man mit der Inputresolution gehen kann. Also z.B. wie gut sieht der Performancemode noch aus? Je größer das Verhältnis aus input zu outputresolution, desto höher der Leistungsgewinn.

Mein bisheriger Eindruck aus der bisherigen Berichterstattung ist, dass die Quality modes sich nicht viel nehmen jedoch der Performancemode (wo es dann für das Verfahren schwieriger wird) bei DLSS 2.x noch ein gutes Stück besser rekonstruiert.

[dargo]

Mein bisheriger Eindruck aus der bisherigen Berichterstattung ist, dass die Quality modes sich nicht viel nehmen jedoch der Performancemode (wo es dann für das Verfahren schwieriger wird) bei DLSS 2.x noch ein gutes Stück besser rekonstruiert.
Das ist so, leider aber mit vielen Kompromissen behaftet (selbst bei Quality). Ob ich diese bei FSR 2.0 bereit bin zu akzeptieren weiß ich noch nicht da ich FSR 2.0 noch nicht selbst gespielt habe. FSR 1.0 war für mich jedenfalls als 1440p Spieler inakzeptabel.

[Geldmann3]

Für 4K oder niedrigere Auflösungen würde ich mir einen Modus mit intern nativer Auflösung wünschen, wie es beim DLAA der Fall ist.
In 8K reicht der Performance-Modus wahrscheinlich dicke für eine nahezu perfekte Bildqualität.

[Gast]

Mein bisheriger Eindruck aus der bisherigen Berichterstattung ist, dass die Quality modes sich nicht viel nehmen jedoch der Performancemode (wo es dann für das Verfahren schwieriger wird) bei DLSS 2.x noch ein gutes Stück besser rekonstruiert.

Sehe ich auch so, je geringer die Renderauflösung umso größer wird der Vorteil von DLSS.

Bei 4kQ sind sie sehr nah beinander.

[blaidd]

Das ist so, leider aber mit vielen Kompromissen behaftet (selbst bei Quality). Ob ich diese bei FSR 2.0 bereit bin zu akzeptieren weiß ich noch nicht da ich FSR 2.0 noch nicht selbst gespielt habe. FSR 1.0 war für mich jedenfalls als 1440p Spieler inakzeptabel.

Da soll ja auch noch ein TAA kommen, also im Grunde FSR 2.0 ohne den Upsampling-Faktor (natürlich ist dann höchstwahrscheinlich auch eine Option für Upsampling vorhanden, sonst wäre es je ein bisschen dämlich). Dürfte aber auch ganz interessant sein, mal zu sehen, wie viel das bei nativer Darstellung ausmacht.

EDIT: Hatte gerade ein langes Interview mit Nic Thibieroz, AMDs Director of Game Engineering. Der ist für FSR 2.0 verantwortlich (auch für die ganzen FidelityFX-Effekte) und auch für die Dev-Relations zuständig.
Der konnte noch ein paar ganz interessante Details erzählen (API- und Spiele-Support, wie viele Frames werden da eigenlich verrechnet, wie ist das mit Dynamic Scaling, wenn sich die Grundauflösung dauernd ändert...). Ich muss die Chose noch übersetzen und ein bisschen fesch machen, damit es präsentierbar ist, aber bis zum WE sollte das eigentlich klappen. :)

[aufkrawall]

Das gibt es ja schon in Deathloop, wie auch "DLAA". Einfach die dynamische Skalierung auf 30fps stellen, die man locker überschreiten sollte.

[Gast]

Einfach die dynamische Skalierung auf 30fps stellen, die man locker überschreiten sollte.

Am Steamdeck nicht unbedingt.

[Achill]

Richtig interessant ist der Vergleich zwischen Rekonstruktionsverfahren, wenn es schwierig wird. Also wenig Input und Outputresolution. Dort trennt sich die Spreu vom Weizen. Zum Beispiel 1440p Performance.
[..]


Wichtig ist m.E. immer der Vergleich bezogen auf reale HW, also wo dieses Szenario zum Einsatz kommen würde. Ich behaupte, dass die Artefaktbildung und Wahrnehmung dieser bei den temp. Rekonstruktionsverfahren u.a. Abhängig von den FPS ist. Je höher diese sind, desto weniger Artefakte treten auf bzw sind weniger wahrnehmbar, da für die aktuelle angezeigte Szene mehr aktuelle Daten vorliegen.

Will man also Vergleichen, dann bitte mit FPS Limiter (und eigentlich mit frame time jittering) um verschiedene HW-Klassen zu simulieren. Dann kann man 1440p mit "Performance" bei 30/45/60/90 fps bezogen auf Stand und Bewegung bei den verschiedenen Lösungen gern ins Detail gehen.

[robbitop]

Das (fps) hat einen Effekt aber dieser ist überraschenderweise in der Praxis relativ gering.

[DrFreaK666]

Testet PCGH FSR 2.0 beim FS22? Ich denke mal ja, aber eine Bestätigung wäre trotzdem nice :)

[Andron]

Es gibt wohl ein ziemlich übles Ghosting-Problem im LWS22:

Klick (https://www.computerbase.de/forum/threads/amd-fsr-2-0-start-am-12-mai-in-deathloop-weitere-spiele-ankuendigungen.2084785/post-26938158)

Betroffen sind laut Screenshot Fahrzeug und Anbaugerät. Es scheint, als wären die Bewegungsvektoren fehlerhaft oder gar nicht vorhanden. Zur restlichen, schlechten Qualität des Screenshots kann man mangels Informationen über Auflösung und Einstellung wenig sagen. Die Bäume wirken allerdings auch fehlerhaft.

[Gott1337]

Es gibt wohl ein ziemlich übles Ghosting-Problem im LWS22:

Klick (https://www.computerbase.de/forum/threads/amd-fsr-2-0-start-am-12-mai-in-deathloop-weitere-spiele-ankuendigungen.2084785/post-26938158)

Betroffen sind laut Screenshot Fahrzeug und Anbaugerät. Es scheint, als wären die Bewegungsvektoren fehlerhaft oder gar nicht vorhanden. Zur restlichen, schlechten Qualität des Screenshots kann man mangels Informationen über Auflösung und Einstellung wenig sagen. Die Bäume wirken allerdings auch fehlerhaft.
Das ist kostenloses Motion Blur, AMD denkt einfach mit :smile:

[Troyan]

Es gibt wohl ein ziemlich übles Ghosting-Problem im LWS22:

Klick (https://www.computerbase.de/forum/threads/amd-fsr-2-0-start-am-12-mai-in-deathloop-weitere-spiele-ankuendigungen.2084785/post-26938158)

Betroffen sind laut Screenshot Fahrzeug und Anbaugerät. Es scheint, als wären die Bewegungsvektoren fehlerhaft oder gar nicht vorhanden. Zur restlichen, schlechten Qualität des Screenshots kann man mangels Informationen über Auflösung und Einstellung wenig sagen. Die Bäume wirken allerdings auch fehlerhaft.

Muss nicht. In Deathloop gibt es das selbe Ghosting auch. Das hat nichts mit Motion Vectors zu tun. Man müsste DLSS dagegen stellen, um ein Vergleich zu haben.

[Lurtz]

AC Valhalla hat gestern mit dem Patch ohne große Ankündigung auch FSR reingepatcht, laut ersten Forenmeldungen aber offenbar nur FSR 1.0.

[DrFreaK666]

Ja, ist nur FSR 1.0

[Andron]

Muss nicht. In Deathloop gibt es das selbe Ghosting auch. Das hat nichts mit Motion Vectors zu tun. Man müsste DLSS dagegen stellen, um ein Vergleich zu haben.

Sorry, das ist kompletter Quatsch. Ich konnte FSR 2.0 mittlerweile in Deathloop testen, sogar im direkten Vergleich mit DLSS.

FSR 2.0 hat definitiv noch ein paar Probleme, die u. a. von aufkrawall und auch Dir selbst in diesem Thread aufgezeigt wurden. Ghosting ist dabei im Vergleich das geringste, hier hat DLSS unter dem Strich deutlich mehr Probleme.

Ein Verhalten wie auf dem verlinkten LWS 22 Screenshot zeigt Deathloop nicht mal ansatzweise, man kann hier quasi die Anzahl der verrechneten Frames zählen. So hätte AMD FSR 2.0 wohl nie freigegeben, da komplett unbrauchbar in Bewegung.

Ein Software-Fehler (analog zum FSR-Bug in Deathloop), Usererror oder allgemein schlechte Umsetzung sind da deutlich wahrscheinlicher. Leider gibt es bisher keine Tests, da heißt es abwarten.

[-=Popeye=-]

Um mich mal selbst zu zitieren..

Schön für dich, ich kann diesem DLSS und FSR Gedöns aktuell nichts abgewinnen.:(

Der Gedanke ist gut.. die Umsetzung eher OK, wenn man es braucht und zwingend darauf angewiesen ist.

Mit damaligen Eye Candy hat das ganze nichts mehr zu tun, hier geht es nur um reine Performanz um den Konkurrenten eins auszuwischen.

Und ja beide Verfahre haben ihr Vorteile.

[DrFreaK666]

... hier geht es nur um reine Performanz um den Konkurrenten eins auszuwischen...

Wie wischt AMD Nvidia eines aus, wenn FSR auch mit Nvidia-Karten funktioniert?

[Gott1337]

Sorry, das ist kompletter Quatsch. Ich konnte FSR 2.0 mittlerweile in Deathloop testen, sogar im direkten Vergleich mit DLSS.

FSR 2.0 hat definitiv noch ein paar Probleme, die u. a. von aufkrawall und auch Dir selbst in diesem Thread aufgezeigt wurden. Ghosting ist dabei im Vergleich das geringste, hier hat DLSS unter dem Strich deutlich mehr Probleme.

Ein Verhalten wie auf dem verlinkten LWS 22 Screenshot zeigt Deathloop nicht mal ansatzweise, man kann hier quasi die Anzahl der verrechneten Frames zählen. So hätte AMD FSR 2.0 wohl nie freigegeben, da komplett unbrauchbar in Bewegung.

Ein Software-Fehler (analog zum FSR-Bug in Deathloop), Usererror oder allgemein schlechte Umsetzung sind da deutlich wahrscheinlicher. Leider gibt es bisher keine Tests, da heißt es abwarten.
Es gibt auch Spiele die mit gewissen DLSS Versionen so wenig Ghosting haben wie FSR 2.0. Dazu aber noch alle Vorteile. Ein generelles Problem gibt es dort nicht mehr.
Jetzt haben wir eben ein gutes und ein schlechtes FSR 2.0 Spiel, war doch abzusehen das sowas kommen wird. Was aber jedem klar sein sollte ist, dass das Potenzial von FSR ohne ML/NN niemals so groß sein wird, wie von DLSS/XeSS

[aufkrawall]

Es gibt auch Spiele die mit gewissen DLSS Versionen so wenig Ghosting haben wie FSR 2.0. Dazu aber noch alle Vorteile. Ein generelles Problem gibt es dort nicht mehr.

Wer das behauptet, sieht schlecht.

[Gott1337]

Wer das behauptet, sieht schlecht.
Und das ist auch nur eine Behauptung von dir. Gibt genug Leute mit viel Ahnung die das behaupten und schon gezeigt haben. Das hat nichts mit "schlecht sehen" zu tun.
Ein Problem ist eher, das die implementierung nehazu nie perfekt ist. Aber es gibt Versionen wo es gelöst ist. Das meine ich mit "Generel". Die Technik kann es, die Umsetzungen meistens nicht.

[aufkrawall]

Und das ist auch nur eine Behauptung von dir. Gibt genug Leute mit viel Ahnung die das behaupten und schon gezeigt haben. Das hat nichts mit "schlecht sehen" zu tun.

Ich sehe es, je nach Content und Integration, in jedem Spiel und kann es auch für jedes Spiel auf Bild festhalten. Wo soll es denn so eine Wunderimplementierung außerhalb von Fanboy-Fantasien geben?

[Wiseman]

@Wiseman
Screenshote bitte mal im Simulator 22 einmal 4k + FSR 2.0 Quality (Vsync und/oder Framelimit natürlich bitte off) und einmal nativ 1440p. Mich würden die Kosten von FSR 2.0 Q interessieren wie hoch die ausfallen.

PS: wenns geht bitte 2-3 verschiedene Szenen um einen besseren Schnitt zu bekommen.

Für einen besseren Schnitt bin ich auf dem Farmgelände 1 Minute und so mit dem Traktor herumgefahren. Da siehst du auch gleich die min fps.

Ich muss des Weiteren einen wichtigen Hinweis zu Native vs FSR 2.0 geben. Schau dir dazu weiter oben meinen Screenshot zu den Grafikeinstellungen an.

Sobald ich FSR 2.0 aktiviere, werden logischerweise folgende Optionen auf n/a gestellt:
- Kantenglättung (=2x/4x/8xMSAA)
- Post-process Anti-Aliasing (=TAA)
- FidelityFX Super Resolution (=FSR 1.0)

Das heißt, wenn ich "Native + maxed" out testen will, muss ich mich für TAA + 8xMSAA entscheiden. Und 8xMSAA haut ganz schön rein.

2560x1440, TAA + 8xMSAA, Rest maxed out, native: min 73 fps - avg 112 fps

3840x2160, TAA + 8xMSAA, Rest maxed out, native: min 49 fps - avg 60 fps

3840x2160, maxed out, FSR 2.0 Quality: min 113 fps - avg 130 fps

Weil ich weiter oben im Thread was von Ghosting lese. Mir ist auch etwas Unnatürliches aufgefallen. Ich sehe bei mir Schatten von Grasbüscheln und Schatten der angehängten Egge mal mehr mal weniger hin- und herhuschen. Dürfte ein durch den letzten Patch erzeugter Bug sein, denn ich beobachte dieses Phänomen (Ghosting?) sowohl mit als auch ohne FSR 2.0.

[Gott1337]

Ich sehe es, je nach Content und Integration, in jedem Spiel und kann es auch für jedes Spiel auf Bild festhalten. Wo soll es denn so eine Wunderimplementierung außerhalb von Fanboy-Fantasien geben?
https://youtu.be/3kIJOTfOG8s?t=330 er sagt in doom gibts praktisch kein ghosting, kannst ja mal dein ghosting zeigen, dann aber bitte auch mehrere DLSS versionen, solange glaube ich den Profis anstatt dir, danke.

[dargo]

AC Valhalla hat gestern mit dem Patch ohne große Ankündigung auch FSR reingepatcht, laut ersten Forenmeldungen aber offenbar nur FSR 1.0.
Dann hast du den falschen Thread erwischt. ;)


Das heißt, wenn ich "Native + maxed" out testen will, muss ich mich für TAA + 8xMSAA entscheiden. Und 8xMSAA haut ganz schön rein.

Nee... MSAA muss da bei der Gegenüberstellung natürlich komplett raus. Insbesondere bei sehr hohen Kosten macht ein Vergleich mit MSAA keinen Sinn. Also wenn dann nur bitte mit TAA vergleichen.

[mironicus]

Beim Landwirtschaftssimulator macht FSR 2.0 eigentlich keinen Sinn bei meiner 6900XT. Der Stromverbrauch bei 4K60 höchste Details (TAA) vs FSR 2.0 Quality ist praktisch identisch und die native Bildqualität etwas besser.

[dargo]

Beim Landwirtschaftssimulator macht FSR 2.0 eigentlich keinen Sinn bei meiner 6900XT. Der Stromverbrauch bei 4K60 höchste Details (TAA) vs FSR 2.0 Quality ist praktisch identisch und die native Bildqualität etwas besser.
Hast du nur einen 60Hz Bildschirm? Ansonsten das 60fps Limit hiermit aufheben.
https://geekguide.de/ls22-nur-60-fps-fps-begrenzung-aufheben/

[Troyan]

Sorry, das ist kompletter Quatsch. Ich konnte FSR 2.0 mittlerweile in Deathloop testen, sogar im direkten Vergleich mit DLSS.

FSR 2.0 hat definitiv noch ein paar Probleme, die u. a. von aufkrawall und auch Dir selbst in diesem Thread aufgezeigt wurden. Ghosting ist dabei im Vergleich das geringste, hier hat DLSS unter dem Strich deutlich mehr Probleme.

Ein Verhalten wie auf dem verlinkten LWS 22 Screenshot zeigt Deathloop nicht mal ansatzweise, man kann hier quasi die Anzahl der verrechneten Frames zählen. So hätte AMD FSR 2.0 wohl nie freigegeben, da komplett unbrauchbar in Bewegung.

Ein Software-Fehler (analog zum FSR-Bug in Deathloop), Usererror oder allgemein schlechte Umsetzung sind da deutlich wahrscheinlicher. Leider gibt es bisher keine Tests, da heißt es abwarten.

Doch, in Deathloop existiert es auch. Nur gibt es dort keine wirklich bewegenden Objekte. Siehe nochmal hier bei der Figur: https://imgsli.com/MTA4MDEx

Das ist exakt das selbe Ghosting wie im Screenshot aus dem Computerbase-Forum.

[Andron]

Es gibt auch Spiele die mit gewissen DLSS Versionen so wenig Ghosting haben wie FSR 2.0. Dazu aber noch alle Vorteile. Ein generelles Problem gibt es dort nicht mehr.

Da würde ich gerne mal ein Beispiel in Bewegung sehen, ohne Ghosting bei quasi perfekter Bildqualität.

Jetzt haben wir eben ein gutes und ein schlechtes FSR 2.0 Spiel, war doch abzusehen das sowas kommen wird.

Ich habe FS22 mal günstig erstanden, um FSR 2.0 zu testen, auch wenn es kein wirklich guter Titel dafür ist. Das ist nicht nur eine schlechte Umsetzung, dass ist völlig kaputt. Wir reden hier nicht von leichtem Ghosting, sondern von sehr harten Mehrfachkonturen. Betroffen sind aber nur die Fahrzeuge, an anderen Elementen kann ich dieses Problem in Bewegung nicht erkennen. Auch ist der Effekt nur rausgezoomt in dieser Intensität vorhanden.

https://abload.de/thumb/fs22_fsr2.0_quality_20tjlo.png (https://abload.de/image.php?img=fs22_fsr2.0_quality_20tjlo.png)

Reingezoomt bleiben einige Probleme bestehen, das Extreme Ghosting ist aber verschwunden in Bewegung.

https://abload.de/thumb/fs22_fsr2.0_quality_1ymkd8.png (https://abload.de/image.php?img=fs22_fsr2.0_quality_1ymkd8.png)

Mausbewegung mit Ingame maximal eingestellter Empfindlichkeit zeigt ebenfalls kein extremes Ghosting. Da ist mit großer Wahrscheinlichkeit etwas kaputt, bei den Fahrzeugen.

https://abload.de/thumb/fs22_fsr2.0_quality_4anj86.png (https://abload.de/image.php?img=fs22_fsr2.0_quality_4anj86.png)

https://abload.de/thumb/fs22_fsr2.0_quality_3qej7x.png (https://abload.de/image.php?img=fs22_fsr2.0_quality_3qej7x.png)

EDIT: Alle Screenshots @max settings, WQHD und FSR Quality. FS22 bietet übrigens auch den optionalen Ultra Performance Modus von FSR 2.0 an.

Was aber jedem klar sein sollte ist, dass das Potenzial von FSR ohne ML/NN niemals so groß sein wird, wie von DLSS/XeSS

Was erstmal auch nur eine Behauptung ist und abzuwarten bleibt. Eine Qualität, wie FSR 2.0 sie in Deathloop in der aller ersten Version liefert, hat fast keiner erwartet oder als realistisch angesehen. Genauso gut könnte man behaupten, dass der ML/NN-Ansatz nur zur Arbeitsbeschaffung für die Tensor Cores / Matrixeinheiten dient. Das kann man ebenso wenig nachweisen. Daher heißt es abzuwarten, bis mehr Spiele FSR 2.0 Unterstützen und weitere Iterationen der Technik veröffentlicht werden, parallel zu DLSS und zukünftig auch XeSS.

[robbitop]

Naja im Performancemode scheint DLSS schon deutlich vorn zu liegen was Rekonstruktion feiner Details angeht. Je weniger Inputauflösung desto größer die Herausforderung und desto größer die Unterschiede. Das clamping bei DLSS scheint artefaktnormiert mehr Samples akkumulieren zu können.

[Andron]

Das habe ich auch nicht damit in Frage stellen wollen, mit sehr niedrigen Eingangsauflösungen rekonstruiert DLSS auf jeden Fall etwas besser. Die Frage ist aber eher, ob das auch in den ersten DLSS 2.0 Titeln so war, ohne jegliche Nebenwirkungen. Denn genau diese Version testen wir bei FSR 2.0 gerade. Da ist es schwer abzusehen, wie viel Potenzial noch in der Technik steckt.

Ich hätte bei FSR 2.0 ehrlicherweise nicht mit einer Qualität oberhalb von Unreals TAAU/TSR gerechnet, in Deathloop zumindest ist das mMn. schon eingetreten. Es bleibt halt abzuwarten, wohin sich FSR 2.0 entwickelt und wie künftige Integrationen aussehen werden.

[robbitop]

TAAU sollte es schlagen - TSR muss man in einem gleichen Titel sehen. Das könnte knapp ausgehen.

[aufkrawall]

TSR muss man in einem gleichen Titel sehen. Das könnte knapp ausgehen.
TSR hat massivsten Motion Blur selbst gegen DLSS. Was bringen mehr feine Details im Standbild, wenn bei der kleinsten Kamerabewegung Vaseline übers komplette Bild geschüttet wird? Sehe FSR 2.0 massiv voraus.

Zumindest, wenn die Kinderkrankheiten hoffentlich mal abgestellt sein werden. AMD sollte mit dem SDK etc. in die Puschen kommen...

[basix]

Das TSR das ich bis jetzt gesehen habe hat mMn wirklich deutlich mehr Motion Blur und Ghosting (direkt verglichen mit DLSS). Wenn typische FSR 2.0 Implementationen mindestens so gut wie bei Deathloop sind, sehe ich FSR 2.0 klar im Vorteil.

[Wiseman]

Nee... MSAA muss da bei der Gegenüberstellung natürlich komplett raus. Insbesondere bei sehr hohen Kosten macht ein Vergleich mit MSAA keinen Sinn. Also wenn dann nur bitte mit TAA vergleichen.

Habe ich doch längst für dich gemacht. Ich kenne doch deine Ansprüche. :biggrin:

Damit du nicht hin- und herblättern brauchst, hänge ich außerdem nochmals den 4k, FSR 2.0 Quality Screenshot an. Wat'n Service.

3840x2160, TAA, noMSAA, Rest max, native: min 106 fps - avg 121 fps

3840x2160, maxed out, FSR 2.0 Quality: min 113 fps - avg 130 fps

[dargo]

Danke für deine Mühe, so wird das leider aber nichts. Ich brauche schon im Vergleich den exakten Bildinhalt. :)

[Wiseman]

Danke für deine Mühe, so wird das leider aber nichts. Ich brauche schon im Vergleich den exakten Bildinhalt. :)

Ich bin doch für alle meine Rundfahrten auf dem Farmgelände die gleiche Strecke abgefahren, sodass nicht nur eine Momentaufnahme gemacht wird, sondern viele, viele Daten erfasst werden. Außerdem sind die vom AB ausgegebenen Bench-Werte für so eine Rundfahrt mehr wert als das Glotzen auf das exakt gleiche Bild, wo nur der current value zu sehen ist.

[DrFreaK666]

Er meinte wahrscheinlich wegen dem Bildvergleich, nicht den FPS

[Andron]

Doch, in Deathloop existiert es auch. Nur gibt es dort keine wirklich bewegenden Objekte. Siehe nochmal hier bei der Figur: https://imgsli.com/MTA4MDEx

Das ist exakt das selbe Ghosting wie im Screenshot aus dem Computerbase-Forum.

Das ist nicht mal ansatzweise dasselbe. Fahrzeuge im FS22 ghosten in Bewegung und komplett herausgezoomt wie die Hölle, schlimmer als bei jeder noch so schlechten TAA(U) Umsetzung. Du kannst doch nicht ernsthaft glauben, dass das technisch bedingt ist und kein Bug/Implementierungsfehler. Damit wäre FSR 2.0 vollkommen unbrauchbar.

Wie in meinen Screenshots zu sehen passiert es eben auch nicht bei schneller Mausbewegung oder wenn man näher an das Fahrzeug heranzoomt. Das spricht mMn. auch gegen ein generelles Problem von FSR. EDIT: Ich muss mich korrigieren, auch wenn man näher an das Fahrzeug heranzoomt ghostet es weiterhin, je nach Blickwinkel ist es allerdings deutlich reduziert.


In deinem Vergleich suchst du mal wieder in den Krümeln und ja, am (bewegten) Bein einer winzigen Figur ghostet FSR, wohingegen DLSS dieses Problem nicht aufweist. Dafür ghostet die gesamte Figur minimal stärker mit DLSS. Das ist beides aber nicht im Ansatz mit dem Problem im FS22 vergleichbar

Charakterbewegung vermeidest du in deinen DLSS/FSR 2.0 Vergleichen übrigens auch gerne.

[dildo4u]

Hat eigentlich mal jemand den Verbrauch getestet?Laut DF braucht eine 3090 50 Watt weniger mit DLSS da die Hardware Blöcke genutzt werden.
Hoffentlich kann AMD FSR 2.0 in RDNA 3 beschleunigen.

[dargo]

Laut DF braucht eine 3090 50 Watt weniger mit DLSS da die Hardware Blöcke genutzt werden.

Das ist doch kompletter Unsinn. Wenn eine 3090 mit DLSS weniger verbraucht wird sie von der CPU gebremst. Oder intern gibt es einen Flaschenhals mit DLSS. Letzteres halte ich eher für unwahrscheinlich.

[DrFreaK666]

Die Karte rendert doch in einer niedrigeren Auflösung. Wieso sollte sie nicht weniger verbrauchen?

[dildo4u]

Ich tippe drauf das Deathloop extrem CPU Limitiert ist die 3090 ist selbst in 4k zu schnell.Die 6800XT wird eher vom RT gebremst.
Ich hoffen wird bekommen FSR 2.0 in Games wo man 300fps schaffen kann z.b Doom oder so.

[GerryB]

Hat eigentlich mal jemand den Verbrauch getestet?Laut DF braucht eine 3090 50 Watt weniger mit DLSS da die Hardware Blöcke genutzt werden.
Hoffentlich kann AMD FSR 2.0 in RDNA 3 beschleunigen.

oder
Ampere kann net so gut mit FSR2 umgehen, weil nur normales FP16 x1 genutzt wird!?

Müsste man auf RDNA2 mal schauen, wo garantiert FP16 x2 läuft.

Ganz interessant wirds dann mit XeSS und DP4a durch INT x4.

[Troyan]

Hat eigentlich mal jemand den Verbrauch getestet?Laut DF braucht eine 3090 50 Watt weniger mit DLSS da die Hardware Blöcke genutzt werden.
Hoffentlich kann AMD FSR 2.0 in RDNA 3 beschleunigen.

Ich habe in Deathloop gemessen, dass für die selben Frames meine 3090 mit 280W laufen kann anstelle der 350W mit FSR 2.0. Je stringenter das Powerlimit, umso schneller ist DLSS.

[dildo4u]

oder
Ampere kann net so gut mit FSR2 umgehen, weil nur normales FP16 x1 genutzt wird!?

Müsste man auf RDNA2 mal schauen, wo garantiert FP16 x2 läuft.

Ganz interessant wirds dann mit XeSS und DP4a durch INT x4.
Was meinst du ist Ampere nicht schneller mit FSR2.0?Nur DLSS setzt noch ein drauf?

3060 TI + 49% 6700XT + 47%.

https://youtu.be/s25cnyTMHHM?t=1092

Ich dachte das ganze läuft über Compute dort sollte Ampere weniger Limitiert sein.

[basix]

Alles ab RDNA1 und Turing läuft sehr gut mit FSR 2.0. Vega und Polaris eigentlich auch. Nur Pascal ist aufgrund des weniger guten Async Compute etwas hinten dran. Bei Intel iGPUs bin ich überfragt.

[dargo]

@Wiseman

Ich verfolge da was anderes. :)

Habe mir jetzt mal selbst FSR 2.0 beim Landwirtschafts-Simulator 22 angesehen. Also das Gemüse profitiert imo von FSR 2.0 schon sehr deutlich. Trotz 960p Rendering bei 1440p + FSR 2.0 Q ist das Gemüse wesentlich feiner dargestellt. Auch so feine Details wie die Straßenlaternen links in der Ferne und/oder die Details der Häuser in der Ferne (links im Bild) werden feiner dargestellt. Letzteres ist mir (und da bin ich ehrlich) nur im direkten Vergleich mit Screenshots aufgefallen. Ingame gar nicht, kann aber sein, dass ich zu wenig darauf geachtet habe. Ob ich das Game mit 1440p + FSR 2.0 Q spielen würde? Eher nicht... bei diesem Setting gibts leider auch sichtbare Nachteile die mich durchaus etwas stören. Habe dazu ein Video aufgenommen. Leider ist YT zu dämlich nach mittlerweile 17 Stunden immer noch das Material in 4k zu liefern. Bei einem 38 Sekunden langen Video. :facepalm: In der 1080p Youtube-Kompressionsgülle sieht man das Problem leider nicht. Bei bestimmten Abstand zum Vehikel schwabbeln die Schriftkanten als ob das temporale AA dort Aussetzer hätte. Erst in 4k + FSR 2.0 auf meinem 1440p Bildschirm sehe ich das Problem nicht. Oder besser gesagt es ist so minimal, dass mich das nicht mehr stört. Als weiteres Problem bei 1440p + FSR 2.0 Q ist mir aufgefallen, dass die Silos eine Art Moiré-Effekt aufweisen, wieder nur in bestimmten Abstand zum Objekt. Bei 4k + FSR 2.0 passt es für mich wieder. Das sind zwei Nachteile gegenüber 1440p nativ + TAA.

Im direkten Screenshotvergleich fällt mir noch auf, dass die Kantenglättung rechts im Bild auf diesem Geländer mit 1440p + FSR 2.0 Q schwächelt vs. 1440p nativ + TAA.

1440p nativ + TAA
https://abload.de/thumb/ls22_1440p_nativzwjrb.png (https://abload.de/image.php?img=ls22_1440p_nativzwjrb.png)

1440p + FSR 2.0 Q (Schärfe 1.0)
https://abload.de/thumb/ls22_960pfsr2.062kp1.png (https://abload.de/image.php?img=ls22_960pfsr2.062kp1.png)

1440p + 150% SR + FSR 2.0 Q (Schärfe 1.0)
https://abload.de/thumb/ls22_4kfsr2.0iojx7.png (https://abload.de/image.php?img=ls22_4kfsr2.0iojx7.png)

Hier noch das erwähnte Video, aber unbedingt abwarten bis 4k verfügbar ist. Ich hoffe auch, dass man das Problem dann bei 4k erkennen kann. Möglich, dass selbst die Kompression bei 4k von YT nichts taugt um das zu zeigen.
LULB6O7a98E

Als weiteres wollte ich mal sehen wie teuer FSR 2.0 Q bei meiner RX 6800XT tatsächlich ist. 4k + FSR 2.0 Q ist dafür zu wenig GPU-Last da ich in der Szene bereits im Bereich von ~170fps im CPU-Limit mit max. Details bin (max. Details kann man nur manuell wählen, max. Preset ist nicht gleich max. Details!). Ergo bin ich auf 5k + FSR 2.0 Q vs. 4k nativ gegangen. Ergebnis... FSR 2.0 Q kostet hier in 5k 2ms vs. 4k Nativ + TAA.

1440p + 150% SR
https://abload.de/thumb/ls22_4k_nativt7kre.png (https://abload.de/image.php?img=ls22_4k_nativt7kre.png)

1440p + 200% SR + FSR 2.0 Q (Schärfe 1.0)
https://abload.de/thumb/ls22_5kfsr2.0g1jee.png (https://abload.de/image.php?img=ls22_5kfsr2.0g1jee.png)

[aufkrawall]

Wie in meinen Screenshots zu sehen passiert es eben auch nicht bei schneller Mausbewegung oder wenn man näher an das Fahrzeug heranzoomt. Das spricht mMn. auch gegen ein generelles Problem von FSR. EDIT: Ich muss mich korrigieren, auch wenn man näher an das Fahrzeug heranzoomt ghostet es weiterhin, je nach Blickwinkel ist es allerdings deutlich reduziert.

Ich habe es im FS nicht selbst gesehen, aber es kann schon ein Problem des Algorithmus an sich sein. Ist natürlich nicht in Stein gemeißelt, dass das unfixbar ist. Würde eher vom Gegenteil ausgehen.

[Cpu0815]

Habe mir jetzt mal selbst FSR 2.0 beim Landwirtschafts-Simulator 22 angesehen. Also das Gemüse profitiert imo von FSR 2.0 schon sehr deutlich. Trotz 960p Rendering bei 1440p + FSR 2.0 Q ist das Gemüse wesentlich feiner dargestellt. Auch so feine Details wie die Straßenlaternen links in der Ferne und/oder die Details der Häuser in der Ferne (links im Bild) werden feiner dargestellt.
Die Schilder der Tankstelle und das Dorf hinten links sind mit FSR tatsächlich feiner dargestellt.
Das Video ist, wie erwartet, ein einziger totkomprimierter Matsch.

[dargo]

Die Schilder der Tankstelle und das Dorf hinten links sind mit FSR tatsächlich feiner dargestellt.

Auch die Beschriftung vom Fahrzeug gefällt mir besser, das Schneidewerk ist mit FSR 2.0 auch feiner dargestellt.


Das Video ist, wie erwartet, ein einziger totkomprimierter Matsch.
Ohne 4K Video wird das nichts wie ich schon sagte. Keine Ahnung was mit YT los ist... selbst nach 19 Stunden geben die das 4k Video immer noch nicht frei. :freak:

Edit:
Hier mal das Video als Downlaod, Youtube ist nicht mehr das was es mal war. :down:
https://www.mediafire.com/file/bqnj99nbqzncd3r/LS22.mkv/file

Insbesondere auf die Schrift "Top Liner" achten. Aber auch das Blech und Rohr drüber schwabelt etwas unschön.

[Andron]

Ich habe es im FS nicht selbst gesehen, aber es kann schon ein Problem des Algorithmus an sich sein. Ist natürlich nicht in Stein gemeißelt, dass das unfixbar ist. Würde eher vom Gegenteil ausgehen.

Hoffe es auch, denn gerade rausgezoomt ist das völlig kaputt und wäre für jeden Third-Person Titel unbrauchbar. Es passiert allerdings wie bereits erwähnt nur bei Eigenbewegung von Fahrzeugen. Durch schnelle Mausbewegung bekomme ich den Effekt nicht provoziert, auch nicht an Fahrzeugen. Das lässt etwas hoffen.

Ansonsten zeigt FSR 2.0 genau die gleichen Problemstellen wie in Deathloop:

Grobpixelig am Bildschirmrand und bei überlagernden Objekten, eben alles was in vorangegangenen Frames nicht im Screen Space vorhanden war, dazu leichte Probleme bei der Rekonstruktion einiger feiner Details in Bewegung. Transparenzeffekte scheinen auch leichte Probleme zu bereiten, das habe ich aber noch nicht mit normalem TAA gegengetestet.

[aufkrawall]

(y) Objektive Berichte ohne falsche Rücksichtnahme beste Berichte.

[Cpu0815]

Hier mal das Video als Downlaod, Youtube ist nicht mehr das was es mal war. :down:
https://www.mediafire.com/file/bqnj99nbqzncd3r/LS22.mkv/file

Insbesondere auf die Schrift "Top Liner" achten. Aber auch das Blech und Rohr drüber schwabelt etwas unschön.
Stimmt, dort schwabbelt es. Dabei sind diese Elemente die ganze Zeit zu sehen. Seltsam. Grad bei der Schrift sollte FSR es doch leicht haben.

Ansonsten nichts schlimmes zu erkennen.

[Andron]

(y) Objektive Berichte ohne falsche Rücksichtnahme beste Berichte.

Ich hatte jetzt mal etwas Zeit, mir FSR 2.0 im FS22 länger anzuschauen und kann nun doch etwas Entwarnung geben:

- Die Grafikfehler bei Transparenzeffekten wie Auspuffrauch sind mit TAA mindestens genauso stark vorhanden, das hat nichts mit FSR zu tun.

- Das extreme Ghosting bei schneller Fahrt ist wie schon zuvor erwähnt von der Zoomstufe und noch stärker vom Blickwinkel abhängig. Ändert man letzteren während der Fahrt in die richtige Richtung, verschwindet das Ghosting oder wird zumindest minimiert.
Ich habe daraufhin etwas recherchiert und einige Forenbeiträge gefunden, in denen Probleme mit starkem Ghosting im Zusammenhang mit DLSS/DLAA beschrieben wurden. Leider kann ich das nicht gegentesten, vieles spricht hier aber mMn. für allgemeine Probleme des FS22.

- Das von Dargo im Video festgehaltene wabern des Schriftzugs kann ich bestätigen, allerdings ist auch dieses Problem bei mir blickwinkel-/positionsabhängig. Auch hier wäre DLSS im Vergleich sehr spannend.

- Im großen und ganzen decken sich die Problemstellen mit denen in Deathloop, wenn man die Ghosting Problematik bei den Fahrzeugen ausklammert.

- Vor allem die Vegetation, Fahrzeuge und Anbaugeräte profitieren teils deutlich von FSR Quality in WQHD. In Bewegung schwankt die Qualität allerdings etwas bei sich überdeckenden, feinen Details.

- Wenn man die technischen Baustellen des FS22 berücksichtigt, ist das doch eine relativ solide, aber keineswegs problemfreie Vorstellung von FSR 2.0. FS22 ist aber insgesamt keine gute Bewertungsgrundlage.

[Wiseman]

Beim Landwirtschaftssimulator macht FSR 2.0 eigentlich keinen Sinn bei meiner 6900XT. Der Stromverbrauch bei 4K60 höchste Details (TAA) vs FSR 2.0 Quality ist praktisch identisch und die native Bildqualität etwas besser.

Also wenn du FS22 weiterhin in 4k spielen willst, macht FSR2.0 für deine 6900XT keinen Sinn. Gamer mit einer weniger potenten Grafikkarte dagegen werden sicher dankbar das Upsampling-Angebot annehmen.

Ich hab auch eine 6900XT. Bisher hatte ich FS22 in 4k, TAA, Preset Sehr Hoch gespielt. War sehr zufrieden damit - optisch wie leistungsmäßig.

Edit:

In Zukunft werde ich FS22 in 5760x3240, FSR 2.0 Quality, absolutely maxed out spielen. Leistungsmäßig hat da unsere 6900XT keine Probleme damit (Screenshot #1) und es wird zu einem optischen Schmankerl.

Falls es dein Monitor zulässt, überprüf mal 6k bei dir. Wenn dir weiterhin TAA besser als FSR 2.0 Quality gefällt, dann bleib dabei. FS22 läuft auch in 6k, TAA und maxed out geschmeidig. (Screenshot #2)

[dargo]

- Das von Dargo im Video festgehaltene wabern des Schriftzugs kann ich bestätigen, allerdings ist auch dieses Problem bei mir blickwinkel-/positionsabhängig.
Ist hier ebenfalls der Fall. Siehe Video und mein Text. :)

[aufkrawall]

Hier hats jemand mit DLSS verglichen:
https://www.reddit.com/r/Amd/comments/uz1f9d/fsr_20_vs_dlss_in_farming_simulator_22/
Gibt da offenbar schon noch einiges, das verbessert werden sollte. Das liegt auch imho weniger an der Implementierung.

[dargo]

Cool... mit DLSS bekommen die Games völlig neue Effekte spendiert. ;D :freak:
https://gfycat.com/plushunequaledhuman

Immerhin passt dann wohl v2.3.9.

[aufkrawall]

Jo, komischerweise sieht man so etwas von DF für DLSS nie. Oder erst, nachdem es verbessert wurde...

[dargo]

Och... da würden mir so einige Personen mehr einfallen die vieles nicht sehen. Unser Trojaner zum Beispiel. :whistle:

[robbitop]

Hatten sie das nicht auch bei Death Stranding und anderen Spielen gezeigt bevor neuere DLSS dlls das gefixt haben (die Partikel die Trails hinter sich herziehen)? Ich habe sowas in Erinnerung.

[vinacis_vivids]

DLSS ist Aufgrund der fp8 Einheiten bei Bewegungsvektoren dem FSR 2.0 deutlich unterlegen, welches mindesten fp16 verlangt.
Das sind mathematisch-technische Grundkenntnisse bei der Rechenpräzision.
Bei AMD (ab RDNA) werden fp16 Multiplikations-Ergebnisse zudem noch in fp32 Format abgespeichert, um Rundungsfehler zu vermeiden.
AMD FSR 2.0: Ursache: Höhere Präzision der der Berechnung -> Wirkung: Bessere Ergebnisse.
NV DLSS 2.X: Ursache: Niedrigere Präzision bei der Berechnung -> Wirkung: Schlechte Ergebnisse.

[Tobalt]

Soeinfach gestaltet sich die Sache nicht mehr. Du kannst auch mit 8 bit (zwischen)operanden hohe Präzision erreichen, wenn dein Algo darauf ausgerichtet ist. Das ist typisch für NN dass die Zwischenoperanden relativ niedrige Präzision haben.

[Gast]

AMD FSR 2.0: Ursache: Höhere Präzision der der Berechnung -> Wirkung: Bessere Ergebnisse.
NV DLSS 2.X: Ursache: Niedrigere Präzision bei der Berechnung -> Wirkung: Schlechte Ergebnisse.

Ich sehe du hast insiderinformationen über Funktion von DLSS, möchtest du diese mit uns teilen?

[Troyan]

DLSS ist Aufgrund der fp8 Einheiten bei Bewegungsvektoren dem FSR 2.0 deutlich unterlegen, welches mindesten fp16 verlangt.
Das sind mathematisch-technische Grundkenntnisse bei der Rechenpräzision.
Bei AMD (ab RDNA) werden fp16 Multiplikations-Ergebnisse zudem noch in fp32 Format abgespeichert, um Rundungsfehler zu vermeiden.
AMD FSR 2.0: Ursache: Höhere Präzision der der Berechnung -> Wirkung: Bessere Ergebnisse.
NV DLSS 2.X: Ursache: Niedrigere Präzision bei der Berechnung -> Wirkung: Schlechte Ergebnisse.

Das stimmt. Dank der doppelten Genauigkeit bei AMD sieht man auch doppelt soviele Geisterbilder: https://imgsli.com/MTA5ODU0

[DrFreaK666]

oh nein, fängt wieder das cherry-picking an?

[aufkrawall]

Muss wohl, weil bestimmte Leute nicht gesperrt sind.

[ChaosTM]

I love this Faden, cos es geht um genau fast nix.. sorry for that

add.: ich bin einfach zu blind/alt, um wirkliche Unterschiede ausmachen zu können

[DrFreaK666]

I love this Faden, cos es geht um genau fast nix.. sorry for that

add.: ich bin einfach zu blind/alt, um wirkliche Unterschiede ausmachen zu können

Wir haben einfach Glück :)

[Dampf]

Ich finds hier echt köstlich. Vinacis labert wieder von INT wovon er nichts versteht und Troyan kontert draufhin wieder mit feinsten gepickten Kirschen.

So kanns doch für immer weitergehen ;D

[OpenVMSwartoll]

Somit liest man beide Extreme, schmunzelt und - da Samstag abend ist - gönnt man sich nen Megapint.

[Gott1337]

Jo, komischerweise sieht man so etwas von DF für DLSS nie. Oder erst, nachdem es verbessert wurde...
ist doch alles schon bekannt, DLSS wurde schon 100 mal durchgekaut... deine Unterstellungen gegenüber DF sind lächerlich. Die können auch nicht jeden low Budget Titel testen.
desweiteren ist das hier der FSR Thread also wieder mal nur off Topic und bashing.

[aufkrawall]

desweiteren ist das hier der FSR Thread also wieder mal nur off Topic und bashing.
Es gibt auch Spiele die mit gewissen DLSS Versionen so wenig Ghosting haben wie FSR 2.0. Dazu aber noch alle Vorteile. Ein generelles Problem gibt es dort nicht mehr.

Halten wir fest: Lob von DLSS (auf fragwürdiger "Faktenlage"...): kein OT
Kritik: böses Bashing
Trollaccount?

[Wiseman]

I love this Faden, cos es geht um genau fast nix.. sorry for that

add.: ich bin einfach zu blind/alt, um wirkliche Unterschiede ausmachen zu können

Ich bin da ganz bei dir.

Normalerweise meide ich solche Threads wie der Teufel das Weihwasser, aber "dummerweise" wurde in FS22 FSR 2.0 implementiert, wo es IMHO gar nicht notwendig gewesen wäre. Und wenn FS22 nicht das zweite FSR2.0 Spiel nach Deathloop, sondern sagen wir mal das 25. Spiel mit FSR2.0-Implementierung wäre, würde es wahrscheinlich eh keiner beachten.

"Dummerweise" habe ich dieses Spiel und da konnte ich der Versuchung nicht widerstehen, mit eigenen Augen FSR 2.0 Quality zu begutachten. Da ich es in 6k und 100% maxed out begutachten kann, gibt es aus meiner Sicht nicht allzu viel zu kritisieren.

Ich gebe außerdem aufkrawall recht, wenn er meint, dass nicht alles Kritikwürdige an der Implementierung liegt.

Hier hats jemand mit DLSS verglichen:
https://www.reddit.com/r/Amd/comment..._simulator_22/
Gibt da offenbar schon noch einiges, das verbessert werden sollte. Das liegt auch imho weniger an der Implementierung.

Ich habe mir die Vergleichs-Videos aus aufkrawalls reddit-Link gründlich angeschaut und habe anschließend selbst überprüft. Viele "Ghosting"-Stellen, die man beim reddit-Verfasser mit viel gutem Willen erahnen kann, ließen sich bei mir nicht nachvollziehen. Na gut, er hat in 1440p mit nicht genannten Grafikeinstellungen getestet, ich habe in 6k (5760x3240) + 100% maxed-out Settings überprüft. Nicht nachvollziehbar waren bei mir u. a. "Ghosting" beim Basketballkorb oder das "Sparkling" bei den Blättern an den Bäumen.

Gut nachvollziehbar war das extreme Ghosting beim Rückwärtsgehen im Weizenfeld. Kann man fast schon als Schulungsmaterial für "Gelungenes Ghosting" benutzen. Nicht unerwähnt sollte allerdings bleiben, dass bei mir mit TAA auch Ghosting beim Rückwärtsgehen im Weizenfeld zu sehen war.

FSR 2.0 steht ganz am Anfang seiner Entwicklung. Ist doch nur verständlich, dass in diesem Stadium in dem einen oder anderen Spiel bei der Implementierung noch Patzer passieren. Und auf die Idee, rückwärts durch ein Weizenfeld zu trampeln, muss man erst kommen. Deswegen mach ich doch kein Fass auf. :biggrin:

[DrFreaK666]

ist doch alles schon bekannt, DLSS wurde schon 100 mal durchgekaut... deine Unterstellungen gegenüber DF sind lächerlich. Die können auch nicht jeden low Budget Titel testen.
desweiteren ist das hier der FSR Thread also wieder mal nur off Topic und bashing.

Lächerlich ist, wenn man FSR 2.0 und DLSS 2.3 vergleicht und Mängel von DLSS nicht nennt, die hier und bei anderen Tests erwähnt werden.
Das Thema hatten wir aber schonmal

[blaidd]

Hier ist das Interview zu FSR 2.0 (https://www.pcgameshardware.de/FidelityFX-Super-Resolution-Software-277617/Specials/Interview-Nic-Thibieroz-AMD-FSR-20-Upsampling-1395899/)

[Gott1337]

Lächerlich ist, wenn man FSR 2.0 und DLSS 2.3 vergleicht und Mängel von DLSS nicht nennt, die hier und bei anderen Tests erwähnt werden.
Das Thema hatten wir aber schonmal
Natürlich wäre das lächerlich, die Fehler wurden doch aber schon hundert mal durchgekaut... und die sind nicht neu. Wie ich es bereits vorher sagte, also einfach nur lesen.

[OpenVMSwartoll]

Hier ist das Interview zu FSR 2.0 (https://www.pcgameshardware.de/FidelityFX-Super-Resolution-Software-277617/Specials/Interview-Nic-Thibieroz-AMD-FSR-20-Upsampling-1395899/)

Das scheint ein sehr freundlicher und höflicher Gesprächspartner zu sein und es war sicherlich angenehm, von ihm Wertschätzung zu erfahren.

Aber er hat auch sehr elegant den Finger in die Wunde gelegt: Open Source statt Black Box, somit hat der Entwickler mehr Einfluss und ist nicht auf AMD zur Problemlösung angewiesen, sondern kann verstehen, was passiert, wenn sein Verständnis genügend ausgeprägt ist.

Zudem Animation zur Verwendung, kein wie auch immer gearteter Einfluss.

Und dass dies nicht das Ende der Fahnenstange in punkto Pflege der Lösung ist, hatten wir ja geahnt. Er gibt sogar zu, dass gewisse Nebenwirkungen derzeit vorhanden sind, was auf beide Anbieter zutrifft.

Danke für das Interview.

@"Gott1337": Zur Vollständigkeit dürfen diese Fehler aber durchaus Erwähnung finden, sie müssen es sogar.

[Gott1337]

@"Gott1337": Zur Vollständigkeit dürfen diese Fehler aber durchaus Erwähnung finden, sie müssen es sogar.
Okay also müssen wir jedes mal wenn wir über FSR reden, die Fehler von FSR und DLSS auflisten, verstehe. ;D

[OpenVMSwartoll]

Okay also müssen wir jedes mal wenn wir über FSR reden, die Fehler von FSR und DLSS auflisten, verstehe. ;D

Ich weiß nicht, was Du mit dieser Argumentation erreichen möchtest. Manche Fehler scheinen sogar systemimmanent zu sein aufgrund der Größe des Inputs, also natürlich.

[Gast]

Hier ist das Interview zu FSR 2.0 (https://www.pcgameshardware.de/FidelityFX-Super-Resolution-Software-277617/Specials/Interview-Nic-Thibieroz-AMD-FSR-20-Upsampling-1395899/)


Kein Wort zu Streamline?

[DrFreaK666]

Okay also müssen wir jedes mal wenn wir über FSR reden, die Fehler von FSR und DLSS auflisten, verstehe. ;D

Natürlich müssen dann Pros und Kontras beider Seiten gezeigt werden. Was soll der Vergleich sonst?
Wenn man FSR testet und DLSS zum Vergleich heranzieht, dann gehören die Negativ-Punkte beider Seiten aufgezählt. Macht man das nicht, das hat das einen (im Fall von DF grünen) Beigeschmack.

[OpenVMSwartoll]

Kein Wort zu Streamline?

Dumm gefragt: Warum sollte ihn das interessieren? Für mich riecht Streamline bisher nach nem Stunt, damit auch ja DLSS zusätzlich zu FSR integriert wird. Die Developer Seite schreit auch ganz viel: "Aber wir haben doch DLSS", was immer noch eine Black Box ist und sicherlich bleiben wird.

Also warum soll das "Tool" für AMD interessant sein?

[Gast]

Dumm gefragt: Warum sollte ihn das interessieren?


Es geht nicht darum was ihn interessiert, ich erwarte dass ein Journalist zumindest danach fragt anstatt es totzuschweigen.


Also warum soll das "Tool" für AMD interessant sein?

Weil man damit „automatisch“ in allem was DLSS verwendet auch drinnen wäre.

[aufkrawall]

Den temporalen Blur und das temporale Aliasing von DLSS empfinde im Vergleich schon frappierend schlecht (dabei ist das schon 0.2 höhere CAS-Stärke für DLSS):
https://abload.de/thumb/deathloop_2022_05_29_ctjt4.png (https://abload.de/image.php?img=deathloop_2022_05_29_ctjt4.png) https://abload.de/thumb/deathloop_2022_05_29_iaj5l.png (https://abload.de/image.php?img=deathloop_2022_05_29_iaj5l.png)

Ist natürlich ein gestellter Spezial-Case, im eigentlichen Gameplay läuft man ja nie geradeaus. :freak:
Wie käme man also dazu, so etwas zu testen...

[hmmm]

Dumm gefragt: Warum sollte ihn das interessieren? Für mich riecht Streamline bisher nach nem Stunt, damit auch ja DLSS zusätzlich zu FSR integriert wird. Die Developer Seite schreit auch ganz viel: "Aber wir haben doch DLSS", was immer noch eine Black Box ist und sicherlich bleiben wird.

Also warum soll das "Tool" für AMD interessant sein?
Ich glaube nicht das die Developer Seite schreit: "Aber wir haben doch DLSS" das kommt aus der Fanboy Ecke. Eher hat von der Developer Seite keiner Lust auf Binary Blob im "eigenem" Code.

[OpenVMSwartoll]

Ich glaube nicht das die Developer Seite schreit: "Aber wir haben doch DLSS" das kommt aus der Fanboy Ecke. Eher hat von der Developer Seite keiner Lust auf Binary Blob im "eigenem" Code.

Du meinst, weil man von AMD als "Hardware Vendor #3" schreibt, Intel hingegen nennt? Aber ja, ne Middleware mehr, soweit ich es verstehe.

[hmmm]

Du meinst, weil man von AMD als "Hardware Vendor #3" schreibt, Intel hingegen nennt? Aber ja, ne Middleware mehr, soweit ich es verstehe.
Nein, ich meine nvidi/DLSS = BinaryBlob! Um wie viele Kreise und Ecken man es auch einbinden will, es bleibt ein BinaryBlob.

[OpenVMSwartoll]

Nein, ich meine nvidi/DLSS = BinaryBlob! Um wie viele Kreise und Ecken man es auch einbinden will, es bleibt ein BinaryBlob.

Also richtet sich Deine Kritik an DLSS, die Blackbox, während man Open Source haben kann? Aber Streamline dient ja dazu, DLSS etwas schmackhafter zu machen. Er fragte nach Streamline.