nVidias Deep Learning Super Sampling - DLSS 2.x und DLSS 3 [Archiv] - Seite 13

PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : nVidias Deep Learning Super Sampling - DLSS 2.x und DLSS 3

Seiten : 1 2 3 4 5 6 7 8 9 10 11 12 [13] 14 15 16 17 18 19 20 21 22 23 24 25 26

Darkman.X

2022-03-23, 17:39:07

Danke @ aufkrawall,

für dein Feedback wie gut/schlecht bestimmte DLSS-Versionen sind :up:

aufkrawall

2022-03-23, 18:29:40

Kein Prob. Habe es hier gesehen, nachdem ich die TPU-Seite zuletzt gestern selber abgeklappert hatte:
https://forums.guru3d.com/threads/news-about-ray-tracing-games-dlss-dlaa-dldsr-fsr-xess-etc.439761/page-17#post-6003554

Ist immer noch nicht perfekt in diesen händisch nachträglich aktualisierten Titeln (also gar kein Smearing), aber schon mal bedeutsam besser. 2.2.6 ist in manchen Szenen immer noch leicht besser, aber dafür 2.3.9 in anderen (+weniger Kanten-Jittering etc.).

Troyan

2022-03-24, 19:11:27

Habe ja schonmal geschrieben, dass jemand für die ganzen Upscaler-Sachen eine API oder Bibliothek schreiben wird. Das hat nun nVidia übernommen: https://developer-blogs.nvidia.com/wp-content/uploads/2022/03/Streamline_Diagram-625x415.png
https://developer.nvidia.com/blog/new-ray-tracing-ai-cloud-and-virtual-world-tools-streamline-game-development-at-gdc-2022/

Ist auch der absolut richtige Weg. Schaut man sich AMDs FSR 2.0 an, wo die Entwickler noch fleißig für andere Hardware optimieren sollen, sollten dies die Hersteller selbst machen.

basix

2022-03-24, 21:28:45

Streamline hört sich gut an. Und man halte sich fest: Open Source :D

BlacKi

2022-03-24, 22:01:01

ich hab gehört, dlss sei jetzt doch auch schon open source, oder nicht?^^

aufkrawall

2022-03-25, 12:26:43

Gibt DLSS 2.4.0 im SDK. Taugt laut einhelliger Meinung bei Guru3D (btw. deutlich interessanteres Forum) aber nichts, also besser bei 2.3.9 bleiben.

robbitop

2022-03-25, 12:34:07

ich hab gehört, dlss sei jetzt doch auch schon open source, oder nicht?^^
Nein da wurden nur Schnittstellen zusammengefasst mMn. Also ist nur dieses Gerüst open source. Ich glaube nicht, dass NV DLSS open source macht. Speziell nicht das trainierte NN von DLSS (so dass man dieses auch verändern und weiterentwickeln kann).

aufkrawall

2022-03-25, 12:40:11

Er hat auf den Leak angespielt. Ob der angebliche SC in dieser Form wirklich für die Konkurrenz nutzbar ist, sei dahin gestellt. Ich hätte ehrlich gesagt aber nichts dagegen, denn umgekehrt ist es nicht implausibel, dass Nvidia sich auch XeSS und FSR 2.0 anschauen wird und ggf. daraus Rückschlüsse zieht.

Reaping_Ant

2022-03-25, 13:45:38

Nvidia - Intel - "Hardware Vendor #3". ;D

Tobalt

2022-03-25, 14:09:47

Ich würde sagen, dass das trainierte NN relativ wertlos für die Konkurrenz ist. Entscheidender wären Trainingsdaten und Scorefunktion.

-/\-CruNcher-/\-

2022-03-25, 14:12:23

Nvidia - Intel - "Hardware Vendor #3". ;D

Jep schon merkwürdig, als würde man Intel noch nicht als ernsthafte Konkurenz betrachten und scheut sich AMDs namen zu erwähnen.

Dabei sind Intel die die Nvidia in der Zukunft auseinanderreisen werden, schon witzig ;)

iamthebear

2022-03-25, 16:02:32

Es könnte auch daran liegen, dass zum Zeitpunkt der Erstellung FSR 2.0 noch nicht von AMD vorgestellt wurde und man nichts leaken wollte. XeSS wurde ja bereits seit einiger Zeit präsentiert.

Ich weiß aber nicht ob ich mich da so wohl dabei fühle wenn Nvidia die Schnittstelle zu AMD und Intel kontroliert. Das birgt die Gefahr, dass hier heimlich etwas gebremst wird oder dass an der eigenen Technologie fleißig erweitert wird während AMD/Intel dann bei ihrer aktuellen Implementierung festhängen.

why_me

2022-03-25, 16:37:40

basix

2022-03-26, 00:06:32

Ich weiß aber nicht ob ich mich da so wohl dabei fühle wenn Nvidia die Schnittstelle zu AMD und Intel kontroliert. Das birgt die Gefahr, dass hier heimlich etwas gebremst wird oder dass an der eigenen Technologie fleißig erweitert wird während AMD/Intel dann bei ihrer aktuellen Implementierung festhängen.

Was heisst hier kontrollieren? Ist ein Open Source Paket. AMD und Intel können es also selbstständing anpassen und erweitern, wenn es was nutzt oder was nicht passt.

Gast

2022-03-26, 00:57:16

Was heisst hier kontrollieren? Ist ein Open Source Paket. AMD und Intel können es also selbstständing anpassen und erweitern, wenn es was nutzt oder was nicht passt.
Naja, aber dann kann man es ja gleich lassen. Wenn jeder Hardwarehersteller das dann so abändert, wie er es gern hätte, dann haben die Spieleentwickler ja wieder 3 Schnittstellen zu implementieren und haben gar nichts gewonnen :) .

In Bezug auf TAAU ist wahrscheinlich die Sorge da, dass ein Spieleentwickler einfach die Intel oder AMD Lösung implementieren könnte, und dann DLSS gar nicht benutzt, weil die andere Lösung ja schon auf allen Grafikkarten läuft. Gerade wenn AMD dann auch FSR als reine TAA Komponente ohne Upscaling fertig hat und man damit dann gleich TAA und TAAU mit einer Lösung für alle Grafikkarten erschlagen kann.

Mit so einer gemeinsamen API könnte man natürlich sagen: Hier, ihr braucht nur ein Flag zu setzen, und schon bekommen die nVidia Karten DLSS und die anderen Karten was anderes. Und damit weiter besser DLSS vermarkten.

AffenJack

2022-03-26, 10:26:03

Nvidia - Intel - "Hardware Vendor #3". ;D

Dürfte wohl daran liegen, dass Intel da gerne mit Nvidia zusammenarbeitet, da man nichts dagegen hat, wenn andere Lösungen implementiert werden, solange man selbst Mindshare mit XeSS gewinnt. Da XeSS am besten auf Intel läuft, ist Ihnen am wichtigsten es in möglichst vielen Spielen drin zu haben. Ich glaube Nvidia und Intel sehen das als Softwarewettkampf ihrer Programmierer, wer das beste Upscaling hinkriegt.

basix

2022-03-26, 11:07:04

Naja, aber dann kann man es ja gleich lassen. Wenn jeder Hardwarehersteller das dann so abändert, wie er es gern hätte, dann haben die Spieleentwickler ja wieder 3 Schnittstellen zu implementieren und haben gar nichts gewonnen :)

Schon mal was von Upstream gehört? ;)

Meine Aussage ist war die, dass man mit einem Open Source Paket keinen Marktteilnehmer ausschliessen kann. Es ist ein Wrapper, welcher angepasst und dann wieder in den Master gemerged werden kann. Und solange die API bei allen relevanten Temporal Upsampling eh faktisch identisch ist (ist es bei DLSS, XeSS und FSR 2.0 nach meinem Verständnis der GDC Talks), spielt es auch nicht wirklich eine Rolle. Wenn die Lösungen an sich in Zukunft wieder auseinanderdivergieren, mit ganz anderen Input-Values, dann wird man sehen wie gut der Wrapper passt. Aber auch hier, kann man genau diesen Wrapper für das auflösen von solchen API Konflikten verwenden.

In Bezug auf TAAU ist wahrscheinlich die Sorge da, dass ein Spieleentwickler einfach die Intel oder AMD Lösung implementieren könnte, und dann DLSS gar nicht benutzt, weil die andere Lösung ja schon auf allen Grafikkarten läuft. Gerade wenn AMD dann auch FSR als reine TAA Komponente ohne Upscaling fertig hat und man damit dann gleich TAA und TAAU mit einer Lösung für alle Grafikkarten erschlagen kann.

Mit so einer gemeinsamen API könnte man natürlich sagen: Hier, ihr braucht nur ein Flag zu setzen, und schon bekommen die nVidia Karten DLSS und die anderen Karten was anderes. Und damit weiter besser DLSS vermarkten.

Das ist ein gutes Argument. Damit beugt man dem Fall vor, dass FSR/XeSS so stark werden dass sie DLSS aus dem Markt verdrängen. Nvidia hat es bei DLSS aber auch selbst in der Hand: Solange es Vorteile bietet (Performance, Qualität, Features) wären Argumente für DLSS auf dem Tisch. Bietet man das nicht oder nur in zu geringem Ausmass, ist die Restriktion auf RTX only halt ein Hemmschuh.

hmmm

2022-03-26, 11:14:25

Gast

2022-03-26, 12:28:52

Jep schon merkwürdig, als würde man Intel noch nicht als ernsthafte Konkurenz betrachten und scheut sich AMDs namen zu erwähnen.

Das liegt daran, dass Intel bereits bestätigt hat XeSS mit dem Framework kompatibel zu machen.

Nvidia kann nicht AMD draufschreiben, wenn noch gar nicht bekannt ist ob sich AMD darauf überhaupt einlassen wird, bzw. könnte das sogar Klagen von AMD nach sich ziehen wenn AMD damit gar nichts zu tun haben will, durch die NV Folie aber der Eindruck entsteht AMD wäre schon mit an Bord.

Zudem dürfte beim Erstellen der Folien noch gar nicht bekannt gewesen sein, dass AMD ebenfalls an einem temporalen Upscaler arbeitet.

Troyan

2022-03-26, 12:29:42

Nvidia - Intel - "Hardware Vendor #3". ;D

Intel hat schon gesagt, dass sie XeSS einbauen werden. AMD wird wahrscheinlich nichts machen, weil es dann ja keinen Sinn mehr gibt FSR für "läuft überall" zu promoten. Daher auch "Hardware Vendor #3".

Tobalt

2022-03-26, 13:03:01

Troyan

2022-03-26, 13:09:44

XeSS wird auf Intel-Hardware am besten laufen. Daher ist es ein Nachteil für AMD. FSR wird auf AMD Hardware am besten laufen, daher ist es ein Nachteil von nVidia und Intel.

Für Streamline ist es egal. Als Spieleentwickler wird Streamline eingebaut und die entsprechenden DLLs bzw. Upscaling-Dateien ausgeliefert. Es ist für Spieleentwickler vollkommen transparent.

Es macht keinen Sinn für nicht bezahlte Entwickler und Publisher auf individuelle Implementierungen zu setzen.

robbitop

2022-03-26, 13:38:21

Naja XeSS und FSR sind open source. Entsprechend kann jeder Vendor das auf seine selbst HW optimieren soweit ich das verstanden habe.

AffenJack

2022-03-26, 14:55:48

Naja XeSS und FSR sind open source. Entsprechend kann jeder Vendor das auf seine selbst HW optimieren soweit ich das verstanden habe.

Nur wird jemand das tun? Wenn der Vendor die nächste Version bringt, dann funktioniert diese vielleicht wieder schlechter auf deiner Hardware oder soll der Entwickler dann XeSS 1.0 AMD Optimized und XeSS 2.0 non-optimized gleichzeitig nutzen, weil sich das Verfahren geändert hat? Jeder der drei wird nur an seiner eigenen Version rumschrauben und deswegen unterstützen Nvidia und Intel ja diese Runtime zur Implementierung.

robbitop

2022-03-26, 15:07:20

Troyan

2022-03-26, 15:10:18

Open Source ist vollkommen irrelevant, da die Spiele geschlossen sind. Jede direkte Implementierung limiert also die Anpassungsfähigkeit. Bei DLSS und XeSS liegt die Magie im transparenten Netzwerk.

Jemand könnte z.B. XeSS auf CUDA portieren und dann reicht es aus einfach die Dateien zu tauschen. Für die Spieleimplementierung mit Streamline ist dies vollkommen egal. So etwas ist bei einer direkten Implementierung eben nicht möglich.

Tobalt

2022-03-26, 15:13:41

Was dann halt inakzeptabel ist, wenn bestimmte Streamline features dann nur auf nv Hardware laufen würden. Es muss rben für alles ein guter hardwareagnostischer Fallback her.

Mal schauen ob sich nV wirklich diese Mühe macht. Für devs macht es auch nur Sinn wenn nV ehrlich ist und Intel/AMD nicht irgendwelche Fallstricke und Bottlenecks einbaut.

Letzlich würde nV nicht drumherum kommem, zumindest ein bischen auch für Intel und AMD Optimierungsarbeit zu leisten. Mal sehen ob sich das lohnt für den Lohn einer erhöhten DLSS Implementierung

Troyan

2022-03-26, 15:37:24

Streamline ist open source: https://github.com/NVIDIAGameWorks/Streamline

Selbst wenn nVidia neue Funktionen für DLSS einbaut, kann dies jeder in Streamline portieren.

basix

2022-03-26, 16:55:30

Nur wird jemand das tun? Wenn der Vendor die nächste Version bringt, dann funktioniert diese vielleicht wieder schlechter auf deiner Hardware oder soll der Entwickler dann XeSS 1.0 AMD Optimized und XeSS 2.0 non-optimized gleichzeitig nutzen, weil sich das Verfahren geändert hat? Jeder der drei wird nur an seiner eigenen Version rumschrauben und deswegen unterstützen Nvidia und Intel ja diese Runtime zur Implementierung.

Die Neueinsteiger (AMD, Intel) sind an einer weiten Verbreitung ihrer Upsampling Implementationen interessiert. Entsprechend wird dort schon eine gewisse Optimierung für ein breites HW-Feld vorliegen. Aber klar, auf der eigenen HW wird sicher am meisten Optimierungs-Liebe investiert worden sein. Bei Intel ist es aufgrund XMX und DP4A Unterteilung eh klar, dass XeSS auf den eigenen GPUs schneller laufen wird. FSR 2.0 läuft potentiell auf allen Vendors gleich gut.

Ob Optimierungen umgesetzt werden ist mMn eine Frage der Produktpolitik.
- 1. Eigenes Verfahren pushen (z.B. DLSS)
- 2. Eigene HW pushen (z.B. Nvidia optimiert XeSS und FSR 2.0 für Nvidia GPUs)

Geld verdienen tut man schlussendlich nur an 2., das 1. erlaubt aber einen zusätzlichen Wettbewerbsvorteil. Ich tendiere im Falle von Nvidia dazu, dass sie beides machen werden (falls 2. nötig ist). AMD und Intel werden es vermutlich ähnlich handhaben.

Schlussendlich wird es bei XeSS und FSR auf Hardwareagnostik hinauslaufen. Im Falle von FSR ist das schon eingebaut (siehe den GDC Talk). Im einfachsten Fall hat man eine Liste von GPU-Typen/Architekturen mit entsprechenden Konfigurationsflags für den Algorithmus. Bei neuen GPU-Architekturen wird einfach das Set dieser Flags erweitert und angepasst. Fertig. Dass der Algorithmus komplett umgebaut wird usw. ist eher unwahrscheinlich, aber nur so Sachen wie Wave-Grösse oder Grössen von Datenpartitionierungen können viel ausmachen. Dass man die Parameter anpassen kann liegt auch im Sinne des Erfinders, da die eigenen (zukünftigen) GPUs auch davon profitieren.

AffenJack

2022-03-26, 17:02:54

Abwarten. Versionssprünge heißen selten, dass die ganze Welt verändert wird. Neue Versionen kann man auch optimieren. Vermutlich kann man die Optimierungen auch schnell mit „umziehen“.
Es wäre schlau von AMD auch XeSS zu unterstützen und Intel FSR 2.0 einfach wegen der Verbreitung.

Die Frage ist, wie viel GPU spezifische Optimierung man da überhaupt noch braucht. Moderne GPUs sind zumindest was Vektorinstruktionen angeht ziemlich ähnlich.

Was willst du da optimieren, wenn Intel zb die Komplexität des neuronalen Netzes erhöht in einer neuen Version? Vll nötig, um ein besseres Bild zu haben und alle GPUs, die nicht die Matrixbeschleunigung von Intel nutzen verlieren dann mal 10% Leistung.
Wird sich keiner groß antun und Intel wird auch nicht den Support für die Matrixcores von AMD einbauen, wenn da welche kommen. Muss AMD schon machen. Also soll AMD 2-fachen Entwicklungsaufwand betreiben, anstatt ihre Lösung zu pushen? Das glaube ich nicht.

Intel unterstützt Streamline, weil man damit an seiner eigenen Software optimieren kann, ebenso wie Nvidia an DLSS. Beide haben kein großes Interesse irgendwas an FSR zu optimierenund bei AMD wird es nicht anders sein.

gedi

2022-03-26, 22:57:20

Überholt!

iamthebear

2022-03-26, 23:21:03

ich vermute, AMD wird XeSS genauso supporten, wie Intel FSR supporten wird. Ich sehe keinen Vorteil darin wenn sie es nicht supporten. Für den User ist halt relevant, dass XeSS auf Intel Hardware wahrscheinlich besser ist als FSR und umgekehrt bei AMD Hardware

Es ist gar nicht notwnedig dass Intel FSR supported bzw. AMD XeSS. Das sind Bibliotheken, die von Spieleentwicklern eingebunden werden können und die sich lediglich standardisierter Befehle bedienen, die die GPU bereits zur Verfügung stellt.

Naja XeSS und FSR sind open source. Entsprechend kann jeder Vendor das auf seine selbst HW optimieren soweit ich das verstanden habe.

Ja es ist Open Source aber einbinden muss es der Spieleentwickler. Nvidia und Intel könnten zwar ihre eigenen Optimierungen einbauen aber sie müssten die Spieleentwickler überzeugen den eigenen Code statt dem von AMD zu verwenden und ob das gelingt ist fraglich. Da es auch keine externe dll ist kann man auch nicht einfach wie bei DLSS die dll austauschen.

Bei XeSS wird es ähnlich sein. Wenn Intel Spieleentwickler dafür bezahlt XeSS zu integrieren, dann werden diese kaum alternativen Code von Nvidia akzeptieren um z.B. die Tensor Cores in XeSS zu nutzen.

Beim Durchlesen der FSR 2.0 Infos auf GPUOpen (AMD) ist mir folgendes Statement aufgefallen:
Often, ML-based real-time temporal upscalers use the model learned solely to decide how to combine previous history samples to generate the upscaled image: there is typically no actual generation of new features from recognizing shapes or objects in the scene.

Das kann sich doch nur auf DLSS beziehen. Dies würde bedeuten, dass ML hier einen deutlich geringeren Anteil hat als ich bisher angenommen habe. Ich denke das bedeutet auch, dass der Performance Overhead von DLSS großteils von den Shadern stammt und die Performance nicht durch die Tensor Cores limitiert wird.

Gast

2022-03-26, 23:51:26

