AMDs FidelityFX Super Resolution 2.0/3.0/4.0 (FSR 2.0, FSR 3.0, FSR 4.0) [Archiv] - Seite 15

dargo

2023-11-20, 18:17:17

Ich habe jetzt FSR3 dank der Demo in Immortals of Aveum getestet. Im Prinzip verhält es sich fast genau so wie in der Forspoken Demo. Framegeneration läuft hier absolut butterweich solange Vsync aktiviert ist. Der einzige kleine Unterschied zu Forspoken... ich brauche in Immortals of Aveum kein Framelimit von 140fps in RTSS. Und mit der Framegeneration gibt es das gleiche Problem wie in Forspoken... sobald Framevervielfältigung eingreifen muss gibt es Stutter im Bild. Alles größer min. Frequenz vom Bildschirm (oder besser gesagt ohne Framevervielfältigung, diese greift ja auch schon früher ein und nicht erst mit exakt bei min. Hz) läuft FG perfekt. Der Mehrwert durch FG hält sich bei mir aber subjektiv in Grenzen. Ja... ich habe mehr fps, aber fühlt sich das Game dadurch flüssiger an? Ich weiß nicht so recht. Auch ohne FG sind die Frames für mich persönlich in IoA schon hoch genug mit ca. 80-110fps.

Edit:
Ok... zum Strom sparen ist Framegeneration sehr gut geeignet. :ulol:
https://abload.de/thumb/immortalsofaveum-win6efcxz.jpg (https://abload.de/image.php?img=immortalsofaveum-win6efcxz.jpg)

Gibt natürlich auch mehr Wattchen wenn ich nicht im Monitorlimit lande.
https://abload.de/thumb/immortalsofaveum-win69sfgw.jpg (https://abload.de/image.php?img=immortalsofaveum-win69sfgw.jpg)

DrFreaK666

2023-11-20, 20:09:27

Welche Einstellungen?

dargo

2023-11-20, 21:05:53

Globale Beleuchtung und Schattenauflösung High, Rest Max. FSR2_Quality.

Relex

2023-11-20, 22:53:02

Gut zu wissen, dass es jetzt ne Demo gibt.

Habs direkt geladen und getestet.

Zu FSR3 leider genau das selbe Fazit wie schon bei Forspoken.

Es ist nichtmal ansatzweise mit DLSS Frame Generation vergleichbar. Wenn ich FSR Frame Generation aktiviere, stehen zwar deutlich mehr FPS auf dem Zähler (z.B. 130 FPS), aber es ist kaum flüssiger als vorher. Ich sehe bei schnelleren Kameraschwenks leichte doppelbilder und judder, der Monitor fängt an, leicht zu flimmern und der Inputlag steigt spürbar.

DLSS FG ist das komplette Gegenteil davon. Deutlich responsiver und man sieht, dass das Bild deutlich flüssiger wird, praktisch als hätte man tatsächlich so viele FPS. Keinerlei Doppelbilder oder sonstige Probleme.

Auch das FSR AntiAliasing und Upscaling "glänzt" schon im Hauptmenü mit deutlichem Flimmern. z.B. an der Wasseroberfläche. Mit DLSS ist das komplett ruhig. Zieht sich halt ingame mal mehr, mal weniger Stark durchs Bild. Dass man hier nichtmal TAA mit FSR Frame Generation kombinieren kann ist ein Witz.

Ein einziges Trauerspiel mal wieder... Schade. Hätte gehofft, dass AMD weiter daran arbeitet und die Spiele Updates bekommen. Scheint ja nicht der Fall zu sein. Dass AMD das nicht peinlich ist und die Patches so lange zurückziehen lässt? Das ist ja mal richtig schlechte Werbung.

Mal sehen, ob dann zumindest Avatar die ersten Verbesserungen zeigt. In der Form ist es völlig unbrauchbar.

DrFreaK666

2023-11-20, 23:27:36

Globale Beleuchtung und Schattenauflösung High, Rest Max. FSR2_Quality.

https://abload.de/thumb/2555360_202311202322231egg.png (https://abload.de/image.php?img=2555360_202311202322231egg.png)

Nicht mal die Hälfte an FPS. Aber vielleicht habe ich eine falsche Schatten-Einstellung auf High gestellt

...In der Form ist es völlig unbrauchbar.

Das ist BS.

Relex

2023-11-20, 23:47:11

Das ist BS.

Warum?

Es wird nicht flüssiger. Damit hat’s einfach keinen Nutzen.
Was soll ich denn sonst damit machen?

Taigatrommel

2023-11-21, 00:11:54

Schade. Hätte gehofft, dass AMD weiter daran arbeitet und die Spiele Updates bekommen. Scheint ja nicht der Fall zu sein. Dass AMD das nicht peinlich ist und die Patches so lange zurückziehen lässt? Das ist ja mal richtig schlechte Werbung.

Mal sehen, ob dann zumindest Avatar die ersten Verbesserungen zeigt. In der Form ist es völlig unbrauchbar.
Das liest sich tatsächlich nicht so toll. Ich selbst habe es nicht ausprobiert, allerdings hatte ich irgendwo noch Hoffnung, dass FSR 3 in jeglicher Hinsicht eine sicht- und spürbare Verbesserung gegenüber FSR 2 wird. Scheint ja nach bisherigem Wissensstand doch nicht so zu sein. Für AMD sehe ich dies als zunehmendes Problem:
Upscaling scheint generell immer wichtiger zu werden und gerade für Leute, die nicht zwingend die absolute High-End Karte im System haben, sicher teilweise die einzige Lösung auch mal höhere Bildraten fahren zu können. Hier scheint nVidia gefühlt bedeutend mehr Fortschritte bzw. ausgereiftere Technologien anbieten zu können, welche von den Entwicklern auch aufgegriffen werden. In Kombination mit der generell eher schwachen RT Leistung der Radeons sicher auch nicht wirklich attraktiv für mögliche Kundschaft.

Dennoch will ich mal Avatar abwarten, das dürfte ja so etwas wie ein Paradebeispiel für FSR werden. Andererseits erwartete man dies bereits von Starfield.

aufkrawall

2023-11-21, 00:15:43

Immerhin scheinen das auch einige Entwickler zu checken und es gibt TSR zunehmend öfter im Optionsmenü anzutreffen. :freak:

DrFreaK666

2023-11-21, 01:19:06

Warum?

Es wird nicht flüssiger. Damit hat’s einfach keinen Nutzen.
Was soll ich denn sonst damit machen?

Bei deinen letzten Sätzen ging es ums Upscaling und danach sofort die Bewertung. Darauf bezog sich mein "BS".

Was FG angeht müssen wir schauen, was die Zukunft bringt. Dass es bei Forspoken und Immortals nicht gut umgesetzt wurde, ist ja nichts Neues.
Und vielleicht hat AMD ja keinen Scheiß erzählt, als sie sagten, dass sie die Fehler analysiert und behoben haben.
Daran glauben mag ich allerdings nicht so recht

Gast

2023-11-21, 07:46:54

Bei deinen letzten Sätzen ging es ums Upscaling und danach sofort die Bewertung. Darauf bezog sich mein "BS".

Es ging in seinem Posting gesamt um die FSR3 FG, der Zwang es mit FSR2 Upscaling zu nutzen und damit eine nicht besonders gute Basis zu erben war lediglich einer der Negativpunkte.

Was FG angeht müssen wir schauen, was die Zukunft bringt. Dass es bei Forspoken und Immortals nicht gut umgesetzt wurde, ist ja nichts Neues.

Die Ausrede von "nicht gut umgesetzt" hören wir schon viel zu oft wenn es um FSR (2 und 3) geht.
Das lässt nur 2 Schlüsse zu. Entweder das "nicht gut umgesetzt" ist ein Märchen, und der Grundalgorithmus selbst ist einfach viel zu instabil, oder aber es ist zu schwierig "gut umzusetzen" bzw. der Bereich in dem es gut funktioniert ist viel zu schmal für die breite Anwendung.

Egal was es ist, die Folge ist, dass die qualitativen Endergebnisse von FRS im allgemeinen schlecht sind, und die guten die Ausnahmen sind.

Und vielleicht hat AMD ja keinen Scheiß erzählt, als sie sagten, dass sie die Fehler analysiert und behoben haben.
Daran glauben mag ich allerdings nicht so recht

Wenn das so einfach ist, warum hat es dann bis heute keine Updates der entsprechenden Spiele gegeben.

dargo

2023-11-21, 09:54:44

https://abload.de/thumb/2555360_202311202322231egg.png (https://abload.de/image.php?img=2555360_202311202322231egg.png)

Nicht mal die Hälfte an FPS. Aber vielleicht habe ich eine falsche Schatten-Einstellung auf High gestellt

Check mal ob du eventuell Native AA bei FSR2 drin hast. Die Demo nennt das fälschlicherweise AMD FSR 2 oder so ähnlich anstatt Native AA. :freak: Bei FSR2 muss Quality stehen.

DrFreaK666

2023-11-21, 15:07:16

FSR3 für CP2077 hat immer noch kein Release-Datum
https://wccftech.com/cyberpunk-2077-dev-talks-about-upcoming-path-tracing-improvements-fsr3-support-and-unreal-engine-5-switch/

BlacKi

2023-11-21, 15:37:45

das warum hättest du aber auch posten können.
I can definitely confirm that we are working on a full FSR3 implementation — but it is still an ongoing process and we feel we need still more time to release it with the desired outcome.
sie arbeiten daran, läuft aber noch kacke.

Gast

2023-11-21, 15:38:44

FSR3 für CP2077 hat immer noch kein Release-Datum
https://wccftech.com/cyberpunk-2077-dev-talks-about-upcoming-path-tracing-improvements-fsr3-support-and-unreal-engine-5-switch/

Bei dem Zustand von FSR3 auch kein Wunder

aufkrawall

2023-11-21, 15:40:50

Entweder das "nicht gut umgesetzt" ist ein Märchen, und der Grundalgorithmus selbst ist einfach viel zu instabil
Das Eine schließt das Andere nicht aus, bei seltsamem Dauer-Gejitter freistehender Objekte ist logischerweise etwas nicht optimal. Der Algorithmus baut aber auch abseits dessen zu viel Mist. Dass es bei 100% Renderauflösung teilweise stärker flimmert als bei 66%, gibt schon viel Auskunft über zentrale Design-Schnitzer.

DrFreaK666

2023-11-21, 16:17:20

Sie sind mit dem Ergebnis nicht zufrieden. Heißt aber nicht, dass es kacke läuft.
Wenn mein Sohn bei einer Arbeit eine 3-4 schreibt, dann bin ich mit dem Ergebnis auch nicht unbedingt zufrieden, von Kacke ist das aber noch ein Stückchen entfernt.
Immer dieses Schwarz-Weiss Denken... :rolleyes:, von einem NV-User
"Zufall"

aufkrawall

2023-11-21, 16:43:33

Und wer kommt auf die Idee, etwas unbrauchbar schlecht Funktionierendes als "nicht kacke" zu verteidigen? Und komm mir bloß nicht mit NV-Fanboy, hab gestern eine 7800 XT bestellt. Aber Hauptsache vor lauter Borniertheit wieder alles vollspammen...

RoNsOn Xs

2023-11-21, 16:56:13

Hab nu auch die Demo anzocken können. Wie ich schon mal anderswo meinte, empfinde ich die Texturen wie aus ´nem anderen Jahrzehnt. Wirkte also nicht nur auf den Bildern so.
Als ich direkt ins Spiel warpte, hatte ich das Gefühl als wenn der FOV absolut nicht stimmt. Aber jetzt hat man sich dran gewöhnt.
FG funktioniert gut (mein Empfinden). Es benötigt hier jedoch - anders wie in Forspoken wirklich Vsync on. Dann wirds plötzlich smoother.

Bei der Stelle der anderen beiden: 4k, alles max, FSR-Q ~72FPS, mit FG dann ~107FPS
Treibereseitiges FG (FMF oder wie auch immer) funktioniert, allerdings wirkt es nicht flüssiger als ohne, genau wie schon in Alan Wake 2.

dargo

2023-11-21, 17:28:27

Ich schau nachher nochmal die Settings an. Wie gesagt: es gab mehrere Einstellungen, was Schatten anging. Welche Einstellung genau hast du auf "high" gesetzt?
Habs doch oben geschrieben Schattenauflösung.

Edit:
https://abload.de/thumb/immortalsofaveum_202381i8c.png (https://abload.de/image.php?img=immortalsofaveum_202381i8c.png)

Relex

2023-11-21, 18:41:38

Dass es bei 100% Renderauflösung teilweise stärker flimmert als bei 66%, gibt schon viel Auskunft über zentrale Design-Schnitzer.

Das Problem hat DLSS in gewisser Weise auch ein wenig. Wenn man mit Preset D auf 100% Auflösung geht, dann wird das tendenziell zu scharf und es kommt zu mehr Aliasing. Deswegen hat Nvidia auch die Nutzung von Preset F für DLAA vorgesehen, welches optisch ein wenig weicher wirkt, aber eben das Aliasing komplett verhindert (selbst wenn man nachschärft).

Keine Ahnung, wie man das technisch erklären kann. Wahrscheinlich könnte man es als Oversampling bezeichnen. Den Effekt hab ich bei Anisotropischer Filterung schon gesehen, wenn man ingame 16x AF nochmal mit erzwungenem Treiber AF kombiniert oder wenn man den LoD Bias zu hoch einstellt.

BlacKi

2023-11-21, 18:48:49

Sie sind mit dem Ergebnis nicht zufrieden. Heißt aber nicht, dass es kacke läuft.doch, eigentlich schon.

hab gestern eine 7800 XT bestellt. Aber Hauptsache vor lauter Borniertheit wieder alles vollspammen...

kannst du für mich mal testen, welche taktraten du mit 0,7v erreichst? und was die karte dort dann säuft? das testet irgendwie keiner, interessiert mich aber.

aufkrawall

2023-11-21, 18:51:35

Das Problem hat DLSS in gewisser Weise auch ein wenig.

Halte ich nicht für vergleichbar, weil das nur den Kanten-Kontrast betrifft. Die temporale Stabilität wird auch mit DLAA Preset D besser gegenüber Upsampling. Bei FSR 2 nativ wird das Geflimmer in dichter Vegetation teilweise noch schlimmer gegenüber Upsampling.

Diese "Jaggies" sind eine komische Eigenart von DLSS. Weder FSR 2, TSR noch XeSS zeigen die so. Mit Preset F sind sie auch in die umgekehrte Richtung übers Ziel hinaus geschossen, ergo zu blurry. Komisch auch, weil teilweise selbst schnödes SMAA ohne temporale Samples Kanten im Standbild besser glätten kann. Bei Upsampling verschleiert die Unschärfe das Problem halt etwas. Ist auch mit Preset C da, wenn auch längst nicht so ausgeprägt wie mit D.

dargo

2023-11-21, 19:00:43

Hab nu auch die Demo anzocken können. Wie ich schon mal anderswo meinte, empfinde ich die Texturen wie aus ´nem anderen Jahrzehnt. Wirkte also nicht nur auf den Bildern so.

Apropo Texturen...

1440p + FSR2_Q + FG:
https://abload.de/thumb/immortalsofaveum-win6h1e1w.png (https://abload.de/image.php?img=immortalsofaveum-win6h1e1w.png)

1440p + TAA, kein FG:
https://abload.de/thumb/immortalsofaveum-win6dbf5i.png (https://abload.de/image.php?img=immortalsofaveum-win6dbf5i.png)

Intern schärft das Game mit FSR2 massiv nach, schon weit übers Ziel hinaus. Keine Ahnung ob man das irgendwie abstellen kann. Finde die passende ini jetzt auch nicht auf Anhieb.

Exxtreme

2023-11-21, 19:09:20

OK, habe mir die Demo mal herunter geladen. Sowohl DLSS wie auch FSR sehen schrecklich aus. Beide flimmern, FSR flimmert mehr und kann feine Strukturen nicht gut rekonstruieren. DLSS ist in dieser Hinsicht besser, hat aber wieder diese tolle Quincunx-Bildschärfe. Also so wie immer halt. Leider kann man Upsampling wohl nicht abschalten. Wenn man sowohl DLSS wie auch FSR deaktiviert dann scheint man TAA zu bekommen. Und das ist DLSS in noch unschärfer.

Ex3cut3r

2023-11-21, 20:00:14

Ist dir CAS immer noch Fremd? X-D

Relex

2023-11-21, 21:14:22

Halte ich nicht für vergleichbar, weil das nur den Kanten-Kontrast betrifft. Die temporale Stabilität wird auch mit DLAA Preset D besser gegenüber Upsampling. Bei FSR 2 nativ wird das Geflimmer in dichter Vegetation teilweise noch schlimmer gegenüber Upsampling.

Diese "Jaggies" sind eine komische Eigenart von DLSS. Weder FSR 2, TSR noch XeSS zeigen die so. Mit Preset F sind sie auch in die umgekehrte Richtung übers Ziel hinaus geschossen, ergo zu blurry. Komisch auch, weil teilweise selbst schnödes SMAA ohne temporale Samples Kanten im Standbild besser glätten kann. Bei Upsampling verschleiert die Unschärfe das Problem halt etwas. Ist auch mit Preset C da, wenn auch längst nicht so ausgeprägt wie mit D.

Hmm ja, hast recht. Ist nicht vergleichbar. DLSS zeigt zwar mit Preset D stellenweise einen Treppeneffekt, aber es ist in Bewegung trotzdem stabil und flimmert deswegen nicht.

Milchkanne

2023-11-22, 00:31:57

Hier nochmal der Noob Linux-Gamer. Die Immortals Demo läuft auch mit Proton und deutlich besser, als Forspoken - also auch ohne Frame-Gen sauber.
Bei Forspoken war ich (3700X, RX 5700, 1080p@60) auch bei allem auf Anschlag noch fast immer bei 60fps. Deswegen hab ich vom Frame-Gen fast nichts gemerkt. Ich hab zum test mal meine GPU untertaktet. Wenn ich die Framerate auf 30fps abgesenkt hatte, war der Input-Lag bei >1s (!!). Keine Ahnung warum, irgendwie kaputt.

Immortals of Aveum fordert dagegen meine GPU deutlich stärker. Hier bin ich mit Native AA und alles auf Ultra schnell bei 30-40fps ohne FG. Mit FG dagegen komm ich auf 45-60 fps. Und ich muss sagen, das spielt sich für mich absolut sauber. Einzige Einschränkung: Der Navigationspunkt wird nicht korrekt interpoliert. Das heißt, der juddert jeden zweiten Frame massiv hin und her. Das nervt ganz besonders, weil man (zumindest jetzt am Anfang) ziemlich oft jemandem hinterherläuft.

Ansonsten ist die Qualität für mich als Laie aber absolut ok. Input Lag geht für mich voll in Ordnung. Bei nem ersten subjektiven Test habe ich mir eingebildet, dass es mit FG schlimmer wäre. Bei späteren tests konnte ich aber keinen Unterschied mehr merken.
Bei Regentropfen sieht man natürlich schlieren (wegen FSR2). Die sind aber klein genug, dass mich das kaum stören würde. Bei Szenenwechseln baut sich manchmal erst das AA auf (oder so ähnlich, man sieht halt, dass sich das Bild irgendwie verbessert).

Ohne FG, nur mit FSR2 hatte ich probleme überhaupt auf die Performance mit FG zu kommen. Sicher könnte ich jetzt einige Effekte runterdrehen, das würde mir wahrscheinlich auch kaum auffallen. Aber für mich als Laie ist FSR3 absolut tauglich um das Spiel auf 60FPS zu hieven.