Das kann sich doch nur auf DLSS beziehen. Dies würde bedeuten, dass ML hier einen deutlich geringeren Anteil hat als ich bisher angenommen habe.

Das war doch schon hinlänglich bekannt, und das ist auch deren großer Vorteil.

Deshalb wird es interessant ob FSR 2.0 hier mit herkömmlichen Heuristiken qualitativ mithalten kann.

Schließlich sind AMD nicht die ersten die TAA zum Upscaling benutzen und die bisher qualitativ beste Umsetzung von TAA von Id-Tech liegt beim Upscaling immer noch meilenweit hinter DLSS.

dildo4u

2022-03-28, 08:26:59

Hier gibts Vergleiche vom neuen Unreal Engine TSR vs DLSS 2.3

FbFMafKzJyY

Tobalt

2022-03-28, 08:44:30

Es ist gar nicht notwnedig dass Intel FSR supported bzw. AMD XeSS. Das sind Bibliotheken, die von Spieleentwicklern eingebunden werden können und die sich lediglich standardisierter Befehle bedienen, die die GPU bereits zur Verfügung stellt.

Ich meinte dass AMD Hardware in der Lage ist XeSS auszuführen und umgekehrt. DLSS können/dürfen sie halt nicht als Gegenbeispiel.

Zu deinem letzten Gedanke: Details hinzufantasieren ist für Computergrafik absolut untauglich, da es immer verschiedene Blickwinkel gibt.. Dies überhaupt anzudeuten war von nV eine absolute Nebelkerze bri DLSS 1 und natürlich nicht vorhanden bzw. zum scheitern verurteilt.

Ansonsten habe ich noch nirgends eine Andeutung in diese Richtung gesehen.

Das ganze ist natürlich nicht zu verwechseln mit 2d Upscaling oder Image Completion, Water Mark Removal etc., dort wird bewusst stimmiges Material hinzufantasiert. Evtl. hier nV bewusst mit dem Hype gespielt um positiv auf ihr Image zu wirken als hippe AI Firma..

robbitop

2022-03-28, 08:50:32

Soweit ich weiß wird bei DLSS wenn das clamping fehlschlägt (Wiederfinden des entsprechenden Subpixels in einem Frame) durch das NN eine Annahme getroffen, die das nicht gefundene Subpixel ersetzt. Das scheint relativ gut zu funktionieren.

Tobalt

2022-03-28, 08:57:41

@ robbitop: Wo wir wieder bei der leidigen Diskussion wären: Ab wann ist es ein NN und kein "numerischer Algo" mehr.

Wenn ich ein fehlendes Sample durch eine Interpolation im xyt Space errechne, treffe ich auch nur eine Annahme.

Es steht natürlich noch mehr Rohmaterial zur Verfügung, sodass der Algo durchaus etwas komplexer sein kann..Solange es aber prinzipiell eine Interpolation bleibt, wird IMO nichts *hinzu*-fantasiert.

Ich kann auch jeden hart formulierbaren Algo stattdessen als DNN abbilden. Dadurch sinkt zwar die Effizienz, mit der das Ergebnis erzielt wird, aber ich kann sagen, dass ich AI verwende

robbitop

2022-03-28, 09:24:56

TSR ist momentan das beste der besten Heuristik basierenden Verfahren. Im DF Video was dildo4u verlinkt hat (https://www.youtube.com/watch?v=FbFMafKzJyY), sieht man den Vergleich.
Bei wenig Bewegung sieht DLSS und TSR ähnlich gut aus. Aber in Bewegung (gerade dann wird Clamping deutlich herausfordernder) versagt TSR deutlich (Alex hält die Animation an und man sieht, wie die Hand des Protagonisten unscharf und blocky wird - also das Clamping offenbar fehlschlägt) während DLSS es hinbekommt.

Zumindest solange es kein Heuristik basierendes Verfahren gibt was in Bewegung an DLSS heran kommt, gilt es für mich die Prämisse noch.

Es gab etliche Heuristik basierende (und auch einige hervorragende wie id's, Insomniac's und Epics Verfahren) Iterationen bereits so dass man davon ausgehen kann, dass man im oberen Bereich des sinkenden Grenzertrags ist und trotzdem nicht an ein NN basiertes kommen wird.

Klar muss man noch AMDs FSR 2.0 abwarten und es wäre schön, wenn es in Bewegung Epic's und Id's Verfahren deklassiert. Aber wie wahrscheinlich ist das? Das sind super erfahrene Teams, die sich nicht erst seit gestern damit beschäftigen.

Man kann das Kind ("ist ja doch nur ein Algorithmus...") nennen wie man es will. Aber in der Praxis zeigt es deutliche Unterschiede zwischen den beiden Implementierungsverfahren. Mal schauen ob XeSS (NN) und FSR 2.0 (Heuristik) dieses Muster weiter erhärten können oder es widerlegen können. Stand heute ist für mich zumindest ziemlich eindeutig.

edit:
auch interessant zu sehen, was TSR kostet:
RTX 3090:
1080p nativ: 98 fps
4K TSR performance (1080p input): 81 fps
4K DLSS 2.3 performance (1080p input: 81 fps

Kostet beides knapp über 2 ms. FSR 2.0 wurde auf einer 6900XT mit weniger Kosten beworben. Mal schauen ob es da einen Zusammenhang zwischen Kosten und BQ gibt.

aufkrawall

2022-03-28, 10:08:56

Hatte per Config (sofern es richtig umgesetzt wird) auch mal das Gen 5 TSSAU in Shadow Warrior 3 (UE 4.26) aktiviert: Kann nicht im Entferntesten mit DLSS mithalten, überall sind statische Bereiche deutlich am jittern und in Bewegung wird es sehr unscharf. Obendrein gibts noch mindestens genau so Ghosting bei Partikeleffekten:
https://abload.de/thumb/sw3_2022_03_27_10_25_xgk80.png (https://abload.de/image.php?img=sw3_2022_03_27_10_25_xgk80.png)

FSR 2.0 müsste schon deutlich besser sein, um mich zu überzeugen.

Tobalt

2022-03-28, 11:14:02

robbitop

2022-03-28, 11:16:51

Ich denke beides spielt eine Rolle. Die Frage ist, wie hoch der quantitative Anteil von beiden ist. Ich tippe aber auch darauf, dass das "Wiederfinden" die größere Rolle spielt als das "Erfinden". Am Ende ergibt die Kombination aus beidem das Ergebnis was wir heute wiederfinden. :)

aufkrawall

2022-03-28, 11:38:21

Wir können da von außen wirklich nur mutmaßen. Dass es ab und an mehr Jaggies gibt als mit anderen TAAU-Lösungen (die dafür natürlich extrem blurren), spricht imho nicht für so massig viele Samples. Da ist imho auch viel DL-Magie bei der Verrechnung für die temporale Stabilität.

Es sieht halt in Bewegung einfach komplett anders aus als alles andere, wobei man im Gegensatz zu (alten) spatial Scalern auch nicht so einen komischen "DL-Look" ala Ölgemälde o.ä. hat.

Troyan

2022-03-28, 11:46:25

robbi: Ich bestreite nicht, dass ein DNN bessere Ergebnisse liefern kann als ein expliziter Algorithmus beim zuordnen der temporalen Bildinformationen. Im Gegenteil. Diese Aufgaben (Mustererkennung, Denoising) sind geradezu maßgeschneidert für DNNs.

Was ich meine ist: DLSS ist nicht deshalb so gut, weil es fehlende Sample durch extrem gutes DNN-basiertes "Dazuerfinden" wieder wettmacht, sondern es ist gut, weil es von vornherein viel mehr reale Samples zuordnen kann.

Nein, DLSS ist so gut, weil man mit deutlich mehr Rechenleistung ein Problem lösen kann. Was macht TAA? Es verschmiert Pixels. DLSS und XeSS jedoch versuchen anhand von Pixelbewegungen die Lücken mit ähnlichen Farbwerten zu füllen. Das ist mit TAA nicht möglich ohne immensen Aufwand zu betreiben.

Deswegen sieht man bei DLSS auch ab und zu schlieren oder eben nicht 100% perfekte Kantenglättung. Dafür müsste DLSS ja Objekte wirklich "rund" machen, die jedoch auf des Pixelrasters und der Geometrie nie wirklich rund wären.

Dampf

2022-03-28, 11:58:39

Die Vergleiche, die mein Kumpel auf seiner 3080 gemacht hat sind auch sehr interessant.

Hier stellt er TSR Ultra Quality (Renderscale 77-85%?) gegen DLSS Performance (50%) in 1440p gegenüber.

https://imgsli.com/MTAxNTMz

Man sieht, DLSS Performance steht TSR Ultra Quality in vielen Bereichen in nichts nahe, im Gegenteil. Die Detailrekonstruktion ist an manchen Stellen besser und das Bild ist insgesamt einen Tick schärfer. Die Performance ist dank dank der niedrigen Input-Auflösung deutlich höher und sie wäre nochmal höher wenn das Spiel nicht so komische Bottlenecks hätte. Noch dazu sagt er sieht es Motion besser aus, was das Video von DF ja nochmal bestätigt hatte.

TSR Performance gegenüber DLSS Performance zeigt eine nochmals deutlich bessere Detailrekonstruktion und schärferes Bild von DLSS:

https://cdn.discordapp.com/attachments/409816332796690433/957433232792641616/unknown.png

https://cdn.discordapp.com/attachments/409816332796690433/957433239046336542/unknown.png

https://cdn.discordapp.com/attachments/409816332796690433/957427610739179620/unknown.png

https://cdn.discordapp.com/attachments/409816332796690433/957427818042626099/unknown.png

TSR ist echt gut und eine super Alternative für Non-RTX GPUs aber der Vergleich zeigt deutlich, dass sich das Nutzen von ML auszahlt.

Ich denke besonders der Aspekt, dass niedrigere DLSS Modi gleichwertige/bessere Bildqualität liefern im Vergleich zu höheren Modi vom non-ML Ansatz ist einer, der gerade viel zu wenig beachtet wird.

Ich bin gespannt, wie sich FSR 2.0 im Vergleich schlagen wird!

basix

2022-03-28, 13:48:03

Klar muss man noch AMDs FSR 2.0 abwarten und es wäre schön, wenn es in Bewegung Epic's und Id's Verfahren deklassiert. Aber wie wahrscheinlich ist das? Das sind super erfahrene Teams, die sich nicht erst seit gestern damit beschäftigen.

Aus meiner Sicht ist die Wahrscheinlichkeit hoch. Wieso? AMD wird mit hoher Wahrscheinlichkeit deutlich mehr Ressourcen in die Entwicklung von FSR 2.0 gesteckt haben. AMD verdient Geld mit dem Verkauf von HW. DLSS ist hier ein Pluspunkt für Nvidia und ein Nachteil für Radeon GPUs. Wenn dann die Leute sehen, dass Nvidia GPUs mit DLSS Performance doppelt so viele FPS haben, wie mit AMDs GPUs ohne DLSS, ist das halt ein grosser Nachteil. Ergo weniger hartes Geld für AMD.

Bei den Spiele-Engines sind hauptsächlich das Spiel selbst (Spieler) oder die Anwenderfreundlichkeit / das Overall Featureset (Entwickler) für den Erfolg entscheidend. Da sind TSSAA und TSR nur relativ kleine Anteile des ganzen.

Edit:
Ich kaufe kein Spiel, nur weil es TSR unterstützt. Aber eine GPU, welche bei vielen modernen Spielen doppelt so schnell sein kann, weil gutes Temporal Upsampling unterstützt wird? An dieser Fragestellung sieht man schön, dass AMD ein deutlich höheres Interesse an einem sehr guten FSR 2.0 hat als alle Engine-Entwickler an TSR oder TSSAA.

robbitop

2022-03-28, 15:30:57

Tobalt

2022-03-28, 15:51:46

basix hat meine Gedanken gut auf den Punkt gebracht. nv mit DLSS2 hat IMO *alle* AMD Karten obsolet gemacht. Ich bewerte halt das Preisleistungs-Niveau inkl. DLSS/FSR.

Damit AMD hier was absetzt, haben sie entweder die möglichkeit besseres FSR abzuliefern oder sie müssen mit dem Preislevel runter um den Rückstand auf DLSS auszugleichen.

Es macht also sehr viel Sinn für AMD das absolut mögliche aus dem Verfahren rauszuquetschen ;) Und (wie ich schon mehrfach erwähnte): Nur weil AMD "No AI" behauptet (und auch das wurde in der letzten Präsi ja auf "no AI Hardware" aufgeweicht), heißt das nicht, dass sie nicht auch ein DNN auf FP16 basis einsetzen für das temporale zusammenstückeln.

Ich drücke halt einfach die Daumen, dass es nach gefühlt ~5 Jahren absoluter nV Monopolisierung des Marktes mal wieder eine Chance gibt für AMD (einen Ryzen Moment). Dies kann halt nur passieren wenn FSR2 richtig abliefert.

robbitop

2022-03-28, 16:12:44

Natürlich ist es wichtig, dass FSR 2.0 so gut wie nur möglich wird. Aber nur die reine Notwendigkeit macht es nicht auch gleichzeitig wahrscheinlich. Sie haben nunmal den Nachteil, kein lange tot optimiertes, zum xten mal trainiertes NN nutzen zu können.

Ich denke auch nicht, dass FSR 2.0 überall genauso gut sein muss, um den DLSS Vorteil zu entschärfen. Der Massenmarkt ist nicht der 3DCenter Nerd. Es bringt schon einiges, wenn es deutlich besser als FSR 1.0 ist und halbwegs vergleichbar ist. TSR ist das auch. Nur nicht in allen einzelnen Belangen. Digital Foundry hat TSR ja trotzdem gelobt und die Masse sieht den Unterschied kaum.

aufkrawall

2022-03-28, 16:15:22

TSR sieht sicherlich ziemlich schlecht aus vs. DLSS auf einem 1080p-Monitor.

robbitop

2022-03-28, 16:17:02

Ja je geringer die output resolutions werden, desto größer wird der Unterschied werden. DF hat nur 4K Performance für Ghostwarrior gezeigt.

aufkrawall

2022-03-28, 16:18:51

Ganz ehrlich: 4k only = Fail-Test. Die Kunst besteht darin, dass es in 1440p (oder gar 1080p) besser aussieht als nativ bzw. als mit dem spieleigenen TAA.

robbitop

2022-03-28, 16:48:59

Ja da trennt sich die Spreu vom Weizen. Wobei ich den 4K usecase schon verstehen kann. Zocken auf einem 4K TV - insbesondere einem OLED - das ist einfach phantastisch.
Ich hab mir extra beim Hausbau ein optisches HDMI 2.1 Kabel in der Mancave verlegen lassen, damit der OLED auch zum Zocken genutzt werden kann. Entsprechend ist 4K schon nett. :)

Platos

2022-03-28, 16:50:25

Hast du 4k120Htlz, robbi? Also der TV ? Funzt das Kabel da gut? Was für ne länge ? Welches Kabel?

robbitop

2022-03-28, 17:06:20

Ist ein 55BX - der kann 4K120 Hz bei HDR mit HDMI 2.1. Sebst der 77C9 im Wohnzimmer kann das.
Das Kabel hat 300 EUR gekostet. Aber dummerweise gurke ich immernoch mit einer 1080ti rum. Entsprechend habe ich nur 4K120Hz mit Chroma Subsampling getestet in 8 bit SDR Color. Und das geht wunderbar. Aber damit ist der HDMI 2.0 Port der 1080ti an der Kotzgrenze.

aufkrawall

2022-03-28, 17:07:36

Entsprechend ist 4K schon nett. :)
Ja, natürlich. Aber 4k >60Hz heißt entweder aktueller TV (also Risen-Diagonale mit üblicherweise hohem Sitzabstand) oder so ein >1000€ Monitor-Monstrum.
Der typische Gamer mit leicht gehobenem Anspruch dürfte ein 1080p oder 1440p ~144Hz-Gerät haben. Wenn man nur den Anwendungsfall für einen relativ kleinen Teil der Nutzer abbildet, ist das nicht sonderlich realitätsbezogen. Warum nicht gleich nur 8k (überspitzt gesagt)...

Gast

2022-03-28, 19:14:00

Es macht also sehr viel Sinn für AMD das absolut mögliche aus dem Verfahren rauszuquetschen ;) Und (wie ich schon mehrfach erwähnte): Nur weil AMD "No AI" behauptet (und auch das wurde in der letzten Präsi ja auf "no AI Hardware" aufgeweicht), heißt das nicht, dass sie nicht auch ein DNN auf FP16 basis einsetzen für das temporale zusammenstückeln.

Sehr unwahrscheinlich, es gab den Stream in dem AMD ziemlich genau auf die technische Funktionsweise von FSR 2 eingegangen ist, und da war nicht das geringste von DL zu hören, ganz im Gegenteil, es sind ganz einfach fixe Threshholds die entscheiden ob und mit welchem Gewicht Samples verwendet werden.

basix

2022-03-28, 20:39:13

Abwarten. Tiago Sousa befasst sich mit temporalen Verfahren seit Crysis 2 und ist einer der besten Leute in der Branche (der Macher des 8x TSSAAs in id) und selbst id musste Zugeben, dass DLSS inputresolution normiert auf einer anderen Ebene operiert.

Ja AMD hat 3D Know How. Das haben andere Leute auch und auch entsprechende Erfahrungen mit den Verfahren. Und die wurden etlich oft durchiteriert. Und dennoch hälst du es für wahrscheinlich, dass FSR 2.0 all das deutlich hinter sich lassen wird?

Ich nicht. Ich würde mich aber sehr freuen, wenn ich falsch liegen würde.

Es ist schon ein Unterschied, ob man ein 10-Mann Team 2 Jahre lang mit einem Thema beschäftigt (FSR = "one of the biggest SW initiatives within RTG") oder 2-3 Leute das Teilzeit für eine Engine entwickeln (Achtung, Mann-Zahlen dienen einfach dem Vergleich und sind wild gewählt). Ausserdem kann man von dem geballten Wissen der letzten ~10 Jahre an temporalem Filtering, Reconstruction, Denoising & Upsampling profitieren. TSR zeigt ja selbst, dass gegenüber TAAU bereits ein grosser Fortschritt erzielt wird. Zumindest wenn nicht allzuviel Bewegung im Spiel ist. Waren die Leute bei TAAU damals weniger kompetent? Nein, sie hatten einfach weniger Informationen und Erfahrung zur Verfügung. Der Name Brian Karis könnte bekannt vorkommen: Vater von Nanite der UE5. Den Namen findet man auf der UE4 Präsentation von TAAU anno 2014 ;)
- TAAU der UE4 wurde erstmals 2014 präsentiert
- TSSAA wurde so um 2016 rum released (idTech 6), refined 2020 (idTech 7) mit Doom Eternal (Release März 2020)
- DLSS 2.0 wurde 2020 gezeigt (März 2020)
- Erster TSR Showcase war auch 2020 (Mai 2020) //Edit: UE5 Early Access mit Source Code ist seit Mai 2021 public

Wann hat die FSR Entwicklung angefangen? Schwierig zu sagen. Aber spätestens seit DLSS 2.0 Showcase wird man ein paar Gänge hochgeschraubt haben und Mitte 2020 waren alle heutigen modernen State-of-the-Art Temporal Upsampling Algorithmen "released" oder zumindest bekannt. AMD hatte also ~1.5 Jahre Zeit für FSR 2.0.