Ich hab mit OBS mal ein high-quality Video gemacht (60fps, 60Mbps, 444 subsampling). Hier ein kurzes (62MB) (https://1fichier.com/?n5lew03qeogdxtklx29y), dass nur das Juddern des Nav-Punktes zeigt, Hier ein etwas längers (360MB) (https://1fichier.com/?07u93dgo3oxavjkexzxr).

Klar, wenn ich das Bild für Bild durchgehe, sieht die Interpolation an den Händen und Beinen natürlich mies aus. Aber bei 60fps, merke ich das kaum.

Ich verstehe, dass ihr Pro-Gamer da einen anderen Anspruch habt. Aber das wird für viele Leute sehr wertvoll sein. Insbesondere natürlich auf den Konsolen, wo sich ja wahrscheinlich viele Casual Gamer tümmeln.

DrFreaK666

2023-11-22, 00:42:34

doch, eigentlich schon...

Wenns also Ghosting gibt bei DLSS, dann ist es sofort kacke. ok

Habs doch oben geschrieben Schattenauflösung.

Edit:
https://abload.de/thumb/immortalsofaveum_202381i8c.png (https://abload.de/image.php?img=immortalsofaveum_202381i8c.png)

Dann habe ich es richtig gemacht. Mein System ist demnach deutlich langsamer

dargo

2023-11-22, 07:08:58

Ich hab mit OBS mal ein high-quality Video gemacht (60fps, 60Mbps, 444 subsampling). Hier ein kurzes (62MB) (https://1fichier.com/?07u93dgo3oxavjkexzxr), dass nur das Juddern des Nav-Punktes zeigt, Hier ein etwas längers (360MB) (https://1fichier.com/?n5lew03qeogdxtklx29y).

Sowas habe ich hier gar nicht. Allerdings teste ich FG auch nicht mit so niedrigen fps und unter Windows, nicht Linux.

btw.
Die Beschriftung der beiden Videos ist vertauscht. ;)

Dann habe ich es richtig gemacht. Mein System ist demnach deutlich langsamer
Sind die 63fps mit FG bei dir? Dann klemmt da definitiv was. So viel langsamer kann eine RX 6700XT gar nicht sein. Hast du den Adrenalin 23.11.1 drauf?

Edit:
Nachdem ich jetzt ausgiebig FSR3 in IoA getestet habe ist ein endgültiges Urteil von meiner Seite aus schwierig ob das für mich eine Option ist oder nicht. Ich denke aber auch, dass für FG mein Monitor mit "nur" max. 144Hz zu stark limitiert. Imho wäre für sowas ein Bildschirm mit max. 240Hz besser geeignet. Ein Beispiel mit Szene X wo ich die Maus ständig in beide Richtungen bewege.

Mit 1440p + FSR2_Q habe ich um die 120fps. In gleicher Szene mit FSR2_Q + FG + 140fps Limit fühlt sich die Maus subjektiv etwas träger an. Dieser Vergleich ist aber für den popo da wie gesagt mein Bildschirm hier limitiert, der Unterschied von 120pfs vs. 140fps ist viel zu gering. Deaktiviere ich Framelimit und Vsync sind es mit FSR2_Q + FG um die 180fps. Das wiederum fühlt sich subjektiv an der Maus etwas direkter an als die 140fps (falschen Vergleich beschrieben) 120fps vorhin. Sieht dann aber wieder blöd aus am Bildschirm da Freesync logischerweise nicht mehr greifen kann. :freak:

Ein anderer Vergleich wo Freesync in beiden Fällen greifen kann. Gleiche Szene mit Native AA ohne FG bedeutet ca. 82fps. Mit FG und Framelimit von 140fps fühlt sich die Maus wieder subjektiv direkter an als diese 82fps. Hier würde ich wieder FG vorne sehen.

PS: hinzu kommt noch die Fressync-Limitierung bei meinem Bildschirm mit 56-144Hz. Die 56Hz sind für FG nicht wirklich optimal da wie schon gesagt Stutter aufkommt sobald Framevervielfältigung eingreifen muss. Die perfekte Freesync-Range für sowas wäre imo 40-240Hz an einem 240Hz Monitor.

dildo4u

2023-11-22, 08:03:34

60 fps klingt normal für 6700XT die Konsolen nutzen tonnen Upsampling um dahin zu kommen.

AMD Performance sah zum Launch OK aus spielt de Treiber eine Rolle?

https://www.techpowerup.com/review/immortals-of-aveum-benchmark-test-and-performance-analysis/5.html

dargo

2023-11-22, 08:11:52

60 fps klingt normal für 6700XT die Konsolen nutzen tonnen Upsampling um dahin zu kommen.

Vielleicht mal im Kontext lesen? :rolleyes:

RX 6700XT = 63fps
RX 6800XT = 140fps

Was ist daran normal?

Das Thema ist hier FSR3 falls du es nicht mitbekommen hast und nicht irgendwelche alten Messungen von Techpoweup mit max. Settings.

dildo4u

2023-11-22, 08:18:14

Deine Werte ergeben kein Sinn viel zu Hoch warum auch immer.
Das Game nutzt Standard mäißg Upsampling weil aktuelle Midrange Hardware zu langsam für das Game ist.

dargo

2023-11-22, 08:19:27

Deine Werte ergeben kein Sinn viel zu Hoch warum auch immer.
Das Game nutzt Standard mäig Upsampling weil aktuelle Midrange Hardware zu langsam für das Game ist.
Und der nächste bullshit von dildo. :facepalm: Bleib dem Thread einfach fern wenn du zum Thema nichts beizutragen hast anstatt ihn wieder mit OT-Kramm vollzuspamen.

The_Invisible

2023-11-22, 08:21:35

Sowas habe ich hier gar nicht. Allerdings teste ich FG auch nicht mit so niedrigen fps und unter Windows, nicht Linux.

btw.
Die Beschriftung der beiden Videos ist vertauscht. ;)

Sind die 63fps mit FG bei dir? Dann klemmt da definitiv was. So viel langsamer kann eine RX 6700XT gar nicht sein. Hast du den Adrenalin 23.11.1 drauf?

Edit:
Nachdem ich jetzt ausgiebig FSR3 in IoA getestet habe ist ein endgültiges Urteil von meiner Seite aus schwierig ob das für mich eine Option ist oder nicht. Ich denke aber auch, dass für FG mein Monitor mit "nur" max. 144Hz zu stark limitiert. Imho wäre für sowas ein Bildschirm mit max. 240Hz besser geeignet. Ein Beispiel mit Szene X wo ich die Maus ständig in beide Richtungen bewege.

Mit 1440p + FSR2_Q habe ich um die 120fps. In gleicher Szene mit FSR2_Q + FG + 140fps Limit fühlt sich die Maus subjektiv etwas träger an. Dieser Vergleich ist aber für den popo da wie gesagt mein Bildschirm hier limitiert, der Unterschied von 120pfs vs. 140fps ist viel zu gering. Deaktiviere ich Framelimit und Vsync sind es mit FSR2_Q + FG um die 180fps. Das wiederum fühlt sich subjektiv an der Maus etwas direkter an als die 140fps vorhin. Sieht dann aber wieder blöd aus am Bildschirm da Freesync logischerweise nicht mehr greifen kann. :freak:

Ein anderer Vergleich wo Freesync in beiden Fällen greifen kann. Gleiche Szene mit Native AA ohne FG bedeutet ca. 82fps. Mit FG und Framelimit von 140fps fühlt sich die Maus wieder subjektiv direkter an als diese 82fps. Hier würde ich wieder FG vorne sehen.

PS: hinzu kommt noch die Fressync-Limitierung bei meinem Bildschirm mit 56-144Hz. Die 56Hz sind für FG nicht wirklich optimal da wie schon gesagt Stutter aufkommt sobald Framevervielfältigung eingreifen muss. Die perfekte Freesync-Range für sowas wäre imo 40-240Hz an einem 240Hz Monitor.

Genauer: Dein Vergleich ist für FSR3 gültig aber nicht für DLSS-FG

Gast

2023-11-22, 08:26:05

Es benötigt hier jedoch - anders wie in Forspoken wirklich Vsync on. Dann wirds plötzlich smoother.

Was es unbrauchbar macht.

Wenn man für eine Latenzsteigernde Maßnahme (FG) eine andere Latenzsteigernde Maßnahme (VSYNC) aktivieren muss, wird es in Summe zu viel.

dildo4u

2023-11-22, 08:26:39

Und der nächste bullshit von dildo. :facepalm: Bleib dem Thread einfach fern wenn du zum Thema nichts beizutragen hast anstatt ihn wieder mit OT-Kramm vollzuspamen.
Es soll halt nicht anfangen an seinem System zu fummeln weil du Fantasie Werte produziert.

dargo

2023-11-22, 08:39:49

Es soll halt nicht anfangen an seinem System zu fummeln weil du Fantasie Werte produziert.
Wird dir dein Trolling nicht langsam peinlich?
LEycmA_HwSQ

In der Cutszene scheint irgendwas kaputt zu sein. Entweder FG kaputt oder die Stelle extrem unoptimiert. Im Gameplay ist mir sowas noch nicht vorgekommen.

Genauer: Dein Vergleich ist für FSR3 gültig aber nicht für DLSS-FG
Check mal in welchen Thread du dich hier befindest. :rolleyes:

Was es unbrauchbar macht.

Wenn man für eine Latenzsteigernde Maßnahme (FG) eine andere Latenzsteigernde Maßnahme (VSYNC) aktivieren muss, wird es in Summe zu viel.
Was für Noob bist du eigentlich? Noch nie was von einem Framelimiter gehört um nicht im Vsync-Limit zu landen der zu höheren Latenzen führt?

DrFreaK666

2023-11-22, 10:08:21

... Sind die 63fps mit FG bei dir? Dann klemmt da definitiv was. So viel langsamer kann eine RX 6700XT gar nicht sein. Hast du den Adrenalin 23.11.1 drauf?...

Achso. Du hattest FG aktiviert... :lol:
Das erklärt es natürlich.
Mit FG habe ich 105FPS

RoNsOn Xs

2023-11-22, 10:13:10

Vielleicht mal im Kontext lesen? :rolleyes:

RX 6700XT = 63fps
RX 6800XT = 140fps

Was ist daran normal?

Das Thema ist hier FSR3 falls du es nicht mitbekommen hast und nicht irgendwelche alten Messungen von Techpoweup mit max. Settings.
7900xtx, selbe Szene mit FG ca. 130fps. Bitte die CPU nicht außer Acht lassen bzw die Auslastung der Graka :)

DrFreaK666

2023-11-22, 10:39:18

7900xtx, selbe Szene mit FG ca. 130fps. Bitte die CPU nicht außer Acht lassen bzw die Auslastung der Graka :)

Ich hatte FG aus

Gast

2023-11-22, 10:54:43

Was für Noob bist du eigentlich? Noch nie was von einem Framelimiter gehört um nicht im Vsync-Limit zu landen der zu höheren Latenzen führt?

VSync führt immer zu höheren Latenzen, und mit Framelimiter umso mehr, da die Framerate mit VSYNC damit auf einen ganzzahligen Teiler der Refreshrate reduziert wird.

RoNsOn Xs

2023-11-22, 10:55:40

Ja hatte ich gelesen. Teste doch nochmal nach.

Was es unbrauchbar macht.

Wenn man für eine Latenzsteigernde Maßnahme (FG) eine andere Latenzsteigernde Maßnahme (VSYNC) aktivieren muss, wird es in Summe zu viel.
Kommt aufs Gefühl an. Für nen Singleplayert-Shooter ist das völlig okay. Antilag und Antilag+ gibt es ja auch noch. Fand es jetzt gar nicht soo schlimm.

dildo4u

2023-11-22, 11:44:51

Noch mal zu Einordnung es ist normal das Low End weniger gewinnt DF hat sich das mit der 6700 angeguckt.

https://youtu.be/e0gKIo6o3ZA?si=2M-WCnR94-bh_IZB&t=1738

DrFreaK666

2023-11-22, 11:46:32

Ja hatte ich gelesen. Teste doch nochmal nach...

Hab ich. Steht im edit. Du (130FPS) hast ca. 24% mehr FPS als ich (105FPS). Solltest vielleicht mal über eine neue CPU nachdenken, denn eine 7900XTX sollte schneller sein als nur 24%

RoNsOn Xs

2023-11-22, 11:53:02

Nö nö, das meiste Zeugs rennt sowieso ins GPU-Limit, da reicht mir mein Proz. noch dicke. Irgendwann mal wenn er dauerhaft zu schwach wird, klar. Die Zeit ist aber noch nicht gekommen.
Und mal ehrlich - 130FPS reichen für alles (in diesem Fall sowieso).

DrFreaK666

2023-11-22, 12:07:01

Hier fehlt ein Like-Button

dargo

2023-11-22, 19:38:40

Achso. Du hattest FG aktiviert... :lol:
Das erklärt es natürlich.
Mit FG habe ich 105FPS
Boah... beim nächsten Mal vielleicht mal genauer lesen was ich schreibe.

Edit:
Ok... muss zugeben war vielleicht dann doch etwas zweideutig. Hier spreche ich explizit von FG.
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13439382&postcount=3503

Und hier tatsächlich vergessen FG zu erwähnen.
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13439461&postcount=3505

Insofern sorry für die Verwirrung.

Monsta

2023-11-22, 22:17:55

Ich habe mir dir Demo von Inmortals of Aveum auch mal gegeben.

Ich habe mit Controller gespielt und ich finde FG gut.

Aber FSR ist mal richrtig fies in Bewegung, oft ein Krieseln und Flimmern.

DLSS ist zu unscharf, bei anderen Spielen ist mit das nicht so aufgefallen. Ich hab die Texturen auf High, aber ich finde die Qualität schwankt extrem in dem Spiel.

Schade das man FG nicht mit DLSS kombinieren kann.

Geht das technisch nicht, oder will AMD das nicht, oder ist das nur eine Limitierung in dem Spiel?

DrFreaK666

2023-11-22, 22:48:44

Laut AMD ist FSR zwingend notwendig. Aber wer weiß...

Exxtreme

2023-11-22, 22:56:04

Geht das technisch nicht, oder will AMD das nicht, oder ist das nur eine Limitierung in dem Spiel?
AMD will das wohl nicht. :( Zudem ist das FSR-FG auch noch bissl ... naja ... Alpha-Status. Hat noch etliche Quirks.

dargo

2023-11-23, 06:10:19

Ich habe mir dir Demo von Inmortals of Aveum auch mal gegeben.

Ich habe mit Controller gespielt und ich finde FG gut.

Aber FSR ist mal richrtig fies in Bewegung, oft ein Krieseln und Flimmern.

FSR2 in IoA lässt leider keine Bewertung zu da die DEVs intern extrem nachschärfen was sich nicht ausschalten lässt. Keine Ahnung was die da wieder gesoffen haben. Die Nachschärfung ist vieeel zu hoch hier.

Gast

2023-11-23, 15:23:14

AMD will das wohl nicht. :( Zudem ist das FSR-FG auch noch bissl ... naja ... Alpha-Status. Hat noch etliche Quirks.

AMD braucht die ganzen Inputs von FSR.
Man müsste da einen eigenen Pfad für die ganzen Buffer für FG und den Upscaler basteln wenn man dafür verschiedene verwenden will.

Ist dann eben mehr Aufwand für die Implementierung, bzw. potentiell auch ein minimaler Performanceverlust.

basix

2023-11-24, 13:01:26

Geht das technisch nicht, oder will AMD das nicht, oder ist das nur eine Limitierung in dem Spiel?
Laut AMD ist FSR zwingend notwendig. Aber wer weiß...
AMD will das wohl nicht. :( Zudem ist das FSR-FG auch noch bissl ... naja ... Alpha-Status. Hat noch etliche Quirks.

FSR3 FG nutzt FSR2 als Grundlage für die Framegeneration. Motion Vectors, Disocclusion Masken, usw. werden für FG verwendet. Da kannst du FG nicht ohne weiteres von FSR2 separieren.

Nvidia geht mit FG einen ganz anderen Weg. Sie nehmen das fertige Bild und mit einem HW-Accelerator und AI-Trickerei werden die erforderlichen Informationen generiert. Das kann man dann auch ohne DLSS verwenden, hat aber auch zusätzliche Probleme (HUD Ghosting -> HUD kann man bei FSR3 explizit exkludieren, was das Problem bei der Wurzel löst).

Ich finde AMDs Ansatz eigentlich relativ smart. Re-Use von bestehenden Informationen. Nvidias Ansatz ist da eher Brute Force im Vergleich. Was am Ende besser funktioniert: Abhängig von der Qualität der Implementation. Momentan ist Nvidias Lösung im Vorteil. Dass FSR3 FG nur mit FSR2 genutzt werden kann ist zwar schade, aber auch nicht wirklich ein Problem. Oder nutzt jemand mit Nvidia Karte DLSS und will FSR3 FG drüberbügeln, wenn es DLSS FG bereits gibt? Wenn DLSS nicht integriert ist, kann man sowieso nur FSR benutzen. Wenn DLSS3 und FSR3 integriert sind, werden beide FG unterstützen. Die anderen Techniken (XeSS, TSR) werden mit Sicherheit auch FG bekommen. Dann ist es wie heute: Man nimmt das, was einem besser passt. Temporal Upsampling der Wahl mit/ohne FG ;)

Ich habe zudem lieber eine FG Technologie, die gut mit dem zugrunde liegenden Temporal Upsampling Algorithmus funktioniert. Kann sein, dass DLSS FG deutlich schlechter mit FSR2 oder XeSS harmoniert. FG alleine erscheint mir zudem eh sinnfrei. DLSS / FSR native sind eigentlich immer deutlich besser als TAA. Bei FSR3 ist der native Mode Pflicht und bei DLSS3 soweit ich weiss auch (DLAA). Also wird man FG faktisch immer zusammen einem Temporal Upsampling Algorithmus brauchen (egal ob nativ oder nicht). FG + TAA ist mMn nutzlos.

rumpeLson

2023-11-24, 13:39:44

The_Invisible

2023-11-24, 13:50:34

FSR2 in IoA lässt leider keine Bewertung zu da die DEVs intern extrem nachschärfen was sich nicht ausschalten lässt. Keine Ahnung was die da wieder gesoffen haben. Die Nachschärfung ist vieeel zu hoch hier.

Die Tests dazu gabs schon lange bei Release des Spiels, FSR ist da mal wieder am schlechtesten weggekommen, das überschärft wurde hat man auch immer angemerkt.

Achill

2023-11-24, 14:15:04

Ich glaube das ist nur eine Teilmenge der Wahrheit. DLSS FG ist ebenfalls auf weitere Input wie Motion Vectors angewiesen. Sofern ich es richtig verstanden habe, dienen die Optical Flow Accelerator auch eher als Fallback, sofern sich Informationen nicht über Motion Vectors rekonstruieren lassen.
[..]

(Edit an mich selbst) Hier wird es ausgeführt ..

[..]
For each pixel, the DLSS Frame Generation AI network decides how to use information from the game motion vectors, the optical flow field, and the sequential game frames to create intermediate frames. By using both engine motion vectors and optical flow to track motion, the DLSS Frame Generation network is able to accurately reconstruct both geometry and effects, as seen in the picture below.
[..]

--

[..]
Aus technischer Sicht wäre es sicher möglich FSR 3 mit anderen Upsampling Verfahren kombiniert zu nutzen. Zur Not wird FSR 3 mit den notwendigen FSR 3 Inputs versorgt und die notwendigen Inputs für das andere Verfahren separat gepflegt. Im Worst Case kostet das dann minimal Performance und VRAM.
[..]

Nur weil etwas technisch möglich ist, ist es noch lange nicht sinnvoll. Wir könnten sämtliche Kriege durch Einsatz von Nuklear-Waffen in kürzester Zeit entscheiden - ist technisch möglich - nur in allen anderen Belangen nicht sinnvoll.

[..]
Anders wird das mit gleichzeitiger Nutzung von DLSS FG und anderen Verfahren auch nicht laufen.
[..]

Es wurde doch nur ein Post über deinen eben erklärt, warum dies bei NV Ansatz möglich ist. Da muss man nichts umdeuten ...

Raff

2023-11-24, 14:20:00

AMDs Lösung für das HUD ist unabhängig davon sehr smart.

Das ist für Upsampling seit jeher "best practice", die Anzeigen werden stets mit nativer Auflösung dargestellt (was einer der Gründe dafür ist, dass das mehr VRAM braucht als eine durchweg geringe Auflösung). Dass Nvidias Frame Generation mit spieleigenen Anzeigen Probleme hat bzw. hatte, wundert mich daher auch. Möglicherweise ist das nur eine Eigenheit der RED Engine.

Es wurde doch nur ein Post über deinen eben erklärt, warum dies bei NV Ansatz möglich ist. Da muss man nichts umdeuten ...

Jo. Ich möchte das noch einmal betonen: Nvidias FG lässt sich mit allen Verfahren kombinieren, also TAA, DLSS, FSR, TSR und weiß der Geier, was noch. Allerdings wird das nicht von allen Spielen nach Lehrbuch angeboten - manchmal, und sei es nur bis zu einigen Patches -, wird FG erst nach Aktivierung von DLSS freigeschaltet, was so AFAIK nicht in Nvidias Guidelines steht. Ich hoffe, dass die offizielle Finalversion von FSR 3 ebenfalls FG für alle Verfahren möglich machen wird.

MfG
Raff

DrFreaK666

2023-11-24, 14:34:55

FSR2 in IoA lässt leider keine Bewertung zu da die DEVs intern extrem nachschärfen was sich nicht ausschalten lässt. Keine Ahnung was die da wieder gesoffen haben. Die Nachschärfung ist vieeel zu hoch hier.

Kannst die anderen Modi ja auch überschärfen und dann vergleichen XD

robbitop

2023-11-24, 14:39:52

FSR3 FG nutzt FSR2 als Grundlage für die Framegeneration. Motion Vectors, Disocclusion Masken, usw. werden für FG verwendet. Da kannst du FG nicht ohne weiteres von FSR2 separieren.

Nvidia geht mit FG einen ganz anderen Weg. Sie nehmen das fertige Bild und mit einem HW-Accelerator und AI-Trickerei werden die erforderlichen Informationen generiert. Das kann man dann auch ohne DLSS verwenden, hat aber auch zusätzliche Probleme (HUD Ghosting -> HUD kann man bei FSR3 explizit exkludieren, was das Problem bei der Wurzel löst).

Ich finde AMDs Ansatz eigentlich relativ smart. Re-Use von bestehenden Informationen. Nvidias Ansatz ist da eher Brute Force im Vergleich. Was am Ende besser funktioniert: Abhängig von der Qualität der Implementation. Momentan ist Nvidias Lösung im Vorteil. Dass FSR3 FG nur mit FSR2 genutzt werden kann ist zwar schade, aber auch nicht wirklich ein Problem. Oder nutzt jemand mit Nvidia Karte DLSS und will FSR3 FG drüberbügeln, wenn es DLSS FG bereits gibt? Wenn DLSS nicht integriert ist, kann man sowieso nur FSR benutzen. Wenn DLSS3 und FSR3 integriert sind, werden beide FG unterstützen. Die anderen Techniken (XeSS, TSR) werden mit Sicherheit auch FG bekommen. Dann ist es wie heute: Man nimmt das, was einem besser passt. Temporal Upsampling der Wahl mit/ohne FG ;)

Ich habe zudem lieber eine FG Technologie, die gut mit dem zugrunde liegenden Temporal Upsampling Algorithmus funktioniert. Kann sein, dass DLSS FG deutlich schlechter mit FSR2 oder XeSS harmoniert. FG alleine erscheint mir zudem eh sinnfrei. DLSS / FSR native sind eigentlich immer deutlich besser als TAA. Bei FSR3 ist der native Mode Pflicht und bei DLSS3 soweit ich weiss auch (DLAA). Also wird man FG faktisch immer zusammen einem Temporal Upsampling Algorithmus brauchen (egal ob nativ oder nicht). FG + TAA ist mMn nutzlos.
DLSS FG nutzt auch beides. Motion Vectors und Optical Flow. Die Verfahren sind nach meinem Verständnis nicht so unterschiedlich. Nvidia hat HW für Optical Flow und AMD macht es per compute.
Dass man die Motion Vectors von FSR nutzt ist eher ein Schnittstellenthema. Wenn man sich auf Streamline eingelassen hätte, wäre das nicht notwendig. Da sind die Schnittstellen alle klar definiert und man kann sich standardisiert die Daten aus den Schnittstellen holen. Wahrscheinlich ginge dann auch die Kombination mit XeSS und DLSS Upsampling.
Wenn FSR Upsampling ein Stück weiter wäre, würde man die Diskussion wahrscheinlich gar nicht führen müssen.

basix

2023-11-24, 14:40:21

Das ist für Upsampling seit jeher "best practice", die Anzeigen werden stets mit nativer Auflösung dargestellt (was einer der Gründe dafür ist, dass das mehr VRAM braucht als eine durchweg geringe Auflösung). Dass Nvidias Frame Generation mit spieleigenen Anzeigen Probleme hat bzw. hatte, wundert mich daher auch. Möglicherweise ist das nur eine Eigenheit der RED Engine.

Bei DLSS FG ist das nicht ganz richtig. FG wir auf den finalen Bildern appliziert. Also inkl. HUD.

Ausserdem hat(te) Immortals of Aveum auch grosser Probleme mit dem HUD Ghosting. FSR3 ist davon nicht betroffen.

Ich hoffe, dass die offizielle Finalversion von FSR 3 ebenfalls FG für alle Verfahren möglich machen wird.
Wie vorher bereits geschrieben: Sobald alle Verfahren eine Form von FG unterstützen (was garantiert kommen wird), macht das Mischen einfach keinen Sinn mehr. Die Bildqualität hängt primär vom verwendeten Upsampling Algorithmus ab und nicht von FG. Das zeigen zumindest die verschiedenen Tests zu DLSS & FSR FG.

DLSS FG nutzt auch beides. Motion Vectors und Optical Flow. Die Verfahren sind nach meinem Verständnis nicht so unterschiedlich. Nvidia hat HW für Optical Flow und AMD macht es per compute.
Dass man die Motion Vectors von FSR nutzt ist eher ein Schnittstellenthema. Wenn man sich auf Streamline eingelassen hätte, wäre das nicht notwendig. Da sind die Schnittstellen alle klar definiert und man kann sich standardisiert die Daten aus den Schnittstellen holen. Wahrscheinlich ginge dann auch die Kombination mit XeSS und DLSS Upsampling.
Wenn FSR Upsampling ein Stück weiter wäre, würde man die Diskussion wahrscheinlich gar nicht führen müssen.
Afaik ist FSR3 FG +/- einfach FSR2 mit interpolierten Motion Vectors usw., d.h. der FSR2 Algorithmus wird "einfach" 2x durchgerechnet. Zumindest habe ich das anhand der (momentan) spärlichen vorhanden Informationen zur inneren Funktionsweise von FSR3 verstanden.
Ob das DLSS FG auch so macht? Kann sein. Würde mich aber ein wenig überraschen, da die Runtime Cost von FG deutlich höher zu sein scheint als von DLSS. Und FSR3 FG ist hier deutlich schneller. Kann mich aber natürlich irren. Ebenso kann ich mich auch zur Funktionsweise von FSR3 irren ;)