AMD war in diesem Bereich bisher nicht unbedingt der, der völlig neue Sachen erfindet. Aber sie lernen von allen anderen, picken die sinnvollen Algorithmen-Teile raus und kombinieren diese. Beispielsweise Sample-Jittering mit Halton-Sequence(2,3) wird von FSR 2.0, XeSS wie auch TSSAA verwendet (bei DLSS weiss ich es nicht). Anscheinend ist das ein Art Optimum, AMD musste hier nichts neues erfinden. Im FidelityFX Package gibt es einige Beispiele davon zu sehen, da sind auch Paper von Nvidia oder anderen Industriegrössen wie Unreal oder Unity verlinkt. Und seit DLSS 2.0 veröffentlicht wurde, hat Research im Bereich Temporal Upsampling massiv an Fahrt aufgenommen. Von allen Marktteilnehmern. Und bei AMD betrifft es direkt den Core Business Case hinsichtlich Geld verdienen, was eben etwas anders gelagert ist verglichen mit einem Engine-Feature.

Ich denke nicht, dass FSR 2.0 so gut ist dass es DLSS in allen Belangen schlägt. Aber in vielen Aspekten/Situationen gleichwertig mit DLSS und besser als TSSAA / TSR kann es schon sein.

DrFreaK666

2022-03-29, 01:07:15

Ich glaube nicht dass FSR 2 DLSS schlagen wird. Es könnte auch allerdings trotzdem etablieren, da wohl wenig Arbeit nötig ist, wann DLSS schon in die Engine eingefügt wurde. Dürfte andersrum ähnlich sein

iamthebear

2022-03-29, 01:43:09

TSR sieht sicherlich ziemlich schlecht aus vs. DLSS auf einem 1080p-Monitor.

Die Frage ist: Wenn ich mir die Leistungsdaten der nächsten Generation ansehe welche der Karten benötigt überhaupt noch Upscaling um 1080p flüssig darzustellen?
Ich denke selbst wenn man im unteren Ende kauft (4050/60), dann wird man 1440p Native flüssig hinbekommen und für 4K kommt dann vielleicht der Quality Mode zum Einsatz.

Die Karten, die wirklich von qualitativ hochwertigen Upscaling profitieren würden sind die die es nicht mehr bekommen (GTX 1060/70 bzw. Radeon 580)

Der Punkt bei FSR 2.0 ist der:
Wenn der Algorithmus keine ML Hardware benötigt, dann muss AMD diese auch nicht verbauen. Angenommen AMD kann stattdessen 10% mehr Shader verbauen. Die 10% sind in jedem Review direkt sichtbar. Ob nun DLSS Quality etwas besser aussieht als FSR 2.0 werden nur die Wenigsten bemerken sofern FSR überhaupt notwendig ist.

Bei den Spiele-Engines sind hauptsächlich das Spiel selbst (Spieler) oder die Anwenderfreundlichkeit / das Overall Featureset (Entwickler) für den Erfolg entscheidend. Da sind TSSAA und TSR nur relativ kleine Anteile des ganzen.

Für fertige Spiele mag das vielleicht stimmen aber Unreal verkauft hier nicht das Spiel. Die leben vom Verkauf der Engine und hier zählen nur technische Argumente nämlich welche Qualität kann man bei gegebener Performance liefern und gerade bei Konsolen ist Performance ein riesiges Thema speziell wenn man für Konsolen entwickelt die nicht gerade erst vor 1-2 Jahren auf den Markt gekommen sind.

Weiters hat Epic einen entscheidenden Vorteil:
Deren Implementierung muss nur mit der eigenen Engine kompatibel sein. Da kann die Schnittstelle auch deutlich komplexer sein. AMD hingegen muss eine Lösung bereitstellen, die sich zumindest in jedes DLSS unterstützte Spiel in 2-3 Tagen integrieren lässt. Dauert das lange kämpft man mit der Verbreitung so wie Nvidia am Anfang.

robbitop

2022-03-29, 07:51:22

@iamthebear
sehr guter Beitrag! Beide Teile des Beitrages sind für mich schlüssig und würde ich auch so sehen. :up:

@basix
Du hast dir die technische GDC Präsentation angesehen oder? Das waren alles relativ bekannte Algorithmen mit festen Grenzwerten. Nichts Bahnbrechendes vor allem für das Clamping auf den ersten Blick. Versteckt wird vermutlich auch nichts sein, da es ja als Open Source verfügbar ist.
Es kann gut sein, dass FSR 2.0 in Bewegung eben nicht die Ergebnisse von DLSS 2.x erzielen wird.

Ich würde sagen man weiß nicht, wie lange diese 10x Leute und wie intensiv in der Zeit jeder davon an FSR 2.0 gearbeitet hat (haben alle Vollzeit dran gearbeitet oder war es eines von vielen Projekten?). Das gleiche gilt für Epic (das Engine Team ist relativ groß) und id.
Auch gibt es Probleme, die nicht besser oder schneller durch mehr Leute lösbar sind. Und auch ist die grundsätzliche Arbeit mit der Engine und Spielen sicherlich sehr sehr hilfreich für das gesamte Verständnis eines solchen Algoritmus.

Wie Jim Keller mal in einem Interview gesagt hat: Innovation geht am besten und schnellsten, wenn es möglichst viele verschiedene "Experimente" (in dem Falle Permutationen von TAA) gibt, die dann alle durchiteriert werden. So zeigt sich, welcher Weg der Richtige ist. Und diese "Experimente" gibt es seit >10 Jahren.
Ja AMD hatte den Vorteil, dass sie potenziell die Möglichkeit hatten sämtliche Erfahrungen bis zum Start von FSR 2.0 sich anzuschauen. Aber die Frage ist: wie tief läßt Epic oder id oder Insomniac AMD ihre Arbeit sich anschauen? Zumindest die allerneuste?
Man kann potenziell annehmen, dass sie eben nur einen Teil der Learnings zur Verfügung hatten.

Auch war TAUU oder 8xTSSAA beim release ja nicht in der Fassung in der sie heute sind. Das 8xTSSAA war ja nicht einfach 2016 "fertig". Das wurde in idtech 7 nochmal aufgebohrt und ist noch cleaner. Auch TAUU hat sich bis zum Start von TSR noch verbessert. Will sagen, diese Firmen haben auch 10 Jahre daran iteriert.

Viele Experimente von verschiedenen Firmen mit vielen Iterationen die am Ende ungefähr auf das gleiche Level kommen. Und nun soll AMD mit festen Grenzwerten und dem Gezeigten in Bewegung deutlich besser sein? Ich hoffe es - fürchte aber es kommt auf's Ähnliche hinaus. Was trotzdem nicht schlecht wäre. Ganz im Gegenteil es ist potenziell eine 80% Lösung, die nun für alle verfügbar ist und nicht nur für RTX Karten.

TSR kostet nach den Benchmarks von DF übrigens ~2ms. AMD's FSR 2.0 ist mit 1 ms für 4K @Performance beworben. Scheint also weniger Rechenleistung zu kosten. Das ist gut. Aber was bedeutet das für die Qualität? In halber Rechenzeit trotzdem bessere Ergebnisse? :)

Ich bleibe skeptisch aber würde mich sehr sehr gern irren. :)
Dennoch selbst wenn es so wird, dass AMD "nur" TSR Niveau bringt - es wäre sinnvoll. Denn damit gibt es wie gesagt eine Lösung für alle, die auch gut funktioniert. Ein FSR 2.0 mit NN und potenziell besserer Qualität hätte das nicht gebracht. Mein Tipp ist, dass das mit FSR 3.0 kommt. Bis dahin ist moderne dp4a HW viel verbreiteter und AMD hat potenziell auch Matrix Units. Und dann hat man einen vollen Stack für alle. Von spatial (einfach zu implementieren und sogar als RSR zu injezieren/forcieren) zu temporal/Heuristik (schwieriger zu implementieren aber für alle nutzbar) zu temporal/NN (der neuste "shit" für neuere HW).
Damit sind dann alle bedient - 3x level. Und es macht auch Sinn die hintereinander zu bringen, um möglichst viele zu erreichen, denn es passt zur verfügbaren Hardware zum jeweiligen Zeitpunkt und zur Implementierungskomplexität.

Und ob jetzt NN oder Heuristik ist von der Implementierung durch den Entwickler wohl fast egal. Ggf. kann AMD dann FSR 3.0 mit NN entweder super einfach für den Entwickler bereitstellen oder sogar einfach injecten. Die Schnittstellen werden ja eh bedient. Wer weiß...?
Nur ein paar Gedanken.

Tobalt

2022-03-29, 07:59:18

Ich denke auch dass man FSR 2 auf FSR 3 "patchen" können wird, so wie das bei DLSS ja auch einfach zu machen ist. Der API dafür ist es ja egal welcher Algorithmus intern abgearbeitet wird. Also solange Input und Output der API gleich bleibt, sollte es gehen.

Wenigstens dafür scheint bei alle Techniken ein vorläufiger Kompromiss gefunden. depth, motion vectors, low res image mit jitter koordinaten rein. High Res Image raus.

TheAntitheist

2022-03-29, 08:18:07

Tobalt

2022-03-29, 08:19:09

Lies meinen Post nochmal...Was die API an den Treiber schickt, ist doch für die 3d Engine völlig egal. Ins Spiel ließe es sich also leicht durch ein API Update reinfixen.

Natürlich würde ein potentielles DNN-FSR 3 dann nur auf Grakas funktionieren, die entsprechende Hardware aufbieten.

basix

2022-03-29, 08:57:32

@basix
Du hast dir die technische GDC Präsentation angesehen oder? Das waren alles relativ bekannte Algorithmen mit festen Grenzwerten. Nichts Bahnbrechendes vor allem für das Clamping auf den ersten Blick. Versteckt wird vermutlich auch nichts sein, da es ja als Open Source verfügbar ist.
Es kann gut sein, dass FSR 2.0 in Bewegung eben nicht die Ergebnisse von DLSS 2.x erzielen wird.

Ich würde sagen man weiß nicht, wie lange diese 10x Leute und wie intensiv in der Zeit jeder davon an FSR 2.0 gearbeitet hat (haben alle Vollzeit dran gearbeitet oder war es eines von vielen Projekten?). Das gleiche gilt für Epic (das Engine Team ist relativ groß) und id.
Auch gibt es Probleme, die nicht besser oder schneller durch mehr Leute lösbar sind. Und auch ist die grundsätzliche Arbeit mit der Engine und Spielen sicherlich sehr sehr hilfreich für das gesamte Verständnis eines solchen Algoritmus.

Wie Jim Keller mal in einem Interview gesagt hat: Innovation geht am besten und schnellsten, wenn es möglichst viele verschiedene "Experimente" (in dem Falle Permutationen von TAA) gibt, die dann alle durchiteriert werden. So zeigt sich, welcher Weg der Richtige ist. Und diese "Experimente" gibt es seit >10 Jahren.
Ja AMD hatte den Vorteil, dass sie potenziell die Möglichkeit hatten sämtliche Erfahrungen bis zum Start von FSR 2.0 sich anzuschauen. Aber die Frage ist: wie tief läßt Epic oder id oder Insomniac AMD ihre Arbeit sich anschauen? Zumindest die allerneuste?
Man kann potenziell annehmen, dass sie eben nur einen Teil der Learnings zur Verfügung hatten.

Auch war TAUU oder 8xTSSAA beim release ja nicht in der Fassung in der sie heute sind. Das 8xTSSAA war ja nicht einfach 2016 "fertig". Das wurde in idtech 7 nochmal aufgebohrt und ist noch cleaner. Auch TAUU hat sich bis zum Start von TSR noch verbessert. Will sagen, diese Firmen haben auch 10 Jahre daran iteriert.

Viele Experimente von verschiedenen Firmen mit vielen Iterationen die am Ende ungefähr auf das gleiche Level kommen. Und nun soll AMD mit festen Grenzwerten und dem Gezeigten in Bewegung deutlich besser sein? Ich hoffe es - fürchte aber es kommt auf's Ähnliche hinaus. Was trotzdem nicht schlecht wäre. Ganz im Gegenteil es ist potenziell eine 80% Lösung, die nun für alle verfügbar ist und nicht nur für RTX Karten.

Wer wie lange an was gearbeitet hat kann man von aussen nicht mit Bestimmtheit sagen. AMD hatte aber sicher den Vorteil, dass viele Irrwege schon begangen wurden und man sich diesen Aufwand sparen konnte.

Wo TSSAA und TSR "fertig" waren Mitte 2020, war DLSS 2.0 nigelnagelneu. Da gibt es allenfalls schon Dinge, die DLSS einfach besser macht. Und AMD konnte das für FSR mitnehmen.

Im Endeffekt werden wir an den Resultaten sehen, wie sich FSR 2.0 im Vergleich schlägt. Ich sehe bei FSR 2.0 aber die Chance, dass es sich besser schlägt wie TSR & TSSAA. Allenfalls nicht ganz auf DLSS Niveau aber nah dran. Nur schon dass es einen FSR Ultra Performance Mode gibt spricht für mich dafür, dass es nicht extrem weit hinter DLSS abfallen sollte.

@basix
TSR kostet nach den Benchmarks von DF übrigens ~2ms. AMD's FSR 2.0 ist mit 1 ms für 4K @Performance beworben. Scheint also weniger Rechenleistung zu kosten. Das ist gut. Aber was bedeutet das für die Qualität? In halber Rechenzeit trotzdem bessere Ergebnisse? :)

TSR kostet nicht 2ms ;) Ich bin bei DLSS auch mal diesem Irrglauben aufgesessen und es ging relativ lange bis ich es gecheckt hatte (auch wenn es eigentlich logisch ist). Fakt ist, dass in der Grafikpipeline nach TSR/DLSS noch einige Module in voller Auflösung berechnet werden müssen (Post Processing usw.). Deswegen wird man mit z.B. 4K DLSS Performance Mode nie die nativ 1080p Perfrormance erreichen, selbst wenn DLSS an sich gratis ist. Und deswegen streuen Ausführungszeit-Vergleiche basierend auf nativem Rendering von Spiel zu Spiel, je nach Anteil von Post Processing an der gesamten Renderzeit. Nvidia hatte DLSS @ 4K mal mit 1.5ms angegeben, mit einer 2080 Ti. Unwahrscheinlich, dass eine 3090 bei 4K plötzlich 1.7ms benötigt. Bei vielen Spielen ist der Performanceunterschied mit einer 2080 Ti im Bereich ~3ms bei einer 2080 Ti und ~2ms bei einer 3090 (beides verglichen zu nativ). Das ist aber nicht die reine Ausführungszeit von DLSS.

Den selben Effekt sieht man auch bei FSR, HW Unboxed hat das gerade letztens getestet: RSR ist bei 50% Resolution Scale deutlich performanter als FSR Performance.
https://youtu.be/IL3QQmwRsIw?t=740

Auch bei FSR 2.0 wird man sehen, dass der Unterschied bei Nativ vs. FSR 2.0 4K Performance >1ms sein wird. Einfach weil einige Bildanteile noch in nativer Auflösung berechnet werden müssen.

Hier bei der UE5 Preview waren die Ergebnisse bezüglich Performance von TSR noch deutlich anders, eher so ~0.5ms, wenn man es auf 4K extrapoliert:
https://www.reddit.com/r/hardware/comments/nozuvo/testing_unreal_engine_5_temporal_super_resolution/

Und:
AMD wird sehr stark auf ihre HW optimiert haben. Optimierungen macht Epic sicher auch, aber AMD traue ich zu, dass sie ihre HW am besten kennen ;)

Für fertige Spiele mag das vielleicht stimmen aber Unreal verkauft hier nicht das Spiel. Die leben vom Verkauf der Engine und hier zählen nur technische Argumente nämlich welche Qualität kann man bei gegebener Performance liefern und gerade bei Konsolen ist Performance ein riesiges Thema speziell wenn man für Konsolen entwickelt die nicht gerade erst vor 1-2 Jahren auf den Markt gekommen sind.

Weiters hat Epic einen entscheidenden Vorteil:
Deren Implementierung muss nur mit der eigenen Engine kompatibel sein. Da kann die Schnittstelle auch deutlich komplexer sein. AMD hingegen muss eine Lösung bereitstellen, die sich zumindest in jedes DLSS unterstützte Spiel in 2-3 Tagen integrieren lässt. Dauert das lange kämpft man mit der Verbreitung so wie Nvidia am Anfang.

Beim zweiten Teil stimme ich dir zu. Das ist ein Vorteil für TSR. Insbesondere, wenn man Nanite mit TSR und Lumen verschränken kann. Stand jetzt ist das aber vermutlich nicht passiert. DLSS und TSR zeigen aufgrund der reduzierten Renderauflösung genau die gleichen geometrischen Details und Beleuchtung, wo TSR theoretisch in der Lage wäre, mehr Details zu zeigen wenn es mit z.B. Nanite verschränkt wäre.

Und ist die grafische Qualität bei deinem ersten Teil wirklich so entscheidend? Klar, ein Vorteil ist es immer. Aber als Entwickler werden mMn die Tools drumherum, Workflows und Arbeits-Effizienz deutlich wichtiger sein als ein einziges einzelnes Feature namens TSR. Da sind Nanite und Lumen die deutlich schwergewichtigeren Features, da sie neben der grafischen Qualität auf die Effizienz von Workflows verbessern. Insbesondere auch, da mit DLSS, XeSS und FSR 2.0 Technologien da sind, die TSR vermutlich qualitativ übertreffen und als Plugin für die UE5 verfügbar sein werden. Und je nach Art des Spiels passt UE5 gar nicht zum Spielkonzept, dann nützen auch all die tollen technischen Features nichts (ja, bei UE eher unwahrscheinlich das sehr breit einsetzbar).

TSR ist sicher ein Fortschritt, aber ich denke nicht dass Epic hier den meisten Aufwand investiert hat. Evtl. gibt es nach UE5 Release noch ein TSR 2.0, dann sieht das wieder etwas anders aus. Aber momtentan ist Epics Hauptfokus, die primären Features und die Tools der UE5 zu finalisieren.

-/\-CruNcher-/\-

2022-03-29, 09:19:11

Hier gibts Vergleiche vom neuen Unreal Engine TSR vs DLSS 2.3

https://youtu.be/FbFMafKzJyY

Welche 4er Version stellt den Core 4.22 ?

PS: Ihm wird bald auffalen das der Unreal Unlocker öfter fehlschlagen wird

robbitop

2022-03-29, 11:20:38

TSR kostet nicht 2ms ;) Ich bin bei DLSS auch mal diesem Irrglauben aufgesessen und es ging relativ lange bis ich es gecheckt hatte (auch wenn es eigentlich logisch ist). Fakt ist, dass in der Grafikpipeline nach TSR/DLSS noch einige Module in voller Auflösung berechnet werden müssen (Post Processing usw.). Deswegen wird man mit z.B. 4K DLSS Performance Mode nie die nativ 1080p Perfrormance erreichen, selbst wenn DLSS an sich gratis ist. Und deswegen streuen Ausführungszeit-Vergleiche basierend auf nativem Rendering von Spiel zu Spiel, je nach Anteil von Post Processing an der gesamten Renderzeit. Nvidia hatte DLSS @ 4K mal mit 1.5ms angegeben, mit einer 2080 Ti. Unwahrscheinlich, dass eine 3090 bei 4K plötzlich 1.7ms benötigt. Bei vielen Spielen ist der Performanceunterschied mit einer 2080 Ti im Bereich ~3ms bei einer 2080 Ti und ~2ms bei einer 3090 (beides verglichen zu nativ). Das ist aber nicht die reine Ausführungszeit von DLSS.