Tesseract

2023-11-24, 14:47:07

die inputs für DLSS-FG sind depth buffer, motion vectors, framebuffer ohne UI und das UI mit alpha.

FSR3 FG nutzt FSR2 als Grundlage für die Framegeneration. Motion Vectors, Disocclusion Masken, usw. werden für FG verwendet. Da kannst du FG nicht ohne weiteres von FSR2 separieren.

warum sollte man das nicht können? entsprechende masken und vektoren muss man dann halt extra für FG berechnen bzw. aus anderen verfahren wie DLSS/XeSS/TAA übernehmen und ggf. anpassen. die entscheidung FSR-FG zwingend mit FSR zu kombinieren wirkt rein politisch motiviert.

DrFreaK666

2023-11-24, 14:51:42

... Wenn FSR Upsampling ein Stück weiter wäre, würde man die Diskussion wahrscheinlich gar nicht führen müssen.

Wenn DLSS nicht NV-only wäre, müsste man die Diskussion auch nicht führen.
Bin gespannt ob Intels FG Arc-only wird

Exxtreme

2023-11-24, 14:53:08

FSR3 FG nutzt FSR2 als Grundlage für die Framegeneration. Motion Vectors, Disocclusion Masken, usw. werden für FG verwendet. Da kannst du FG nicht ohne weiteres von FSR2 separieren.

Klar kann man das separieren wenn man will. Das ganze scheint viel mehr ein API-Problem denn ein technisches Problem zu sein. Bewegungsvektoren und Disocclusion-Masken kannst du auch so ermitteln. Was fehlt, ist ein API um diese Ergebnisse vor dem Upscaling abzugreifen. Und so ein API nicht anzubieten sieht mir eher nach einer Entscheidung des Managements zu sein denn eine technische Notwendigkeit.

basix

2023-11-24, 14:55:35

Klar "kann" man das kombinieren, wenn man unbedingt will. Nur musst du dann zusätzliche Teile von FSR2 rechnen, die bei FSR3 gratis dabei sind und wenn man es mit DLSS oder XeSS kombiniert musst du das obendrauf rechnen. Und wie gesagt, sind die internen Informationen von z.B. DLSS nicht für FSR FG zugänglich. Allenfalls fehlt "nur" eine API. Allenfalls müsstest du aber vieles in andere Formate und Datenstrukturen usw. konvertieren, dass das funktionieren würde. Geil, Querabhängigkeiten des eigenen Algorithmus zu DLSS. Und XeSS. Und TSR. Will sicher jeder Entwickler so machen, weil so schön hinsichtlich Maintenance ;) Wenn du die Informationen von DLSS nicht hast, müsstest du das volle DLSS durchrechnen, dann das (mehr oder minder) volle FSR2 und obendrauf noch FSR FG, nur um das FSR2 Temporal Upsampling Ergebnis dann wegzuschmeissen. Kostet Performance. Kostet Speicher. Dann noch potentielle Inkonsistenzen bei Bilddarstellung zwischen DLSS und FSR FG, was zu einem unruhigen Bild führen könnte. Scheint mir nicht sehr sinnvoll zu sein. Und um das wirklich nochmals zu unterstreichen: FG bei FSR und DLSS sind eine Momentaufnahme. Alle anderen Konkurrenztechnologien werden nachziehen. Und jeder kann dann FG in einer Form nutzen, egal ob AMD, Intel oder Nvidia.

Und: Wenn ich Nvidia DLSS nutze, nutze ich auch Nvidia FG. Ich sehe keinen Vorteil, FSR3 FG zu nutzen. Und DLSS sowie DLSS3 FG läuft nicht auf nicht-Nvidia Karten. Womit man auch da keinen Nutzen ziehen kann. Jetzt könnte jemand TSR oder XeSS mit FSR3 FG nutzen wollen. OK. Das Problem wird sich aber bis geschätzt Mitte nächstes Jahr von selbst lösen, weil FG in XeSS und TSR integriert werden wird.
Wenn DLSS nicht NV-only wäre, müsste man die Diskussion auch nicht führen.
Bin gespannt ob Intels FG Arc-only wird
Arc only oder XeSS only? Sind zwei veschiedene Dinge ;) FSR3 geht auch auf Intel und Nvidia.

dargo

2023-11-24, 15:17:03

Und: Wenn ich Nvidia DLSS nutze, nutze ich auch Nvidia FG. Ich sehe keinen Vorteil, FSR3 FG zu nutzen. Und DLSS sowie DLSS3 FG läuft nicht auf nicht-Nvidia Karten. Womit man auch da keinen Nutzen ziehen kann.
Kleine Ergänzung... DLSS3 FG läuft nicht mal bei Nvidia auf non Ada.

DrFreaK666

2023-11-24, 15:28:26

...Arc only oder XeSS only? Sind zwei veschiedene Dinge ;) FSR3 geht auch auf Intel und Nvidia.

Meinte schon Arc-only. Vielleicht geht Intel da den NV-Weg, da das einfacher wäre

robbitop

2023-11-24, 15:49:44

Afaik ist FSR3 FG +/- einfach FSR2 mit interpolierten Motion Vectors usw., d.h. der FSR2 Algorithmus wird "einfach" 2x durchgerechnet. Zumindest habe ich das anhand der (momentan) spärlichen vorhanden Informationen zur inneren Funktionsweise von FSR3 verstanden.
Ob das DLSS FG auch so macht? Kann sein. Würde mich aber ein wenig überraschen, da die Runtime Cost von FG deutlich höher zu sein scheint als von DLSS. Und FSR3 FG ist hier deutlich schneller. Kann mich aber natürlich irren. Ebenso kann ich mich auch zur Funktionsweise von FSR3 irren ;)
Nach meinem Verständnis funktionieren beide Verfahren sehr sehr ähnlich. Motion Vectors + Optical Flow. Nur, dass eben letzteres bei Nvidia mit HW erledigt wird.
Der Fakt, dass die Zwischenbilder bei FSR3 FG gar nicht mal so schlecht sind (verglichen mit DLSS 3 FG) unterstützt das. Es sind die (leider sehr unschönen) Details wie Frame Pacing und wie man das in den Griff bekommt, die Nvidia sehr viel cleaner gemacht hat.

Wenn DLSS nicht NV-only wäre, müsste man die Diskussion auch nicht führen.

Volle Zustimmung. Gut finde ich es auch nicht. Aber es ist halt clever von Nvidia und im Interesse der Shareholder (Gewinn zu maximieren). Nvidia ist in einer anderen Position. Sie haben die Marktmacht und das deutlich bessere Verfahren. Sie müssen nichts open source machen.
AMD hingegen hat beides nicht - entsprechend ist das Öffnen des Verfahrens schon fast ein Muss wenn man breite Implementierung wünscht. Genau aus dem Grund hat Intel es auch gemacht.

In der Realität hilft es AMD nur, FSR besser zu machen. Dass am Upsampling seit >1 Jahr keine sichtbaren Verbesserungen mehr kamen, ist etwas besorgniserregend. In der gleichen Zeit hat Epic es mit TSR geschafft, an FSR vorbei zu ziehen (weil sie weiter mit Hochdruck dran gearbeitet haben).
Es hilft nichts - man muss in die Hände spucken.

Interessant ist, dass sogar Apple mittlerweile ein NN basiertes temporales Upsampling Verfahren zu haben scheint was ganz brauchbar zu sein scheint (in Resident Evil kann man es sich anschauen). Es nutzt wohl die Tensor HW, die nicht in der GPU aber auf dem Chip selbst (A und M Serie ist.

Gast

2023-11-24, 15:51:42

Bei DLSS FG ist das nicht ganz richtig. FG wir auf den finalen Bildern appliziert. Also inkl. HUD.

Trotzdem bekommt DLSS FG auch die G-Buffer und Motionvectoren als Input. Es soll nur "intelligent" erkennen wenn diese nicht stimmen.

Ausserdem hat(te) Immortals of Aveum auch grosser Probleme mit dem HUD Ghosting. FSR3 ist davon nicht betroffen.

Weil man vergessen hatte die entsprechenden Masken zu setzen. Das wurde mit dem ersten Patch schon behoben.

FSR3 FG hat allerdings das Problem, das HUD überhaupt nicht mit einzubeziehen, du bekommst mit FSR3 FG das HUD immer nur mit der originalen Framerate zu Gesicht, was bei statischen Elementen zwar egal ist, bei dynamischen aber extrem störend, da die Elemente immer zwischen 2 Positionen in der Welt hin und herspringen.

DLSS FG interpoliert auch die HUD-Elemente, und wenn die Masken gesetzt sind auch ohne Ghosting.

DrFreaK666

2023-11-24, 16:18:32

...In der gleichen Zeit hat Epic es mit TSR geschafft, an FSR vorbei zu ziehen (weil sie weiter mit Hochdruck dran gearbeitet haben)...

Ich glaube bei Epic arbeiten mehr Menschen an der Unreal Engine als bei AMD an FSR ;)
AMD hat sich auf FG fokussiert, da das in der Wahrnehmung wichtiger ist

The_Invisible

2023-11-24, 16:34:36

In der Realität hilft es AMD nur, FSR besser zu machen. Dass am Upsampling seit >1 Jahr keine sichtbaren Verbesserungen mehr kamen, ist etwas besorgniserregend. In der gleichen Zeit hat Epic es mit TSR geschafft, an FSR vorbei zu ziehen (weil sie weiter mit Hochdruck dran gearbeitet haben).
Es hilft nichts - man muss in die Hände spucken.

Interessant ist, dass sogar Apple mittlerweile ein NN basiertes temporales Upsampling Verfahren zu haben scheint was ganz brauchbar zu sein scheint (in Resident Evil kann man es sich anschauen). Es nutzt wohl die Tensor HW, die nicht in der GPU aber auf dem Chip selbst (A und M Serie ist.

TSR ist halt schon ein Spezialfall weil es nur mit UE5 geht und sie auch Daten der ganzen Engine abgreifen können.
Die Frage ist ob es mit herkömmlichen Methoden überhaupt noch besser geht wenn man nur einen generischen Ansatz verfolgt.

Aber ja, wird Zeit das auch AMD mit einem AI basierten Ansatz daherkommt, ich hoffe sie arbeiten schon (länger) daran und haben jetzt mit FSR3 nicht unnötig Entwicklungszeit vergeudet...

aufkrawall

2023-11-24, 16:39:19

TSR ist halt schon ein Spezialfall weil es nur mit UE5 geht und sie auch Daten der ganzen Engine abgreifen können.
Die Frage ist ob es mit herkömmlichen Methoden überhaupt noch besser geht wenn man nur einen generischen Ansatz verfolgt.

Es wurde auch ewig über TAA gesagt, das wäre nicht in Spiele modbar etc. Jüngstes Gegenbeispiel GTA V DLSS-Mod, wo der Entwickler diverse Custom Shader geschrieben hat, um dafür Bewegungsvektoren etc. zu erzeugen.
Gerade weil es Open Source ist und auf den Konsolen läuft, muss Mehraufwand kein Hinderungsgrund sein.

Tesseract

2023-11-24, 16:54:36

motion vectors kann man für jedes 3D-spiel generieren, die inputs von TSR haben in anderen engines möglicherweise überhaupt kein gegenstück. kann man irgendwo nachlesen was das genau macht?

aufkrawall

2023-11-24, 17:00:32

Es sollte mal einen Tech Blog Post dazu geben, ist aber offenbar nichts draus geworden:
https://www.unrealengine.com/en-US/feed/tech-blog

Ansonsten könnte man als Game-Dev in den Source Code auf GitHub schauen.

robbitop

2023-11-24, 18:25:15

Ich glaube bei Epic arbeiten mehr Menschen an der Unreal Engine als bei AMD an FSR ;)
AMD hat sich auf FG fokussiert, da das in der Wahrnehmung wichtiger ist

Aber nur ein Bruchteil der Menschen der Engine arbeitet an TSR. Es waren iirc auch nicht so viele Leute die an FSR upsampling gearbeitet haben wenn ich mich an die credits im whitepaper erinnere. Wenn AMD nicht der Ansicht ist, dass das wichtig ist, müssen sie mit dem Ergebnis leben.
FSR3 ist ja leider auch in die Hose gegangen. Und das obwohl die Zwischenbildberechnung gut aussieht. Da bringt alle Priosierung nichts, wenn man es mit unschönem framepacing ausliefert.
IMO muss man schauen, dass man mehr SW Talent aufbaut um in solchen Dingen zukünftig mehr umsetzen zu können.

Ggf könnte man den open source Aspekt auch mehr ausnutzen wenn man nicht nur den source code auf github dumpen würde sondern auch dort mit der community Verbessserungen einbauen würde. Open source kann einiges bringen wenn man den Gedanken „develop code in public“ auch lebt. Und dort würden sich sicherlich auch ein paar Talente herauskristallisieren die man anheuern könnte.

DrFreaK666

2023-11-24, 19:27:27

FSR3 wurde zu früh angekündigt. Die Entwickler waren dann irgendwann in Zugzwang, da "soon" schon längst vorbei war.

robbitop

2023-11-24, 20:00:37

Man hätte es lieber verschoben und gesagt es ist noch nicht im guten Zustand. Das wäre für das Image besser gewesen. Inzwischen ist das auch wieder 3 Monate her. Von Verbesserungen haben wir leider bis dato noch nichts gesehen. Hoffentlich hat AMD was in der Mache…

robbitop

2023-11-24, 20:02:36

TSR ist halt schon ein Spezialfall weil es nur mit UE5 geht und sie auch Daten der ganzen Engine abgreifen können.
Die Frage ist ob es mit herkömmlichen Methoden überhaupt noch besser geht wenn man nur einen generischen Ansatz verfolgt.