Den selben Effekt sieht man auch bei FSR, HW Unboxed hat das gerade letztens getestet: RSR ist bei 50% Resolution Scale deutlich performanter als FSR Performance.
https://youtu.be/IL3QQmwRsIw?t=740

Auch bei FSR 2.0 wird man sehen, dass der Unterschied bei Nativ vs. FSR 2.0 4K Performance >1ms sein wird. Einfach weil einige Bildanteile noch in nativer Auflösung berechnet werden müssen.

Hier bei der UE5 Preview waren die Ergebnisse bezüglich Performance von TSR noch deutlich anders, eher so ~0.5ms, wenn man es auf 4K extrapoliert:
https://www.reddit.com/r/hardware/comments/nozuvo/testing_unreal_engine_5_temporal_super_resolution/

Und:
AMD wird sehr stark auf ihre HW optimiert haben. Optimierungen macht Epic sicher auch, aber AMD traue ich zu, dass sie ihre HW am besten kennen ;)

Sehr konkludent und aufschlussreich. Vielen Dank. :up:

basix

2022-03-29, 12:49:33

Beim HWUB Video habe ich RSR vs. FSR mal durchgespielt. Es ist relativ schade, dass man RSR mit 80% Resolution Scale getestet hat. FSR Ultra Quality hat 77%. Man kann es aber approximieren.

HZD:
- RSR 50% = Faktisch gratis
- FSR P = ~1.0ms --> Kosten des Full-Res Post Processings

Deathloop:
- RSR 50% =~0.2ms
- FSR P = ~1.0ms --> Kosten des Full-Res Post Processings

Far Cry 6:
- RSR 80% =~0.2ms
- FSR UQ = ~0.7ms --> Kosten des Full-Res Post Processings

Man kann wohl sagen, dass bei modernen Spielen und 4K im Schnitt ca. 1.0ms fürs Post Processing verwendet wird (6800XT+, RTX 3080+). Siehe auch die DLSS Zahlen, welche ich oben genannt hatte.
Ich kann jetzt Wahrsagerei betreiben und behaupten, dass FSR 2.0 in Deathloop ~2.0ms Frametime vs. Nativ kosten wird ;) Damit wäre es auch im Ballpark von DLSS, wenn man die Performance vergleicht.

robbitop

2022-03-29, 13:00:09

Entsprechend liegt TSR dann in etwa bei den Frametimekosten von FSR 2.0 und DLSS 2.x.

basix

2022-03-29, 14:50:41

Scheint bei der UE4 zumindest so zu sein, ja. Beim UE5 Preview hätte ich behauptet, dass es performanter ist. Da aber bei TSR das Delta zu nativ mit TAA verglichen wird, könnte in der UE5 auch einfach das TAA mehr Rechenleistung benötigen.

aufkrawall

2022-03-29, 15:06:49

Vermutlich ist bei Version 5 das neuere, teurere TAA standardmäßig aktiviert, was man in 4 noch in der Config freischalten muss:
https://portal.productboard.com/epicgames/1-unreal-engine-public-roadmap/c/270-next-gen-temporal-aa-experimental

Das r.TemporalAA.Upsampling schmiert in Shadow Warrior 3 definitiv mehr als DLSS 2.3.9 (auch bei sich bewegender Geometrie, nicht nur Partikeleffekte). Da kann man also fragen, ob dieses Problematik überhaupt direkt irgendetwas mit DL zu tun hat. In der FSR 2.0-Präsentation gab es da Veranschaulichungs-Bilder im Context von Pixel Locking gegen Jittering dünner Elemente, die ziemlich die gleichen Artefakte demonstrierten.

basix

2022-03-29, 15:32:06

Ja könnte sein, dass UE5 das neue TAA verwendet. Würde auch Sinn machen, denn damit wollte man ja NextGen präsentieren.

Seit ich mich in letzter Zeit etwas detaillierter mit Temporal Upsampling beschäftigt habe, ist mir auch klar, wieso niedrige Auflösungen und feine Geometrie stärker zu Smearing tendieren. Bei XeSS, DLSS, FSR 2.0 und auch TSSAA werden Motion Vectors mit fixem 3x3 Pixel Blockraster verwendet. Das ist nicht direkt an die Geometrie selbst gekoppelt.

Neben einer geringeren Anzahl Pixel aufgrund der geringeren Renderauflösung sind somit auch die Motion Vectors von schlechterer Qualität. DLSS und Co. haben somit bei sinkender Renderauflösung ein doppeltes Handicap. Und es verschlimmert auch so Phänomene wie völlig verschmierte Planen, welche schnell im Wind wedeln. Dort werden die Motion Vectors über die Zeit einfach all over the place sein und eine temporale Rekonstruktion wird sehr schwierig.

aufkrawall

2022-03-29, 20:23:55

Rumschwirrende Partikel wie Laub haben in Metro EE massive Schlieren mit TAA, mit DLSS 2.3.9 sind die weg:
https://abload.de/thumb/metroexodus_2022_03_2nykyr.png (https://abload.de/image.php?img=metroexodus_2022_03_2nykyr.png) https://abload.de/thumb/metroexodus_2022_03_233jjv.png (https://abload.de/image.php?img=metroexodus_2022_03_233jjv.png)

Bei der Bewegtbildschärfe sieht das TAA auch mal wieder kein Land. Es wäre wirklich ein kleines Wunder, wenn FSR 2.0 da auf einmal auch nur in die Nähe von der DL-Lösung käme.

Ex3cut3r

2022-03-29, 20:40:05

Ich kann mir das Spiel nicht mehr geben. Ich habs von einer Woche genervt deinstalliert, habe bis zur Wüste gespielt. Aber das steife Gameplay mit einem Treffer Feedback wie aus der Steinzeit, und die hölzernen Animationen, gehen gar nicht, was mir auch noch negativ auffiel, die Texturen....meine Güte da sind einige Totalausfälle mit drin.

Shadow Warrior 3 taugt mir als Shooter momentan am meisten.

aufkrawall

2022-03-29, 21:16:48

Ich habe es auch nur mit dem beabsichtigten Verwendungszweck der Tech-Demo installiert. Das dürfte mit neuen DLSS-Versionen wohl noch einige Male passieren, ansonsten fasse ich das Kackspiel aber auch nicht mal mit der Kneifzange mehr an. Das Spiel hat ja TAA, das als gut gilt, aber auch damit springen einen die Schwächen vs. DLSS mittlerweile an.

iamthebear

2022-03-29, 22:47:19

TSR kostet nach den Benchmarks von DF übrigens ~2ms. AMD's FSR 2.0 ist mit 1 ms für 4K @Performance beworben. Scheint also weniger Rechenleistung zu kosten. Das ist gut. Aber was bedeutet das für die Qualität? In halber Rechenzeit trotzdem bessere Ergebnisse? :)

Die Frage ist, ob die ausgemessenen 2ms wirklich nur durch DLSS/TSR verursacht werden oder ob hier im Hintergrund auch noch einige andere Einstellungen geändert wurden (z.B. Qualität der Texturen etc.), was auch die Framerate beeinflusst. Auch diverse Post processing Effekte die nach dem Upscaling passieren müssen schon mit der höheren Auflösung durchgeführt werden. Das mag zwar nicht die Welt sein aber wenn man das alles addiert hat man schnell einmal 1ms zusätzlich beisammen.

Vor einigen Monaten gab es schon einen Reddit Thread wo TSR vs. TAA verglichen wurde:
https://www.reddit.com/r/hardware/comments/nozuvo/testing_unreal_engine_5_temporal_super_resolution/

Dort war der Performanceverlust von 1440p TSR Performance vs. 720p Native mit TAA gerade einmal 81fps vs. 79fps also ca. 0.3ms mit einer 6800
Wenn ich das auf 4K umrechne sind das um die 0.6ms bis 0.7ms. Jetzt frage ich mich wo kommt die zusätzlichen 1.4ms auf einmal her?

Ich denke der Overhead ist auch die Antwort auf die Frage, warum erst jetzt alle an hochwertigen Upscalingverfahren arbeiten. Es war vor ein paar Generationen einfach nicht genug Performance dafür da bzw. das Kosten/Nutzen Verhältnis war einfach zu schlecht.

TheAntitheist

2022-03-30, 00:58:27

CAS kommt vllt noch drauf? oder es ist schon drin.

aufkrawall

2022-03-30, 01:26:34

CAS kostet via ReShade schon fast gar nichts mehr für einen 1440p Framebuffer auf der 3060. Es gibt in der UE noch r.TemporalAASharpness und r.Tonemapper.Sharpen, die kosten beide afair noch weniger. Das r.Tonemapper.Sharpen gefällt mir btw. ziemlich gut, dürfte für das scharfe Bild mit DLSS in Fortnite (Config leider gelockt) verantwortlich sein.

robbitop

2022-03-30, 07:00:32

Das r.TemporalAA.Upsampling schmiert in Shadow Warrior 3 definitiv mehr als DLSS 2.3.9 (auch bei sich bewegender Geometrie, nicht nur Partikeleffekte).
Ist das TAUU in einer neueren Form oder bereits TSR oder etwas separates was dazwischen liegt?

blaidd

2022-03-30, 11:08:47

TSR kostet nach den Benchmarks von DF übrigens ~2ms. AMD's FSR 2.0 ist mit 1 ms für 4K @Performance beworben. Scheint also weniger Rechenleistung zu kosten. Das ist gut. Aber was bedeutet das für die Qualität? In halber Rechenzeit trotzdem bessere Ergebnisse? :)

Ist das auf Ghostwire Tokyo bezogen? Da kann man FSR 1.0, TSR und DLSS vergleichen...

Beachtenswert dabei: Sowohl TSR als auch DLSS berechnen zumindest Teile des Post-Processings in nativer Auflösung, FSR 1.0 in diesem Fall nicht, das dürfte einen nicht unbeträchtlichen Anteil an den höheren Performance-Kosten von TSR und DLSS im Vergleich zu FSR ausmachen.

Interessant bei FSR: Sie können erkennen, dass zumindest einige Post-Processing-Anteile VOR dem Upsampling gerendert werden, also ebenfalls in reduzierter Auflösung. Dies ist sehr gut sichtbar an der Chroma-Verschiebung etwa an der Fassade unterhalb des grünen Schildes mittig im Bild - während sowohl TSR als auch DLSS den Effekt NACH dem Upsampling in nativer Auflösung applizieren. Da dies nicht nur auf die Chroma-Verschiebung, sondern wohl auch auf einige andere Effekte zutrifft (etwa auch die anspruchsvolle SSGI oder das Depth of Field), ist somit ein Teil der höheren Leistungskosten von DLSS und TSR gegenüber FSR zu erklären - und ein Anteil der optisch schlechter und krümeliger anmutenden Hochskalierung generell.

https://www.pcgameshardware.de/Ghostwire-Tokyo-Spiel-67695/Specials/Test-Release-Review-Benchmark-Raytracing-1391882/

Bildvergleich (https://www.pcgameshardware.de/commoncfm/comparison/clickSwitchNew.cfm?article=1391882&page=1&draft=-1&rank=5)

basix

2022-03-30, 13:16:57

Spannend, dass FSR 1.0 hier anders behandelt wird.

Die momentane "Analyse" zeigt (siehe die letzten 15-20 Posts), dass DLSS 2.0 und TSR gleich viel Ausführungszeit auf einer 3090 benötigen. Verglichen zur Performance der nativen Renderauflösung (z.B. 1080p) ist nicht alles davon TSR und DLSS, ein guter Teil davon ist das Post-Processing in höheren der Output-Auflösung. Und AMDs FSR 2.0 wird anhand der Quervergleiche und Performance-Angaben von AMD vermutlich sehr ähnlich abschneiden. Verglichen mit nativer 1080p Auflösung bedeutet das: ~1ms für FSR 2.0; ~1ms fürs Post Processing in 4K.

aufkrawall

2022-03-30, 15:01:56

Ist das TAUU in einer neueren Form oder bereits TSR oder etwas separates was dazwischen liegt?
Schätze, das ist noch nicht TSR, aber auch nicht so gravierend weit davon weg. Genau wissen könnte man es, indem man einfach mal in einem UE5-Projekt oder -Spiel damit rumprobiert.

blaidd

2022-03-30, 17:12:30

Schätze, das ist noch nicht TSR, aber auch nicht so gravierend weit davon weg. Genau wissen könnte man es, indem man einfach mal in einem UE5-Projekt oder -Spiel damit rumprobiert.

Bei der UE5 kann man mehrere verschiedene nutzen.

r.TemporalAA.Algorithm 0 ist TAA Gen 4
r.TemporalAA.Algorithm 1 ist "Next-Gen" TAA Gen 5 - das ist aber offenbar ein bisschen anders als bei der UE4, da aktiviert der Befehl TAA Gen 5, bei der UE5 ist es aber TSR. Ich nehme an, die sind relativ eng verwandt.

TAAU geht an, wenn man zudem noch das Upsampling zuschaltet (r.TemporalAA.Upsampling 1).

Bei r.TemporalAA.Upsampling 0 wird nur reguläres spatiales Upsampling genutzt, das erst nach dem Großteil der Berechnungen (inklusive Post-Provessing und dem TAA) appliziert wird.Da kann man dann noch ein paar verschiedene Filter nutzen (von 0 = Bicubic bis 5= 36-tap Gaussian-filtered unsharp mask. Standard ist 3 = 5-tap Catmull-Rom bicubic, approximating Lanczos 2)

Das erste ist im Grunde nur als Kantenglättung gedacht, das zweite in erster Linie als Upsampling-Verfahren (das ist auch merklich teurer)
https://docs.unrealengine.com/4.27/en-US/RenderingAndGraphics/ScreenPercentage/
(https://docs.unrealengine.com/4.27/en-US/RenderingAndGraphics/ScreenPercentage/)

aufkrawall

2022-03-30, 17:15:47

blaidd

2022-03-30, 17:47:41

Ok, das klingt jetzt aber nicht anders als bei aktuellen UE4-Versionen. Dann könnte das TAA Gen 5 + TAAU in der UE4 schon das "TSR" aus der UE5 sein.
Wenn das so wäre, dann verstünde ich den Hype darum überhaupt nicht.

Ich nehme an, da gibt es noch gewisse Unterschiede. Das TAA Gen 5 ist das, was gerade in relativ vielen UE4-Spielen genutzt wird (z.B. Chernobylite, Necromunda, Assetto Corsa Competizione...). Das TSR in z.B. Ghostwire Tokyo wirkt nochmal eine ganze Ecke stabiler und sauberer. Aber vielleicht sind das hauptsächlich Tweaks etc. man kann (zumindest theoretisch, damit habe ich mich noch nicht so richtig befasst) auch Jitter bzw. den Umfang davon etc. verändern.

Gibt auch noch ein paar andere Schalter, die in der UE5 noch als "experimental" bezeichnet werden, etwa diesen hier r.TemporalAA.R11G11B10History=0/1 (der soll die Performance verbessern, aber das geht wohl zu Lasten von Ghosting). Das hab ich aber alles noch nicht groß ausprobieren können und die UE-Community rätselt selbst noch ein wenig daran herum - ich nehme an, da kommen noch ein paar Verbesserungen und Optimierungen, ein paar Macken hat TSR jedenfalls noch (wenn man die Auflösung zu weit reduziert, gibt's z.B. bunt funkelnde Sternchen auf dem Schirm, hier und da ghostet's noch recht stark, usw.)

crux2005

2022-03-30, 22:21:48

The Division 2 bekommt DLSS Unterstützung: https://www.reddit.com/r/nvidia/comments/tsbr7m/division_2_is_finally_getting_dlss/

Wird wohl mit dem neuen "Frontiers of Pandora" Spiel zusammenhängen. Also die Implementierung in die Snowdrop Engine.
https://twitter.com/TheDivisionGame/status/1509216015963537411?cxt=HHwWhoCyjY3-5_EpAAAA

-/\-CruNcher-/\-

2022-03-30, 22:48:32

Ok, das klingt jetzt aber nicht anders als bei aktuellen UE4-Versionen. Dann könnte das TAA Gen 5 + TAAU in der UE4 schon das "TSR" aus der UE5 sein.
Wenn das so wäre, dann verstünde ich den Hype darum überhaupt nicht.

Gen 5 Kamm erst später nur es ist ordentlich in der Lage Ghosting zu verhindern, wenn die Assets optimal konfiguriert worden sind kostet aber auch etwas mehr Latenz es kommt auch drauf an welcher Core genutzt wird da in älteren Release Cores, als wie lass mich lügen „offiziell“ stable muss es um 4.27 geworden sein, allerdings wurde es primär für 5 in Zusammenspiel mit Nanite und Lumen entwickelt und so nur sporadisch backgeportet.

blaidd

2022-03-31, 01:03:44

Gen 5 Kamm erst später nur es ist ordentlich in der Lage Ghosting zu verhindern, wenn die Assets optimal konfiguriert worden sind kostet aber auch etwas mehr Latenz es kommt auch drauf an welcher Core genutzt wird da in älteren Release Cores, als wie lass mich lügen „offiziell“ stable muss es um 4.27 geworden sein, allerdings wurde es primär für 5 in Zusammenspiel mit Nanite und Lumen entwickelt und so nur sporadisch backgeportet.

Das "backported" hab ich auch schon mehrfach irgendwo gehört oder gelesen... aber ich hab auf die Schnelle nicht mehr gefunden was oder wo (zumindest nichts verlässliches). Aber ich schätze, das Ganze ist schon relativ nah verwandt.

Was ich interessant finde:TSR und DLSS sehen sich in einigen Belangen auch verdammt ähnlich. Neural Network oder nicht, das erscheint vom Grundkonzept jedenfalls relativ ähnlich (https://www.pcgameshardware.de/commoncfm/comparison/clickSwitchNew.cfm?article=1391882&page=1&draft=-1&rank=4).

-/\-CruNcher-/\-

2022-03-31, 02:51:44

Was hier am meisten aua im Visuellen Cortex verursacht, behebt man hiermit

r.SceneColorFringe.Max=0
r.SceneColorFringeQuality=0

robbitop

2022-03-31, 14:31:37

Was ich interessant finde:TSR und DLSS sehen sich in einigen Belangen auch verdammt ähnlich. Neural Network oder nicht, das erscheint vom Grundkonzept jedenfalls relativ ähnlich (https://www.pcgameshardware.de/commoncfm/comparison/clickSwitchNew.cfm?article=1391882&page=1&draft=-1&rank=4).
Beides temporales Supersampling Verfahren. Der Unterschied liegt in den Clampingmechanismen. Das ist nichts neues. In Bewegung trennt sich dann aber die Spreu vom Weizen.

aufkrawall

2022-03-31, 14:37:21

Leider 4k, jpeg, massives CA & Grain...

Tesseract

2022-03-31, 15:18:42

das post processing ist so dermaßen deep-fried dass selbst native wie 800*600 aussieht. :freak:

Ex3cut3r

2022-03-31, 18:11:38

:uup:

Ich kann mit dem ganzen Spiel nix anfangen.

Bei PCGH gibt es übrigens CPU Benchmarks, mit RT steigen die CPU Anforderungen nochmal immens, allerdings mir unerklärlich warum das Game solche niedrigen CPU FPS ausspuckt. CP77 hat eine ähnliche Grafik und eine gewisse Open World mit Tonnen an NPCs teilweise und läuft besser. :freak:

Außerdem mal wieder das typische Shader Compile Ruckeln der UE4.

robbitop

2022-04-01, 07:14:06

Wuge

2022-04-01, 10:43:34

CoD Black Ops oder wie das Ding heißt, dass es damals zur 3090 dazu gab kompiliert die Shader beim ersten Laden. DCS macht das auch, warteste beim ersten Laden nach installation eines Shader Mods durchaus mal ein paar Minuten. Dafür gibts danach keine Hickups.

robbitop

2022-04-01, 10:55:39

Lieber warten als stottern. ;)

crux2005

2022-04-01, 14:50:06

Weil das mit dem Shadercompilingruckeln in letzter Zeit öfter mal auftritt: kann man das nicht quasi in der Ladezeit vorkompilieren? Ich meine mich erinnern zu können, dass es Spiele gab, die beim Laden angezeigt haben was sie tun und da stand auch mal "kompiliere shader".
Warum muss das Online geschehen und uns die Frametimes versauen? Kann man doch beim ersten Start kompilieren oder bei der Installation oder sowas.

Das hängt mit UE4 und der Anzahl an verschiedenen Shadern zusammen. Erinnere mich an kein UE Spiel das die Shader beim starten kompiliert. Epic interessiert es offensichtlich nicht und die Studios bekommen das (bis auf paar Ausnahmen wie The Coalition) nicht hin.

Ex3cut3r

2022-04-01, 14:58:16

Ganz genau, das tritt bei jedem UE4 Spiel auf, und ich letzter Zeit kommen verdammt viele mit der UE4 raus. Mir auch ein Rätsel warum da nicht einfach vorher kompiliert wird, aber es ist tatsächlich immer wieder der Fall. Und es ist scheißegal wie stark deine HW ist, du wirst unerträgliche Ruckler ingame haben!

Am besten bezahlt man jemanden, der das Spiel erstmalig für dich einmal durchspielt, und dann bist du dran. X-D

aufkrawall

2022-04-01, 17:04:21

Erinnere mich an kein UE Spiel das die Shader beim starten kompiliert
Days Gone.

Ex3cut3r

2022-04-01, 17:23:26

Wenn das so ist. Warum ruckelt Days Gone immer wieder mal, vorallem beim Fahren/Streaming?
Selbst mit Nvidia und Null im Treiber, ist es nicht das gelbe vom Ei.

Mir allgemein ein Rätsel warum PCler immer so eine Gängelung hinnehmen müssen. Direct Storage wurde nur halb released der wichtige IO Part fehlt bis 2025 (meine Vermutung) Konsolen haben es seit dem PS5 rls drin.

Immer wieder Shader Compile Ruckler/Probleme. Also geht mir sowas richtig auf den Sack, vorallem mit VRR sind gute Frametimes nochmal wichtiger. Zwar kaufe ich meistens sowieso nur bei Key Reseller, aber ich stelle mir grade vor, ich wurde die Steam Preise beim release zahlen, 60€ und es ist es wirklich gut spielbar in einem halben wenn nicht sogar erst nach einem ganzen Jahr und zig Patches.

aufkrawall

2022-04-01, 17:31:16

Wenn das so ist. Warum ruckelt Days Gone immer wieder mal, vorallem beim Fahren/Streaming?

Ressourcen-Verwaltung, seit wann ist jeder Ruckler durch Shader Compile?
Btw. ziemlich OT.

-/\-CruNcher-/\-

2022-04-01, 23:48:55

IO probleme, Shader Compiler, Background Task (Process Hooks,Low Level System Drivers, Power Management), so viele Möglichkeiten von Race Conditions und oder thread locks ;)
Merke in Windows Handles und Timer immer auf minimum halten.

Lurtz

2022-04-02, 09:26:04

Mir allgemein ein Rätsel warum PCler immer so eine Gängelung hinnehmen müssen.
Die PS5 hat bis heute kein VRR... Das Gras ist auf der anderen Seite des Gartenzauns auch nicht immer grüner.

crux2005

2022-04-02, 13:59:00

Die PS5 hat bis heute kein VRR... Das Gras ist auf der anderen Seite des Gartenzauns auch nicht immer grüner.

Ich dachte das hätten sie mit dem letzten Update hinzugefügt. Evtl. täuscht mich meine Erinnerung.

DrFreaK666

2022-04-02, 14:05:13

Ich dachte das hätten sie mit dem letzten Update hinzugefügt. Evtl. täuscht mich meine Erinnerung.

Es würde angekündigt. Mehr aber auch nicht

Akkarin

2022-04-02, 20:47:50

Woher kommt das ghosting/schmieren bei TAA/DLSS/etc.pp eigentlich ? Wenn man motion vectors hat müsste es doch eigentlich trivial sein kein ghosting mehr zu haben ? Aber wenn so viele Entwickler da so viel R&D rein stecken stimmt das natürlich nicht, aber warum ?

robbitop

2022-04-02, 21:35:08

Das ist halt keine 2D Grafik. Wenn die Geometrie sich perspektivisch verändert passt die Subpixelfarbe nicht mehr. Die Güte bzw die Trefferrate des Wiederfindens (clamping) entscheidet darüber wie viele Samples artefaktnormiert akkumuliert werden können.
Die Güte der Implementierung des Verfahrens spielt auch mit rein.
Wenn man ghosting sieht, ist das clamping zu aggressiv eingestellt. Ist auch situationsabhängig. Weniger aggressiv würde dann aber auch zu weniger rekonstruierter Auflösung führen. Also sieht dann blocky aus.
Clamping ist alles andere als Trivial und auch die Erkennung ob das Ergebnis passt oder nicht. Gerade das ist die geoße Stärke des NN basierten Clampings bei DLSS.

Gast

2022-04-03, 02:10:34

Woher kommt das ghosting/schmieren bei TAA/DLSS/etc.pp eigentlich ? Wenn man motion vectors hat müsste es doch eigentlich trivial sein kein ghosting mehr zu haben ?

Motion Vectors sind nicht immer perfekt und können teilweise auch komplett fehlen.

BTW: du plenkst.

basix

2022-04-03, 12:40:23

Motion Vectors sind nicht immer perfekt und können teilweise auch komplett fehlen.

Und sie liegen nur mit einem 3x3 Pixelraster vor (Gründe dafür wird es wohl geben). Bei einem 1080p Render-Bild also nur mit 360p.

Motion Vectors mit höherer Auflösung und 3D-Koordinaten könnte vermutlich einiges bringen. Heute hat man den Depth Buffer, mit welchem man wohl zusammen mit den 2D-Motion Vectors einiges interpolieren kann. Mehr und bessere Daten sind aber immer besser.

Für 3D-Motion Vectors benötigt man aber wohl eine Anpassung der Engines. Depth Buffer und 2D-Motion Vectors sind in vielen Engines aufgrund der generellen Rendering Pipeline und TAA schon sehr oft vorhanden. Deswegen hat man vermutlich die Temporal Upsampling Algorithmen auch darauf aufgsetzt. Das heisst aber nicht, dass das schon die optimale Umsetzung ist.

Geldmann3

2022-04-07, 08:55:29

basix

2022-04-07, 12:19:24

Generell hoffe ich, dass temporales Upsampling in Zukunft wesentlich flexibler werden kann. Das ist in den UE5 Demos z.b. zum Kotzen, um den Charakter herum.
Solche Stellen müsste man in meinen Augen erkennen und hier auf klassisches Supersampling zurückfallen, auch, wenn das teuer ist.
Oder im Sparmodus wenigstens nativ rendern.

Temporaler Shit funktioniert ja bei 95% des Bildes super, doch die restlichen 5% brauchen eine Spezialbehandlung.

Das was du da vorschlägst ist prinzipiell VRS (variable resolution scaling) oder alternativ VRS (variable rate shading) um Punkte herum, welche wichtig sind oder im Fokus stehen. Könnte mir schon vorstellen, dass das eine sehr schöne Ergänzung zu Temporal Upsampling Algorithmen wäre. Alternativ gleich in sagen wir mal ein DLSS 3.0 integriert.

Das Handling dieser Zusätze ist allerdings definitiv Aufgabe der Engine. DLSS könnte allerdings von diesen "Importance Sampling" Informationen profitieren und dort entsprechend die Parameter des Upsamplings anpassen.

Gast

2022-04-07, 13:29:29

Temporaler Shit funktioniert ja bei 95% des Bildes super, doch die restlichen 5% brauchen eine Spezialbehandlung.

Mit Rasterizing wird es eher schwer, aber mit Raytracing ist das ohne große Probleme umsetzbar, indem man für die erkannten Pixel einfach weitere Strahlen verschießt.

Gast

2022-04-07, 13:31:43

Das was du da vorschlägst ist prinzipiell VRS (variable resolution scaling) oder alternativ VRS (variable rate shading) um Punkte herum, welche wichtig sind oder im Fokus stehen.

Mit VRS geht das nicht, da hier immer noch die volle Auflösung gerastert wird, und nur im Pixelshader auf eine geringere Auflösung zurückgeschaltet wird.

Genauer gesagt ist es sogar fast das Gegenteil, was man hier bräuchte ist eine pro Pixel (nicht nur pro Frame) dynamische Kantenauflösung, VRS kann diese nur innerhalb der Flächen variieren.

Geldmann3

2022-04-07, 16:38:35

Wobei bin mir da nicht ganz sicher, ob das Aufgabe der Engine wäre.

Wenn irgendwo etwas aus der Occlusion eines Objektes kommt, gibt es dafür erstmal keine ordentlichen Samples, sowas sollte das Upsampling auch selbst erkennen und behandeln können.
Das ist ja das Problem, um den Charakter herum.

basix

2022-04-07, 22:05:46

Es ist halt einfacher, wenn gerade in diesem kritischen Bereich mehr Informationen vorliegen. Das kann nur die Engine selbst bereitstellen.

iamthebear

2022-04-07, 23:28:56

Ich denke das sind 2 komplett verschiedene Ansätze:
a) Wenn der Upscaler nur eine feste Auflösung bekommt muss er das Beste daraus machen. Die Lösung wäre deshalb an den Kanten weniger aggressives Upscaling zu betreiben was das Ganze an den Kanten etwas verschwommener wirken lässt.

b) Die Engine wäre in der Lage an den Kanten mit erhöhter Auflösung zu rendern. Das Problem daran:
Das ist dann eine Implementierung pro Engine. Das könnte vielleicht der richtige Weg sein für engine gebundene Upscaler wie TSR. Aber die Hwrausforderung von DLSS/XeSS/FSR ist, dass man einen Upscaler entwickelt, der ohne großen Aufwand in einen Großteil der am Markt verwendeten Engines eingebunden werden kann.

robbitop

2022-04-08, 08:23:30

Geldmann3

2022-04-08, 08:39:47

Ich hatte genau dieses Problem mal unter einem UE5 Entwicklervideo angesprochen und wenn ich mich richtig erinnere, war wegen Nanite diesbezüglich nichts geplant. Soll schwer zu implementieren sein.

basix

2022-04-08, 09:33:18

Ist für Nanite eigentlich ein Modus für temporales Upscaling vorgesehen? IIRC erzeugt Nanite dynamisch eine an die Auflösung gekoppelte Geometrie. 1x Dreieck pro Pixel. Mit niedrigerer Auflösung also auch weniger Geometrie. Wenn jetzt aber temporales Downsampling zum Einsatz kommt, passt das Geometriedetail nicht mehr zur Endauflösung. Entsprechend müsste Nanite die Geometrie zur Outputauflösung generieren anstatt zur Inputauflösung.
Dazu natürlich auch ein negatives Textur LoD.

Prinzipiell wäre Nanite ideal dafür geeignet. Man müsste das Sample-Jittering einfach auf die Nanite-Geometrie übertragen. Das wird vermutlich aber etwas an Performance kosten, da die Nanite Geometrie öfters geupdated werden muss. Allenfalls muss man die Nanite Geometrie intern in der Outputauflösung vorhalten, damit das einfacher geht.

Das Problem besteht aber generell. Wenn aufgrund der reduzierten Auflösung LoDs oder Geometriedetails reduziert werden, wird das nach dem Temporal Upsampling fehlen. Momentan scheint das bei allen Engines so zu sein. LoD und MIP Bias sind noch einfach zu beheben. Fehlende Geometrie-Details und reduzierte Shadow-Map und RT-Auflösung scheinen stärker in den Engines verankert zu sein.

Geldmann3

2022-04-08, 10:13:29

Ich vermute ja, dass das den Entwicklern völlig bewusst ist, sie Nanite aber in der internen Auflösung berechnen, damit TSR in der Lage ist mehr Performance einzusparen. Nur würde ich mir einen Toggle wünschen, um die Nanite Meshes auf Wunsch immer nativ vorzuhalten.

robbitop

2022-04-08, 10:16:03

Prinzipiell wäre Nanite ideal dafür geeignet. Man müsste das Sample-Jittering einfach auf die Nanite-Geometrie übertragen. Das wird vermutlich aber etwas an Performance kosten, da die Nanite Geometrie öfters geupdated werden muss. Allenfalls muss man die Nanite Geometrie intern in der Outputauflösung vorhalten, damit das einfacher geht.

Das Problem besteht aber generell. Wenn aufgrund der reduzierten Auflösung LoDs oder Geometriedetails reduziert werden, wird das nach dem Temporal Upsampling fehlen. Momentan scheint das bei allen Engines so zu sein. LoD und MIP Bias sind noch einfach zu beheben. Fehlende Geometrie-Details und reduzierte Shadow-Map und RT-Auflösung scheinen stärker in den Engines verankert zu sein.
IMO muss obiges nicht mal unbedingt sein. Erzeuge einfach mehr Dreiecke. Ist doch kein Drama wenn es mehr Dreiecke pro Pixel hjat. Ist ja heute z.T. auch der Fall.
Was du beschreibst wäre der Idealfall aber mein beschriebener Fallback wäre IMO gut genug.

basix

2022-04-08, 12:02:26

Klar, Nanite kann/sollte sich an der Ausgabeauflösung orientieren und gut ist. Genauso wie alle anderen Systeme, welche mit der Auflösung skalieren (z.B. MIP Bias).

- Wird je nach System Performance kosten (finde ich aber OK, die Qualität steigt)
- Die Engine muss für dieses Konzept vorbereitet worden sein. Was wohl einfach noch keine Engine kann. Das war bisher einfach noch keine Anforderung.

Und ein Toggle Switch wie ihn Geldmann beschreibt wäre auch top. Bei Bedarf nur die geringere interne Auflösung nehmen, wenn man etwas mehr Performance will. Oder alternativ maximale Qualität und dafür etwas reduzierter Performance. Ich stelle mir die Implementation in der Engine aber komplex vor. Toll wäre es dennoch.

robbitop

2022-04-08, 13:38:45

Lurtz

2022-04-15, 11:54:35

Diablo 2 Resurrected Patch 2.4:
Fixed artifacting that could occur on certain VFX when using DLSS
Fixed a DLSS-related ghosting artifact that could occur on moving objects while the game camera is stationary
https://news.blizzard.com/en-us/diablo2/23788293/diablo-ii-resurrected-patch-2-4-now-live#bugs

basix

2022-04-15, 13:35:38

Wobei es merkwürdig ist, wenn die brandneue UE5 mit Nanite nicht darauf vorbereitet ist obwohl TSR ja ein solches temporales Upsampling Verfahren ist, welches das braucht um korrekt zu funkionieren. Und dazu kommt, dass es mit TAAU ja auch schon einen Vorläufer seit Jahren gab der grundsätzlich genau so funktioniert. Verstehe dann nicht, warum man die Engine nicht gleich daran angepasst hat bzw in dem Fall Nanite. Wirkt auf mich "disconnected".

Soweit ich verstanden habe, ist Nanite recht komplex. Es funktioniert nur für Static Meshes und der Brian Karis hat jahrelang daran rumgetüftelt. Anscheinend gibt es, wenn man Nanite falsch umsetzt, etliche Varianten von Artefakten und Fehldarstellungen. Und performant laufen soll es dann auch noch. Evtl. ist das mal Nanite v1.0. Spätere Versionen aka Nanite v2.0 können dann auch Vegetation oder wie hier angesprochen "Temporal Geometry Upssampling".

Genau das selbe gilt für RT. Momentan reduziert sich die RT-Qualität mit reduzierter Render-Auflösung. RT in Form von Lumen ist ebenfalls noch relativ jung. Ich kann mir vorstellen, dass Lumen v2.0 sich ebenfalls in Richtung Temporal Upsampling entwickeln wird. Temporal Accumulation ist bereits vorhanden, damit RT performant läuft.

Grundsätzlich wäre das ein Trend für die gesamte Engine-Industrie. Render-Systeme wie Geometrie, RT, sonstige Schatten und Beleuchtungseffekte, Volumetrics, MIP/LOD Bias etc. sollten sich bezüglich Auflösung und Qualität an der Ausgabeauflösung orientieren. Dazwischen passiert Sample Jitterung usw. sowie Temporal Upsampling. Damit erreicht man "True Upsampling", wo Qualitätsunterschiede in Form von Auflösung der verschiedenen Sub-Rendersysteme nicht mehr auftreten.

aufkrawall

2022-04-27, 00:37:30

*seufz*
Aktiviert man in SW3 DLSS, ist r.SSR.Temporal nicht mehr =1 gesetzt. Default vs. über Config =1 erzwungen:
https://abload.de/thumb/sw3_2022_04_27_00_26_pvji7.png (https://abload.de/image.php?img=sw3_2022_04_27_00_26_pvji7.png) https://abload.de/thumb/sw3_2022_04_27_00_31_abjzy.png (https://abload.de/image.php?img=sw3_2022_04_27_00_31_abjzy.png)

Entwickler können echt viele Fehler machen. :frown:

Lurtz

2022-05-15, 21:36:22

Es gibt eine neue DLL, 2.4.3.

Raff

2022-05-15, 21:44:04

Quelle, Changelog? :)

MfG
Raff

aufkrawall

2022-05-15, 21:46:00

Wie immer TPU.
Besser als 2.4.0, schliert aber immer noch deutlich mehr als 2.2.6 in Doom Eternal.
2.2.6 versagt übrigens ganz gut mit dem Zaun im Komplex-Level in Deathloop.

aufkrawall

2022-05-24, 15:56:30

Hitman 3 shipt 2.3.2. Könnte schlimmer sein, könnte besser sein...
https://abload.de/thumb/hitman3_2022_05_24_158sjvh.png (https://abload.de/image.php?img=hitman3_2022_05_24_158sjvh.png) https://abload.de/thumb/hitman3_2022_05_24_15knjb2.png (https://abload.de/image.php?img=hitman3_2022_05_24_15knjb2.png)

Besser könnte auch die Skalierung bei viel Vegetation sein ;D :
https://abload.de/thumb/hitman3_2022_05_24_15erjpv.png (https://abload.de/image.php?img=hitman3_2022_05_24_15erjpv.png) https://abload.de/thumb/hitman3_2022_05_24_15wujjz.png (https://abload.de/image.php?img=hitman3_2022_05_24_15wujjz.png)

crux2005

2022-06-03, 23:11:36

basix

2022-06-04, 12:21:39

robbitop

2022-06-04, 12:28:40

Es müsste einfach auch ein DLDSR 4x geben - dann könnte man das mit DLSS-P kombinieren und dss beste aus allen Welten haben. Das Spielchen kann man mit DLSS-UP und 3x3 DSR weiter treiben. Allerdings kostet der DLSS overhead extremst viel bei UP iirc.