Aber ja, wird Zeit das auch AMD mit einem AI basierten Ansatz daherkommt, ich hoffe sie arbeiten schon (länger) daran und haben jetzt mit FSR3 nicht unnötig Entwicklungszeit vergeudet...
TSR ist immerhin ein Belegt, dass ohne NN noch ordentlich Potenzial da ist.
Ob und was da wirklich mehr genutzt werden soll ist iirc völlig unklar. Ich hab da noch keine spezifischen Dinge gelesen, die da besonders helfen sollten, die für FSR, DLSS ind XeSS nicht bereitstünden.

DrFreaK666

2023-11-27, 17:23:40

Exxtreme

2023-11-27, 17:26:20

Eventuell sperrt sich Micros~1 stark dagegen. Directx 12 ist ja proprietär und nicht offen.

DrFreaK666

2023-11-27, 17:30:39

Mir schon klar dass es proprietär wäre, aber dann würde man AMDs Tech öfter nutzen. Sie haben ja mehr als nur FSR entwickelt

Exxtreme

2023-11-27, 17:35:25

Micros~1 hat in der Vergangenheit nicht so wirklich etwas herstellerspezifisches verbaut. Da fällt mir nur die Texturkompression von S3 ein. Aber das ist jetzt auch gefühlt 20 Jahre her.

Zudem braucht man das jetzt auch nicht unbedingt in Directx 12. Die jetzige Lösung funktioniert auch so praktisch überall.

The_Invisible

2023-11-27, 17:38:22

Wenn sollte man eine allgemeine Schnittstelle für Upscaling einbauen, derzeit macht das ja eher Nvidia mit ihrem Streamline... komischerweise will da AMD nicht mitmachen obwohl OpenSource ;)

Exxtreme

2023-11-27, 17:41:02

Mag ja sein. Andererseits ist Streamline unter der MIT-Lizenz. Und die ist sehr offen. Also ist das auch nicht wirklich ein Problem da jeder Hersteller und jeder Spieleentwickler das ohne Hickhack nutzen kann, ohne vorher Lizenzanwälte konsultieren zu müssen.

DrFreaK666

2023-11-27, 17:59:02

Wenn sollte man eine allgemeine Schnittstelle für Upscaling einbauen, derzeit macht das ja eher Nvidia mit ihrem Streamline... komischerweise will da AMD nicht mitmachen obwohl OpenSource ;)

Es sollte sich ein Upscaling durchsetzen. Was bringen uns vier verschiedene, wobei es sogar verschiedene TAA-Ansätze gibt?
Unverständlich dass MS nicht deren ML-Upscaling weiterentwickelt haben

edit: hab TSR vergessen, dann sind es sogar fünf!

Dass jeder sein eigenes Süppchen kochen muss, ist zum kotzen.

aufkrawall

2023-11-27, 18:03:03

Wenn sollte man eine allgemeine Schnittstelle für Upscaling einbauen, derzeit macht das ja eher Nvidia mit ihrem Streamline... komischerweise will da AMD nicht mitmachen obwohl OpenSource ;)
Schon, ändert aber auch nichts am Algorithmus dahinter. Scheint einfach eine Nummer zu groß für AMDs "Software-Sparte" zu sein.

Lurtz

2023-11-27, 19:02:15

Exxtreme

2023-11-27, 19:05:30

Es sollte sich ein Upscaling durchsetzen.

Bei sowas bekommst du in der Regel den schlechtesten Kompromiss bzw. den kleinsten gemeinsamen Nenner. Und das ist derzeit FSR. :freak: Nur für FSR braucht's wiederum kein erweitertes Directx 12. Das geht auch so ohne Probleme.

DrFreaK666

2023-11-27, 19:13:46

Bei sowas bekommst du in der Regel den schlechtesten Kompromiss bzw. den kleinsten gemeinsamen Nenner. Und das ist derzeit FSR. :freak: Nur für FSR braucht's wiederum kein erweitertes Directx 12. Das geht auch so ohne Probleme.

XeSS kann auch ein gemeinsamer Nenner sein. Nvidia ist ja nicht daran interessiert, dass DLSS auf anderen Karten läuft, denn dann fehlt ein Selling-Point

Linmoum

2023-11-27, 19:24:56

Wie soll DLSS auf anderen Karten mit identischer Qualität wie aktuell laufen? Herstellerübergreifender "Standard" bedeutet in dem Fall Abstriche bei der Qualität machen zu müssen. Verständlicherweise ist man daran nicht interessiert.

Sowieso sinnfreie Diskussion, da auch AMD spätestens mit RDNA5 dedizierte Einheiten wird verbauen müssen (und es garantiert auch tun wird) und dann alte Radeon-Besitzer doof aus der Wäsche gucken werden. Alles andere ist aus Herstellersicht schlicht illusorisch.

Exxtreme

2023-11-27, 19:25:37

XeSS kann auch ein gemeinsamer Nenner sein. Nvidia ist ja nicht daran interessiert, dass DLSS auf anderen Karten läuft, denn dann fehlt ein Selling-Point

Das volle Xess läuft nur auf Intel-GPUs. Du bräuchtest also das Spar-Xess. Und da hast du schonmal so einen Kompromiss, der alles andere als optimal ist. Und Opensource ist das Spar-Xess auch nicht. Und deshalb ist FSR in der Summe der beste Kompromiss. Nur halt nicht für Leute, die auf brauchbare Bildqualität stehen.

DrFreaK666

2023-11-27, 19:31:10

Bei dem was Microsoft dem PC sonst so "geschenkt" hat, darf man wohl eher froh darüber sein.

MS hat 2018 Super Resolution mit ML gezeigt
https://i.postimg.cc/FsYmcxP0/carcompare.png (https://postimg.cc/MvJhJ1JG)

Das entstand mit Hilfe von NV und die hatten natürlich kein weiteres Interesse daran

Das volle Xess läuft nur auf Intel-GPUs. Du bräuchtest also das Spar-Xess. Und da hast du schonmal so einen Kompromiss, der alles andere als optimal ist. Und Opensource ist das Spar-Xess auch nicht. Und deshalb ist FSR in der Summe der beste Kompromiss. Nur halt nicht für Leute, die auf brauchbare Bildqualität stehen.

Das Spar-XeSS wird aber trotzdem empfohlen, wenn man eine bettere Bildqualität als mit FSR möchte.
Für FSR spricht am Ende nur die bessere Performance

aufkrawall

2023-11-27, 19:43:53

MS hat 2018 Super Resolution mit ML gezeigt

Wahrscheinlich spatial Schrott ala DLSS 1, Bild sieht auch entsprechend bloaty aus.

vinacis_vivids

2023-11-27, 20:25:04

Das Spar-XeSS wird aber trotzdem empfohlen, wenn man eine bettere Bildqualität als mit FSR möchte.
Für FSR spricht am Ende nur die bessere Performance

Quelle? Ich habe bisher keine legitime Quelle gefunden, die deine Aussage hier untermauert.

Auch merke ich immer die gleiche Leier von den gleichen Leuten als unterschwelligen Versuch AMD mies reden zu wollen.

Wird nicht funktionieren, FSR ist in vielen Fällen selbst mit FSR-P also 50% Redering-Pipeline besser als DLSS-P.

Was DLSS-P da liefert, ist meistens Müll für die Augen.

DrFreaK666

2023-11-27, 21:13:21

Wahrscheinlich spatial Schrott ala DLSS 1, Bild sieht auch entsprechend bloaty aus.

Für Spatial benötigt man kein NN. Oder meinst NV hat auf diesem Ergebnis aufbauend DLSS1 entwickelt? Kann natürlich sein

rumpeLson

2023-11-27, 22:09:40

FSR ist in vielen Fällen selbst mit FSR-P also 50% Redering-Pipeline besser als DLSS-P.
Eine legitime Quelle hierfür würden sicher viele gerne sehen ;)

Mir gefällt das DP4a XeSS meistens auch besser als FSR, weil XeSS immerhin versucht Dinge zu rekonstruieren und eine gewisse temporale Stabilität zu erzeugen.

DrFreaK666

2023-11-27, 23:24:17

...Auch merke ich immer die gleiche Leier von den gleichen Leuten als unterschwelligen Versuch AMD mies reden zu wollen...

Und da zitierst du gerade mich?

Monsta

2023-11-28, 08:26:32

Quelle? Ich habe bisher keine legitime Quelle gefunden, die deine Aussage hier untermauert.

Auch merke ich immer die gleiche Leier von den gleichen Leuten als unterschwelligen Versuch AMD mies reden zu wollen.

Wird nicht funktionieren, FSR ist in vielen Fällen selbst mit FSR-P also 50% Redering-Pipeline besser als DLSS-P.

Was DLSS-P da liefert, ist meistens Müll für die Augen.

Alles unter FSQ-Q ist nicht konkurrenzfähig, und in Bewegung bei niedrigen FPS ist jeder DLSS Modus besser als FSR.
Kauf Dir mal ne billige Nvidia Karte und guck Dir das an, Youtube usw reichen dafür nicht.

Solange das Upscaling nicht ausgereift ist, finde ich Konkurrenz gut.

robbitop

2023-11-28, 09:06:39

Es sollte sich ein Upscaling durchsetzen. Was bringen uns vier verschiedene, wobei es sogar verschiedene TAA-Ansätze gibt?
Unverständlich dass MS nicht deren ML-Upscaling weiterentwickelt haben

edit: hab TSR vergessen, dann sind es sogar fünf!

Dass jeder sein eigenes Süppchen kochen muss, ist zum kotzen.
Es ist nervig aber leider funktioniert Innovation so. Sagt sogar Jim Keller (nicht im Zusammenhang mit TAA sondern mit uArchs aber das kann man breit anwenden).
Die höchste Innovationsrate gibt es, wenn es so viele wie mögliche in Konkurrenz laufende "Experimente" mit unterschiedlichen Verfahren gibt. Dann hat man Wettbewerbs- und Innovationsdruck und es wird alle möglichen Herangehensweisen ausprobiert und es gibt Erkenntnisse, was gut funktioniert und was weniger gut funktioniert.
Langfristig setzt sich dann die sinnvollste Funktionsweise durch. Solange Verfahren aber HW oder SW proprietär sind, gibt es auch langfristig das Bedürfnis nach mehreren Verfahren.
TSR bspw ist proprieätr zur UE5. DLSS proprietär zur NV Tensor Core HW.
Entsprechend werden diese Verfahren niemals die Alleinherrschaft übernehmen können. Es sei denn, dass sich die Restriktion auflöst.

Schon, ändert aber auch nichts am Algorithmus dahinter. Scheint einfach eine Nummer zu groß für AMDs "Software-Sparte" zu sein.
IMO könnte AMD das ändern, wenn man das in der richtigen "Kultur" machen würde. Open Source kann dank der Community so mächtig sein. Es gibt in der communitiy einige richtig starke Talente und die wachsen auch ständig nach und die arbeiten sogar freiwillig mit. Wenn man den Open Source Gedanken auch leben würde (develop in public statt source code zu droppen - einen Dialog mit den Contributors offen halten und sie auch contributen lassen etc), ginge mehr. Und darüber würde man sicherlich sehr schnell richtige Talente identifizieren, die man anheuern könnte und sich verstärken könnte. Man müsste das nur richtig leben. Tut man aber nicht so richtig. Wirkt irgendwie wie aufgesetzt.
Methapher: Man beißt ideenlos in die Zitronen, die einem gegeben wird und verzieht das Gesicht anstatt clever zu sein und Limonade zu machen. ^^

Wahrscheinlich spatial Schrott ala DLSS 1, Bild sieht auch entsprechend bloaty aus.
Dafür sind IMO viel zu viele Details in dem upgescalten Bild wieder da, die im lowres nicht vorhanden sind. IMO spricht das für eine temporale Komponente. Man darf aber auch nicht vergessen dass es (1) 2018 (also 5 Jahre her) war und es (2) sicherlich einen Grund dafür gab, dass es nicht releast wurde. Ein gutes temporales Upsampling Verfahren ist (insbesondere mit ML) offenbar alles andere als trivial. :)

Für Spatial benötigt man kein NN. Oder meinst NV hat auf diesem Ergebnis aufbauend DLSS1 entwickelt? Kann natürlich sein
Man kann neuronale Netze natürlich auch für Spatiale Filter und Rekonstruktion nutzen.
Einige TV Upscaler machen das und auch DLSS1 hat das zT gemacht.

Wie soll DLSS auf anderen Karten mit identischer Qualität wie aktuell laufen? Herstellerübergreifender "Standard" bedeutet in dem Fall Abstriche bei der Qualität machen zu müssen. Verständlicherweise ist man daran nicht interessiert.

Sowieso sinnfreie Diskussion, da auch AMD spätestens mit RDNA5 dedizierte Einheiten wird verbauen müssen (und es garantiert auch tun wird) und dann alte Radeon-Besitzer doof aus der Wäsche gucken werden. Alles andere ist aus Herstellersicht schlicht illusorisch.

Ob man für DLSS Upsampling wirklich dedizierte Einheiten braucht ist fraglich. Wenn man sich die Rendertime eines Frames in nSight anzeigen lässt mit aktivem DLSS Upsampling leuchten die Tensorcores nur sehr sehr kurz auf. IIRC hat basix das mal anhand dessen Rechenleistung umgerechnet was für ein Impact das mit normalen Vektor FPUs wäre und das wäre immernoch sinnvoll gewesen wenn auch teurer.
Vor allem will Nvidia nicht, dass es auf fremder HW läuft (ob Matrix FPUs oder nicht) - ist halt ein unique selling point.

IMO wird Radeon nur Matrix Cores in RDNA verbauen (CDNA hat die schon), wenn sie sinnvolle Applikationen für Consumer 3D (= Gaming) machen können. Die HW zu bauen ist trivial - die Dinger sind in jedem modernen Smartphone SoC. Bei AMD ist die Softwareabteilung leider aktuell der Bremsklotz. Und ML ist auch nichts, was jetzt jedem Programmierer zu liegen scheint. Entsprechende Leute muss man auch erstmal dafür haben, die sowohl 3D Grafik verstehen als auch wie man mit modernen Transformer models umgeht. Nvidia hat hier viel Zeit bei den Grundlagen investiert und dadurch ein entsprechendes Team aufgebaut. Das muss AMD erstmal tun. Und bis dato ist davon noch nichts zu sehen (was nicht heißen muss, dass das nicht im Aufbau ist). Und ob die Xilinx Leute dabei so hilfreich sind (die haben viele ML Leute aber wenig 3D Hintergrund) ist fraglich.

fondness

2023-11-28, 09:24:16

Wie soll DLSS auf anderen Karten mit identischer Qualität wie aktuell laufen? Herstellerübergreifender "Standard" bedeutet in dem Fall Abstriche bei der Qualität machen zu müssen. Verständlicherweise ist man daran nicht interessiert.

Begründung? Manche tun hier so als wären diese "Tensor-Cores" irgendwelcher Voodoo. Das sind stink normale Matrix-Einheiten für sehr kleine Formate wie FP8 und INT8, mehr nicht. Natürlich könnte man das auch auf Radeons ausführen, wäre halt vermutlich langsamer ohne dezidierte Einheiten. Nvidia ist zudem mehr als bekannt dafür alles was sie irgendwie machen Vendor zu locken bzw. closed source zu machen. Wer das bestreitet lebt nun wirklich hinterm Mond.

Raff

2023-11-28, 09:29:33

fondness

2023-11-28, 09:33:59

Nvidias Narrativ ist: Diese (den anderen Verfahren überlegene) Qualität geht nur, weil die Tensor-Kerne das flott berechnen. Würde man also reines ALU-Compute machen, müsste man den Aufwand reduzieren. Leider ist das von außen schwer nachprüfbar.

MfG
Raff

Ist auf jeden Fall sehr glaubwürdig bei einer Firma die meint für Adaptive Sync benötigt man ein riesiges FPGA im Monitor, weil man es sonst nicht vendor locken kann. Ob das dann auf anderen GPUs zu langsam ist könnten zudem eh die Kunden selbst beurteilen.

Raff

2023-11-28, 09:36:46

fondness

2023-11-28, 09:39:26

Najaaa ... Ginge es nach einigen, würden wir immer noch stur und ausschließlich Rasterizing-Einheiten à la Pascal verbauen, als gäb's nix anderes, weil Raytracing ja Leistungsverschwendung ist. ;) Es ist gut, dass schlaue Köpfe uns die Entscheidungen abnehmen und Innovationen vorantreiben. Downgraden kann man dann immer noch.

MfG
Raff

Den Zusamenhang darfst du mir jetzt gerne erklären, denn Raytracing ist eine völlig andere Baustelle. Da gibt es auch keinen Vedor lock oder dergleichen, das wird über offene APIs unterstützt und jeder kann es supporten wenn er möchte (egal wie schnell). Das ist eigentlich ein Argument für mich ;)

Raff

2023-11-28, 09:42:03

Der Zusammenhang: Kunden - also wir - sollten nicht entscheiden, was wie und wann implementiert wird, denn da fehlen Visionen. Wer hätte beispielsweise vor fünf Jahren gesagt, dass wir jetzt beim Raytracing so weit sein würden? Wer hätte 2010, als Nvidia ständig von "Deep Learning" gefaselt hat, vorausgesagt, dass nun so eine Welle über die Gesellschaft rennt?

MfG
Raff

fondness

2023-11-28, 09:58:05

Deisi

2023-11-28, 10:08:39

Ohne Vendor-Lock und closed Source fehlen Visionen? Eine spannende Theorie :D. Ich würde es mal so formulieren: Hätte wir funktionierende Monopol-Gesetze, dürfte ein Unternehmen das an den 80% Weltmarktanteil kratzt definitiv keine Vendor-Locked und closed source "Produkte" launchen. Leute die das auch noch verteidigen erinnern mich immer an den Typen der den Ast absägt auf dem er sitzt.

Die meisten Unternehmen entwickeln neue Tech doch primär um sie zu verkaufen und nicht für das Allgemeinwohl. Ist zwar schlechter für die Kunden, aber die Motivation von Unternehmen viel Geld in OpenSource zu stecken dürfte deutlich geringer sein.

dargo

2023-11-28, 10:11:47

Der Zusammenhang: Kunden - also wir - sollten nicht entscheiden, was wie und wann implementiert wird, denn da fehlen Visionen. Wer hätte beispielsweise vor fünf Jahren gesagt, dass wir jetzt beim Raytracing so weit sein würden?
:lol:

Tut mir leid, aber beim Thema Raytracing sind wir immer noch am Anfang der sehr langen Reise, und das nach >5 Jahren seit Einführung von Turing. Dass immer noch nichts mit Mindestanforderung HW-RT bei Games von den Publishern released wird ist eine eindeutige Sprache. Ich frage mich echt wann du und so manch anderer das begreifen. Im übrigen war sich Nvidia vor einiger Zeit nicht zu schade raus zu posaunen 2023 wäre das Jahr wo Games mit HW-RT als Mindestvoraussetzung kommen, sprich... ohne HW-RT läuft Game XYZ erst gar nicht. Was daraus geworden ist sieht man ja. ;)

Ganon

2023-11-28, 10:15:48

Wer hätte beispielsweise vor fünf Jahren gesagt, dass wir jetzt beim Raytracing so weit sein würden? Wer hätte 2010, als Nvidia ständig von "Deep Learning" gefaselt hat, vorausgesagt, dass nun so eine Welle über die Gesellschaft rennt?

Sie haben sich auch sehr viel Mühe gegeben die Konkurrenz an der Stelle klein zu halten, damit sie dort Vorreiter sind.

Das ging schon damit los, dass sie als Marktführer OpenCL nicht vollständig implementiert haben und damit zwangsläufig die Grundlagen über Nvidia APIs laufen mussten. Ab da ging es dann nur aufwärts... für Nvidia. Die Konkurrenz hatte an der Stelle keine Chance, vollkommen unabhängig davon wie viel besser sie dort ggf. gewesen wäre.

Das ist auch nicht weit weg von dem was Intel damals so alles getan hat, um Marktführer zu bleiben. Ist für den Kunden und für den Fortschritt allgemein am Ende nur schlecht, auch wenn ein kleiner Peak in einer kurzen Zeit was anderes vermuten lässt.

The_Invisible

2023-11-28, 11:03:35

:lol:

Tut mir leid, aber beim Thema Raytracing sind wir immer noch am Anfang der sehr langen Reise, und das nach >5 Jahren seit Einführung von Turing. Dass immer noch nichts mit Mindestanforderung HW-RT bei Games von den Publishern released wird ist eine eindeutige Sprache. Ich frage mich echt wann du und so manch anderer das begreifen. Im übrigen war sich Nvidia vor einiger Zeit nicht zu schade raus zu posaunen 2023 wäre das Jahr wo Games mit HW-RT als Mindestvoraussetzung kommen, sprich... ohne HW-RT läuft Game XYZ erst gar nicht. Was daraus geworden ist sieht man ja. ;)

Was hast du immer mit deiner Mindestvorraussetzung, sieh dir mal an wie langsam das alles in Raster vorwärts geht/ging. Immer das gleiche Geheule hier, RT/PT erst gut wenn perfekt, Raster darf aber jahrzehntelang dahinvegetieren... UE5 hat Raytracing standardmäßig drinnen (egal ob Software oder Hardware), wir sind also schon längst mittendrinnen aber manche merken das anscheinend noch immer nicht...

dargo

2023-11-28, 11:20:47

Was hast du immer mit deiner Mindestvorraussetzung, sieh dir mal an wie langsam das alles in Raster vorwärts geht/ging. Immer das gleiche Geheule hier, RT/PT erst gut wenn perfekt, Raster darf aber jahrzehntelang dahinvegetieren... UE5 hat Raytracing standardmäßig drinnen (egal ob Software oder Hardware), wir sind also schon längst mittendrinnen aber manche merken das anscheinend noch immer nicht...
Vielleicht mal mehr im Kontext lesen und verstehen bevor du wieder Schaum vor dem Mund bekommst? Ich sprach von HW-RT! SW-RT der UE5 finde ich übrigens eine brauchbare Übergangslösung denn die Kosten sind noch relativ überschaubar. Letzteres aber auch nur dank TSR. An der UE5 wird aber immer noch optimiert, kann also nur noch besser werden. Wenn ich es richtig verstanden habe ist das Ziel 60fps bei den Konsolen. Wird man dieses Ziel erreichen profitieren automatisch auch PC-Spieler davon.

Gast

2023-11-28, 11:30:58

Würde man also reines ALU-Compute machen, müsste man den Aufwand reduzieren. Leider ist das von außen schwer nachprüfbar.

Schwer nachprüfbar, aber zumindest das Verhalten des ähnlich arbeitenden XeSS, dass auf GPUs ohne unterstützte Matrixcores deutlich langsamer läuft obwohl es ein deutlich reduziertes NN verwendet welches auch für sichtbare Qualitätseinbußen sorgt ist schon ein starkes Indiz dass an Nvidias Aussage was dran ist.

DLSS mit 1:1 Qualität dürfte wohl tatsächlich nicht sinnvoll umsetzbar sein, ein Weg wie Intel mit reduziertem NN dass trotzdem noch eine annehmbare Performance bei akzeptabler Qualität zeigt evtl. schon, aber das würde die Marke DLSS als hochqualitatives Upsampling nachhaltig schädigen.

Gast

2023-11-28, 11:41:30

Wieso geht man bei AMD den Open Source Weg und nicht den DX12-Weg? Wäre man nicht deutlich erfolgreicher wenn die eigene Technologie in DX12 eingebettet wäre? Oder bietet DX12 keine fertigen Bibliotheken an?

Was hat ein Upsamplingalgorithmus in DX12 zu suchen?
Das wäre ja als wenn man einen Texturfilter direkt in DX implementieren würde, das ist irgendwie die falsche Baustelle.

basix

2023-11-28, 22:55:54

Nvidias Narrativ ist: Diese (den anderen Verfahren überlegene) Qualität geht nur, weil die Tensor-Kerne das flott berechnen. Würde man also reines ALU-Compute machen, müsste man den Aufwand reduzieren. Leider ist das von außen schwer nachprüfbar.
Schwer nachprüfbar, aber zumindest das Verhalten des ähnlich arbeitenden XeSS, dass auf GPUs ohne unterstützte Matrixcores deutlich langsamer läuft obwohl es ein deutlich reduziertes NN verwendet welches auch für sichtbare Qualitätseinbußen sorgt ist schon ein starkes Indiz dass an Nvidias Aussage was dran ist.

DLSS mit 1:1 Qualität dürfte wohl tatsächlich nicht sinnvoll umsetzbar sein, ein Weg wie Intel mit reduziertem NN dass trotzdem noch eine annehmbare Performance bei akzeptabler Qualität zeigt evtl. schon, aber das würde die Marke DLSS als hochqualitatives Upsampling nachhaltig schädigen.

Ich hatte mal 0.15ms pro Frame für DLSS ausgemessen (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13285616#post13285616). Mit ~50% peak Auslastung. Macht auf einer 4090 & FP16 ~25 GFLOP (ohne "S") oder 50 GOP INT8. Nimmt man die ~100 TOPS einer 7900 XTX, landet man bei ~0.5ms. Klar, wird real noch etwas mehr sein und DLSS besteht aus mehr als nur DNN via Tensor. Doch genau dieser Teil ist deutlich grösser als der DNN Teil und würde auf einer RDNA Karte etwa so schnell laufen wie auf einer sonst vergleichbar schnellen Turing/Ampere/Ada Karte (=Compute Shader). Ich würde schätzen, dass DLSS2 auf einer 7900XTX ähnlich schnell oder eher sogar schneller läuft als auf einer 2080 Ti ;) Das wäre einiges langsamer als FSR2 (ca. 2-3x langsamer oder +1...2ms pro Frame in 4K) aber bei weitem nicht unbrauchbar.

Was hat ein Upsamplingalgorithmus in DX12 zu suchen?
Das wäre ja als wenn man einen Texturfilter direkt in DX implementieren würde, das ist irgendwie die falsche Baustelle.
Nein, das Verfahren gehört nicht in DX12, ausser es würde als HW-FF abgebildet werden (was wenig Sinn macht). Aber die APIs und Schnittstellen gehören schon dorthin. Dort hat es vor ein paar Wochen / Monaten ein Update gegeben: Matrix-Befehle in DX12. Dann kann das via Tensor Cores, Matrix Cores oder WMMA / "Shader" laufen. Gut wäre noch was wie Motion Vectors Formate oder so. Wenn sowas standardisiert würde (wenn man das kann?), würde es die Implementationen robuster machen.

TheAntitheist

2023-11-28, 23:01:58

Nvidias Narrativ ist: Diese (den anderen Verfahren überlegene) Qualität geht nur, weil die Tensor-Kerne das flott berechnen. Würde man also reines ALU-Compute machen, müsste man den Aufwand reduzieren. Leider ist das von außen schwer nachprüfbar.

MfG
Raff
wurde doch schon nachgeprüft mit den GPUs die DLSS ausführen konnten ohne tensor cores zu haben... also was du schreibst stimmt einfach nciht.

TheAntitheist

2023-11-28, 23:04:46

Ohne Vendor-Lock und closed Source fehlen Visionen? Eine spannende Theorie :D. Ich würde es mal so formulieren: Hätte wir funktionierende Monopol-Gesetze, dürfte ein Unternehmen das an den 80% Weltmarktanteil kratzt definitiv keine Vendor-Locked und closed source "Produkte" launchen. Leute die das auch noch verteidigen erinnern mich immer an den Typen der den Ast absägt auf dem er sitzt.
warum sollte man als Firma Milliarden in zB DLSS stecken, damit die Konkurrenz dann davon profitiert? Das macht keinen Sinn..

AMD hat ja auch keine Opensource Hardware

DrFreaK666

2023-11-28, 23:26:08

warum sollte man als Firma Milliarden in zB DLSS stecken, damit die Konkurrenz dann davon profitiert? Das macht keinen Sinn..

Erzähl das mal Intel

Raff

2023-11-29, 01:02:32

wurde doch schon nachgeprüft mit den GPUs die DLSS ausführen konnten ohne tensor cores zu haben... also was du schreibst stimmt einfach nciht.

"Nachgeprüft", also bewiesen, ist das erst, wenn man denselben Workload gezielt einmal über die Tensoren und einmal über die ALUs laufen lassen kann. Alles andere ist Stochern im Nebel und befeuert Verschwörungstheorien bzw. Aggressionen. ;) Das gilt übrigens auch für Frame Gen. Nvidia hat nie bestritten, dass man das auch für Ampere & Co. bringen könnte, nannte aber von Anfang an die Qualität als KO-Kriterium. Wenn, dann richtig alias "Es muss gut genug aussehen, ansonsten kann man es sich sparen". In den meisten Fällen geht das Konzept auf. Aber eben nicht überall. Und jetzt stelle man sich vor, es sähe schlechter aus oder würde noch stärker laggen. Was will man mit einem Feature, das zu hässlich oder schwammig ist, um es zu nutzen?

Erzähl das mal Intel

Deren Herangehensweise der Sorte "Die Wettbewerber bekommen nur die Demo, unsere eigenen Produkte die Vollversion" ist interessant und hat eigene Vor- wie Nachteile. Dass bereits DP4a-XeSS in vielen Fällen bessere Ergebnisse als FSR 2 erzielt, sollte aber zu denken geben. Ist an den KI-Geschichten doch etwas dran? Rhetorische Frage. ;)

MfG
Raff

robbitop

2023-11-29, 09:14:00

AMD zeigt ja dass Optical Flow auch über compute geht. Dass deren Frame Pacing kaputt ist hat allerdings mit dem reinen Optical Flow Compute nichts zu tun. Ampere hat ja sogar einen Optical Flow Accelerator und ich bin mal gespannt, wann Nintendo Spiele das auf der Switch 2 (mit Ampere IP) das nutzen wird.

Basix' Blick auf nsight gibt auch klare Indizien, dass DLSS auch noch nutzbar ohne Matrix FPUs ist. TOPs sind TOPs ob jetzt Vektor FPUs oder Matrix FPUs.

DrFreaK666

2023-11-29, 09:30:56

...ich bin mal gespannt, wann Nintendo Spiele das auf der Switch 2 (mit Ampere IP) das nutzen wird...

Welchen Sinn soll das haben? Die Switch 2 wird sicherlich nicht als 120FPS Konsole vermarktet

robbitop

2023-11-29, 09:34:45

Welchen Sinn soll das haben? Die Switch 2 wird sicherlich nicht als 120FPS Konsole vermarktet
Spieleentwickler wählen nicht immer sinnvolle Targets. Ich kann mir gut vorstellen, dass es auch (ggf. wenige) Spiele geben wird, die von 30 auf 60 fps hoch samplen. Auch wenn das nicht unbedingt sinnvoll ist.
Und wer weiß, was für ein Display die Switch hat - ggf. kann es auch auf verschiedenen Hz Raten betrieben werden. Zum Beispiel auf 90 Hz wo man dann von 45 fps auf 90 fps eine Verdopplung machen kann. Oder von 40 auf 80 fps mit einem 80 Hz Display.

Gast

2023-11-29, 09:39:18

Ich hatte mal 0.15ms pro Frame für DLSS ausgemessen (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13285616#post13285616). Mit ~50% peak Auslastung. Macht auf einer 4090 & FP16 ~25 GFLOP (ohne "S") oder 50 GOP INT8.

Ohne genaueres Wissen über den Algorithmus und was da genau abläuft ist eine reine Umrechnung nach theoretischen OPS höchstwahrscheinlich ziemlich fehlerbehaftet. Ich kann mich an eine Intel-Folie erinnern, in der sie XeSS mit und ohne XMX vergleichen und der Unterschied war enorm. Klar hat hier auch Intel Interesse die Vorzüge von XMX zu präsentieren, aber so einfach, dass die Tensor Cores eh nur 0,15ms beschäftigt sind, also wäre es auch ohne schnell genug kann man es sich definitiv auch nicht machen.
Dazu kommt auch noch, dass die Tensorcores beim Gaming ansonsten nix zu tun haben und das Ganze quasi "gratis" nebenher machen.

Ohne dass Nvidia uns eine non Tensor Version zum testen gibt wird das immer ein Stochern im Nebel bleiben. Wie gesagt das nächste was wir tatsächlich testen können ist was uns Intel anbietet, und hier sind die Unterschiede sowohl bei der Performance als auch bei der Qualität erheblich.

Nein, das Verfahren gehört nicht in DX12, ausser es würde als HW-FF abgebildet werden (was wenig Sinn macht). Aber die APIs und Schnittstellen gehören schon dorthin.

Ja eben, sowas wie Streamline als Teil von DX würde sinnvoll sein, aber nicht die Algorithmen selbst.

DrFreaK666

2023-11-29, 09:39:41

Spieleentwickler wählen nicht immer sinnvolle Targets. Ich kann mir gut vorstellen, dass es auch (ggf. wenige) Spiele geben wird, die von 30 auf 60 fps hoch samplen. Auch wenn das nicht unbedingt sinnvoll ist.
Und wer weiß, was für ein Display die Switch hat - ggf. kann es auch auf verschiedenen Hz Raten betrieben werden. Zum Beispiel auf 90 Hz wo man dann von 45 fps auf 90 fps eine Verdopplung machen kann. Oder von 40 auf 80 fps mit einem 80 Hz Display.

Nintendo schaut bestimmt, dass man echte 60FPS erreicht nicht 40FPS-75FPS. Niemand will ein Mario mit 40FPS spielen, ein F-Zero erst recht nicht.
Ich glaube FG wird man da kaum sehen

Gast

2023-11-29, 09:39:58

wurde doch schon nachgeprüft mit den GPUs die DLSS ausführen konnten ohne tensor cores zu haben... also was du schreibst stimmt einfach nciht.

Konnten sie nicht, man konnte scheinbar DLSS aktivieren, es war aber nicht wirklich aktiv.

Gast

2023-11-29, 09:54:31

Ampere hat ja sogar einen Optical Flow Accelerator und ich bin mal gespannt, wann Nintendo Spiele das auf der Switch 2 (mit Ampere IP) das nutzen wird.

Ziemlich sicher gar nicht, da die Switch-Spiele generell für eine zu niedrige Framerate ausgelegt sind um FG sinnvoll zu nutzen.

Aber selbst wenn man mit FG plant, die Switch 2 wird ein echtes Custom Design bekommen und der OFA ist ein unabhängiger Baustein, denn man dafür ausreichend dimensionieren könnte, selbst wenn der Grafikteil auf Ampere-Technik basiert.

The_Invisible

2023-11-29, 10:04:20

Nintendo schaut bestimmt, dass man echte 60FPS erreicht nicht 40FPS-75FPS. Niemand will ein Mario mit 40FPS spielen, ein F-Zero erst recht nicht.
Ich glaube FG wird man da kaum sehen

Wenn DLSS-Upscaling/FG auf alle Hardware verfügbar ist wird das auch genutzt. Gerade hier wird es interessant weil quasi das erste mal gutes Hardware Upscaling/FG in einer Konsole verfügbar ist, von demher ist man rein featuretechnisch dann sogar PS5/XBox voraus.

DrFreaK666

2023-11-29, 10:14:55

Wenn DLSS-Upscaling/FG auf alle Hardware verfügbar ist wird das auch genutzt...

Dann wird es nicht genutzt, denn die API der PS5 heißt nicht DX12 und Sony scheint immer noch nicht an was eigenem zu arbeiten.
Andererseits ist FSR3 open source. Abwarten. Die Xbox wird aber eher kompatibel sein

robbitop

2023-11-29, 11:07:02

Nintendo schaut bestimmt, dass man echte 60FPS erreicht nicht 40FPS-75FPS. Niemand will ein Mario mit 40FPS spielen, ein F-Zero erst recht nicht.
Ich glaube FG wird man da kaum sehen
Es gibt aber nicht nur first party Titel. Die Switch hat >4500 Spiele. Und da gibts genug Kram, der merkwürdige Settings wählt.
Außerdem kann je nach Spieltyp auch schon 40@80 oder 45@90 fps (gerade am Gamepad) noch sinnvoll sein.

DrFreaK666

2023-11-29, 11:11:27

Das wird zu OT.
Gerne hier weiter
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13440575#post13440575

Dann kannst mir vielleicht erläutern, was du mit "merkwürdige Settings" meinst

robbitop

2023-11-29, 11:11:54

Ohne genaueres Wissen über den Algorithmus und was da genau abläuft ist eine reine Umrechnung nach theoretischen OPS höchstwahrscheinlich ziemlich fehlerbehaftet. Ich kann mich an eine Intel-Folie erinnern, in der sie XeSS mit und ohne XMX vergleichen und der Unterschied war enorm. Klar hat hier auch Intel Interesse die Vorzüge von XMX zu präsentieren, aber so einfach, dass die Tensor Cores eh nur 0,15ms beschäftigt sind, also wäre es auch ohne schnell genug kann man es sich definitiv auch nicht machen.
Dazu kommt auch noch, dass die Tensorcores beim Gaming ansonsten nix zu tun haben und das Ganze quasi "gratis" nebenher machen.

Was genau spricht denn dagegen, Tensorcore Rechenzeit in Vektorcore Rechenzeit umzurechnen? Gibt es Usecases wo ein Tensorcore effizienter mit den TOPS umgeht als eine Vektor FPU? Und wenn ja warum?

Und Intel ist sicherlich auch ein Datenpunkt - aber man kennt es ja auch von genug Beispielen, dass es eine große Bandbreite an Effizienz von Algorithmen und neuronalen Netzwerken gibt oder Code im Allgemeinen gibt.

Den Datenpunkt in nsight kann man IMO ohne konkrete Begründung mit einem Fallbeispiel oder einer konkreten Begründung warum das nicht geht nicht wegdiskutieren. Welches Szenario genau kann dazu führen, dass ein Tensorcore mehr pro TOP rausholt als eine Vector FPU?
Wenn dann hätte ich eher die gegenteilige Annahme getroffen. Begründung: Je breiter eine ausführende Einheit, desto ineffizienter wird es ja meistens.

Ich wüsste sehr gern warum das Gegenteil der Fall sein kann (nicht muss - weil wir ja alle nicht in NVs Code schauen können). Aber Fallbeispiele sollte es dazu doch geben, wenn man diese Annahme trifft.

robbitop

2023-11-29, 11:15:50

Ziemlich sicher gar nicht, da die Switch-Spiele generell für eine zu niedrige Framerate ausgelegt sind um FG sinnvoll zu nutzen.

Aber selbst wenn man mit FG plant, die Switch 2 wird ein echtes Custom Design bekommen und der OFA ist ein unabhängiger Baustein, denn man dafür ausreichend dimensionieren könnte, selbst wenn der Grafikteil auf Ampere-Technik basiert.
Ich bin da noch sehr skeptisch. Für mich sieht es auch etwas verdächtig nach Produktsegmentierung aus. Ada ist extrem teuer pro Performance und das ist natürlich rein zufällig ein unique selling point. Und warum sollte man bei Ampere einen OFA einbauen, der dann immer zu schwach ist? Ggf. gibt es Auflösungs / Frameratenkonfigurationen, bei denen es doch passt. Und wie gesagt, zeigt AMD ja, dass es auch über compute geht (was nichts mit dem kaputten framepacing von FSR 3 zu tun hat).

Und siehe obige Beispiele. 40@80 oder 45@90. Je nach Display (höhere Refreshrate und mehrere Settings möglich) und Spiel kann das schon funktionieren. Und wie gesagt gibt es genug 3rd party Games mit merkwürdigen Settings dass das schon auch sein kann.

Gast

2023-11-29, 11:50:24

Was genau spricht denn dagegen, Tensorcore Rechenzeit in Vektorcore Rechenzeit umzurechnen? Gibt es Usecases wo ein Tensorcore effizienter mit den TOPS umgeht als eine Vektor FPU? Und wenn ja warum?

Datenlokalität. Da der Tensorcore immer mit einer gesamten Matrix arbeitet könnten die notwendigen Speicherzugriffe (sowie auch auf all die anderen Zwischenspeicher wie Caches und Register) effizienter sein.

Wir wissen auch nicht wie viel Sparsity beim von NV verwendeten Algorithmus hilft, auch wenn das im Gegensatz zu den Marketingfolien nicht die Rechenleistung erhöht sondern unnötige Berechnungen vermeidet müssen die Vector-Cores diese in jedem Fall durchführen bzw. wäre es teurer diese zu vermeiden.

Gast

2023-11-29, 12:01:25

Und siehe obige Beispiele. 40@80 oder 45@90. Je nach Display (höhere Refreshrate und mehrere Settings möglich) und Spiel kann das schon funktionieren.

Viel zu wenig, das einzige was halbwegs sinnvoll wäre ist 60-->120.

Dazu müsste man der Switch2 aber auch erstmal ein entsprechendes Display verbauen.

robbitop

2023-11-29, 12:08:40

Datenlokalität. Da der Tensorcore immer mit einer gesamten Matrix arbeitet könnten die notwendigen Speicherzugriffe (sowie auch auf all die anderen Zwischenspeicher wie Caches und Register) effizienter sein.
Die Register und Caches bei RDNA3 sind nicht gerade klein pro CU. Gibt es da Beispiele aus der Praxis die ein solches Verhalten (bei Matrixberechnung deutlich schwächer auf den Vektor FPUs) zeigen?
Und wenn doch gibt es doch sicherlich genug threads in flight um die Auslastung oben zu halten oder?

Wir wissen auch nicht wie viel Sparsity beim von NV verwendeten Algorithmus hilft, auch wenn das im Gegensatz zu den Marketingfolien nicht die Rechenleistung erhöht sondern unnötige Berechnungen vermeidet müssen die Vector-Cores diese in jedem Fall durchführen bzw. wäre es teurer diese zu vermeiden.
Turing hatte IIRC noch kein Sparsity und zumindest die Benchmarks die ich mir mal angeschaut hatte (auf die reinen Performancekosten pro Frame) hatten da keinen großen Unterschied zu Ampere gezeigt.

robbitop

2023-11-29, 12:14:33

Viel zu wenig, das einzige was halbwegs sinnvoll wäre ist 60-->120.
Ich habe leider keine Ada um das zu simulieren. Aber ich habe aus der Community auch schon einige gelesen, die bei manchen Spielen schon Vorteile mit ~40...45 FPS als input gesehen haben.
Dazu muss man sagen:
1.) Joypad statt M/T als Input macht Inputlag massiv weniger problematisch
2.) Es ist ein handheld - man sieht also auch die Schwächen etwas weniger
3.) Der 0815 Nutzer sind nicht wir Nerds oder Digital Foundry sondern irgendwelche 0815 Leute oder 0815 Kinder. Die haben ganz andere Ansprüche.
Ich glaube man muss auch mal ein Stück weg aus seiner Filterblase schauen. ;)

Dazu müsste man der Switch2 aber auch erstmal ein entsprechendes Display verbauen.
Ja absolut. Allerdings sind 90 Hz Displays jetzt auch keine starke Besonderheit mehr. Und die kann man beliebig zwischen ~ 30 und 90 Hz (auch ohne VRR) betreiben.
Entsprechend hat man (auch ohne FG) mehr Freiheit sein Spiel auf ein jeweiliges Performancetarget zu tunen. Schafft man die 60 fps nicht, will aber auch nicht 30 fps liefern? Nun es gäbe entsprechend die Möglichkeit 30 Zwischenstufen zwischen beidem zu wählen für den Entwickler.
Das ist doch schonmal ein Mehrwert.

Ob Nintendo das tut? Keine Ahnung - klingt nicht nach Nintendo. Allerdings ist ein moderner Nvidia custom Chip auch nicht unbedingt das was man Nintendo historisch gesehen zugetraut hätte, da sie lieber merkwüridge und oder billig yesteryear HW verbaut haben seit langem.
Wenn es nur 60 Hz sind - ja dann macht es noch weniger Sinn mit FG. Das hat DF ja schon zu Genüge in mehreren Podcasts diskutiert und damit gehe ich auch konform.

The_Invisible

2023-11-29, 12:37:28

Dann wird es nicht genutzt, denn die API der PS5 heißt nicht DX12 und Sony scheint immer noch nicht an was eigenem zu arbeiten.
Andererseits ist FSR3 open source. Abwarten. Die Xbox wird aber eher kompatibel sein

Meinte damit die ganze Switch2 Lineup, wenn sich die ähnlich gut verkauft wie Switch 1 hat man mehr Hardware draußen als PS5/Xbox zusammen. Zudem nutzt Nintendo FirstParty eigentlich immer alle Features was gibt.

@robbitop
Jap, selbst AlanWake2 ging an manchen Stellen im Wald auf (mit FG) 6xfps runter, war für mich aber problemlos spielbar obwohl dort auch Shooter Einlagen sind. Zumindest wenn es etwas ähnliches wie Reflex/Antilag auch auf Switch gibt wovon ich ausgehe

aufkrawall

2023-11-29, 12:44:31

Andererseits ist FSR3 open source.
Bislang noch nicht.

robbitop

2023-11-29, 12:50:22

@robbitop
Jap, selbst AlanWake2 ging an manchen Stellen im Wald auf (mit FG) 6xfps runter, war für mich aber problemlos spielbar obwohl dort auch Shooter Einlagen sind. Zumindest wenn es etwas ähnliches wie Reflex/Antilag auch auf Switch gibt wovon ich ausgehe
Danke für die Bestätigung. Dachte ich mir doch. Und auf einem Handheld ist sowas noch weniger sichtbar.

Gast

2023-11-29, 12:54:15

Ich habe leider keine Ada um das zu simulieren.

Ich schon und ich kann dir sagen, selbst 60-->120 ist grenzwertig, erst 70-80 Base-FPS sind wirklich sorgenfrei für FG.

aufkrawall

2023-11-29, 13:22:53

Tesseract

2023-11-29, 13:23:30

als ob der lag auf einem handheld ohne maus so eine große rolle spielen würde. da könnte man wahrscheinlich auch auf 30fps FG drauf klatschen und 99% der user würden es als deutliches upgrade empfinden. das ist jetzt nicht abwertend gemeint aber sowohl ausgangslage als auch inputmethoden sind da völlig andere.

in einem stark vom power budget limitieren handheld sind sowohl upscaler als auch FG quasi cheatcodes.

DrFreaK666

2023-11-29, 13:24:46

Ganz ehrlich: Ich hab den Switch2-Link nicht zum Spaß gepostet! Und es muss auch nicht schon wieder ein Mod eingreifen, oder etwa doch?
Also hier gehts mit der Switch 2 weiter:
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13444427#post13444427

Wir sind im AMD FSR2/3 Thread

The_Invisible

2023-11-29, 13:35:44

Kommt drauf an. Wenn DLSS FG Fälle noch besser handhaben würde, in denen nach plötzlicher Änderung des Bildinhaltes, wie das Anzeigen von Menüs wie einer Karte, des Inventars etc., die Frame Time-Varianz nicht mehr so fett werden würde, wären auch 50fps als Basis für SP-Spiele noch "ok". Aber wenn man das in manchen Spielen ständig macht, nervt es im aktuellen Zustand schon.

Theorie vs Praxis... wenn ich CP2077 und AW2 mit Drops auf 6x durchspielen kann hat es den Test bestanden. Wenn jemand >100fps braucht bitte gerne, machbar ist es aber auch mit deutlich weniger.

aufkrawall

2023-11-29, 13:38:04

Nur muss deine Praxis nicht unbedingt die anderer sein, das Verhalten ist nun mal da. Logischerweise würde es den Anteil an Leuten, die es dann noch stört, deutlich reduzieren.

robbitop

2023-11-29, 14:02:07

Ich schon und ich kann dir sagen, selbst 60-->120 ist grenzwertig, erst 70-80 Base-FPS sind wirklich sorgenfrei für FG.
Du entsprichst aber anscheinend nicht den Kriterien die ich genannt habe:

1. Gamepad
2. kein 0815 Typ sondern einer von uns Nerds - wahrscheinlich extrem verwöhnt von feinster High End HW (was schon ganz andere Grundvoraussetzungen schafft als zB das 30 fps Erlebnis auf der Switch was dessen Spielerschaft OK findet)
3. kein Handheld

Und wie gesagt: hier gab es gerade Feedback von jemandem der es okay findet bei Alan Wake 2. ;)

Ich persönlich sehe es wie du - mir ist aber auch klar, dass unsere Hardware und Ansprüche komplett anders sind als von den typischen Switch Kunden. ;)

als ob der lag auf einem handheld ohne maus so eine große rolle spielen würde. da könnte man wahrscheinlich auch auf 30fps FG drauf klatschen und 99% der user würden es als deutliches upgrade empfinden. das ist jetzt nicht abwertend gemeint aber sowohl ausgangslage als auch inputmethoden sind da völlig andere.

in einem stark vom power budget limitieren handheld sind sowohl upscaler als auch FG quasi cheatcodes.
This :up:
Auch wenn FG zugegeben etwas eingeschränkte Usecases hat und stark abhängig vom verbauten Display sein wird.

The_Invisible

2023-11-29, 14:10:29

Der durchschnittliche Switch User spielt auch Games bei 2xfps mit MickeyMaus Auflösung und meckert nicht (viel). Das irgendwie mit Highend PC-Hardware und >100fps zu vergleichen ist schon hart :D

Zudem es hier auch schon einige User gab die mit AFMF und 60-70fps keine Probleme hatten also muss schon was dran sein.

Lurtz

2023-11-29, 14:27:16

Kommt drauf an. Wenn DLSS FG Fälle noch besser handhaben würde, in denen nach plötzlicher Änderung des Bildinhaltes, wie das Anzeigen von Menüs wie einer Karte, des Inventars etc., die Frame Time-Varianz nicht mehr so fett werden würde, wären auch 50fps als Basis für SP-Spiele noch "ok". Aber wenn man das in manchen Spielen ständig macht, nervt es im aktuellen Zustand schon.
Ist das bei Alan Wake 2 eigentlich gefixt? Da gabs ja bei jedem Cut zu den Filmsezenen einen heftigen Frametimes-Ruckler, das stand mittlerweile aber in den Patch Notes als behoben.

aufkrawall

2023-11-29, 14:37:26

Ist das bei Alan Wake 2 eigentlich gefixt? Da gabs ja bei jedem Cut zu den Filmsezenen einen heftigen Frametimes-Ruckler, das stand mittlerweile aber in den Patch Notes als behoben.
Lag das an FG? Dass der Graph fett wird, gibts ja mitunter auch ohne Spikes. Bei AW2 bin ich außen vor.

Lurtz

2023-11-29, 16:53:39

Hm, hast recht, es spiket in den Szenen auch ohne FG ein wenig, aber anders :ugly:

aufkrawall

2023-12-01, 18:10:40

Sons of the Forest hat FSR 2 bekommen. Sieht nicht wirklich gut aus, aber immer noch bedeutend angenehmer als das Unity-TAA. :freak:

mksn7

2023-12-05, 13:00:24

Datenlokalität. Da der Tensorcore immer mit einer gesamten Matrix arbeitet könnten die notwendigen Speicherzugriffe (sowie auch auf all die anderen Zwischenspeicher wie Caches und Register) effizienter sein.

Die Zugriffe auf Register sind bei Matrixoperationen effizienter, da jeder Registerzugriff gleich mehrfach verwendet wird. Das ist der einzige Grund warum für Matrixoperationen so hohe Rechenleistung verbaut werden kann. Für gleich viele Vektorrecheneinheiten wäre nicht die Registerbandbreite da.

Was sich nicht ändert ist wie die Daten in die Register reinkommen. Mittels Matrixoperationen können wesentlich mehr Daten verarbeitet werden, und die werden über die gleichen load/store units mit der gleichen L1 cache Bandbreite geladen. Es ist definitiv schwieriger die Tensorcores auszulasten als die normalen Vektorrecheneinheite, selbst für sowas dankbares wie Matrixmultiplikation.

robbitop

2023-12-05, 13:14:05

Also könnte man es doch halbwegs so umrechnen? TOPS Matrix Units zu TOPS Vektor FPUs.

mksn7

2023-12-05, 13:54:14

Ich bin mir gerade nicht gaaaanz sicher, ob nicht die Einschränkungen bei der Registerbandbreite bei RDNA3 und Ampere die dual ops/issue verhindern... Bei RDNA3 erzeugt der Compiler aber dual_fmacs für einen matmul Kernel, und bei Ampere müsste das auch klappen.

Aber sonst ja. Die Vektor TOPs sind mindestens so gut wie die Matrix TOPs.

robbitop

2023-12-05, 15:08:37

Was wiederum bedeutet, dass basix' Annahme, dass DLSS (basierend auf der Frametime auf den TCs mittels nsight) auf den Vektor FPUs in gewissen Grenzen sogar sinnvoll einsetzbar wäre gar nicht mal sooo weit hergeholt ist.

basix

2023-12-05, 20:04:58

Man muss auch bedenken, dass ich eine 2080 Ti ungefähr mit einer 7900 XT(X) gleichsetzen würde, falls man DLSS rechnen könnte. Letzere ist die deutlich mächtigere GPU. Die Tensor Cores haben schon ihren Wert. Sobald man auf der N31 Karte WMMA nutzt, müsste es mMn aber sowieso in anständiger Zeit funktionieren. Hier kann N31 mit ca. 50% der Peak INT8 TOPS von TU102 aufwarten. Dazu von RDNA2 ausgehend grössere gewordene L0/L1 Caches sowie Register (Turing = 256kB/SM; RDNA3 = 384kB/CU -> N31 hat total 2x Register-Kapazität von TU102 192kB/WGP -> N31 hat total 50% Register Kapazität von TU102, was in etwa zu den 50% max. INT8 TOPS passen würde) und mehr Speicher- & Cache-Bandbreite. RDNA3's LDS ist latenzmässig ausserdem deutlich schneller geworden, wo Nvidia seit Turing mit dem L1 schon Vorteile hatte (oder noch hat wenn man es mit L0/L1 von RDNA3 vergleicht).

Das DNN kann auf der 2080 Ti immer noch schneller laufen (und würde mich nicht wundern). Dafür läuft der zweite Teil von DLSS (Compute) deutlich schneller auf der 7900 XTX. Unter dem Strich: Könnte auf einen Gleichstand rauslaufen. Macht ca. 2ms Berechnungszeit in 4K aus (2080 Ti soll in etwa so lange für DLSS2 benötigen, sind Angaben von Nvidia). FSR2 liegt bei 0.7ms auf einer 79000 XTX.

Aber egal: AMD soll einfach an FSR2/3 weiterarbeiten und verbessern. Mit oder ohne DNN spielt für mich keine Rolle, TSR der UE5 macht auch eine gute Figur. Dass DLSS auf non-Nvidia laufen wird: Im nächsten Leben. Oder wenn das "zwingende" Verkaufsargument wegfällt, weil DLSS2 keine Vorteile gegenüber der Konkurrenz bietet (siehe G-Sync), was momentan nicht der Fall ist ;)

fondness

2023-12-06, 13:06:47

Denn in Avatar: Frontiers of Pandora (Test) ist FSR 3 Frame Generation nicht mehr wiederzuerkennen und zeigt sich an allen Fronten deutlich verbessert. In dieser Form hätte Frame Generation von Anfang an erscheinen sollen – es hätte der Technologie, die auf vielen Radeon, GeForce und Arc läuft, viel Lob eingebracht. Natürlich wird sich noch zeigen müssen, ob dies nun die Ausnahme gewesen ist, auch weil AMD als Technik- und Bundle-Partner viel Zeit und Geld investiert haben dürfte, oder dieser Zustand die neue Regel wird. Doch davon unabhängig hätte Avatar mit FSR 3 inklusive FMF der Technologie erst mal den roten Teppich ausgerollt, anstatt mit Forspoken und Immortals of Aveum alle Brücken der Erwartungen vorerst einzureißen.

Zwei Monate später ist AMDs Frame Generation in Avatar durchaus als absolut ebenbürtig zu Nvidias DLSS Frame Generation zu bezeichnen. Zwar gibt es noch leichte Unterschiede zwischen den beiden Technologien mit verschiedenen Vor- und Nachteilen, das Endergebnis ist aber erstaunlich gleich. Performance, Bildqualität, Latenz, generelle Funktionalität: FSR FG schneidet überall vergleichbar mit DLSS FG ab. Bis jetzt nur in dem einen Titel, aber auf dem Niveau dürfen gerne weitere folgen.

https://www.computerbase.de/2023-12/amd-fsr-3-frame-generation-avatar/#abschnitt_fazit_zu_fsr_3_frame_generation_fmf_in_avatar

robbitop

2023-12-06, 13:10:06

Geil! :up: Warum nicht gleich so? :)
Dass das Verfahren grundsätzlich funktioniert haben sie ja bereits im August demonstriert (die Zwischenbilder sahen laut diversen Analysen ja ganz gut aus trotz fehlendem optical flow accelerator - also musste das über compute gelöst werden). Es war ja "nur" das Framepacing.
Ich sehe es auch so: man hätte es nicht "halb fertig" releasen sollen.

Was jetzt noch ganz schön wäre:
- wenn man es von FSR Upsampling entkoppeln würde (oder: FSR Upsampling massiv verbessert würde).
- funktionierendes Antilag+ bei FSR3
- Antilag+ nicht als Hook sondern nativ im Spielecode implementiert wie reflex - und IMO könnte man die Hook Variante ja für den User zugänglich machen, damit er auf Wunsch damit selbst herumspielen kann (Spiele auf die white list setzen und testen)

Auf jeden Fall ein guter Schritt in Richtung offenes Verfahren, dass die Kunden nicht auf propertäre Verfahren und damit langfristig zu einem Monopol zwingt

dargo

2023-12-06, 13:10:11

Falls jemand Avatar: Frontiers of Pandora schon hat bitte mal testen ob es mit Framegeneration immer noch Bildstuttering gibt sobald der Monitor bzw. der Treiber auf die Framevervielfältigung umschaltet. Kann jetzt schlecht einschätzen ob CB auf sowas achtet.

DrFreaK666

2023-12-06, 13:19:03

Hoffentlich schafft man es treiberseitiges FG auch noch stark zu verbessern.
1.Q 2024 steht vor der Tür

robbitop

2023-12-06, 13:21:09

Ja naja da sollten die Erwartungen nicht zu hoch sein. Bei reinem treiberseitigem FG gibt es keine Motion Vectors. Insofern ist das Ergebnis dann auch begrenzt. Ich würde mich nicht wundern, wenn es auf dem Stand vom Preview bleibt nur mit dem Unterschied, dass das Frame Pacing gefixt ist.

DrFreaK666

2023-12-06, 13:23:44

Das wäre ja schonmal das Wichtigste

Exxtreme

2023-12-06, 13:33:51

Ja, AMD braucht dringend andere Marketingleute. Das, was die derzeitigen so anrichten ist schon unglaublich. Ansonsten sehr schön, dass das offenbar so gut funktioniert. Leider kann man die FSR-Version aus dem Artikel nicht entnehmen.

DrFreaK666

2023-12-06, 14:06:42

Jetzt hat CDPR jedenfalls keine Ausrede mehr

Andron

2023-12-06, 14:21:20

Ich sehe es auch so: man hätte es nicht "halb fertig" releasen sollen.

Was jetzt noch ganz schön wäre:
- wenn man es von FSR Upsampling entkoppeln würde (oder: FSR Upsampling massiv verbessert würde).
- funktionierendes Antilag+ bei FSR3
- Antilag+ nicht als Hook sondern nativ im Spielecode implementiert wie reflex - und IMO könnte man die Hook Variante ja für den User zugänglich machen, damit er auf Wunsch damit selbst herumspielen kann (Spiele auf die white list setzen und testen)

Stimme ich in allen Punkten voll zu und würde noch weiter gehen:

- FSR Upscaling sollte massiv verbessert und FG dennoch entkoppelt werden: auch DLSS, XeSS und TSR haben ihre jeweiligen Problemstellen und jeder sollte sich die für ihn am besten funktionierende Kombination aussuchen können.

- Das man Disoclussion bis heute nicht wenigstens durch simples filtering kaschiert ist mir unbebgreiflich. Wäre sicher nicht auf DLSS/XeSS Level, würde die Bildhomogenität dennoch verbessern. Bröselige Pixel stechen halt immer hervor.

- Nativ implementiertes Antilag+ (+) Hook Variante per Whitelist kam mir auch schon in den Sinn, für reine Singleplayer könnte man in Absprache mit den jeweiligen Entwicklern die Hook Variante zur schnelleren Verbreitung standardmäßig whitelisten. Support ab mindestens RDNA1 müsste für eine schnelle Verbreitung ebenfalls zeitnah kommen.

- AMD sollte die Mod-Community stärker unterstützen und einbinden, trotz des Open Source Ansatzes von FSR gibt es relativ wenige Projekte, die FSR optimieren. (wie bspw. die Anti-Ghosting Version der CyberFSR Mod).