basix

2022-06-04, 13:04:59

DSR 4x ist ganz OK. DLDSR 4x? Gerne, sofern sinnvoll.

Was generell interessant wäre zum Vergleichen:
- DLSS-P + DSR 4x / DLDSR 4x
- DLAA

Selbe Rendering und Output-Auflösung, fast identische Performance.

Tobalt

2022-06-04, 13:05:55

diese Kombination ist IMO vollständig sinnfrei. Besser wäre wenn die Renderauflösung einfach gleich auch jenseits der Displayauflösung skalieren kann. Weniger Schritte, besseres Ergebnis, mehr Performance schätzungsweise.

Da Nv dies scheinbar nicht bieten möchte, kommt es hoffentlich mal via dynamic resolution scaling oder FSR legt vor.

Ex3cut3r

2022-06-04, 13:14:23

Bin mir nicht sicher ob das hier rein passt, aber spiele aktuell SOMA mit 2,25x DLDSR. Wenn die Auflösung im Spiel (3840x2160) verfügbar ist läuft auch die "DL" Variante? Irgendwie kann es mich nicht ganz überzeugen. Ja, die Leistung ist besser ggü. 4x (100 anstatt 80 FPS) aber ansonsten sieht 4x besser aus.

Wecher Smoothing Wert? Bei DL braucht es mehr % als beim klassischen DSR, ich z.B. nutze 50% bei dir kanns durch einen anderen Monitor auch nochmal ein bisschen höher sein, ausprobieren.

crux2005

2022-06-04, 16:52:01

Du hast einen 1440p Monitor, nehme ich an?

Im Nvidia Control Panel ist es ja direkt ersichtlich: "DL-Skalierung" oder "veraltete Skalierung". Wenn du dort die Faktoren 1.78x und 2.25x bei "DL-Skalierung" ausgewählt hast, ist es DLDSR 2.25x, wenn du 2160p als Auflösung auswählst.

Und wenn du 4x anwählst (ohne DLSS und Co) wirst du entsprechend auch in 2880p anstatt 2160p rendern (du wählst 2880p als Auflösung aus). Ausser du hast deine Desktop-Auflösung von 1440p auf 1080p runtergestellt (was ich jetzt nicht annehme). Deswegen die bessere Qualität und die niedrigeren FPS. DSR / DLDSR kostet fast nichts an Performance, 20fps Unterschied deuten eindeutig eine andere Renderauflösung an.

Alles sofern korrekt. 1440p Monitor, 144Hz, DLDSR 2,25x im Treiber und dann "4K" im Spiel ausgewählt.

Erinnere mich aber das Nvidia meinte 2,25x DLDSR sei visuell mit 4x DSR ebenbürtig. Ist es aber nicht.
Wenn du testen willst:
Vergleiche doch das alte 2.25x DSR mit dem neuen DLDSR. Die Qualität ist schon besser ;)

Auf die Idee kam ich gestern schon selber. Gegen übliches 2,25x DSR ist 2,25x DLDSR schon besser. Kostet an meiner Stelle aber auch mehr Leistung.

Meine Erfahrung zu DLSDSR:
Eigentlich ganz gut. Aber 4x DSR ist normalerweise leicht im Vorteil. Wie habe ich das getestet: Horizon Zero Dawn mit DLSS. Der Vergleich ist aber auch nicht ganz fair: 2880p mit DLSS-P und 4x DSR auf 1440p vs. 2160p mit DLSS-Q aund 2.25x DLDSR auf 1440p. In beiden Fällen ist die Renderauflösung 1440p. Was bei DLSS ist: Qualität steigt mit erhöhter Ausgabeauflösung. Ein wirklich neutraler Vergleich ist nicht machbar, da Render- und Outputauflösungen identisch sein sollten, was aufgrund der verschiedenen Faktoren ja gar nicht wirklich geht. DLSS-Q vs. P ist hier mMn noch am nächsten dran. Oder eben das alte DSR vs. DLDSR.

SOMA ist von 2015 und unterstützt kein DLSS, FSR oder sogar TAA. Daher bin ich froh die Kantenglättung mit DLDSR aufwerten zu können.

Wecher Smoothing Wert? Bei DL braucht es mehr % als beim klassischen DSR, ich z.B. nutze 50% bei dir kanns durch einen anderen Monitor auch nochmal ein bisschen höher sein, ausprobieren.

Daran könnte es liegen. Habe 40% smoothing mit 2,25x DLDSR eingestellt. Laut Beschreibung sollte "niedrigerer Wert = schärfer" sein. 50% ging auch noch.

aufkrawall

2022-06-10, 15:04:38

Daran könnte es liegen. Habe 40% smoothing mit 2,25x DLDSR eingestellt. Laut Beschreibung sollte "niedrigerer Wert = schärfer" sein. 50% ging auch noch.
Das scheint sich mit DLDSR allerdings nur auf Flächeninhalte, also Texturen, und nicht auf Kanten zu beziehen. Ich fand nur 100% in Witcher 3 gut, tiefere Werte sahen nach komischen DL-Manipulationen aus. DLDSR bräuchte imho noch etwas Sharpen nach dem Runterskalieren für höhere Kanten-Kontraste, aber das geht derzeit leider nur via Monitor/TV.

Mal die Bewegungsunschärfe von DLSS 2.4.3 vs. das Doom Eternal TAA bei gleichen fps verglichen:
https://abload.de/thumb/doometernalx64vk_2022takeq.png (https://abload.de/image.php?img=doometernalx64vk_2022takeq.png) https://abload.de/thumb/doometernalx64vk_202295k1v.png (https://abload.de/image.php?img=doometernalx64vk_202295k1v.png)

DLSS ist schärfer. Man kann auch noch erkennen, dass die Asche-Partikel mit TAA stärker ghosten als mit DLSS. Schon nicht übel für 100% vs. 66% Renderauflösung pro Achse.

aufkrawall

2022-06-12, 15:26:10

Wie schon SW3, skaliert auch die UE5 D3D12 ziemlich gut mit der Auflösung. Bekomme häufig >=45% mehr Performance durch DLSS Q in 1440p raus:
https://abload.de/thumb/fortniteclient-win64-cmk76.png (https://abload.de/image.php?img=fortniteclient-win64-cmk76.png) https://abload.de/thumb/fortniteclient-win64-o6jn0.png (https://abload.de/image.php?img=fortniteclient-win64-o6jn0.png)
Zum Glück wendet das Spiel sein eigenes Sharpen auch mit DLSS an, sieht richtig genial aus für Quality.

aufkrawall

2022-06-26, 11:01:28

Weniger Ghosting mit DLSS als mit TAA :) :
https://abload.de/thumb/fortniteclient-win64-xzj3b.png (https://abload.de/image.php?img=fortniteclient-win64-xzj3b.png) https://abload.de/thumb/fortniteclient-win64-cpkjq.png (https://abload.de/image.php?img=fortniteclient-win64-cpkjq.png)

Troyan

2022-06-27, 13:43:06

F1 2022 hat die 2.4 Version. Mal sehen, ob das Upscaling besser ist als in 21.

/edit: Durch den FSR 2.0 Mod sieht man auch, wie genial die Idee des Ausgliederns aus der Engine in eine extra-Datei ist. Eigentlich sollten Entwickler mit einer Dummy-Datei sogar Dritt-Upscaler ermöglichen.

aufkrawall

2022-06-27, 13:48:11

F1 2022 hat die 2.4 Version. Mal sehen, ob das Upscaling besser ist als in 21.

Welche 2.4-Version? Die 2.4.0 aus den SDKs ist unbrauchbar.

Troyan

2022-06-27, 14:03:57

2.4.0. :eek:

aufkrawall

2022-07-02, 12:06:56

MAX|HASS

2022-07-10, 10:30:00

**muß ich wohl woanders fragen.

fondness

2022-07-10, 10:42:30

Geht ja im FSR 2.0-Thread oft um dessen Disocclusion-Problem. Mit DLSS gibt es das quasi gar nicht, anders als UE5 TAA fast keine Artefakte um die sich vor dem Gras seitwärts bewegende Figur:
https://abload.de/thumb/fortniteclient-win64-vdk0n.png (https://abload.de/image.php?img=fortniteclient-win64-vdk0n.png) https://abload.de/thumb/fortniteclient-win64-1wk2o.png (https://abload.de/image.php?img=fortniteclient-win64-1wk2o.png)

Da sollte es auch dem Letzten einleuchten, dass es in DL2 einfach kaputt implementiert ist:
https://youtu.be/8VG3p-_bXgo

Hat mir der Techland-Support übrigens bestätigt, Fix soll in Arbeit sein.

Wie kann das eigentlich kaputt sein? Bedarf es bei DLSS spezielle Anpassungen pro Spiel? Aktuell wird ja bei einigen Spielen sogar FSR mitten des DLSS-Pfads hinein gehacked. Das hat zwar die typischen Probleme aber "kaputt" scheint nichts davon zu sein.

robbitop

2022-07-10, 12:42:35

Nach meinem Verständnis müssen solche Fälle idealerweise vom Spiel maskiert werden (weil die Erkennung laut FSR 2.0 guideline zumindest aktuell mehr als schwierig ist). Macht aber wohl kaum eines. Entsprechend gibt es Artefakte. Das NN von DLSS wurde anscheinend darauf getunt, das einigermaßen zu erkennen. Man kann zB bei Death Stranding eine alte dll nehmen und sieht wie es ghostet und bei neuen dlls ist das nicht mehr der Fall.
Also biegt es hier das Verfahren wieder halbwegs gerade. Am besten wäre sicherlich eine Maskierung weil die Verfahren sicherlich keine 100%ige Trefferrate (je nach Spiel und Szene - sicherlich ist es nicht ganz grundlos warum es ständig neue dlls gibt) haben und es sicherlich auch Kompromisse hin und wieder gibt (lokales blur).

DrFreaK666

2022-07-10, 13:14:21

Aber ist eine Maskierung nicht nach Szene unterschiedlich oder habe ich da einen Denkfehler?

robbitop

2022-07-10, 13:16:14

Aber ist eine Maskierung nicht nach Szene unterschiedlich oder habe ich da einen Denkfehler?

Das Spiel muss entsprechende Objekte als solche klassifizieren und dynamisch (nach Vorkommen und Positionen) maskieren. Also ja je nach Spiel und Szene. Ich vermute, dass die meisten Spiele das nicht können und es einen gewissen Aufwand kostet diese Funktion nachzurüsten.

DrFreaK666

2022-07-10, 13:19:31

Jetzt sollte man wissen wie viel Mehraufwand das wirklich ist.
Hatten wir nicht mal Programmierer hier im Forum?

robbitop

2022-07-10, 13:27:15

Hängt wahrscheinlich stark von der Engine und den Fähigkeiten des Programmierteams ab. Und wie immer ob man es tut hängt davon ab: Kapazität und Priorität.

ZB bei idtech wäre ich mir relativ sicher, die es korrekt implementieren. Einfach weil das Thema Antialiasing ihnen wichtig ist und Tiago Sousa auch selbst TAA seit der Anfangszeit entwickelt und mitgeprägt hat.
Mal schauen ob und wann es einen Patch für Doom Eternal gibt. Ansonsten erwarte ich für Wolfenstein 3 dann FSR 2.0. (die Engine und der support dafür kommt ja von id)

aufkrawall

2022-07-10, 14:48:29

Wie kann das eigentlich kaputt sein? Bedarf es bei DLSS spezielle Anpassungen pro Spiel? Aktuell wird ja bei einigen Spielen sogar FSR mitten des DLSS-Pfads hinein gehacked. Das hat zwar die typischen Probleme aber "kaputt" scheint nichts davon zu sein.
Ich tippe aufs DLSS Sharpen. Es gibt irgendeinen temporalen Parameter, der mit DLSS Sharpen mitgesetzt wird und temporales Ringing verursacht. In der CryEngine mit ungelockter Konsole kann man den auch einsehen und setzen. Evtl. sitzt der bei Dying Light 2 einfach nicht auf dem neutralen Wert mit DLSS Sharpen 0 und verursacht so unnötig massivsten Motion Blur.
Das DLSS Sharpen wird ja mit dem FSR 2-Mod ebenfalls komplett ersetzt und es wird nur noch die RCAS-Stärke gesetzt. Was auch hervorragend in DL2 funktioniert, brauche so kein ReShade für CAS-Inject. Nvidia hat bei Sharpen leider nur zwei linke Hände.

Gast

2022-07-10, 15:03:44

Das Spiel muss entsprechende Objekte als solche klassifizieren und dynamisch (nach Vorkommen und Positionen) maskieren.

Maskierung ist aber nur eine Krücke, im Endeffekt. Es verhindert zwar Ghosting, aber dafür wird auch die History verworfen und damit hat man nur mehr die schlechte Auflösung eines einzelnen Frames.

Das Aufpixeln was man bei disoclusion beim FSR2.0 sieht zeigt ja gerade dass dieses richtig erkannt wurde, sei es automatisch oder durch Maskierung, ansonsten würde es ja Ghosting geben.

Der große Vorteil von DLSS scheint hier zu sein, dass dieses in solchen Situationen glaubhafte Informationen erfinden kann.

Tobalt

2022-07-10, 20:14:46

"Wie kann etwas kaputt sein?"

Na durch brachiale fahrlässige unter Zeitdruck entstandene Codeglitches. Da sollte man nicht so naiv sein ;)

DLSS schnell ins Menu einfügen, checken ob die DLSS dll auch tatsächlich gecallt wird und fertig. Das Game kriegt publicity als DLSS Adopter, ziel erreicht. bugs und nicht gelesene Implementierungs-guides kann man doch später noch dran arbeiten...

robbitop

2022-07-10, 20:39:17

Maskierung ist aber nur eine Krücke, im Endeffekt. Es verhindert zwar Ghosting, aber dafür wird auch die History verworfen und damit hat man nur mehr die schlechte Auflösung eines einzelnen Frames.

Das Aufpixeln was man bei disoclusion beim FSR2.0 sieht zeigt ja gerade dass dieses richtig erkannt wurde, sei es automatisch oder durch Maskierung, ansonsten würde es ja Ghosting geben.

Der große Vorteil von DLSS scheint hier zu sein, dass dieses in solchen Situationen glaubhafte Informationen erfinden kann.
Glaubhaft und temporal stabil. Das ist schon beeindruckend!

Danke für obige Erklärung- das ergibt Sinn :up:

Raff

2022-07-10, 23:12:38

DLSS Ultra Performance ist in üblichen Auflösungen hässlich. Ohne Zweifel. Es kann gegenüber rein spatialem Upscaling aber schon ein bisschen zaubern. Hier ein Flachköpper-Duell mit internen 853 × 480 Pixel (Ausgabeauflösung 2.560 × 1.440).

F1 22, max. Raytracing, FSR 1.0 UP vs. DLSS 2.4.0.0 UP. Keine Nachschärfung! Sicher, DLSS UP ist hässlich und zeigt klares Aufpixeln - ist aber gegenüber FSR 1.0 UP (das eigentlich ein FSR-2.0-Modus ist, btw) viel, viel besser.

https://abload.de/thumb/f122_fsr1.0upxcklc.png (https://abload.de/image.php?img=f122_fsr1.0upxcklc.png) https://abload.de/thumb/f122_dlss2.aup2pjvc.png (https://abload.de/image.php?img=f122_dlss2.aup2pjvc.png)

Das Texture LOD wird von F1 22 bei DLSS übrigens korrekt auf die Ausgabeauflösung angepasst, was bei F1 2021 zumindest anfangs nicht geschah.

MfG
Raff

Gott1337

2022-07-11, 00:17:18

auf dem Standbild sieht das sogar ganz okay aus

Raff

2022-07-11, 00:32:03

Sagen wir: Es ist akzeptabel. Hier TAA ohne CAS als Rafferenz (hehe).

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

MfG
Raff

Gast

2022-07-11, 07:27:55

DLSS Ultra Performance ist in üblichen Auflösungen hässlich. Ohne Zweifel. Es kann gegenüber rein spatialem Upscaling aber schon ein bisschen zaubern. Hier ein Flachköpper-Duell mit internen 853 × 480 Pixel (Ausgabeauflösung 2.560 × 1.440).

Für die minimalistische Renderauflösung sieht das sogar fantastisch aus. Beeindruckend wie die feinen Zäune rechts immer noch erkennbar bleiben.

Die Erwartungshaltung an DLSS 2.x, nachdem man es erstmals in Wolfenstein Youngblood gesehen hat, dass es trotz besserer Performance sogar besser aussehen kann, und dass auf den ersten Blick sogar Performance zumindest gleichwertig zur nativen Auflösung ist kann UP eben bei weitem nicht erreichen. Mit UP nimmt die Qualität dann doch deutlich gegenüber der nativen Ausgabeauflösung ab, angesichts des Pixelsparens ist das Endergebnis aber immer noch beeindruckend.

BTW: Der Hubschrauber bzw. der Wolkenkratzer dahinter im späteren TAA Shot sieht ja richtig übel aus.

Ex3cut3r

2022-07-13, 19:49:05

Hat schon jemand die 2.4.6 ausgiebig getestet? :smile:

https://www.techpowerup.com/download/nvidia-dlss-dll/

aufkrawall

2022-07-13, 20:27:52

Reiht sich imho ein in 2.3.9 -> 2.4.3. Also empfehlenswert, wenn auch ohne riesige Verbesserung. Ist schwer, das ohne direkten Vergleich genau zusagen, aber vielleicht gibts etwas weniger ausgeprägtes Jittering einiger dünner Linien vs. 2.3.9. Aber vielleicht auch nur Einbildung. "Smearing-Neigung" jedenfalls ~wie 2.3.9/2.4.3.

aufkrawall

2022-07-16, 16:41:29

Mit 516.79 wurd eine DLSS Performance (nicht zu verwechseln mit DLSS Performance 0,5x)-Regression mit RDR2 Vulkan gefixt.

~Standbild (TAA Sharpen 1/3, DLSS Sharpen rausgepatcht, CAS Stärke 1.2 via ReShade für DLSS 2.4.6):
https://abload.de/thumb/rdr22022-07-1616-27-5kfjjq.png (https://abload.de/image.php?img=rdr22022-07-1616-27-5kfjjq.png) https://abload.de/thumb/rdr22022-07-1616-23-039jzp.png (https://abload.de/image.php?img=rdr22022-07-1616-23-039jzp.png)

Bewegtbild:
https://abload.de/thumb/rdr22022-07-1616-29-5mcj3p.png (https://abload.de/image.php?img=rdr22022-07-1616-29-5mcj3p.png) https://abload.de/thumb/rdr22022-07-1616-30-2lnjzz.png (https://abload.de/image.php?img=rdr22022-07-1616-30-2lnjzz.png)

Bessere Grafik und 20% schneller. :)

Lurtz

2022-07-22, 12:27:50

Kann es sein dass CoD Modern Warfare 2019 wieder unter dem üblichen Schrott-DLSS-Sharpen leidet?

Sieht furchtbar aus verglichen mit dem Filmic SMAA 2Tx.

aufkrawall

2022-07-22, 15:40:44

Jap. Nicht ganz so schlimm wie in RDR2 ohne Patcher, aber schon schlimm genug.

Troyan

2022-07-29, 10:19:29

Hitman wurde auf 2.4.3 geupdatet. Habe zwar nur die zweite Trainingsmission von Episode 1 gespielt, aber das massive Ghosting von NPCs habe ich nicht mehr gesehen.

aufkrawall

2022-07-29, 11:09:49

Im Log steht, dass es vorher Probleme mit den neueren Versionen gab. Hatte aber mehrere Level gestartet und nichts in der Richtung bemerkt. So ganz eindeutig, woran es lag oder ob überhaupt irgendwas verbessert wurde, ist der Changelog auch nicht. :freak:

Raff

2022-08-11, 15:09:42

aufkrawall

2022-08-11, 15:13:16

vinacis_vivids

2022-08-11, 15:22:26

DLSS rechnet hardwaremäßig hauptsächlich mit int8. Bei Vektorenmultiplikation mit int8 werden Rundungsfehler ebenfalls mit multipliziert. FSR 2.0 rechnet dagegen mit fp16, also deutlich höhere Präzision und somit auch bessere Ergebnisse.

robbitop

2022-08-11, 18:28:40

Jetzt kommt der Unsinn wieder…
Leider merken Dunning Kruger Betroffene nichts davon.

DrFreaK666

2022-08-11, 21:37:08

Jetzt kommt der Unsinn wieder…
Leider merken Dunning Kruger Betroffene nichts davon.

Was ist dann deine Erklärung dafür, wieso die Tensor-Cores ungenügend beschleunigen?

aufkrawall

2022-08-11, 21:48:11

2.4.12 sieht jedenfalls auch in Fortnite schlechter aus als 2.4.6, enttäuschend. Wird aber nicht der alleinige Grund für die Probleme in Spiderman sein. Schlechte Version, nicht optimale Implementierung und die typischen Schwächen von DLSS summieren sich dort offenbar.

Andron

2022-08-11, 23:03:07

Was ist dann deine Erklärung dafür, wieso die Tensor-Cores ungenügend beschleunigen?

Wie kommst Du darauf, dass die die Tensor Cores ungenügend beschleunigen? Wegen eines Spiels mit suboptimaler DLSS Implementierung? Unterm Strich ist DLSS 2.X die derzeit beste Upsampling-Technologie, die in vielen Spielen sehr gut funktioniert (abgesehen von einigen schlechteren Versionen und Implementierungen, die sich glücklicherweise oft per DLL-Tausch verbessern lassen).

DLSS ist aber eben auch nicht so überlegen und fehlerfrei, wie es einige Hardcorefans hier und in anderen Foren gerne weismachen wollen. Alle Probleme, die durch einen temporalen Ansatz verursacht werden, kann das NN eben nicht lösen, wie man immer wieder sieht. Trotzdem muss man mal die Kirche im Dorf lassen. Welches aktuelle Verfahren ist DLSS denn in der Summe überlegen, abseits von der Hardwarekompatibilität?

FSR 2.0 kommt in einigen Vergleichen eindrucksvoll nahe ran, gleichgezogen hat man insgesamt aber noch nicht.

Ex3cut3r

2022-08-11, 23:11:25

Massiver Fail. Hast du schon eine andere DLSS-Version (2.3.9, 2.4.3 oder 2.4.6) probiert?
Würde mich nicht sonst nicht gänzlich überraschen, wenn ich FSR 2.0 hier vorziehen würde, falls das nicht solche Fails hat.

Wundert mich nicht. Ich finde Nvidis Entwicklung vor allem die Treiber Pflege/Liebe ziemlich ruckständig im Vergleich zu Pascal Zeiten.

Auch rBar ist so ein Thema bei Nvidia was wenig/bis keine Aufmerksamkeit bekommt. Stand heute 20 Games mit rBar Profile Out of the Box ausgestattet. Das neue Spider-Man scheint sehr stark CPU limitiert zu sein, grade hier bringt vlt. rBar etwas. Aber Nvidia bringt einen "Game Ready" Treiber ohne rBar Profil Aktivierung.

DLSS ist auch so eine Geschichte. Viele neue DLLs die schlechter sind als der Vorgänger, DLL wird nicht automatisch mit den Treiber mitgebracht, ok manuell runterladen und einfügen. Dürfte für die meisten User aber zu kompliziert sein. Bzw. wette ich, dass die das nicht mal wissen.

Da fragt man sich schon, was machen die da eigentlich die ganze Zeit?

Also auf Dauer wird man mich so als Kunde nicht behalten können, das kündige ich hiermit offiziell an, auch wenn die nicht mitlesen. ^^

aufkrawall

2022-08-11, 23:21:37

Bei DLSS geb ich dir 100% recht.

rBAR hat allerdings noch einen Haken: Viele Spiele verbrauchen damit ein paar hundert MB mehr VRAM. Das wird dann problematisch, wenn die Spiele so doof sind und unnötig mit damit einhergehenden Einbrüchen Daten aus dem VRAM schmeißen, obwohl noch zig GB frei sind. Ist bei Fortnite und WD Legion so. Tippe, das ist mit AMD nicht anders, aber da hast du nur einen globalen Toggle im Treiber.

Find die Ampere-Treiberqualität generell massiv besser als zu Pascal-Zeiten. Aber mehr als etwas "Pflege" scheint es irgendwie nicht zu geben, stimmt schon. Andererseits besser als Schrott-Treiber.

Gott1337

2022-08-11, 23:29:21

Massives Ghosting gibt's jetzt wieder in Spider-Man Remastered. Hat DLSS 2.4.12 und dieses schmiert, ebenso DLAA: https://www.pcgameshardware.de/Spider-Man-Remastered-Spiel-73740/Specials/Steam-PC-Systemandorderungen-Benchmark-Test-Review-1400598/3/#a2

Ich frage mich, ob Nvidia das jemals in den Griff bekommt. Von Masken halten sie offenbar wenig. ;)

Hier eine ganz simple Bewegung von Spideys Kopf mit DLAA - Schmierseuche: https://www.youtube.com/watch?v=-pvGTAUnTK8&list=PL9RO-m0OS4wY70ZknsfA5GQpBgSZYF6o9&index=1

MfG
Raff
andere schreiben das hier "Darüber hinaus hat FSR 2.0 mit dem bekannten Problem zu kämpfen, dass zunächst verdeckte und dann plötzlich ins Bild tretende Elemente nicht korrekt erfasst werden. In Spider-Man Remastered ist dies ein nur kleines Problem, an sich aber vorhanden.

Ghosting ist weder bei DLSS, noch bei FSR ein großes Problem. Einzig mit aggressiven Einstellungen wie WQHD als Ziel-Auflösung in Kombination mit dem Performance-Modus neigt FSR zum Ghosting, dies hat DLSS etwas besser im Griff. Aber auch dort kann es zu Problemen kommen." also schon deutlich was anderes. merkwürdig.

Andron

2022-08-12, 00:14:24

In den Vergleichsvideos inkl. dem von Computerbase, die Du zitierst, sind aber tatsächlich sehr wenige Disocclusion-Artefakte bei FSR 2.0 zu erkennen, zumindest soweit die Youtube-Kompression eine Beurteilung zulässt. Mit GoW oder FS22 ist das auf jeden Fall nicht mehr vergleichbar und die Unterschiede zu DLSS sind schon sehr gering. Beim schnellen laufen im CB Video wirkt DLSS Performance teilweise etwas homogener um Spiderman herum, ohne den direkten Vergleich sind die Unterschiede aber schwierig auszumachen. In den oben genannten Extrembeispielen war das noch eine ganz andere Situation.

Lurtz

2022-09-05, 15:23:10

Kann es sein dass CoD Modern Warfare 2019 wieder unter dem üblichen Schrott-DLSS-Sharpen leidet?

Sieht furchtbar aus verglichen mit dem Filmic SMAA 2Tx.
In Black Ops Cold War scheint es nicht mehr so schlimm zu sein.

aufkrawall

2022-09-08, 02:20:42

Gibt jetzt einen DLSS Sharpen Slider in RDR2. Gibt aber auch bei 0% weiterhin abartiges Ringing, man braucht weiterhin den Runtime Patcher.
https://abload.de/img/rdr22022-09-0802-04-1deiz4.png

Ich hab die Befürchtung, dass dieser Müll in Zukunft noch öfters vorkommen wird. Das entwertet DLSS schon ziemlich für mich, wie kann das so massiv das Klo runtergehen bei Nvidia? :confused:
Von der Schrott-Version 2.4.12 in Spiderman, die dort und in jedem anderen Spiel beschissen aussieht, könnte ich jetzt auch noch anfangen...

basix

2022-09-11, 10:20:48

Red Gaming Tech hat in einem seiner letzten Videos was verzapft von wegen "neues Killer Feature für DLSS". Nvidia hat "Project Beyond" für 20. September angeteasert, evtl. ein Zusammenhang?

RGT hatte seine Quelle gefragt, um was es sich handeln könnte: Qualität, Performance, für andere Vendors verfügbar. Alles Nein laut der Quelle. Wenn ich raten müsste und für mich ein ein Killer Feature für DLSS wäre: Aktivierbar via Treiber in allen Games (evtl. "nur" alle mit TAA oder auf einer Whitelist von Nvidia).

DrFreaK666

2022-09-11, 10:53:29

Das wäre schon nett.
Ich glaube auch dass NV neben RTX4000 noch DLSS 3 ankündigen wird.
Einfach nötig angesichts der Konkurrenz

Lurtz

2022-09-11, 12:46:05

Am besten nicht abwärtskompatibel, weil man will ja neue GPUs verkaufen :rolleyes:

basix

2022-09-11, 12:49:30

Immerhin war bisher alles auch Turing lauffähig, inkl. DX12 Ultimate ;)

Aber bei Nvidia würde mich Lovelace Exklusivität nicht überraschen. Anderseits würde Abwärtskompatiblität (mit allenfalls mediocre Performance) die eigenen RTX Karten stark aufwerten und AMDs jetzige Basis (RDNA1/2) stark abwerten als auch Intel vor den Bug schiessen. Mindshare ist wichtig. Ich kann mir hier deswegen vorstellen: Läuft auf Ampere auch. Turing ungewiss.

robbitop

2022-09-11, 14:26:19

Ich denke auch an DLSS 3.0.
Aber als forcierbare Option? IMO unrealistisch.

Dampf

2022-09-11, 14:49:23

Wenn es auf Ampere läuft, dann auch auf Turing. Es hat sich von der Architektur her und Tensor Core Leistung sehr wenig getan.

basix

2022-09-11, 14:58:41

Ich denke auch an DLSS 3.0.
Aber als forcierbare Option? IMO unrealistisch.

Ich weiss auch nicht wie es gehen soll. Bei Nvidia sitzen aber intelligente Köpfe mit deutlich mehr Know How, als wir hier im Forum von uns behaupten können ;) Vielleicht eben nicht in dem Sinne forcierbar, dass es wie DLSS 2 gut und performant auf allen Tensor Core GPUs läuft. Damit es überhaupt funktioniert, könnte Lovelace zusätzliche Horse Power aufs Problem werfen, dedizierte Logik im Chip, whatever.

Ich gehe wie gesagt von der RGT Aussage aus, dass Quality, Performance und Vendor Proprietät nicht das Thema dieses "Killer Features" sind. Was bleibt dann übrig? Bei DLSS 3.0 würde ich z.B. auch Qualitätsverbesserungen erwarten.

Wenn es auf Ampere läuft, dann auch auf Turing. Es hat sich von der Architektur her und Tensor Core Leistung sehr wenig getan.
Sparsity ist dazugekommen, ergo im besten Fall 2x Performance. Und künstlich beschneiden kann Nvidia immer ;) Turing ist EOL. Ampere wird man noch eine Weile kaufen können -> Kaufargument für neue Karten und nicht Gebrauchtmarkt-Karten

iamthebear

2022-09-12, 02:05:52

DrFreaK666

2022-09-12, 02:21:05

...Sparsity ist dazugekommen, ergo im besten Fall 2x Performance. Und künstlich beschneiden kann Nvidia immer ;) Turing ist EOL. Ampere wird man noch eine Weile kaufen können -> Kaufargument für neue Karten und nicht Gebrauchtmarkt-Karten

Nach einem Shitstorm bringt Nvidia das Feature per Treiberupdate für Turing und wird dann gefeiert, weil sie auf die Fans hören :ugly:

Gott1337

2022-09-12, 03:56:37

Nach einem Shitstorm bringt Nvidia das Feature per Treiberupdate für Turing und wird dann gefeiert, weil sie auf die Fans hören :ugly:
Sparsity = Hardware. da können sie updaten was sie wollen. Nächster Bash der nach hinten los ging :D

DrFreaK666

2022-09-12, 04:54:18

Sparsity = Hardware. da können sie updaten was sie wollen. Nächster Bash der nach hinten los ging :D

Da ging gar nichts nach hinten los, da auch du nicht weißt, was kommen wird. Eigentlich gehört 3.0 ins Speku-Unterforum

basix

2022-09-12, 07:52:43

Falls DLSS 3.0 nicht vernünftig mit Turing laufen sollte stellt sich die Frage ob zukünftige Spiele dann noch DLSS 2.x Support bieten werden. Falls nein so läuft das in eine sehr bedenkliche Richtung, da es gerade die etwas älteren Karten sind die auf Upscaling angewiesen sind.

Das ist ein sehr guter Punkt. Würde man Turing aussen vor lassen, gäbe das einen grossen Push für FSR und XeSS. Das will Nvidia vermutlich nicht. Und dass Spieleentwickler zwei verschiedene DLSS Versionen einbauen ist auch eher unwahrscheinlich.

Dampf

2022-09-12, 09:29:55

Selbst wenn DLSS 3.0 nicht auf Turing läuft, wird es sicherlich einen abwärtskompatiblen Pfad geben, sodass bei einem Spiel, das DLSS 3.0 nutzt, DLSS 2.0 auf Turing verwendet wird.

Gast

2022-09-12, 09:44:23

Sparsity ist dazugekommen, ergo im besten Fall 2x Performance.

Dass Sparsity zusätzliche Rechenleistung bringt ist ein ähnlicher Marketing Bullshit, wie die bei jeder Generation erhöhte "effektive Bandbreite".

Mit Sparsity erhöht sich nicht die Rechenleistung, es können unnötige Rechenschritte erkannt und nicht durchgeführt werden.

Wieviele aber in der Praxis wirklich unnötig sind, weil sie am Ergebnis nichts ändern ist aber Variabel.

BlacKi

2022-09-12, 10:04:57

warum updaten die spieleentwickler die dlss version nicht? kostet das geld? ansonsten ist der aufwand gering und das spiel hat nur vorteile?

dort wo man die dll selbst austauschen kann, ist es mir egal, da kann ich das auch selbst tun. aber in hauptsächlich multiplayerspielen funktionieren die spiele oder dlss nicht mehr.

warum updaten die spieleentwickler die dll also nicht?

Gast

2022-09-12, 10:22:24

RGT hatte seine Quelle gefragt, um was es sich handeln könnte: Qualität, Performance, für andere Vendors verfügbar. Alles Nein laut der Quelle. Wenn ich raten müsste und für mich ein ein Killer Feature für DLSS wäre: Aktivierbar via Treiber in allen Games (evtl. "nur" alle mit TAA oder auf einer Whitelist von Nvidia).

Klingt sehr unwahrscheinlich.

Wenn man mal zur Konkurrenz sieht kann man erahnen wohin die Reise geht.

XeSS verwendet offensichtlich ein deutlich aufwändigeres NN, welches mit 8x8 SS angelernt wird (DLSS aktuell nur 4x4).

Ich denke hier wird man auch bei Nvidia entsprechende Verbesserungen sehen.

Gast

2022-09-12, 10:28:20

warum updaten die spieleentwickler die dll also nicht?

Das updaten selbst ist kein nennenswerter Zeitaufwand, durchaus aber die daraus folgenden Qualitätssicherungsmaßnahmen.

Neuer=Besser ist bei DLSS nicht immer der Fall, je nach Spiel hat es durchaus schon Szenarien gegeben in denen bei einem Spiel die eine, bei einem anderen Spiel eine andere DLL die besten Ergebnisse geliefert hat.

Nvidia macht ja mittlerweile durchaus Updates per Treiber, aber offenbar nur in Absprache mit den Entwicklern, und diese haben offenbar oft gerne Kontrolle über ihr Produkt und wollen nicht, dass externe DLLs das Verhalten im Nachhinein ändern.

Dovregubben

2022-09-12, 10:31:04

warum updaten die spieleentwickler die dlss version nicht? kostet das geld?
Wie stellst du dir Updates vor?
Da geht nicht der Entwickler hin, ändert was, testet es und drückt auf einen Knopf zum verteilen.

Da änderst du eine Zeile und musst nochmal durch den ganze QA Prozess. Dann geht es zu den Plattformen und muss dort durch den ganzen Prozess.
Je nach Größe des Projekts bedeutet das mehrere Personenwochen bis zu Personenjahre.

Dampf

2022-09-12, 10:38:41

Five Hundred Määään Hauas!

Geldmann3

2022-09-12, 10:42:38

Vielleicht sollte man dann nochmal den QA / Update -Prozess überdenken. Ich meine, es ist eine DLL, die nichts kritisches brickt. Sollte reichen, wenn da mal jemand einen Arbeitstag lang mit Brain.exe drüberschaut. Und das Update sollte im Notfall extrem klein und ohne Probleme zurückrollbar sein. Man könnte den Spieler sogar selbst ein Pre-Start-Menü mit DLSS-Versionsauswahl bieten. Die neueste als Default.

DrFreaK666

2022-09-12, 12:46:26

... Man könnte den Spieler sogar selbst ein Pre-Start-Menü mit DLSS-Versionsauswahl bieten. Die neueste als Default.

Die wenigsten werden dann wissen, was sie da wählen sollen. Plötzlich reicht DLSS Q nicht mehr für beste Qualität?

Gast

2022-09-12, 14:13:44

Man könnte den Spieler sogar selbst ein Pre-Start-Menü mit DLSS-Versionsauswahl bieten. Die neueste als Default.

Viel zu Komplex, die Auswahl einer DLSS Version ist sicher nichts was man dem durchschnittlichen Spieler zumuten kann.

Die beste Lösung wäre wohl, wenn Nvidia dies als "Experteneinstellung" über den Treiber ermöglicht, eine DLSS-Version, natürlich auch nur per Spiel, zu forcieren.

basix

2022-09-12, 15:23:35

Selbst wenn DLSS 3.0 nicht auf Turing läuft, wird es sicherlich einen abwärtskompatiblen Pfad geben, sodass bei einem Spiel, das DLSS 3.0 nutzt, DLSS 2.0 auf Turing verwendet wird.
Wäre auch meine Erwartung. Siehe Intel XeSS mit DP4a: Selbe Funktionalität, geringere Performance.

Dass Sparsity zusätzliche Rechenleistung bringt ist ein ähnlicher Marketing Bullshit, wie die bei jeder Generation erhöhte "effektive Bandbreite".

Mit Sparsity erhöht sich nicht die Rechenleistung, es können unnötige Rechenschritte erkannt und nicht durchgeführt werden.

Wieviele aber in der Praxis wirklich unnötig sind, weil sie am Ergebnis nichts ändern ist aber Variabel.
Hat irgendwer behauptet, es gäbe mehr Rechenleistung? Und das auch in jedem Fall? ;) Praktisch bringt Sparsity oftmals nur ~1.5x Performance (Nvidia Benches). Wie viel Rechenleistung etwas braucht oder eine GPU hat ist prinzipiell egal, die relative Performance ist entscheidend (in Millisekunden Ausführungszeit). Und die kann mit Sparsity eben deutlich besser ausfallen (falls nicht eh schon auf Ampere für DLSS genutzt, wissen wir ja nicht)
Sparsity ist dazugekommen, ergo im besten Fall 2x Performance.