Gast

2023-12-06, 14:24:36

- Antilag+ nicht als Hook sondern nativ im Spielecode implementiert wie reflex - und IMO könnte man die Hook Variante ja für den User zugänglich machen, damit er auf Wunsch damit selbst herumspielen kann (Spiele auf die white list setzen und testen)

Das wird nicht möglich sein, der Hook muss ja pro Spiel implementiert werden und wäre damit unnötige Arbeit wenn es die Spiele eh schon selbst implementieren.

robbitop

2023-12-06, 14:55:31

Ist das mit diesem Hook auf github nicht so, dass einfach eine DLL in's Spielverzeichnis geschmissen wird? Das könnte man sicherlich netter per GUI AMD seitig einbauen. Aber das wäre dann wahrscheinlich nur was für Nerds.

- AMD sollte die Mod-Community stärker unterstützen und einbinden, trotz des Open Source Ansatzes von FSR gibt es relativ wenige Projekte, die FSR optimieren. (wie bspw. die Anti-Ghosting Version der CyberFSR Mod).
Das ist wirklich ein "Kultur Problem". Valve zeigt das krasse Gegenteil. Sehr gute Mods schaffen es in Spiele oder die Macher werden aufgekauft.
Portal, Black Mesa, Dota kamen eigentlich von außerhalb. Bei Half Life Alyx nutzte man das Studio was man gekauft hat, was Firewatch gebaut hat (Indie studio).
Team Fortress und CounterStrike waren IIRC auch ursprünglich Mods.

Leider dumpt AMD nur Quelltext von einigen Dingen auf github und ignoriert jeglichen Input. Man könnte die horse power der Community nutzen (auch der Modder wie du sagst) um ihre Verfahren zu verbessern. Und ganz automatisch wird man in diesem Dialog / Kooperation frisches, gutes Talent erkennen, was man anheuern könnte. Firmen wie Comma.Ai machen genau das sehr erfolgreich. IMO ist das Potenzial von Open Source größer als manch einer denkt und es wird leider verschenkt.

Exxtreme

2023-12-06, 15:15:37

Stimme ich in allen Punkten voll zu und würde noch weiter gehen:

- FSR Upscaling sollte massiv verbessert und FG dennoch entkoppelt werden: auch DLSS, XeSS und TSR haben ihre jeweiligen Problemstellen und jeder sollte sich die für ihn am besten funktionierende Kombination aussuchen können.

Geht womöglich nicht so ohne weiteres. Es ist nämlich so, der FG-Teil von FSR müsste an die Informationen rankommen, die der DLSS/Xess-Upscaler-Teil generiert und benutzt hat. Und möglicherweise geht das nicht oder es geht nicht ohne nennenswerte Leistungseinbußen etc. Denn es ist fraglich ob Nvidia oder Intel die Möglichkeit eingebaut haben eben an diese Informationen ranzukommen. Was eventuell geht, ist wenn FSR so eine Art "passthrough"-Modus hätte. Nur kann es dann sein, dass die generierten Bilder wiederum nicht hochskaliert wären oder nur per FSR hochskaliert etc.

Der umgekehrte Weg, dass man FSR nutzt und den FG-Teil von DLSS 3, funktioniert AFAIR auch nicht. Wohl aus diesen Gründen.

- Das man Disoclussion bis heute nicht wenigstens durch simples filtering kaschiert ist mir unbebgreiflich. Wäre sicher nicht auf DLSS/XeSS Level, würde die Bildhomogenität dennoch verbessern. Bröselige Pixel stechen halt immer hervor.

Gegen Disocclusion kann man nicht viel machen. Denn was Geflimmer/Ausgefranstheit ist, das ist ein höchst subjektiver Eindruck. Und da pauschal irgendeinen Filter drüberzujagen könnte dafür sorgen, dass das Bild "anders schlecht" wird.

- Nativ implementiertes Antilag+ (+) Hook Variante per Whitelist kam mir auch schon in den Sinn, für reine Singleplayer könnte man in Absprache mit den jeweiligen Entwicklern die Hook Variante zur schnelleren Verbreitung standardmäßig whitelisten. Support ab mindestens RDNA1 müsste für eine schnelle Verbreitung ebenfalls zeitnah kommen.

Solange es keine Online-Spiele sind, wäre das wohl kein Problem.

Das wird nicht möglich sein, der Hook muss ja pro Spiel implementiert werden und wäre damit unnötige Arbeit wenn es die Spiele eh schon selbst implementieren.

Nein, muss man nicht. Man kann in der Regel eine Hook-DLL ins Spielverzeichnis reinkopieren. Beim Laden der DLLs wird zuallererst im Verzeichnis der .exe gesucht. So funktionieren auch die ganzen API-Wrapper ala DXVK. Ausnahmen wären wenn das Spiel einen fest einprogrammierten Pfad zur DLL hätte.

Gast

2023-12-06, 16:35:16

Denn was Geflimmer/Ausgefranstheit ist, das ist ein höchst subjektiver Eindruck. Und da pauschal irgendeinen Filter drüberzujagen könnte dafür sorgen, dass das Bild "anders schlecht" wird.

gilt nyquist shannon hier nicht?

Gast

2023-12-06, 18:52:26

Gegen Disocclusion kann man nicht viel machen. Denn was Geflimmer/Ausgefranstheit ist, das ist ein höchst subjektiver Eindruck. Und da pauschal irgendeinen Filter drüberzujagen könnte dafür sorgen, dass das Bild "anders schlecht" wird.

Selbst ein einfacher gaussian blur wäre besser als was FSR aktuell macht.

Und ja, man kann es besser machen, wie diverse TAA-Implementierungen zeigen, die allesamt kein derartiges Flimmern zeigen, ist ja nicht so als wäre Disoclusion ein neues Problem für TAA.

Andron

2023-12-06, 19:36:34

Gegen Disocclusion kann man nicht viel machen. Denn was Geflimmer/Ausgefranstheit ist, das ist ein höchst subjektiver Eindruck. Und da pauschal irgendeinen Filter drüberzujagen könnte dafür sorgen, dass das Bild "anders schlecht" wird.

Dem würde ich widersprechen. Ich hatte vor Monaten Bildvergleiche in diesen Thread gepostet, in denen ich einen einfachen Gaussian Blur über die betroffen Stellen gelegt habe und das Ergebnis war ein viel saubereres/homogeneres Gesamtbild, dass eher dem leichten Unschärfeschleier entsprach, den DLSS/XeSS in Disoclussion-Bereichen erzeugt. Das reduzieren des Flimmerns/Ausfransens ist in jedem Fall eine Verbesserung.

Lurtz

2023-12-07, 09:07:50

https://i.imgur.com/zo57Pna.jpg

It just works :uup:

Was ist Schuld, RTSS? NVCP Framelimiter?

Edit:
RTSS mag er nicht.

Lurtz

2023-12-07, 12:24:13

Hier mit RTX 4070 und GSync compatible-Monitor funktioniert VRR NICHT. Fühlt sich immer noch komplett beschissen an gegenüber DLSS FG.

robbitop

2023-12-07, 12:28:14

Laut HWUB ist FSR3 Upsampling in Avatar wohl eine der besseren Implementierungen. Sieht wohl ganz gut aus wenn auch schlechter als DLSS. https://youtu.be/6McS5GdDozE?si=pL87HwtS_oi0CTtj&t=557
Er geht am Ende sogar soweit es als Referenzimplementierung zu bezeichnen

Raff

2023-12-07, 12:51:25

https://i.imgur.com/zo57Pna.jpg

It just works :uup:

Was ist Schuld, RTSS? NVCP Framelimiter?

Edit:
RTSS mag er nicht.

Bestätige. Sobald RTSS aktiv ist, weigert sich das Spiel.

MfG
Raff

dargo

2023-12-07, 12:55:33

Ich finde diese totkomprimierten YT-Videos immer bemerkenswert wo man eh nahezu keinen Unterschied sehen kann. ;D Das wirklich lustige ist aber, dass im 300% Zoom DLSS-P am Zaun genauso beschissen flimmert wie FSR2/3-P, ich kann mich aber noch an die Lobhudeleien einiger in diesem Forum erinnern bezüglich DLSS-P @4k. ;) Selbst Quality überzeugt mich an dieser Stelle nicht, egal ob DLSS oder FSR2/3. Bildstabilität ist noch zu schlecht.

DrFreaK666

2023-12-07, 13:00:05

Hier mit RTX 4070 und GSync compatible-Monitor funktioniert VRR NICHT. Fühlt sich immer noch komplett beschissen an gegenüber DLSS FG.

Im Preview-Treiber schreibt AMD zu AFMF
For the optimal experience, AFMF is recommended to be used on AMD FreeSync™ displays.

Vielleicht hat AMD beide Technologien für FreeSync optimiert.
Andererseits hat jemand bei CB Probleme trotz FreeSync

dargo

2023-12-07, 13:31:29

Bitte nicht AFMF und FSR3 in einen Topf werfen um für maximale Verwirrung hier zu sorgen.

DrFreaK666

2023-12-07, 22:09:56

2cgciASGTY0

Milchkanne

2023-12-14, 20:05:47

Es ist soweit:
https://gpuopen.com/fsr3-source-available/
https://gpuopen.com/fidelityfx-super-resolution-3/
https://gpuopen.com/presentations/2023/AMD_FidelityFX_Super_Resolution_3-Overview_and_Integration.pdf

We are pleased to confirm that this latest version of AMD FSR 3 includes quality improvements and extends support for Variable Refresh Rate (VRR) monitors within the frame pacing logic.

Relex

2023-12-14, 21:03:33

We are pleased to confirm that this latest version of AMD FSR 3 includes quality improvements and extends support for Variable Refresh Rate (VRR) monitors within the frame pacing logic.

Schade, dass es diese Version nicht in Avatar geschafft hat. :frown:

TheGood

2023-12-14, 21:13:29

Scheint nicht mehr von Interesse zu sein, seit es so gut funktioniert.

Dampf

2023-12-14, 22:12:41

Relex

2023-12-14, 23:26:11

Scheint nicht mehr von Interesse zu sein, seit es so gut funktioniert.

Warum? VRR funktioniert in Avatar jedenfalls nicht… Das wäre dringend nötig.

Und das HUD wird auch nicht richtig bzw. VIEL zu großflächig maskiert, was optisch extrem störend ist.
Man hat praktisch unsichtbare, rechteckige Boxen um jedes HUD element, wo die Framerate innerhalb dieser Box nur die Hälfte beträgt. Dadurch hebt sich dieser Bereich stark vom Rest ab, wenn das Bild in Bewegung ist. Das sieht sehr kaputt aus.

Mir leuchtet wirklich nicht ein, wie AMD eine so gut funktionierende Zwischenbildberechnung entwickeln konnte, die eigentlich mit Nvidia locker mithalten könnte, aber dann verkackt man es auf der Zielgeraten so stark mit fehlendem VRR Support und kaputtem HUD.

Ist jetzt schon das dritte Spiel..

Milchkanne

2023-12-14, 23:55:02

VRR:
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=86360&stc=1&d=1702594470

Hier noch ein Zitat:
A DLL integration is strongly recommended for debug and future compatibility purposes.

*edit*
Übrigens ist auch wieder die Cauldron Demo vorcompiliert da. Einfach SDK runterladen:
https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK/releases/download/fsr3-v3.0.3/FidelityFX-SDK-FSR3-v3.0.3.zip
und dann "./sdk/tools/media_delivery/MediaDelivery.exe --latest" die "UpdateMedia.bat" im root des entpackten folders ausführen. Das lädt dann die Assets runter. Dann "bin/FFX_FSR_NATIVE_DX12.exe" starten.

Da kann man dann auch FSR2 mit FSR3 Upscale only vergleichen.

Relex

2023-12-15, 00:44:27

Die Erklärung von AMD ergibt keinen Sinn.

Warum sollte bei aktivem Vsync mit VRR noch zusätzlich ein FPS Limiter nötig sein?

Wenn ich z.B. ein 120 Hz Display mit VRR habe, durchgehend 100 FPS erreiche und einen Limiter auf 80 FPS setze, dann nutze ich effektiv kein VRR. Das ist dann einfach äquivalent zu 80 Hz mit Vsync.

Diese Empfehlung für ein FPS Limit, um „stable“ Framerates zu erreichen ist doch schon wieder ein fetter disclaimer…

Denn genau so verhält sich FMF schon jetzt. Sobald man einen Limiter setzt, dieses Limit durchgehend erreicht und die Frametime dadurch stabil ist, ist auch FMF flüssig. Genauso wenn man ins Vsync limit kommt.

Lässt man die Framerate im VRR Window aber schwanken, kommts zu judder.

Gut, vielleicht ist in Avatar wirklich die aktuellste Version enthalten. Nur hat diese Version dann keinerlei Verbesserung gegenüber Forspoken und Immortals erhalten, da VRR immernoch genauso wenig funktioniert. Die Erklärung von AMD würde dazu ja auch passen. Ist halt in allen drei Spielen das selbe verhalten.

Sehr enttäuschend.

Achill

2023-12-15, 00:57:56

VRR:
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=86360&stc=1&d=1702594470

Hier noch ein Zitat:

*edit*
Übrigens ist auch wieder die Cauldron Demo vorcompiliert da. Einfach SDK runterladen:
https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK/releases/download/fsr3-v3.0.3/FidelityFX-SDK-FSR3-v3.0.3.zip
und dann "./sdk/tools/media_delivery/MediaDelivery.exe --latest" starten. Das lädt dann die Assets runter. Dann "bin/FFX_FSR_NATIVE_DX12.exe" starten.

Da kann man dann auch FSR2 mit FSR3 Upscale only vergleichen.

Bzw. die "UpdateMedia.bat" im root des entpackten folders ausführen ...

DrFreaK666

2023-12-15, 06:03:52

Das Assets Runterladen hat bei mir nicht funktioniert. Wenn ich die "FFX_FSR_NATIVE_DX12.exe" starte dann öffnet sich ein Fenster mit einer Fehlermeldung.
Und wenn ich davor "MediaDelivery.exe" starte, dann öffnet sich für einen Sekundenbruichteil ein Fenster und schließt sich wieder.
Könnte jemand den kompletten Ordner irgendwo hochladen, oder was mache ich falsch?

edit: habe nun "UpdateMedia.bat" ausgeführt. Es tut sich was

edit2: läuft

DrFreaK666

2023-12-15, 06:52:14

Ich habe mal FSR2 und FSR3 bezüglich des Upscalings verglichen. Die Unterschiede sind in meinen Augen minimalst.
Erster Ausschnitt: FSR2. Beides FSR Quality.

robbitop

2023-12-15, 08:06:24

Schade, dass es diese Version nicht in Avatar geschafft hat. :frown:

Woran siehst du das? Die Version in Avatar ist doch verbessert (juddert nicht) und kommt mit VRR klar?

robbitop

2023-12-15, 08:09:45

Jensen muss sich warm anziehen. Eine Frechheit, dass sie DLSS3 Frame Gen nicht einfach auf die alte Generation in abgespeckter Form bringen.

FSR3 Frame Gen zeigt, dass es auch ohne Ada-Features geht.
DLSS Upsampling würde wahrscheinlich auch ohne TCs gehen aber etwas langsamer. Nvidia will exklusive Features als unique selling points damit man immer schön das neuste von ihnen kauft. Kapitalismus halt.

robbitop

2023-12-15, 08:10:47

Warum? VRR funktioniert in Avatar jedenfalls nicht… Das wäre dringend nötig.

Und das HUD wird auch nicht richtig bzw. VIEL zu großflächig maskiert, was optisch extrem störend ist.
Man hat praktisch unsichtbare, rechteckige Boxen um jedes HUD element, wo die Framerate innerhalb dieser Box nur die Hälfte beträgt. Dadurch hebt sich dieser Bereich stark vom Rest ab, wenn das Bild in Bewegung ist. Das sieht sehr kaputt aus.

Mir leuchtet wirklich nicht ein, wie AMD eine so gut funktionierende Zwischenbildberechnung entwickeln konnte, die eigentlich mit Nvidia locker mithalten könnte, aber dann verkackt man es auf der Zielgeraten so stark mit fehlendem VRR Support und kaputtem HUD.

Ist jetzt schon das dritte Spiel..

In den reviews wurde gesagt vrr ginge. zumindest mit freesync bzw auf amd hw.

———————

edit: endlich kommt AMD mal darauf dlls zu empfehlen ggü den Entwicklern. Besser spät als nie.

dargo

2023-12-15, 08:50:22

Woran siehst du das? Die Version in Avatar ist doch verbessert (juddert nicht) und kommt mit VRR klar?
Frage ich mich auch wie Relex darauf kommt. So wie ich das verstanden habe funktioniert Avatar mit FSR3 und VRR einwandfrei wie es sein soll. Womöglich gibts aber noch Probleme mit Geforces.

PS: ich kanns noch mit Radeon nicht testen da ich das Game noch nicht habe. Habs damit aber auch nicht so eilig. Die Frage was passiert wenn Framevervielfältigung eingreift konnte mir leider immer noch keiner beantworten. Immer muss man alles selbst testen. :P

basix

2023-12-15, 09:01:47

esit: endlich kommt AMD mal darauf dlls zu empfehlen ggü den Entwicklern. Besser soät als nie.

Naja, eigentlich könnten die Entwickler auch selbst darauf kommen ;)

Aber gut, ja. Wäre schön, wenn das zum Standard würde und sowas wie DLSS-Swapper auch für FSR3 zu haben wäre.

robbitop

2023-12-15, 09:08:03

Naja, eigentlich könnten die Entwickler auch selbst darauf kommen ;)

Aber gut, ja. Wäre schön, wenn das zum Standard würde und sowas wie DLSS-Swapper auch für FSR3 zu haben wäre.
Hat sich eigentlich bisher immer gezeigt: wenn man Konsistenz will, muss man es vorgeben.

Exxtreme

2023-12-15, 09:27:32

DLL-Integration hat aber auch so ihre Tücken. Kann sein, dass das Aufkommen im Support steigt weil die Leute anfangen DLLs zu tauschen. Oft vergessen die Leute es sogar, dass sie DLLs getauscht haben und ein neuer Patch könnte inkompatibel werden etc. Und dann sind natürlich die Entwickler schuld.

basix

2023-12-15, 09:38:28

Bei einem Patch werden doch solche Sachen oftmals einfach durch den Patch überschrieben. Und wenn nicht, hat der Patch wohl keinen Zusammenhang mit dem Rendering und der Funktionsweisse innerhalb der FSR-DLL.

Wenn ein Game-Update kommt (je nach Umfang), muss ich DLSS Versionen wieder neu via DLSS-Swapper updaten. Das ist völlig normal.

robbitop

2023-12-15, 09:43:57

Exxtreme

2023-12-15, 09:51:49

Wenn ein Game-Update kommt (je nach Umfang), muss ich DLSS Versionen wieder neu via DLSS-Swapper updaten. Das ist völlig normal.

Und das vergessen die Leute womöglich. Gutes Beispiel ist ja grad im Nvidia-Forum zu sehen. Die Leute beschwerten sich, dass die Videos im Firefox ruckelten. Der Grund dafür ist die undokumentierte und experimentelle Option namens "gfx.webrender.super-resolution.nvidia". Und wer ist schuld? Natürlich die unfähigen Programmierer bei Nvidia und nicht das eigene komplett kaputtkonfigurierte System. Die Leute haben schlicht vergessen, dass sie diese Funktion mal aktiviert haben.

Wenn man FSR jetzt als DLLs ausliefert dann sowas ebenfalls passieren. Die Leute tauschen die Dinger aus, das Spiel läuft einige Monate einwandfrei und ein neuer Treiber oder ein Spielpatch macht es kaputt. Und dann wird der Support angerufen. :freak:

basix

2023-12-15, 12:20:30

Nein, das sollte eben nicht passieren:
- Das Spiel hat die Hoheit, die DLSS-DLL via Patch zu überschreiben -> Die Applikation kann das Verhalten beeinflussen -> Funktioniert
- Der Treiber hat mit jedweder DLSS-DLL zu funktionieren, egal ob alt oder neu

Bei dem Firefox Thema ist das anders gelagert: Firefox kann den Nvidia Treiber nicht beeinflussen. Die Applikation hat hier also eine externe Abhängigkeit, die die App nicht eigenständig auflösen kann. Bei einem Spiele Patch hast du aber diese Möglichkeit, indem der Patch eine entsprechend geprüfte DLSS Version mitbringt. Alles andere ist das Problem des Users.
Firefox muss entweder sicherstellen, dass dieses webrender.super-resolution noch funktioniert oder Nvidia muss es anpassen. Dass hier allerdings nicht x-beliebige Versionen und Treiber gemixt werden können, ist allerdings nur logisch. Evtl. könnte Firefox oder der Treiber eine Info/Warnung an den Nutzer geben, das ein Feature Probleme bereiten könnte. Oder der Treiber detektiert eine Änderung der Firefox Version und deaktiviert das Feature vorsorglich. Man kann Problemen vorbeugen, ist aber alles nicht so einfach ;)

Nvidia scheint gut mit der Strategie zu fahren und ich hab da noch nie von Problemen gehört. Wenn man immer nach Gründen (warum etwas nicht geht) sucht anstatt nach Möglichkeiten, wird man nie etwas erreichen.
Wie oben geschrieben: Bei DLSS / FSR-DLL sollten solche Probleme gar nie entstehen, wenn zwei Bedingungen erfüllt sind:
- Spiele-Patches liefern die DLL mit aus, wenn was von Seiten Spiel hinsichtlich Rendering oder DLSS ändert
- GPU-Treiber kommt mit allen DLL Versionen zurechnt

Die DLSS-DLL manuell zu überschreiben ist hier dann eine Nutzer-Anpassung, welche dann auch der Nutzer "ausbaden" soll, wenn es nicht funktioniert. Mit dem DLSS-Swapper geht das tauschen ganz leicht, aber man muss es allenfalls von Zeit zu Zeit für ein entsprechendes Spiel neu überschreiben. Ist OK für mich aus Nutzersicht. Und Spiele-Entwickler und Nvidia haben keine Probleme mit irgendwelchen inkompatiblen SW-Ständen.

fondness

2023-12-15, 13:29:31

DrFreaK666

2023-12-15, 14:06:46

DrFreaK666

2023-12-15, 14:25:26

"Like a Dragon Gaiden: The Man Who Erased His Name" bekam FSR3.
https://steamcommunity.com/app/2375550/discussions/0/4032474633912472024/

robbitop

2023-12-15, 14:38:47

Nvidia fährt diese Strategie allerdings weil sie ihre Blackbox nicht öffnen wollen.
Das stimmt aber unabhängig vom Motiv funktioniert es offenbar hervorragend.

Laut AMD funktioniert es auch auf der Series X und Series S mit Anpassungen. Die PS5 wird nicht erwähnt.
Das gilt auch für FSR 2 - welches ja in ein paar PS5 Spielen auch schon zum Einsatz kommt. Hat nichts zu sagen schätze ich.

Achill

2023-12-15, 14:53:06

Nvidia scheint gut mit der Strategie zu fahren und ich hab da noch nie von Problemen gehört. Wenn man immer nach Gründen (warum etwas nicht geht) sucht anstatt nach Möglichkeiten, wird man nie etwas erreichen.

Das ist keine besondere Strategie sondern Kapital/Besitz und die Kontrolle über den Zugang dazu. Man wird da viele Beispiele in der Welt finden und ob diese positive oder negative sind, kommt dann imho Maßgeblich auf die eigene Situation an.

basix

2023-12-15, 15:00:59

Laut AMD funktioniert es auch auf der Series X und Series S mit Anpassungen. Die PS5 wird nicht erwähnt. Vielleicht bekommen ein paar Games ja FG-Patches. Avatar wäre naheliegend

https://i.postimg.cc/zD9Q9fzp/AMD-FSR3-GUIDE2.webp (https://postimg.cc/Jt5KXMBB)

PS5 wird nicht erwähnt, weil FSR3 offiziell "nur" DX12 und Vulkan unterstützt. Zumindest das, was auf dem Git-Repo liegt.

The_Invisible

2023-12-15, 15:18:51

Würde auch keinen Sinn ergeben wenn selbst die Switch ein gemoddetes FSR2 bekam

Exxtreme

2023-12-15, 15:30:10

Die Frage ist wer das FSR auf der Switch gemoddet hat. War eventuell Nintendo selber.

DrFreaK666

2023-12-15, 15:41:30

Die Jungs von Now Mans Sky waren das, sonst würden Nintendo Titel das ja auch nutzen

Anscheinend gibt es FSR3-Mods!?
PHu9B0l_qG4
Bin mir aber nicht sicher ob das nicht Fake ist

Gast

2023-12-15, 16:05:38

Nvidia scheint gut mit der Strategie zu fahren und ich hab da noch nie von Problemen gehört.

Es geht hier nicht um Nvidia oder AMD es geht um die Spieleentwickler und die haben in der Regel keine Freude wie sie DLSS über eine externe DLL einbauen müssen.

Es ist lediglich so, dass DLSS so gut ist, dass die meisten darauf nicht verzichten wollen, und DLSS so einbauen weil sie keine andere Wahl haben.

Relex

2023-12-15, 16:31:39

Woran siehst du das? Die Version in Avatar ist doch verbessert (juddert nicht) und kommt mit VRR klar?

In den reviews wurde gesagt vrr ginge. zumindest mit freesync bzw auf amd hw.

Frage ich mich auch wie Relex darauf kommt. So wie ich das verstanden habe funktioniert Avatar mit FSR3 und VRR einwandfrei wie es sein soll. Womöglich gibts aber noch Probleme mit Geforces.

Bei mir habe ich deutlichen Judder, egal was ich einstelle, ich kriegs nur mit einem FPS Limit weg.
Der Monitor geht auch ständig (mit hoher Wechselfrequenz) auf die Maximale Bildwiederholrate. Ergo funktioniert VRR nicht. Bzw. FSR zwingt dem Monitor einen Bildwechsel auf, der dem Verhalten ohne VRR entspricht.

Wenn ich FSR3 FMF deaktiviere und nur mit FSR Upscaling oder DLSS spiele, läuft VRR wieder wie es sein sollte.

Wenn jemand nen Tip hat, was ich tun soll, dann gerne. Aber ich bin mir ziemlich sicher, dass ich schon alles mögliche ausprobiert habe.

Gut möglich, dass es auf AMD Karten funktioniert. Bei meiner Nvidia tuts das eben nicht. Wenn das wirklich so ist bzw. so bleibt dann ist das nicht die versprochene Lösung für "alle". Dann muss von Entwicklern weiterhin beides implementiert werden. DLSS FG und FSR FMF. (Das ist so oder so das sinnvollste)

Exxtreme

2023-12-15, 16:47:21

Dann muss von Entwicklern weiterhin beides implementiert werden. DLSS FG und FSR FMF. (Das ist so oder so das sinnvollste)

Das dürfte sowieso die beste Methode sein. Auch wenn Ampere-Nutzer draussen bleiben müssen.

dargo

2023-12-15, 17:19:06

Das dürfte sowieso die beste Methode sein. Auch wenn Ampere-Nutzer draussen bleiben müssen.
Non Ada trifft es wohl eher.

Relex

2023-12-16, 13:11:14

Ich habe mal FSR2 und FSR3 bezüglich des Upscalings verglichen. Die Unterschiede sind in meinen Augen minimalst.
Erster Ausschnitt: FSR2. Beides FSR Quality.

Also laut Github hat der FSR3 Upscaler die Version 2.2.2.
Da wir 2.2 schon in Spielen gesehen haben sind da also auch keine Verbesserungen zu erwarten.

Praktisch ist 2.2.2 also nur ein API Update, damit es mit Frame Generation funktioniert.

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=86390&stc=1&d=1702728618

DrFreaK666

2023-12-16, 14:13:23

Ja, aber AMD hat auf der Gamescom doch irgendwas von minimalen Veränderungen gesprochen. Wenn ich mal Zeit habe, dann schau ich mal den Sprungbrunnen genauer an

aceCrasher

2023-12-16, 19:00:45

Apple MetalFX ist "powered by FSR". Interessant.

https://www.notebookcheck.net/Apple-s-Metal-FX-upscaling-is-powered-by-AMD-FidelityFX-Super-Resolution-technology.784429.0.html

fondness

2023-12-16, 19:13:06

Apple MetalFX ist "powered by FSR". Interessant.

https://www.notebookcheck.net/Apple-s-Metal-FX-upscaling-is-powered-by-AMD-FidelityFX-Super-Resolution-technology.784429.0.html

Thats the Power of open source.

Gast

2023-12-16, 20:09:39

Apple MetalFX ist "powered by FSR". Interessant.

Ich will jetzt nicht die Party Crashen, aber MetalFX Upscaling gibt es in 2 verschiedenen Settings, „Performance“ und „Quality“. Wobei diese nichts mit der Renderauflösung zu tun hat, Performance ist ein simpler Single Frame Spatial Upscaler.

Dieser basiert auf FSR (1) Technik.

Der einzig wirklich relevante Upscaler ist der Quality Upscaler, welcher ein NN basierter Upscaler ist der auch temporale Daten verwendet. Letzterer ist eine Apple In-house Lösung.

basix

2023-12-16, 20:20:04

Hier wird wohl FSR1 gemeint sein. FSR1 ist auch heute noch der beste (mir bekannte) rein spatial real-time Upscaler. Und die Performance-Kosten sind auch für Mobile Zwecke völlig vertretbar und FSR1 ist sehr einfach integrierbar.

Wundert mich unter dem Strich also nicht ;)

DrFreaK666

2023-12-16, 20:35:31

Hier wird wohl FSR1 gemeint sein...

eher FSR 1+2
However, unsurprisingly, MetalFX incorporates temporal scaling, spatial scaling and anti-aliasing techniques, all of which are core elements of AMD’s FSR technology.

Gast

2023-12-16, 22:34:20

eher FSR 1+2

https://www.notebookcheck.net/fileadmin/_processed_/7/6/csm_IMG_0004_739ae7573d.png

Besser die Orignialquelle als den Abschreiber lesen.

DrFreaK666

2023-12-17, 07:59:53

https://www.notebookcheck.net/fileadmin/_processed_/7/6/csm_IMG_0004_739ae7573d.png

Besser die Orignialquelle als den Abschreiber lesen.

Und was soll das Bild nun belegen?
Die Jahreszahl könnte ein Hinweis sein, ja

robbitop

2023-12-17, 08:38:02

Das beste framepacing soll es in fsr3 nur mit hw gpu scheduling geben laut doku. Und externe monitoring tools sind wohl „gift“ dafür. Ggf ist das eine Erklärung für die unterschiedlichen Erfahrungen.

DrFreaK666

2023-12-17, 09:02:22

Vielleicht mal fühlen statt messen.

robbitop

2023-12-17, 09:12:48

Naja oder das AMD monitoring nutzen. :)
(sofern man AMD HW hat)

DrFreaK666

2023-12-17, 09:34:05

Naja oder das AMD monitoring nutzen. :)
(sofern man AMD HW hat)

Ja. Also knapp 20% der User ^^
AMD sollte das Tool für alle veröffentlichen oder Afterburner kompatibel machen

robbitop

2023-12-17, 10:39:11

Naja sie haben ja den source code veröffentlicht. Die Frage ist ob es AMDs Job ist für alle möglichen 3rd Party Tools Kompatibilität zu supporten. Das hatte ggf systeminhärente Nachteile für das Verfahren. Das können die Toolhersteller dann ggf selbst tun. Bisschen Geduld und es löst sich sicherlich alles in Wohlgefallen auf.
Aber: man hätte zumindest mit 1-2x dieser OSD Anbieter kollaborieren können, so dass diese entsprechende Updates hätten machen können.

AMDs Problem ist, dass sie nicht darauf gedrillt sind, alles zu polishen und due diligence zu machen bevor man launcht.
Das schadet jedes Mal dem Image weil es unprofessionell wirkt.

Lurtz

2023-12-17, 14:24:27

David Owen filmt ja bspw. den Bildschirm ab. Problem ist nur, dass man dann nur noch subjektive Eindrücke wiedergeben kann, keine handfesten Messungen.

Subjektiv fühlt sich FSR FG aber auch in Avatar schlechter an als DLSS FG generell.

robbitop

2023-12-17, 14:32:37

Laut CB Messungen läuft es smoother auf AMD HW. Kann aber an den Messtools oder am GPU HW Scheduling liegen. Das wird man noch herausfinden müssen.

00-Schneider

2023-12-17, 14:32:52

Subjektiv fühlt sich FSR FG aber auch in Avatar schlechter an als DLSS FG generell.

Ich hoffe, DF macht zetnah mal ein Vergleichsvideo zwischen DLSS3 und FSR3 bei Avatar.

Savay

2023-12-17, 16:14:03

Also das AMD Overlay zeigt bei mir mit der FSR3 FG in Avatar 0% Microstutter an und so fühlt es sich auch an.
Komplett andere Story als mit den ersten beiden komplett kaputten AFMF Treibern etc....

Gast

2023-12-17, 17:12:44

Und was soll das Bild nun belegen?

Erstens steht da nur FSR und nichts von FSR2. Und falls das noch nicht eindeutig genug ist, steht da eindeutig das Copyright von 2021, und 2021 gab es noch gar kein FSR2.

Nebenbei hat Apple bei der Vorstellung von MetalFX Upscaling, was ja schon einige Zeit her ist bestätigt, dass es ML nutzt. Nachdem FSR2 bekanntermaßen kein ML nutzt ist auch klar, dass das „richtige“ MetalFX Upscaling eben nicht auf FSR basiert.

DrFreaK666

2023-12-18, 15:57:04

Erstens steht da nur FSR und nichts von FSR2. Und falls das noch nicht eindeutig genug ist, steht da eindeutig das Copyright von 2021, und 2021 gab es noch gar kein FSR2...

Auf die Idee, meinen ganzen Kommentar zu zitieren, bist wohl nicht gekommen :rolleyes:
Und was soll das Bild nun belegen?
Die Jahreszahl könnte ein Hinweis sein, ja.

edit: es gibt einen DLSS3 zu FSR3 Mod, dieser benötigt aber anscheinend eine RTX-Karte
https://wccftech.com/amd-fsr-3-frame-generation-dlss-3-mod/

DrFreaK666

2023-12-18, 17:55:11

Paid FSR3 Mods getestet

YoApt1YURKU

edit: teilweise übles Ghosting

Gast

2023-12-18, 19:02:27

Auf die Idee, meinen ganzen Kommentar zu zitieren, bist wohl nicht gekommen :rolleyes:
.

Nein schließlich bist du auch nicht auf die Idee gekommen deine erste Zeile zu löschen.

robbitop

2023-12-18, 20:31:33

Das mit den paid mods nimmt IMO auch etwas überhand. Sowas war früher nicht gang und gäbe.

Platos

2023-12-18, 20:48:11

Armselig für ein Spiel ist es noch dazu, wenn man bei Modder einkaufen gehen muss, um in einem Spiel Kantenglättung zu kriegen (um es mal überspitzt zu formulieren).

DrFreaK666

2023-12-18, 21:44:16

Das mit den paid mods nimmt IMO auch etwas überhand. Sowas war früher nicht gang und gäbe.

Ja. Finds auch nicht gut, aber die Mod für RTX-User hier ist kostenlos
https://wccftech.com/amd-fsr-3-frame-generation-dlss-3-mod/

Nein schließlich bist du auch nicht auf die Idee gekommen deine erste Zeile zu löschen.

erledigt :P

Ex3cut3r

2023-12-18, 22:59:30

Cool. Werde ich am Wochenende mal in CP77 ausprobieren, nutze eine RTX 3080 Ti.

Exxtreme

2023-12-18, 23:04:41

DrFreaK666

2023-12-19, 00:34:44

Die FSR3 Mod kann man mit DLSS kombinieren. Zumindest in CP2077

ibGw5PuG4Xc

Gast

2023-12-19, 06:37:15

Ja. Also knapp 20% der User ^^
AMD sollte das Tool für alle veröffentlichen oder Afterburner kompatibel machen
eigentlich sind es nur 12%, denn die Notebooks/Laptops sollte man ja auch mit hinein Berechnen. 80% wäre nur der Discrete Market

robbitop

2023-12-19, 08:48:29

Wobei das schon hochgradigst peinlich für diese "AAA-Entwickler" ist, dass irgendwelche 3rd-party-Modder sowas abliefern und sie selbst unfähig zu soetwas sind. Trotz dreistelliger Millionenbeträge, die so ein Titel kostet.

Dem wird oft keine Priorität eingeräumt. Ist das Häkchen in der Box ist alles töfte. :up:
Und deshalb fährt man am besten so wenig wie möglich den Entwicklern zu überlassen (auch wenn es da ein paar richtig gute Ausnahmen wie id gibt).

DrFreaK666

2023-12-19, 09:41:26

Wo ist id eine gute Ausnahme? Doom Eternal hat nur DLSS

robbitop

2023-12-19, 09:58:12

Mir ging es nicht um FSR/DLSS sondern Implementierungen im Allgemeinen.

DrFreaK666

2023-12-19, 09:58:57

Eternal unterstützt nur DLSS; kein FSR; kein XeSS. Was genau meinst du?

Exxtreme

2023-12-19, 10:01:47

Wahrscheinlich geht es Robbitop darum, dass man den Devs nicht zu viele Freiheiten lassen sollte weil sie sonst irgendeinen Mist einbauen, den niemand braucht, ausser sie selbst. ;)

Geldmann3

2023-12-19, 10:25:01

Die FSR3 Mod kann man mit DLSS kombinieren. Zumindest in CP2077

https://youtu.be/ibGw5PuG4Xc

Oh mein Gott, was ist hier mit FSR los? Das flimmert ja wie die Hölle, da würde ich lieber die interne Auflösung nativ spielen. Normal ist das aber nicht...

robbitop

2023-12-19, 10:38:59

Eternal unterstützt nur DLSS; kein FSR; kein XeSS. Was genau meinst du?

Bitte mal abstrakt denken. Ich sagte es ging mir um Implementierungen im Allgemeinen.
Es gibt mehrere Beispiele. ZB:

1.) Specular Flimmern ist etwas was man vermeiden kann, wenn man high frequency content vermeidet (und das shannon nyquist theorem im Hinterkopf behält). Es gab eine Zeit in der man specular flimmern nur mit der Keule verbessern konnte (downsampling). Man hätte es aber bei der Contentwahl (wahl des shaderprogramms, wahl der Geometrie und Textur) vermeiden können. Da hat id immer drauf geachtet - viele andere Studios nicht.
Am Ende hat TAA all das für alle gefixt.

2.) Id hatte das erste richtig gute TAA (8xTSSAA) implementiert.

3.)Ids erste DLSS Implementierung war zu seiner Zeit iirc Referenz. Spätere Implementierungen und neuere DLLs haben andere aufholen lassen. Soweit ich das weiß hat Tiago Sousa damals einige Zeit investiert, die DLSS Dokumentation zu studieren und die best mögliche Implementierung zu bringen.

4.) Id‘s idtech Engine war die erste Engine die lowlevel 3D API richtig richtig gut umsetzte. Entsprechend gab es saubere frametimes und mehr als gute Perf/BQ.

5.) Shadercompilation war jahrelang ein Drama weil sich kaum jemand darum geschert hat. Solche compilation stutters gab es bei idtech iirc nicht.

6.) Bei id hat man extrem viel Zeit investiert, aus den GPUs alles herauszuholen was ging. Un aus GCN das volle Potenzial zu schöpfen hat man die Shadercompiler von MS/Sony mit denen von AMD verglichen (was Auslastung angeht) und stellte fest, dass die von MS/Sony deutlich besser waren. Man hat den vom Konsolen Compiler kompilierten / optimierten Code iirc dekompiliert. Der schmeckte AMDs shadercompiler dann deutlich besser.
Entsprechend waren die ersten idtech6 Spiele überproportional gut auf GCN weil sie dessen schwierig zu extrahierende Auslastung erhöht haben.

Alles nur einzelne Beispiele wovon es hinter den Kulissen viele mehr gibt und die zeigen dass manche bereit sind, die extra Meile zu gehen um alles herauszuholen. Dazu kommt dann aber auch noch dass id auch richtig gute Leute in der 3D Abteilung hat die auch ordentlich mitbestimmen dürfen. Dad gilt leider nicht für alle Studios.