aufkrawall

2022-09-12, 15:51:11

Wäre auch meine Erwartung. Siehe Intel XeSS mit DP4a: Selbe Funktionalität, geringere Performance.

Nope, Petersen hatte im letzten Video nochmal die schlechtere Qualität des DP4a-Fallbacks erwähnt.
Wie stark der Unterschied ist, hat Intel aber immer noch nicht kommuniziert.

basix

2022-09-12, 16:51:06

Nope, Petersen hatte im letzten Video nochmal die schlechtere Qualität des DP4a-Fallbacks erwähnt.
Wie stark der Unterschied ist, hat Intel aber immer noch nicht kommuniziert.
ah, danke. Wusste ich nicht

robbitop

2022-09-12, 17:34:50

Ich auch nicht. Dann müssen sie ja zweil verschiedene trainierte NNs haben damit das Inferencing in unterschiedlicher Qualität resultiert oder? Klingt merkwürdig finde ich

aufkrawall

2022-09-12, 18:59:14

Hat Intel schon mehrfach erwähnt, ich hatte hier auch schon vor Monaten darauf hingewiesen. Stelle im Video:
https://youtu.be/frlXry38tJo?t=1300

Ex3cut3r

2022-09-12, 20:42:35

Soweit ich weiß, ist Nvidia aber ab GP102 und later mit DP4a Support unterwegs. Allerdings wäre RDNA 1 und z.B. eine 5700XT betroffen. (Glaube ich

Gast

2022-09-12, 22:10:42

Ich auch nicht. Dann müssen sie ja zweil verschiedene trainierte NNs haben damit das Inferencing in unterschiedlicher Qualität resultiert oder? Klingt merkwürdig finde ich

Ja, sieht man auch schön auf ihren Folien, das DP4a Network ist schön klein dimensioniert, das XMX-Network grooooooß

robbitop

2022-09-13, 00:12:47

Ist dann natürlich doppelte Arbeit für Intel für alles Kommende. Solche NNs werden ja auch ständig weiter entwickelt.
Wird sicherlich Gründe geben - dp4a ist ggf für das "große" zu langsam um noch viel Sinn zu machen.

Geldmann3

2022-09-13, 08:30:17

Mit der nächsten Toplösung und den neusten AI-Papers von Nvidia wird erstmals ,,Pathtracing" bei knapp 60FPS möglich.

Würde mich sehr wundern, wenn wir davon bei deren Ada-Präsentation nichts zu sehen bekommen.

Gast

2022-09-13, 10:55:12

Ist dann natürlich doppelte Arbeit für Intel für alles Kommende. Solche NNs werden ja auch ständig weiter entwickelt.

Vermutlich nehmen sie schon das selbe NN als Basis, nur reduziert auf 1/4 (oder wie viele auch immer) der Nodes.

Wird sicherlich Gründe geben - dp4a ist ggf für das "große" zu langsam um noch viel Sinn zu machen.

Vermutlich, wenn man Intels Performancegraph ansieht, ist XeSS ALU-Limitiert und nicht XMX limitiert, XMX stemmt dabei aber einen Großteil der benötigten Rechenleistung..

Dampf

2022-09-13, 13:58:18

DrFreaK666

2022-09-13, 15:07:37

Vergiss die Konsolen nicht. Da wird nichts mit großen Schritten passieren

Gast

2022-09-13, 15:24:25

Deutlich mehr RT Performance + DLSS mit höherem Geschwindigkeits-Boost + neue Path Tracing/Denoising Algorithmen + Motion Interpolation

Ich könnte mir schon vorstellen, dass wir uns mit großen Schritten Richtung Path Tracing in modernen Games bewegen.

Vielleicht bei der 2k+ Grafikkarte, bis sich "normalsterbliche" eine derartige Performance leisten können wird noch einige Zeit vergehen.

basix

2022-09-13, 16:32:12

Vergiss die Konsolen nicht. Da wird nichts mit großen Schritten passieren

SW und Algorithmen laufen auch auf den Konsolen ;) Und da ist mMn das grössere Beschleunigungspotential vorhanden als nur in HW. Realtime RT ist noch jung.

Man kann als Bespiel, bei Geometrie, Nanite der UE5 anführen. Rein SW basiert - Quantensprung.

BlacKi

2022-09-14, 00:48:09

Wie stellst du dir Updates vor?
Da geht nicht der Entwickler hin, ändert was, testet es und drückt auf einen Knopf zum verteilen.

Da änderst du eine Zeile und musst nochmal durch den ganze QA Prozess. Dann geht es zu den Plattformen und muss dort durch den ganzen Prozess.
Je nach Größe des Projekts bedeutet das mehrere Personenwochen bis zu Personenjahre.in multiplayer titeln mit anticheat bist du auf das angewiesen, was dir der entwickler an die hand gibt. sonst funktioniert das spiel nicht. dasselbe mit fsr. wenn dice nicht hingeht und in bf2042 endlich mal ihre 2 jahre alte dll mal updatet, dann wird das game immer diese alt dll nutzen müssen.

tarkov hat vor dem letzten wipe zugelassen, die dll manuell auszutauschen. nach dem wipe ging das nichtmehr.

das ist bullshit. wenn sie es wegen des anticheats nicht zulassen können das die dll manuell auf eigenes risiko getauscht werden kann, dann sollten sie wenigstens selbst alle 1-3 monate eine neue dll einspielen. zumindest solange es noch erweiterungen gibt.

aufkrawall

2022-09-14, 00:55:32

Bei Fortnite geht das noch.

aufkrawall

2022-09-15, 19:09:19

Ich tippe aufs DLSS Sharpen. Es gibt irgendeinen temporalen Parameter, der mit DLSS Sharpen mitgesetzt wird und temporales Ringing verursacht. In der CryEngine mit ungelockter Konsole kann man den auch einsehen und setzen. Evtl. sitzt der bei Dying Light 2 einfach nicht auf dem neutralen Wert mit DLSS Sharpen 0 und verursacht so unnötig massivsten Motion Blur.
Das DLSS Sharpen wird ja mit dem FSR 2-Mod ebenfalls komplett ersetzt und es wird nur noch die RCAS-Stärke gesetzt. Was auch hervorragend in DL2 funktioniert, brauche so kein ReShade für CAS-Inject. Nvidia hat bei Sharpen leider nur zwei linke Hände.
Tja, ist so. Man kann mit den DLSS-SDK-DLLs das Sharpen via Hotkey abschalten, dann ist auch das Geblurre weg. Da ist also tatsächlich irgendein Parameter mit DLSS Sharpen 0 im Spiel auf Kaputtblurren anstatt auf Ekel-Sharpen gesetzt. Dummerweise gibts mit den SDK-DLLs ein hässliches Wasserzeichen.
Auto-Exposure ist offenbar auch nicht standardmäßig aktiviert, nach dem Hotkey dafür smeart es auch weniger (aber immer noch kacke vs. FSR 2.1).

Grauenhaft, wie Nvidia Entwicklern gleich mehrere Schrotflinten in die Hände drückt, um sich damit ins Bein zu schießen. Einfach nur grotesk.
Ob sich der Blödsinn mit DLSS 3.x fortsetzt? Du liebe Güte...

Gott1337

2022-09-16, 01:05:22

Tja, ist so. Man kann mit den DLSS-SDK-DLLs das Sharpen via Hotkey abschalten, dann ist auch das Geblurre weg. Da ist also tatsächlich irgendein Parameter mit DLSS Sharpen 0 im Spiel auf Kaputtblurren anstatt auf Ekel-Sharpen gesetzt. Dummerweise gibts mit den SDK-DLLs ein hässliches Wasserzeichen.
Auto-Exposure ist offenbar auch nicht standardmäßig aktiviert, nach dem Hotkey dafür smeart es auch weniger (aber immer noch kacke vs. FSR 2.1).

Grauenhaft, wie Nvidia Entwicklern gleich mehrere Schrotflinten in die Hände drückt, um sich damit ins Bein zu schießen. Einfach nur grotesk.
Ob sich der Blödsinn mit DLSS 3.x fortsetzt? Du liebe Güte...
Zu erwarten das Entwickler ein klein bisschen Ahnung haben, wäre auch wirklich zu viel verlangt ;D
Die Optionen werden schon Sinn machen in manchen Szenarien, sonst wären sie nicht drin. Du denkst einfach nicht weiter.

basix

2022-09-16, 12:12:27

Zu erwarten das Entwickler ein klein bisschen Ahnung haben, wäre auch wirklich zu viel verlangt ;D
Die Optionen werden schon Sinn machen in manchen Szenarien, sonst wären sie nicht drin. Du denkst einfach nicht weiter.

Mehr Optionen sind immer gut. Nur wenn es mit dem setzen eines einfachen Flags anscheinend deutlich besser aussieht, muss man sich schon kurz an den Kopf greifen. Keine Ahnung, evtl. muss Nvidia ihre Default Einstellung dieser Flags überdenken :D

dargo

2022-09-18, 07:46:29

Leider bekomme ich keine Antwort auf meine Frage in anderen Threads, ergo versuche ich es hier mal. Was genau bedeutet DLSS-Ultra in Red Dead Redemption 2 bsw. bei 1440p Output? Immerhin ist DLSS-Quality hier rund 40% schneller als DLSS-Ultra.

aufkrawall

2022-09-18, 08:28:02

Ist kein offizieller DLSS-Modus, fügt nur der Mod hinzu. 40% klingt nach nativer Auflösung.

dargo

2022-09-18, 09:02:03

Ok... das könnte hinkommen denn DLSS-Ultra ist auch langsamer als non DLSS, dafür sieht DLSS-Ultra auch deutlich besser als DLSS-Quality aus. Bei 4k + FSR 2.1Q vs. 1440p + FSR 2.1U bin ich mir nicht mehr sicher ob Zweiteres besser aussieht.

basix

2022-09-18, 21:26:59

DLSS Mod für FSR2 Game :D
https://www.nexusmods.com/judgment/mods/7

Ex3cut3r

2022-09-18, 22:59:36

Wieso hat das Game überhaupt FSR 2.0 aber kein DLSS?

Die Mod läuft natürlich nicht auf non RTX GPUs. Das Game interessiert mich aber nicht.

DrFreaK666

2022-09-19, 00:01:03

DLSS Mod für FSR2 Game :D
https://www.nexusmods.com/judgment/mods/7

Ist es grafisch besser oder läuft es schneller? Sonst macht die Mod sonst wenig Sinn

teezaken

2022-09-19, 17:05:26

Ist es grafisch besser oder läuft es schneller? Sonst macht die Mod sonst wenig Sinn
Habe das nur sehr kurz bei Tiny Tinas Wonderlands probiert... Bildqualität ist mit 2.4.6 DLSS tatsächlich besser so wie ich das sehe, Performance ist aber identisch. (FSR immer 96FPS, DLSS schwankte hin und wieder auf 97FPS hoch)

aufkrawall

2022-09-19, 17:20:05

Positiv: Der Mod scheint so ziemlich genau so auszusehen wie eine native, gescheite DLSS-Implementierung (bis auf das LOD-Bias, das der Entwickler auch für FSR verkackt hat).
Vs. FSR 2 würd ich es aber eher als Mixed Bag bezeichnen. Es kommt besser mit Partikeleffekten klar, manche Linien sehen zumindest im Standbild ununterbrochener aus und es kommt besser mit den Teilen der animierten Vegetation klar, für die offenbar keine korrekten Bewegungsvektoren vorliegen (verschwimmen mit FSR in Bewegung und werden halbdurchsichtig, mit DLSS aliasen sie etwas). Dafür gibts aber Smearing, der Outline Shader zittert stärker in Bewegung als mit FSR und sieht auch ansonsten stärker aliased aus. Außerdem gibt es offenbar etwas Ringing, das mit CAS verstärkt wird, was mit FSR nicht vorhanden ist.
Falls noch eine FSR 2.1 Mod käme, könnte die besser aussehen. :freak:

Platos

2022-09-19, 18:02:44

Wieso hat das Game überhaupt FSR 2.0 aber kein DLSS?

Die Mod läuft natürlich nicht auf non RTX GPUs. Das Game interessiert mich aber nicht.

Naja, man bedient beide Lager und muss nur eins implementieren. Sind die Ressourcen begrenzt, würde ich das auch so machen aus Sicht des Publisher/Entwickler.

aufkrawall

2022-09-19, 18:18:31

Übrigens: Wonderlands lädt natives FSR 2 nicht via DLL, der Mod für DLSS fängt das anderweitig ab. Das heißt, es könnte auch in anderen Spielen ohne DLL klappen. Oder dass so noch FSR 2 Updates auch für Spiele möglich werden, die es nicht per DLL shippen.
Open Source sei Dank. :)

Edit: *seufz*, DLSS Fick Sharpen ist mal wieder obligatorisch aktiv:
https://abload.de/thumb/wonderlands_2022_09_179cvt.png (https://abload.de/image.php?img=wonderlands_2022_09_179cvt.png)

robbitop

2022-09-19, 20:01:30

Diese mods zeigen wie einfach die Implementierung sein muss, wenn bereits DLSS vorhanden ist. Ich frage mich ob das die Studios nicht beschämt, dass modder es umständlich schneller hinbekommen als sie selbst (wenn sie es dann überhaupt bringen).

aufkrawall

2022-09-19, 20:10:37

Offenbar funktioniert es in beide Richtungen fast auf Knopfdruck, wenn der Entwickler sich an Best Practices hält, inkls. der Verträglichkeit von Effekten/Formaten. Das dürfte ein Framework wie Streamline eigentlich ziemlich überflüssig machen, wenn es auch rtfm tut.

robbitop

2022-09-19, 20:58:27

Letztens gab es einen Stream von einem Dev der FSR 2.0 innerhalb kürzester Zeit live implementiert, getestet und gefixt hat. Iirc war das unter 2h.

basix

2022-09-19, 21:07:47

Bei einem Spiel mit DLSS?

Gast

2022-09-19, 21:28:27

Diese mods zeigen wie einfach die Implementierung sein muss, wenn bereits DLSS vorhanden ist.

Wenn ein Spiel nicht gerade ein Live Service Game ist, ist der Support recht bald vorüber und dann gibt es eben nichts mehr neues.

aufkrawall

2022-09-19, 21:49:40

lol, mit dem DLSS-Mod kann man die FSR2-Mod kombinieren, um es so auf neue FSR-Versionen upzudaten. ;D

Lurtz

2022-09-20, 13:22:07

lol, mit dem DLSS-Mod kann man die FSR2-Mod kombinieren, um es so auf neue FSR-Versionen upzudaten. ;D
https://c.tenor.com/IvyuPtEfzhoAAAAM/matrix.gif

:uup:

dildo4u

2022-09-20, 17:34:47

r-hu006p23I

cJlo2I7CiD0

DrFreaK666

2022-09-20, 18:06:33

das längste Video der Welt

Gast

2022-09-20, 18:31:49

DLSS 3 integriert nun endlich temporales upscaling nachdem dies fälschlicherweise schon die ganze Zeit DLSS 2 angedichtet wurde

Ex3cut3r

2022-09-20, 18:33:51

Da man gar nicht weiß, was links überhaupt für eine GPU im CP77 Vergleich arbeitet, wurde ich diese Comparison nicht für bare Münze nehmen, einfach unabhängige Reviews abwarten.

aufkrawall

2022-09-20, 18:39:03

Wird wohl beides die Gleiche sein, also wahrscheinlich 4090. Das neue RT-Preset in CP77 knebelt in 4k sicherlich extra fies, was ein Schwachsinn. ;D

dargo

2022-09-20, 18:48:09

Witzig finde ich die fehlerhafte Beschriftung. RT On, dann wieder RTX Off. Welcher Praktikant hat da nicht aufgepasst? ;D

crux2005

2022-09-20, 19:30:53

3-4x Leistung ist natürlich nett. Aber bessere Qualität wäre mir lieber. Wobei es da keine großen Sprünge mehr geben wird.

https://abload.de/img/dlss3juc8f.jpg
https://www.youtube.com/watch?v=qyGWFI1cuZQ

Ex3cut3r

2022-09-20, 20:05:24

Jo. Ich sehe da keinen Unterschied zwischen 2 und 3 was die Qualität betrifft. Wenn DLSS 3 neustes Killerfeature wirklich nur die Frameverdopplung aka Interpolation ist, ist das nix wo ich sage, ja....das brauche ich jetzt sofort. Vor allem da sowas auch immer Artefakte hervorrufen kann und vermutlich den Input Lag erhöht. Interessant wird auch sein, ob die 370% mehr Leistung, wirklich FPS sind, oder nur die "gefühlten FPS" veranschaulichen sollen. ^^

aufkrawall

2022-09-20, 20:07:22

Gibt in dem Schnipsel von DF doch schon zusätzliche Artefakte zu sehen. Siehe oben mein Bild von Smearing + Sharpen-Haloing, das ist mir schon zu viel des "Guten"...
Und dann noch Frame-Interpolationsartefakte on top...

crux2005

2022-09-20, 20:19:27

Hier noch mal die "detaillierte" Beschreibung von DLSS 3.0: https://www.nvidia.com/en-us/geforce/news/dlss3-ai-powered-neural-graphics-innovations/ (damit ich sie später einfacher finden kann).

Gibt in dem Schnipsel von DF doch schon zusätzliche Artefakte zu sehen. Siehe oben mein Bild von Smearing + Sharpen-Haloing, das ist mir schon zu viel des "Guten"...
Und dann noch Frame-Interpolationsartefakte on top...

Kannst du Zeitstempel geben?

BlacKi

2022-09-20, 20:21:34

iamthebear

2022-09-20, 20:21:51

aufkrawall

2022-09-20, 20:23:34

Kannst du Zeitstempel geben?
Kannst da eigentlich alle 1s das Video anhalten, um fündig zu werden:
https://abload.de/thumb/181d8w.png (https://abload.de/image.php?img=181d8w.png)

Und wie gesagt, ohne Video-Kompression wird das auf dem heimischen Monitor noch mal deutlich stärker auffallen...

crux2005

2022-09-20, 20:24:23

Die Frage ist was bringt es mir die Framerate zu steigern wenn der Inputlag nicht mitzieht. Für Spiele wie Flight Simulator mag das ganz nett aber aber für Spiele relativ sinnlos.
Ich frage mich jedoch auch wie das mit der Kompatibilität aussieht. Wenn man eine Ampere Karte hat kann man dann bei DLSS 3.0 Spielen zumindest noch den Upscaling Teil nutzen?

Wieso gehen alle von einem größeren Inputlag aus?

NV ist nicht dumm. Die Latenz mit DLSS 3.0 wird ähnlich sein wie wenn du die Framerate ohne DLSS 3.0 hättest.

Kannst da eigentlich alle 1s das Video anhalten, um fündig zu werden:
https://abload.de/thumb/181d8w.png (https://abload.de/image.php?img=181d8w.png)

Und wie gesagt, ohne Video-Kompression wird das auf dem heimischen Monitor noch mal deutlich stärker auffallen...

Wenn ich die Spiderman Sequenz verlangsame oder pausiere sehe ich Unterschiede. Aber in Bewegung ist mir nichts aufgefallen. :frown: