nVidias Deep Learning Super Sampling - DLSS 2.x und DLSS 3

[DrFreaK666]

Ich spiel meist in 4k mit AA und da sind die Treppen selbst wenn ich mit das Nase am Monitor klebe kaum mehr auszumachen. Wenn ich 1800p hoch- oder 2160p auf 1800p runter skaliert spiele noch weniger. Das ist der riesige Vorteil eines High DPI Monitors. Nachteil -> keine 120+ hz und grausam hohe Hardware-Anforderungen.

Ich habe nur 27"/1440p. 4k war mir damals zu teuer und die Monitore noch nicht gut genug

[y33H@]

Auch mit 4K hat man Shader-Aliasing usw, hohe Display-Auflösung ist (leider bisher) nicht das Ende.

[ChaosTM]

Das Ende sicher nicht, aber deutlich angenehmer. Derzeit aber hauptsächlich (immer noch) für den Desktop Betrieb durchgehend empfehlenswert. Wäre ich noch Hardcore Gamer, hätte ich wohl auch einen mit 1440p.

[basix]

Wir reden in diesem Thread über ein Konkurrenzprodukt von DLSS, was du hier als gleichwertig bezifferst. Ich zeige daher, wie grottig FSR ist und das es keinen Nutzen für Spieler hat.

Ich habe aufkrawall zwei Screenshots aus der Bewegung geliefert, findest du diese Qualität als "gleichwertig"?

Zeige mir bitte, wo ich FSR als gleichwertig mit DLSS bezeichne. Aber um dir die Arbeit zu ersparen:

Ich kann den ganzen FSR vs. DLSS Kleinkrieg nicht mehr hören.
- Qualität (bei gleicher Performance): DLSS 2.x > FSR
- HW-Support: FSR > DLSS
- Einfachheit Spielintegration: FSR > DLSS

[Tobalt]

Diskussion
lol?
Was lollst du?

Darum liebe ich das 3dc so ;D

Sorry musste mal raus.

krawall: Ich stimme dir zu, dass Bewegtinformationen in vielen reviews nicht ausreichend gecheckt werden. Jedes Temporale SS wird in standbildern und besonders bei statischen Szenen immer göttlich aussehen.

Kennst du ein Review, was die temporale Situation gut darstellt (geht wohl fast nur mit Videoclips) ?

[Geldmann3]

Ich finde der Vergleich zwischen den Technologien hinkt einfach. DLSS ist temporales Supersampling, FSR hingegen Upscaling.

Ich hätte auch nie gedacht, dass Leute die beiden Technologien so sehr als Konkurrenz betrachten, das sollten sie in meinen Augen nämlich nicht sein. Mit FSR 1.0 verliert man technisch bedingt immer Bildinformationen, egal welche Stufe man wählt, während man mit DLSS meist zusätzliche Bildinformationen gegen das ungeglättete Bild in den einzelnen Pixeln verrechnet hat. Selbst im Performance-Modus. Doch Vorsicht, ich vergleiche hier nicht mit TAA, sondern mit no AA. ;)

[Troyan]

Red dir das ruhig ein (gleich postet er bestimmt Screenshots aus dem Standbild...).

Du behauptest also, dass du das massive Kantenflimmern des TAAUs in Watch Dogs Legion als besser empfindest als die deutlich besser Qualität inkl. paar Kantengeister von DLSS-Q?
Du siehst die miserable Qualität des TAAUs in Bewegung nichtmal selbst auf den Bildern (https://imgsli.com/NjIxNjI), wie diesem, aber behauptest die leichten Kantengeisterbilder sind für dich nicht akzeptabel?

Echt jetzt?

Zeige mir bitte, wo ich FSR als gleichwertig mit DLSS bezeichne. Aber um dir die Arbeit zu ersparen:

Beide verbessern ihre upscaling/upsampling Verfahren und von dieser Konkurrenz profitieren am Schluss alle. Grössere Engines werden eigene Verfahren mitbringen und wir erhalten bei deutlich mehr Spielen ein scharfes, flimmerfreies und detailreiches Bild bei guter Performance.

Erkläre mir doch mal, wie man von einer erheblichen schlechteren Technik, die kaum besser ist als billiger Treiberhochskalieren durch nVidia, nun profitiere? Ich sehe hier als Turing/Ampere Kunde eher, dass moderne Techniken wie DLSS von Entwicklern wie Capcom konsequent ignoriert werden, die einen Marketingdeal mit AMD haben und die AMD-Lösung qualitativ deutlich schlechter als nativ ist:

For our tests, we used the Ultra Quality Mode for AMD FSR. This mode offers the best image quality, so that’s the one you should choose, even when playing at 4K. And, unfortunately, AMD FSR cannot come close to native 4K, even at its Ultra Quality Mode.
[...]
AMD FSR improved performance by 20fps on our NVIDIA GeForce RTX 3080. Still, we don’t really recommend using it. It makes more sense to dial back some other settings than to use FSR (which brings a “vaseline” effect to the whole screen).
https://www.dsogaming.com/pc-performance-analyses/resident-evil-village-amd-fsr-versus-native-4k/

Ich finde der Vergleich zwischen den Technologien hinkt einfach. DLSS ist temporales Supersampling, FSR hingegen Upscaling.

Ich hätte auch nie gedacht, dass Leute die beiden Technologien so sehr als Konkurrenz betrachten, das sollten sie in meinen Augen nämlich nicht sein. Mit FSR 1.0 verliert man technisch bedingt immer Bildinformationen, egal welche Stufe man wählt, während man mit DLSS meist zusätzliche Bildinformationen gegen das ungeglättete Bild in den einzelnen Pixeln verrechnet hat. Selbst im Performance-Modus. Doch Vorsicht, ich vergleiche hier nicht mit TAA, sondern mit no AA. ;)

Ja, DLSS kann sehr gut die Bilddarstellung von nativ + spartiales AA nachbilden und das mit temporalen Informationen. Das wird eigentlich garnicht so stark betrachtet, weil man heutzutage nie wirlich das TAA unbehandelte Bild als Vergleich hat. Aber das konnte auch DLSS 1.0 in Final Fantasy 15 auch schon verdammt gut.

/edit: Aus dem Reddit, dort hat jemand Bilder gemacht:
https://pbs.twimg.com/media/E6oyzfHVoAMfpKz?format=jpg&name=4096x4096
https://pbs.twimg.com/media/E6j1j_kVoAAliZ1?format=jpg&name=4096x4096

FSR ist Lichtjahre von nativ entfernt, DLSS dagegen erreicht die Kantenglättung und Stablität von TAA mit der Qualität von NoAA/SMAA vorallem auch in Bewegung.

[aufkrawall]

krawall: Ich stimme dir zu, dass Bewegtinformationen in vielen reviews nicht ausreichend gecheckt werden. Jedes Temporale SS wird in standbildern und besonders bei statischen Szenen immer göttlich aussehen.

Kennst du ein Review, was die temporale Situation gut darstellt (geht wohl fast nur mit Videoclips) ?
Imho war das DF-Review zu FSR in Godfall da ganz gut. Leider haben sie zum Smearing in Legion bislang immer noch kein Wort verloren, die ganze Wahrheit erzählen sie auch nicht.

Ohne Reinzoomen geht es auf YT einfach nicht, wenn das schon so etwas wegfiltert:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12726650&postcount=1794
Dinge wie das ausufernde Pixel Jittering mit FSR sind da natürlich um so weniger zu erkennen, genau so wie die perverse Bewegungsunschärfe.

Die ganzen Reviews haben ja auch trotzdem alle nur bestätigt, dass mir FSR in 1440p rein gar nichts bringt, es ist komplett nutzlos für die meisten User. Mit DLSS gibt es zwar auch Ausfälle, aber das ist trotzdem dafür in anderen Spielen schlicht ein Game Changer. Ich habe in Control mit der 3060 mehr fps mit der 6800, bessere Grafik und keine Treiber-Probleme mit RT. Ich kann mir nicht vorstellen, irgendwann nochmal eine Radeon zu kaufen, sofern sich so etwas nicht ändert.

Troyan, ich lese deinen Post nicht.

[why_me]

Die ganzen Reviews haben ja auch trotzdem alle nur bestätigt, dass mir FSR in 1440p rein gar nichts bringt, es ist komplett nutzlos für die meisten User....

Schau mal etwas über den Tellerrand, die wenigsten haben eine GPU >= RTX3060, die meisten spielen mit deutlich schlechterer hardware mit vermutlich low/medium details und sind froh, wenn das spiel nicht ruckelt.

Stell dir mal folgendes vor, du müsstest um deine 60 FPS in Spiel X zu erreichen von medium auf low details schalten.
Was sieht hier besser aus? Medium + FSR (Quality) oder Low details native resolution?
Kannst du gerne auch mal selbst testen, bevor du FSR allgemein schlecht redest, nur weil es nicht deinen Erwartungen/usecase entspricht :wink:

[aufkrawall]

Als ich die 660 eingebaut hatte, hätte ich es auch in Dota 2 nicht genutzt, weil es schlicht widerwärtig überschärft aussah.
Und Bro konnte auch ganz ohne FSR Metro EE mit RT auf der 6900 XT und 4k-Monitor spielen. Das war mit dem guten temporalen Upsampling des Spiels + CAS überhaupt kein Problem und es sah auch nicht entstellt überschärft aus. FSR hätte hier ja voll den Mehrwert gebracht. Nicht...

[DrFreaK666]

...
/edit: Aus dem Reddit, dort hat jemand Bilder gemacht:
https://pbs.twimg.com/media/E6oyzfHVoAMfpKz?format=jpg&name=4096x4096
https://pbs.twimg.com/media/E6j1j_kVoAAliZ1?format=jpg&name=4096x4096

FSR ist Lichtjahre von nativ entfernt, DLSS dagegen erreicht die Kantenglättung und Stablität von TAA mit der Qualität von NoAA/SMAA vorallem auch in Bewegung.


Was ist das denn für ein Bildvergleich? Da ist ja alles unscharf. :freak:
Und wie viel Prozent des Screenshots sieht man hier, 10%?
Hätten die anderen 90% nicht mehr Bildinformationen gehabt, die besser für einen Vergleich gewesen wären?
Kein Plan wie du bei diesen Bildern einen Unterschied erkennen willst.
Ich erkenne nur dass das 1080p-Bild überschärft ist

[Troyan]

Du erkennst kein Unterschied zwischen 1080p ohne TAA und 1080p mit TAA?
Gut, dann gehörst du zur Gattung wie aufkrawall, der meint, dass DLSS in Watch Dogs deutlich schlechter als TAAU aussehen würde:
DLSS: https://drive.google.com/file/d/1jEJH19XYQ7uAYiqDRwZcbxSBOcQS6GsB/view
TAA: https://drive.google.com/file/d/1D-osiFpB9f_A-ndDC2nNQwPMDm-mMrCW/view

[aufkrawall]

Kirschen rauspicken und dann Unsinn erzählen, das kann der Trollyan gut.
Nice Augenkrebs-Überschärfung übrigens!

[ChaosTM]

Er mag NV halt wirklich sehr gerne. :D
Das vernebelt ihm die Rübe.

[Ex3cut3r]

3060 ist trotzdem keine tolle Karte, auch mit 12GB. Rohleistung in typischen rasterizer Spielen ohne DLSS zu gering in 1440p. Die Leistung hast du schon vor 5 Jahren mit der 1080 gehabt. Von daher verstehe ich den Wechsel von 6800 auf 3060 nicht. Klar die hat kein DLSS und RT ist auch nicht so pralle, ist aber wenigstens ne 100% 1440p Karte.

[ChaosTM]

Die 3060er ist ziemlich genau so schnell wie meine 1080ti von vor 4 Jahren. + RT und DLSS. Find ich ok.
Für 1440p reicht das locker

[aufkrawall]

So ist es.
Ich könnte etwa dieses mittelmäßige Doom Eternal mit RT und DLSS anschmeißen, und anders als mit seiner 2060S, müsste ich mir nicht eine Sekunde einen Kopf um den VRAM machen. :eek:
AMD ist bei mir raus mit Treiber-Bugs in RTX-Spielen + das Pseudo-FSR. Nebenbei hab ich etwas mehr Kohle als vorher.

[DrFreaK666]

Du erkennst kein Unterschied zwischen 1080p ohne TAA und 1080p mit TAA?...

Achso, wir sind im TAA-Thread. Mein Fehler :freak:

[Ex3cut3r]

So ist es.
Ich könnte etwa dieses mittelmäßige Doom Eternal mit RT und DLSS anschmeißen, und anders als mit seiner 2060S, müsste ich mir nicht eine Sekunde einen Kopf um den VRAM machen. :eek:
AMD ist bei mir raus mit Treiber-Bugs in RTX-Spielen + das Pseudo-FSR. Nebenbei hab ich etwas mehr Kohle als vorher.

Texturen auf Ultra und es gibt auch mit 8GB keine Probleme. Hätte ich noch meine 2080 oder ne aktuelle 6800 wurde ich über Ampere in der jetzigen Situation nicht mal nachdenken. Spiele werden ja auch in Zukunft nicht grade weniger Rohleistung benötigen. Ne 3060 kann deshalb auch nur ne Übergangskarte sein, oder aber man freundet sich mit 1080p wieder an.

Die 3060er ist ziemlich genau so schnell wie meine 1080ti von vor 4 Jahren. + RT und DLSS. Find ich ok.
Für 1440p reicht das locker
Naja, liegt oft genug eher auf 1080 non Ti Leistung oder dazwischen.

[aufkrawall]

Hätte ich noch meine 2080 oder ne aktuelle 6800 wurde ich über Ampere in der jetzigen Situation nicht mal nachdenken. Spiele werden ja auch in Zukunft nicht grade weniger Rohleistung benötigen. Ne 3060 kann deshalb auch nur ne Übergangskarte sein, oder aber man freundet sich mit 1080p wieder an.

Ok, kannst du das jetzt meine Sorge sein und das OT lassen?
Btw. ist DLSS Q bei 1440p etwas schneller als native 1080p.

[Troyan]

Kirschen rauspicken und dann Unsinn erzählen, das kann der Trollyan gut.
Nice Augenkrebs-Überschärfung übrigens!

Richtig, endlich gibst du zu, dass du Unsinn erzählst. Das dort war eine normale Szene aus dem Spiel nach einer Ubahnstation.

Und du behauptest weiterhin, dass du das rumgeflimmere durch das TAAU nicht siehst? Beantworte doch einfach die Frage. Kann nicht so schwer sein für jemanden, der felsenfest überzeugt ist, dass DLSS doch klar schlechter wäre.

[DrFreaK666]

Könnt ihr das endlich mal sein lassen? :rolleyes:

[dildo4u]

The Ascent hat Ultra Quality DLSS gelistet das Game kommt näste Woche.

BqYjW-sXi-U

[Dampf]

Krass. Nvidia hat ein SDK rausgebracht, mit dem man DLSS quasi eigens debuggen kann.

https://www.reddit.com/r/nvidia/comments/oswwon/the_dlss_sdk_released_by_nvidia_allows_you_to/

Sehr interessant, auch das Video: https://www.youtube.com/watch?v=cL-Ld4EVqE4

Interessant, was passiert wenn man die jitter accumulation anstellt. Dann sieht es so aus, als würde DLSS trippen. Ghosting at its best :biggrin:

[aufkrawall]

Schade, dass man so offenbar höchstens das Sharpen abschalten, aber nicht einschalten bzw. konfigurieren kann. Wird zumindest nirgendswo erwähnt.

[Troyan]

Also man kann zwischen -1 bis +1 einstellen, muss eben vom Spiel unterstützt werden.

[TheAntitheist]

Schade, dass man so offenbar höchstens das Sharpen abschalten, aber nicht einschalten bzw. konfigurieren kann. Wird zumindest nirgendswo erwähnt.
Ich geb dir Recht, denke aber es ist nicht dadrin weil man das nicht debuggen muss. Das können die Entwickler dennoch einstellen.

[aufkrawall]

Also man kann zwischen -1 bis +1 einstellen
Man = der Entwickler, als User geht über das Debug Overlay nur an oder aus. Oder etwa nicht?
Ist mir schon klar, dass mit 2.2.11 der Regler nun für den User angeboten werden kann. Ist bislang aber noch nirgends der Fall.

[robbitop]

Wo soll der Regler exponiert werden? Über nvapi oder in Spiel? Bei letzterem muss der Entwickler ja explizit einbauen.

[aufkrawall]

Vermutlich Letzteres.

[dildo4u]

Hoffe das Video wird diesmal nicht gelöscht.

CMotQ0TrML8

[ChaosTM]

Da geht es aber fast nur um das Spiel und kaum um DLSS. Habs nur schnell durchgeclickt. Keine Vergleiche .. Spiel wirkt ziemlich repetitive/fad imho.

[DrFreaK666]

Edge of Eternity (FSR Vs DLSS)
Io8MuK7_WgE

An meinem Smartphone sehe ich keinen Unterschied, bis auf dass DLSS schneller ist :D

[dargo]

Es gibt paar Unterschiede, das sind aber schon Nuancen.

Bei den Katzenhaaren flimmert DLSS einen Tick stärker als FSR. Dafür sehen die Haare vom Protagonisten minimal besser aus. Beim Gras erfasst DLSS die feinen Strukturen wiederum besser. Wobei mich dieses Geschmiere beim Gras mit DLSS eher stört. Muss dabei sagen, dass ich allgemein sehr empfindlich auf Bildunschärfe reagiere, das mag ich überhaupt nicht leiden. Mir kommt es auch so vor als wenn DLSS beim Gesamtbild etwas unschärfer wäre. Insofern ein kleiner Äpfel/Birnen Vergleich. Die Tester nehmen halt das was per Default geliefert wird.

[aufkrawall]

Das Gras ist mit FSR offenkundig ziemlich überschärft, den Video-Blur nicht vergessen...

[dargo]

Ich kann nur das bewerten was ich im Video sehe wenn ich das Game selbst nicht habe. Und da stört mich das DLSS-Geschmiere im Gras massiv. Mich erinnert das ein wenig an das Geschmiere in der Vegetation von RDR2 wodurch das Game für mich unspielbar war. Und da waren weder DLSS noch FSR ein Thema.

[aufkrawall]

Das ist überhaupt nicht vergleichbar zu RDR2, weil mit FSR hier schon das Standbild massiv überschärft ist.

[-/\-CruNcher-/\-]

Edge of Eternity (FSR Vs DLSS)
https://youtu.be/Io8MuK7_WgE

An meinem Smartphone sehe ich keinen Unterschied, bis auf dass DLSS schneller ist :D

Alter was für ein Schrott, fasse nicht, was ich da sehe.
Die Anime-Freaks Findens wohl Mega Geil.

Bleib mit diesem Game Weg irgendwas zu vergleichen, wer hat den das Zusammengebastelt Unreal Studenten?

Das muss man schon zusammengepanscht nennen sieht teils ja wie Asset flipped aus :D

Da sind das Bloober Team ja Gold Standard dagegen :D

[dargo]

Massiv ist massiv übertrieben. ;) Aber ich stimme zu, auch ich empfinde das FSR-Bild leicht zu überschärft. DLSS-Bild wiederum leicht zu unscharf. Eigentlich bedarf es bei beiden einer Anpassung, dass sich beide bei der Bildschärfe annähern.

Edit:
Das massive Geflimmer von DLSS rechts im Bild beim Wasser ist mir tatsächlich durchgegangen. Was ist denn da wieder kaputt?
https://youtu.be/Io8MuK7_WgE?t=113

Je öfter ich den Direktvergleich betrachte umso mehr DLSS-Fehler fallen mir auf. :freak: Das Geflimmer der Schatten beim Schiff (die weiße Plane bzw. Stoff) mit DLSS sieht ja auch ziemlich übel aus.

[-/\-CruNcher-/\-]

Krass. Nvidia hat ein SDK rausgebracht, mit dem man DLSS quasi eigens debuggen kann.

https://www.reddit.com/r/nvidia/comments/oswwon/the_dlss_sdk_released_by_nvidia_allows_you_to/

Sehr interessant, auch das Video: https://www.youtube.com/watch?v=cL-Ld4EVqE4

Interessant, was passiert wenn man die jitter accumulation anstellt. Dann sieht es so aus, als würde DLSS trippen. Ghosting at its best :biggrin:

Was tut es trippen [mittelalterlich: Unterschuhe] ?

Oder meinst du, sieht ja so aus als wäre DLSS auf einem Trip ?

Wir gehen mal trippen ;D

[TheAntitheist]

Edit:
Das massive Geflimmer von DLSS rechts im Bild beim Wasser ist mir tatsächlich durchgegangen. Was ist denn da wieder kaputt?
https://youtu.be/Io8MuK7_WgE?t=113


hat ja offensichtlicherweise nix mit dlss zu tun, weil es erst nicht da ist... Ich denke die Schatten haben einen anderen Winkel und dann entstehen halt solche flackernden Schatten wenn die Auflösung nicht ausreicht. Ist also auch ohne DLSS so, kennt man doch schon seit über 10 Jahren..
übrigens ist das geflacker auch bei FSR zu sehen, spul mal zurück wo die Videos separat gezeigt werden https://youtu.be/Io8MuK7_WgE?t=83 . Also wieder mal unnötig. Vielleicht frischst du dein technisches Verständnis diesbezüglich etwas auf. Auch bei den weißen Planen auf dem Schiff reicht die Shadowmap Auflösung einfach nicht aus und man sieht halt das lowpoly Model dadurch deutlich mehr, was durch gouraud shading unbemerkt bleibt.

[dargo]

hat ja offensichtlicherweise nix mit dlss zu tun, weil es erst nicht da ist... Ich denke die Schatten haben einen anderen Winkel und dann entstehen halt solche flackernden Schatten wenn die Auflösung nicht ausreicht.
Tjo... in dem Fall ist dann sowohl DLSS als auch FSR Grütze sofern das Geflacker in der nativen Auflösung von 4k nicht da ist.

Aber stimmt schon, ich hatte mich zu sehr auf den Direktvergleich fixiert. Daneben sind die Einzelbetrachtungen schon wieder lustig. Das Geflimmer am Wasser ist in der Einzelbetrachtung von FSR da, bei DLSS nicht. Im Direktvergleich genau andersrum. :freak: Womöglich hatte der Tester wirklich unterschiedliche ToDs verwendet. In der einen Szene ist es ja direkt erkennbar.
https://youtu.be/Io8MuK7_WgE?t=219

[BlacKi]

Massiv ist massiv übertrieben. ;) Aber ich stimme zu, auch ich empfinde das FSR-Bild leicht zu überschärft. DLSS-Bild wiederum leicht zu unscharf. Eigentlich bedarf es bei beiden einer Anpassung, dass sich beide bei der Bildschärfe annähern.

Edit:
Das massive Geflimmer von DLSS rechts im Bild beim Wasser ist mir tatsächlich durchgegangen. Was ist denn da wieder kaputt?
https://youtu.be/Io8MuK7_WgE?t=113

Je öfter ich den Direktvergleich betrachte umso mehr DLSS-Fehler fallen mir auf. :freak: Das Geflimmer der Schatten beim Schiff (die weiße Plane bzw. Stoff) mit DLSS sieht ja auch ziemlich übel aus.übel ist übelst übertrieben^^ das geflimmer ist aber in der ersten dlss großbildszene nicht vorhanden. und das schlechter aufgelöste schattenwerfen hab nicht nichtmal wahrgenommen. könnte aber auch durch irgendwas anderes zustandegekommen sein. anderer sonnenstand usw.

[dildo4u]

Wer FSR vs DLSS testen will Marvel Avengers hat Grad ein Free Weekend aus Steam.

[aufkrawall]

DLSS ist kaputt in Avengers, manchmal scheinen die Umrisse von Objekten transparent durch Texturen. Schätze, das liegt am negativen LOD-Bias, denn schon in SotTR (gleiche Engine) gab es solche Probleme, wenn man negatives LOD-Bias erzwang (unabhängig von DLSS). Das haben die Dödel wohl nicht so ganz gemerkt...
Wenn man davon mal absieht (sofern man will), sieht DLSS Q aber eindeutig besser als aus als das Schmier-TAA in nativen 1440p. Einfach sauberer und detaillierter und dabei 33% schneller auf der 3060...

[aufkrawall]

Erstaunlich, wie gut 2.2(.11) auch mit B/P noch aussehen kann :eek: :
Jeweils von Performance nach TAA:
https://abload.de/thumb/fortniteclient-win64-aijs1.png (https://abload.de/image.php?img=fortniteclient-win64-aijs1.png) https://abload.de/thumb/fortniteclient-win64-kfjji.png (https://abload.de/image.php?img=fortniteclient-win64-kfjji.png) https://abload.de/thumb/fortniteclient-win64-6gkvn.png (https://abload.de/image.php?img=fortniteclient-win64-6gkvn.png) https://abload.de/thumb/fortniteclient-win64-0xjao.png (https://abload.de/image.php?img=fortniteclient-win64-0xjao.png)

https://abload.de/thumb/fortniteclient-win64-48kp4.png (https://abload.de/image.php?img=fortniteclient-win64-48kp4.png) https://abload.de/thumb/fortniteclient-win64-5fkpy.png (https://abload.de/image.php?img=fortniteclient-win64-5fkpy.png) https://abload.de/thumb/fortniteclient-win64-nnjn1.png (https://abload.de/image.php?img=fortniteclient-win64-nnjn1.png) https://abload.de/thumb/fortniteclient-win64-yjkky.png (https://abload.de/image.php?img=fortniteclient-win64-yjkky.png)

Je niedriger die Render-Auflösung, desto eher schmiert es bei feinen Umrissen vor bestimmten Hintergründen, die Bewegungsunschärfe nimmt auch weiter zu und Schatten werden pixeliger. Ist aber unterm Strich bei der Performance-Skalierung und anderen Vorteilen hinnehmbar. Das gilt für Doom Eternal im Grunde auch genau so wie für Fortnite.

2.2 kam ja schon ganz unverhofft als beachtliche Verbesserung. Hoffentlich dauert es nicht all zu lange bis zur nächsten. :)

[TheAntitheist]

Ich glaub immernoch das die Rainbow Six dlss version (2.2.6?) die wenigsten schlieren zieht, zumindest war es bei doom zumindest so. Die neueren waren schlechter.

[aufkrawall]

Ist auch tatsächlich so (.11 vs. .6 Seitwärtsbewegung):
https://abload.de/thumb/doometernalx64vk_2021xjjzq.png (https://abload.de/image.php?img=doometernalx64vk_2021xjjzq.png) https://abload.de/thumb/doometernalx64vk_2021z8j4m.png (https://abload.de/image.php?img=doometernalx64vk_2021z8j4m.png)

Das sollte bei Nvidia irgendjemand mal merken. :freak:

[TheAntitheist]

Ist auch tatsächlich so (.11 vs. .6 Seitwärtsbewegung):
https://abload.de/thumb/doometernalx64vk_2021xjjzq.png (https://abload.de/image.php?img=doometernalx64vk_2021xjjzq.png) https://abload.de/thumb/doometernalx64vk_2021z8j4m.png (https://abload.de/image.php?img=doometernalx64vk_2021z8j4m.png)

Das sollte bei Nvidia irgendjemand mal merken. :freak:
is das geil oder? ;D Schade das wir pixeljetstream nicht mehr mal anpuffen können, der treibt sich ja schon länger nicht mehr hier rum : (
Und danke für den fixen Vergleich

[Platos]

Ist auch tatsächlich so (.11 vs. .6 Seitwärtsbewegung):
https://abload.de/thumb/doometernalx64vk_2021xjjzq.png (https://abload.de/image.php?img=doometernalx64vk_2021xjjzq.png) https://abload.de/thumb/doometernalx64vk_2021z8j4m.png (https://abload.de/image.php?img=doometernalx64vk_2021z8j4m.png)

Das sollte bei Nvidia irgendjemand mal merken. :freak:

Kann man sich nicht selbst auf.6 Version halten, indem man die .dll austauscht?

[aufkrawall]

Kann man sich nicht selbst auf.6 Version halten, indem man die .dll austauscht?
Ja. Im Fall von Doom Et. wird ja standardmäßig sogar noch eine 2.1-Version ausgeliefert.

Nochmal mit 2.2.6 in Fortnite (geht doch auch mit dieser Version; scheint nur reiner Zufall, ob es aus dem Optionsmenü verschwindet):
https://abload.de/thumb/fortniteclient-win64-dbkj0.png (https://abload.de/image.php?img=fortniteclient-win64-dbkj0.png) https://abload.de/thumb/fortniteclient-win64-mhkm9.png (https://abload.de/image.php?img=fortniteclient-win64-mhkm9.png) https://abload.de/thumb/fortniteclient-win64-v0jet.png (https://abload.de/image.php?img=fortniteclient-win64-v0jet.png) https://abload.de/thumb/fortniteclient-win64-03jqj.png (https://abload.de/image.php?img=fortniteclient-win64-03jqj.png)

Schmiert definitiv sichtbar weniger. Es erscheint mir von daher wirklich in keinster Weise nachvollziehbar, weshalb spätere Versionen wieder stärker schmieren. Hoffentlich ist das nur ein Bug...

[Platos]

Naja, immerhin kann man einfach seine gewünschte Version "auswählen", indem man die gewünschte dll nimmt. Aber verstehe das auch nicht. Der Baum in einem der vorherigen Bildern hat extrem geschmiert.

[Dampf]

Ja. Im Fall von Doom Et. wird ja standardmäßig sogar noch eine 2.1-Version ausgeliefert.

Nochmal mit 2.2.6 in Fortnite (geht doch auch mit dieser Version; scheint nur reiner Zufall, ob es aus dem Optionsmenü verschwindet):
https://abload.de/thumb/fortniteclient-win64-dbkj0.png (https://abload.de/image.php?img=fortniteclient-win64-dbkj0.png) https://abload.de/thumb/fortniteclient-win64-mhkm9.png (https://abload.de/image.php?img=fortniteclient-win64-mhkm9.png) https://abload.de/thumb/fortniteclient-win64-v0jet.png (https://abload.de/image.php?img=fortniteclient-win64-v0jet.png) https://abload.de/thumb/fortniteclient-win64-03jqj.png (https://abload.de/image.php?img=fortniteclient-win64-03jqj.png)

Schmiert definitiv sichtbar weniger. Es erscheint mir von daher wirklich in keinster Weise nachvollziehbar, weshalb spätere Versionen wieder stärker schmieren. Hoffentlich ist das nur ein Bug...

Könnte es vielleicht sein, dass DLSS Debug Einstellungen in der DLL gespeichert werden? Vielleicht haben die Entwickler von R6S Auto-Exposure (was das Schmieren-Problem angeht) an gestellt und die anderen eben nicht.

[Gast]

Könnte es vielleicht sein, dass DLSS Debug Einstellungen in der DLL gespeichert werden? Vielleicht haben die Entwickler von R6S Auto-Exposure (was das Schmieren-Problem angeht) an gestellt und die anderen eben nicht.

Nachdem Nvidia keinen Source hergibt nein, ohne Source kannst du keine DLL neu bauen.

[Troyan]

Zwar nicht wirklich was mit DLSS zu tun, aber Twitter hat gestern herausgefunden, dass nVidia seit Jahren vier Upscaling-Auflösungen anbietet, die im Grunde das selbe machen wie FSR.

Naja, immerhin.

[Blediator16]

Zwar nicht wirklich was mit DLSS zu tun, aber Twitter hat gestern herausgefunden, dass nVidia seit Jahren vier Upscaling-Auflösungen anbietet, die im Grunde das selbe machen wie FSR.

Naja, immerhin.


People interested in FSR and on an NV GPU in a game that does not have it - I recommend checking this driver option:
Same Lanczos upscale as FSR (with more taps for higher quality) with controllable sharpen.
You need to have your output set to scaling on GPU though.
https://twitter.com/Dachsjaeger/status/1422982316658413573

[iamthebear]

Der Algorithmus scheint ähnlich zu sein, jedoch nicht derselbe.

Ein Nachteil, der damit definitiv besteht ist, dass das HUD mitskaliert wird, während bei FSR dieses später in der höheren Auflösung eingefügt wird.

Ich versuche es gerade zu testen aber bei mir fehlt die GPU Scaling Option.

Kann das damit zusammenhängen, dass ich am Windows Desktop HDR aktiviert habe bei meiner 1070 Ti?

[Blediator16]

TomsHardware scheißt auch hart rein:

AMD's FSR Uses Lanczos, Just Like Nvidia's 5-Years-Old Sharpening Filter
https://www.tomshardware.com/news/amds-fsr-uses-lanczos-just-like-nvidias-5-years-old-sharpening-filter?utm_medium=social&utm_source=twitter.com&utm_campaign=socialflow

https://twitter.com/tomshardware/status/1423178309618307072

[aufkrawall]

Halte ich nicht für wirklich vergleichbar (auch wenn FSR nur primitive Bild-Skalierung ist), weil der Lanczos-Filter von AMD kein Ringing verursachen soll und das Sharpen im NV-Treiber (zusätzlich zum dort verwendeten Lanczos-Filter) wie bekloppt Ringing verursacht.
Das generische Treiber-Scaling von NV dürfte also nochmal wesentlich schlimmer aussehen.

[TheAntitheist]

ist schon der gleiche Filter, nur das sie eben ein limit setzen fürs sharpening (kein höherer kontrast als beim Original), was nicht standardmäßig dabei ist. Ist aber auch keine Erfindung von AMD, im Prinzip haben die nichts davon selbst entwickelt.

[Blediator16]

ist schon der gleiche Filter, nur das sie eben ein limit setzen fürs sharpening (kein höherer kontrast als beim Original), was nicht standardmäßig dabei ist. Ist aber auch keine Erfindung von AMD, im Prinzip haben die nichts davon selbst entwickelt.

Der Seitenhieb musste sein?

[DrFreaK666]

Scheint nicht sehr kompatibel zu sein

Currently, the following limitations apply:

Scaling is not supported on MSHybrid systems.
HDR displays driven by pre-Turing GPUs will not support scaling
Scaling will not work with VR
Scaling will not work with displays using YUV420 format.
Scaling uses aspect ration scaling and will not use integer scaling
Sharpening will not work with HDR displays
GPU scaling engages when games are played only in full-screen mode, and not in
windowed or borderless windowed mode.
Some G-SYNC displays have a 6-tap/64-phase scaler which scales better than that
offered by Turing's 5-tap/32-phase scaler.
To avoid accidentally triggering scaling by applications or DWM, first change to the
desired (<native) resolution from the NVIDIA Control Panel and then launch the
application.
Turing's 5-tap upscaler may not engage on certain monitors, based on the monitor's
vblank timing.
Turing's 5-tap upscaler may not engage if the input resolution is greater than 2560px
in either the x or y dimension.
Scaling is turned off automatically when switching display devices.
"Restore Defaults" option in the control panel currently does not revert the upscaling resolution.

[TheAntitheist]

Der Seitenhieb musste sein?
es ist ja eine Tatsache, und dafür hat AMD halt 2 Jahre gebraucht, ja das musste sein ;D

[DrFreaK666]

es ist ja eine Tatsache, und dafür hat AMD halt 2 Jahre gebraucht, ja das musste sein ;D

AMD hat es zur "Marktreife" gebracht und FSR ist deutlich kompatibler - immer noch

[hmmm]

Lanczos gibt es schon wie lange zur 2D Skalierung? 50-70 Jahre?

Nur weil zb 2 Implementierungen auf dem gleichen Verfahren berhuhen, bedeutet dies doch nicht das sie gleich sind und das hier keine Innovation sein kein. Andernfalls gäbe es in der IT keine Innovation.
Vergleicht doch mal FSR vs nvidias GPU Skalierung, eingentlich reicht schon AMDs GPU Skalierung ;)

[Troyan]

Ja, habe ich. Sieht genauso beschissen aus wie GPU-Skalierung bei nVidia. Einziger Unterschied ist das HUD, was in nativer Auflösung vorhanden ist.

Da die GPU-Skalierung dagegen sogar deutlich schneller ist, macht es als Turing+ Besitzer null Sinn FSR zu verwenden.

[TheAntitheist]

Lanczos gibt es schon wie lange zur 2D Skalierung? 50-70 Jahre?

Nur weil zb 2 Implementierungen auf dem gleichen Verfahren berhuhen, bedeutet dies doch nicht das sie gleich sind und das hier keine Innovation sein kein. Andernfalls gäbe es in der IT keine Innovation.
Vergleicht doch mal FSR vs nvidias GPU Skalierung, eingentlich reicht schon AMDs GPU Skalierung ;)
doch die sind Haargenau gleich ;D

[DrFreaK666]

doch die sind Haargenau gleich ;D

Gibt es dazu auch eine Quelle?
Wieso fällt das erst jetzt auf?

[Troyan]

Weil die meisten keine Ahnung haben, was nVidia anbietet. Die haben die vier Skalierungsauflösungen irgendwann vor Jahren eingeführt. Die meisten werden es aber nicht nutzen, da man eben nicht "nativ" das HUD hat. Das ist verständlich. Aber da FSR soviel Leistung kostet, kann man bei nVidia auch die höhste Skalierungsauflösung nehmen und hat so ca. 10% mehr Pixelauflösung pro Achse.

[DrFreaK666]

Und woher weiss man dass die NV-Lösung verformanter ist bei gleicher Qualität?

[Gast]

doch die sind Haargenau gleich ;D
Nicht ganz. AMD hat noch minimal etwas gegen das Ringing gemacht. Macht es trotzdem nicht weniger underwhelming, wenn man in den Quellcode schaut.

[aufkrawall]

Und woher weiss man dass die NV-Lösung verformanter ist bei gleicher Qualität?
Das schon gesehen?
https://www.forum-3dcenter.org/vbulletin/showthread.php?t=606468&page=65
Bikubisch, und man sieht ~keinen Unterschied. :freak: ;D

[DrFreaK666]

Das schon gesehen?
https://www.forum-3dcenter.org/vbulletin/showthread.php?t=606468&page=65
Bikubisch, und man sieht ~keinen Unterschied. :freak: ;D

Hä? Das hat mit dem NV-Filter doch überhaupt nichts zu tun
Blabla wie "man sieht keinen Unterschied" ohne Vergleiche, sind substanzlos

[hmmm]

Ja, habe ich. Sieht genauso beschissen aus wie GPU-Skalierung bei nVidia. Einziger Unterschied ist das HUD, was in nativer Auflösung vorhanden ist.

Da die GPU-Skalierung dagegen sogar deutlich schneller ist, macht es als Turing+ Besitzer null Sinn FSR zu verwenden.
Kann schon mal vorkommen das FSR "genauso beschissen aussieht" wie nvidias GPU-Skalierung. Lass mich raten, du hast 2 Schwarzbilder skaliert und verglichen UND dabei den Monitor noch aus gehabt?
Sorry, aber das hier wird ja langsam lächerlich. Sollte sich der Code von nvidia im inet verbreiten und nvidia nichts dagegen haben, dann können wir den mal mit FSR vergleichen, selbst im Code kann man schon sehen, dass das Bild unterschiedlich aussehen muss.

[aufkrawall]

Hä? Das hat mit dem NV-Filter doch überhaupt nichts zu tun
Blabla wie "man sieht keinen Unterschied" ohne Vergleiche, sind substanzlos
Und? Ist simple bikubische Skalierung, die Video-Renderer seit über zehn Jahren können. Soo gut ist FSR. :freak:

[hmmm]

Und? Ist simple bikubische Skalierung, die Video-Renderer seit über zehn Jahren können. Soo gut ist FSR. :freak:
*kopfschüttel*
Dann nutze die "simple bikubische Skalierung" mal bitte ingame und behalte den FPS Vorteil gegenüber nativ.

[Gratzner]

Das schon gesehen?
https://www.forum-3dcenter.org/vbulletin/showthread.php?t=606468&page=65
Bikubisch, und man sieht ~keinen Unterschied. :freak: ;D

Hier wurde nicht bikubisch verwendet, sondern bikubisch+RCAS und je nach Bildbearbeitungssoftware für die Bikubische Skalierung sind noch weitere optimierungen eingeflossen

[hmmm]

Hier wurde nicht bikubisch verwendet, sondern bikubisch+RCAS und je nach Bildbearbeitungssoftware für die Bikubische Skalierung sind noch weitere optimierungen eingeflossen
Die Laufzeit der "simple bikubische Skalierung" würde mich doch sehr Interessieren. 1060Ti wenn es geht ;)

[aufkrawall]

Sieht mit dem bikubischen Scaler des EVR-CP Renderers in MPC-HC genau so aus wie mit madVR, ist quasi gratis auf jeder GPU. ;D
Mehr dazu im FSR-Thread...

[hmmm]

Sieht mit dem bikubischen Scaler des EVR-CP Renderers in MPC-HC genau so aus wie mit madVR, ist quasi gratis auf jeder GPU. ;D
Mehr dazu im FSR-Thread...
Natürlich sieht es gleich aus, selber Codec. Dann sag was zur laufzeit und mach bitte die Angaben im FSR-Thread.

[Gratzner]

Bikubisch ungleich Bikubisch. Kommt sehr darauf an, was für ein Spline benutz wurde. Beispielsweise der Spline von Mitchell-Netravali kann (je nach Parameter) der gefensterten Sync-Funktionen der Lanczos Rekonstruktion (auf welche FSR basiert) sehr ähnlich aussehen und gibt auch entsprechend die gleiche Bildqualität zurück. Andere Parameter und/oder andere Spline geben andere Ergebnisse zurück. Daher, was ist "simple bikubische Skalierung"?

Die Performance dürfte sehr von der Implementation abhängen und vom verwendeten Spline (Spline = vereinfacht: eine Funktion, welche Abschnittsweise durch Polynome definiert ist. Bikubisch enthält kubisch für polynome dritten Grades und Bi für die 2 Dimensionen eines Bildes).
Ihmo: Hat der Spline ein Funktionswert verschieden von 1 an der Stelle 0, sorgt das dafür, das man für jeden Pixel zusätzlich eine Division durch eine konstante Zahl machen muss (lässt sich optimieren zu Multiplikation und bitshift).
Hat der Spline Funktionswerte verschieden von 0 an den Stellen benachbarten Pixel, also an den Stellen 1, -1, 2, -2, 3,-3, usw., dann müsste man Gleichungssysteme lösen, welche aus dem Spline Polynome bestehen.
Die gefensterten Sync-Funktionen der Lanczos Rekonstruktion ist an der Stelle 0 immer 1 und an den Stellen der benachbarter Pixel immer 0.

[Badesalz]

Wieviele Versionen brauchen die eigentlich bis das auch "fertig" ist? Die wissen doch was intern ansteht oder? Weil es lief bisher in etwa so:

- Fanboys belästigen bei 1.0 alle anderen mit Lobesgejaule, obwohl schon Laien Nicht-Fanboys sehen wie mies 1.0 eigentlich ist (Quali).

- Fanboys belästigen bei 2.0 alle anderen mit Lobesgejaule - 1.0 ist dann plötzlich mies... - obwohl schon Laien Nicht-Fanboys sehen wie mies 2.0 ist, sobald RT mit ins Spiel kommt.

- ... Heißt das, ab der 4000 gibt es 3.0, bevor AMD auch bei RT stärker wird? RT ist die Zukunft und so?

Oder wieviele Iterationen des Gejaules wird es noch geben bis DLSS sie wenigsten auf "Quali" auch real verdient?

Hej ich hätte da noch ein besseres Narrativ:
Auch die Engines und die Spielentwickler selbst müssen bisschen mit DLSS im Hinterkopf optimieren/programieren. Dann sieht das dan gleichermassen gut aus. JA KLAR. Man guckt dann was mit DLSS nicht mehr so hochwertig aussieht und ändert das Rendering (nativ) an den Stellen, so daß es sich kaum noch was durch off/on an der Quali ändert :up:
Dann bringt DLSS zwar nicht mehr SO viel Leistung, da der Aufwand schon nativ sinkt, aber dafür kann man auch erzählen, daß es nun wirklich super ist, weil es keine Unterschiede mehr gegenüber nativ gibt.

Läuft. Alles wird gut.

[robbitop]

Naja bisher hat noch jede größere Iteration von DLSS sichtbare Sprünge in der BQ gebracht. Bezogen auf die Inputresolution sind die Ergebnisse -insbesondere bei guter Implementierung- wirklich erstaunlich. Dass es sichtbare Nachteile gibt, bleibt wahrscheinlich nicht ganz aus, wenn man so viel Auflösung einspart. Aber genau da wird ja jede Iteration immer besser.
Das Einzige was mich massiv stört ist die proprietäre Natur des ganzen. Ich kann es aus Unternehmenssicht verstehen aber aber es ist mal wieder ein weiterer Versuch des Vendorlocks / customer retention. Viele Gamer haben davon nichts leider.

Genau deshalb ist darauf zu hoffen, dass AMD in den nächsten Iterationen von FSR ähnliche Ergebnisse erzielen kann aber ohne Vendorlock. Das wird sicherlich noch dauern.

Rein technisch betrachtet ist DLSS eine gute Option. Man kann sie nutzen, muss es aber nicht.
Reicht die Performance nicht für 4K60? -> DLSS. Neue GPUs zu teuer und das Spiel rennt nicht in ausreichender FPS -> DLSS
Will man 8K@4K oder 5K@1440p downsamplen um noch mehr BQ zu bekommen? -> DLSS

DLSS hat Kompromisse - je nach Spiel. Aber je nach Situation kann es eine sinnvolle Option sein mehr aus den vorhandenen TFLOPs der GPU herauszuholen.

[Badesalz]

@robbitop
Mir fehlt da bisschen ein genauerer Blick auf die realen Gegebenheiten.
Auch wenn einiges aktuell stimmt, ist es eher unwahrscheinlich, daß eine der Ideen hinter DLSS die Bewältigung von "Chipkrisen" war =)

Das Feature wäre sonst sehr auserlesen und Quantitativ kaum der Rede wert, wenn man sich die absolute Mehrheit der Zocker und ihre HW anschaut (ähmm)
Wogegen die HQ Nerds und Freaks die auf 4k wüten wollen, sich nicht einfach nur einen Monitor kauf(t)en, sondern die passende Graka mit dazu haben. Grakas von 8k auf 4k ist dann nochmals erlesener.

Vielleicht haben mich bisher aber nur die Fanboys zu stark beinflusst, mit deren Meinung, die ganze Welt braucht das unbedingt und es muss in jedem Munde sein... Ich muss darüber nochmals in Ruhe nachdenken.
Das klingt grad sonst so bisschen nach poorboys feature.

Was AMD dagegen vor allem am Anfang nicht ganz so stark verkleiden mochte. Hast du keine Kohle für 1-level-better HW, bekommst du ein Feature wo du ab minimalst bis nahezu nicht wahrnehmbar Leistung abgeben musst, es dann aber von der Auflösung her den Eindruck erweckt, als wenn du mind. einen halben Level aufgerüstet hättest.

Wie gesagt ich grübel darüber wohl doch noch paar mal nach. Momentan bin ich leicht geschädigt, weil ich mir wohl zu viele miese Beiträge zu dem Thema reingezogen habe.
Oder auch Artikel wo spätestens nach dem zweiten Absatz klar ist welche Motivation dahinter steckt :frown:

Objektivität ist halt ein schwieriges Thema. Vor allem da wo Kommerz mit Milliardenumsätzen mitmischt.
Bis denne.

[Troyan]

DLSS nutzt moderne Hardware. Natürlich können wir gegen technischen Fortschritt sein, weil eine gewisse Firma unfähig ist moderne Hardware zu bauen. Aber weder hat das Apple vor 14 Jahren interessiert noch nVidia mit Turing.

DLSS ist das Resultat aus Fortschritt.

[Gast]

DLSS nutzt moderne Hardware. Natürlich können wir gegen technischen Fortschritt sein, weil eine gewisse Firma unfähig ist moderne Hardware zu bauen. Aber weder hat das Apple vor 14 Jahren interessiert noch nVidia mit Turing.

DLSS ist das Resultat aus Fortschritt.


DLSS ist das Resultat von zu wenig Rohleistung.

[Badesalz]

natürlich können wir gegen technischen Fortschritt sein, weil eine gewisse Firma unfähig ist moderne Hardware zu bauen.Meist Matsche ist jetzt nicht unbedingt Fortschritt. Oder was meinst du? Oder kannst DU damit etwa von 8k auf 4k/60 runter? Was hast du für eine Graka nochmal?

Erstens. Zweitens hat DLSS nichts mit moderner Hardware zu tun. DLSS ist erstmal eine externe Dienstleistung und keine Eigenschaft einer/deiner GPU.

Das ist es was ich davor meinte Leute. Existenzen ohne Durchblick machen das Thema dermassen ätzend, daß man sie am liebsten einfach sich selbst überlassen würde. Was auch überhaupt kein Ding wäre, wären sie dabei nicht in jeder Gesprächsrunde so vorlaut.

[dargo]

DLSS ist das Resultat von zu wenig Rohleistung.
Die Rohleistung ist da, nur halt auf dem Papier. Wobei selbst wenn die Luftpumpe @Ampere die volle Rohleistung auf die Straße bringen könnte wäre es immer noch viel zu wenig für RT.

[dildo4u]

Was ist das RT?Konsolen Style RT läuft ok ohne DLSS.

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

[robbitop]

Die Anzahl der FPUs ist leider etwas irreführend. Die FPUs wurden verdoppelt aber nicht die Anzahl der Ports im Scheduler. Sogar in synthetischen Workloads ist es schwierig, alles auf die Straße zu bringen. Man sollte sich von reiner Ausführungseinheitenanzahl, TFLOPs etc heute nicht mehr beeinflussen lassen. Es war relativ günstig die FPUs zu verdoppeln. Es brachte mehr Leistung als es Transistoren kostete. Aber es verdoppelte pro SM natürlich nicht die Leistung. Rein technisch war es sicherlich keine schlechte Entscheidung. In den Situationen geht es nur darum wie viel mehr Leistung pro Transistor man rausholen kann.
Im Nachfolger kann es sein, dass dann die Kontrolllogik pro SM auch verbreitert wird und man dann (analog maxwell und pascal) wesentlich mehr aus 128 FP pro SM ziehen kann.

edit: es sind gem mksn7 Messungen (siehe ff) die Registerports die nicht aufgebohrt wurden.

[Troyan]

DLSS ist das Resultat von zu wenig Rohleistung.

Nö, DLSS ist das Resultat von überflüssiger Rechenleistung bereitgestellt durch die TensorCores. Rastergrafik ist digital und daher ist es egal, wie die Farbinformation einzelner Rasterpunkte ermittelt wird.

Bin von 27" auf 32" 4K gewechselt und der Unterschied zwischen DLSS@Ultra und FSR@UQ ist so dermaßen offensichtlich in Avengers, dass man eben erkennt, was dummes Upscaling und hochmodernes Upscaling ist. :eek:

Wenn schon bei einer PPI von 138 das so offensichtlich ist, dann will ich nicht wissen, wie grottig FSR bei 1440p oder sogar 1080p ist.

Die Anzahl der FPUs ist leider etwas irreführend. Die FPUs wurden verdoppelt aber nicht die Anzahl der Ports im Scheduler. Sogar in synthetischen Workloads ist es schwierig, alles auf die Straße zu bringen. Man sollte sich von reiner Ausführungseinheitenanzahl, TFLOPs etc heute nicht mehr beeinflussen lassen. Es war relativ günstig die FPUs zu verdoppeln. Es brachte mehr Leistung als es Transistoren kostete. Aber es verdoppelte pro SM natürlich nicht die Leistung. Rein technisch war es sicherlich keine schlechte Entscheidung. In den Situationen geht es nur darum wie viel mehr Leistung pro Transistor man rausholen kann.
Im Nachfolger kann es sein, dass dann die Kontrolllogik pro SM auch verbreitert wird und man dann (analog maxwell und pascal) wesentlich mehr aus 128 FP pro SM ziehen kann.

Sorry, hä? nVidia hat mit Turing die Kontrollogik erweitert, dass FP32 und INT32 Operationen gleichzeitig ausgeführt werden konnten. Mit Ampere hat man eine zweite FP32 Pipeline eingebaut. Die Kontrollogik ist schon seit Turing soweit gewesen. Pro Compute Unit können 128 FP32 Operationen pro Takt ausgeführt werden.

[why_me]

Bin von 27" auf 32" 4K gewechselt und der Unterschied zwischen DLSS@Ultra und FSR@UQ ist so dermaßen offensichtlich in Avengers, dass man eben erkennt, was dummes Upscaling und hochmodernes Upscaling ist. :eek:

Avengers, das Spiel, an das jeder 2021 denkt, wenn es um die beste Grafik in Videospielen geht....
Selbst vor 5 Jahren wäre Avengers höchstens Mittelmaß gewesen.
DLSS umgeht hier nur das miserable TAA.

[robbitop]

@Troyan
Es gibt tatsächlich Limitierungen für die FP Pfade. Das wurde hier im Forum bereits detaillierter untersucht und erklärt. Mit einem selbst geschriebenen Tool. Maxwell und Pascal verhielten sich da deutlich besser in Bezug auf die Auslastung als Ampere.

Ggf. kann der Autor sich dazu hier nochmal melden um es mit mehr Substanz aufzufüllen.

edit: es sind gem mksn7 Messungen (siehe ff) die Registerports die nicht aufgebohrt wurden.

[Complicated]

Avengers, das Spiel, an das jeder 2021 denkt, wenn es um die beste Grafik in Videospielen geht....
Selbst vor 5 Jahren wäre Avengers höchstens Mittelmaß gewesen.
DLSS umgeht hier nur das miserable TAA.
Das mag auch die Verbreitung bei Spielestudios fördern. Weniger Aufwand in die Grundqualität benötigt, einfach DLSS darüberlegen und fertig ist das Ganze. 1 Jahr Entwicklung gespart.
Hier sollte man nebenbei weiterhin ein Auge drauf haben wie sich die Grund-Qualität/Performance der Spiele entwickelt, bevor die Bildverbesserer zum Einsatz kommen.
Denn auf diese Weise werden die Spieler am Ende um den Mehrwert betrogen, zu Gunsten der Kostenersparnis beim Studio.

[Badesalz]

@Troyan
Es gibt tatsächlich Limitierungen für die FP Pfade. Das wurde hier im Forum bereits detaillierter untersucht und erklärt. Mit einem selbst geschriebenen Tool. Maxwell und Pascal verhielten sich da deutlich besser in Bezug auf die Auslastung als Ampere.Ja. Das könnte übrigens auch gewollt sein, damit die Dinger in Consumerboxen nicht in die Limits laufen.

[robbitop]

Ja. Das könnte übrigens auch gewollt sein, damit die Dinger in Consumerboxen nicht in die Limits laufen.

Er hat den Code iterativ umgeschrieben und dann gab es die volle Leistung. Dazu musste aber iirc Abhängigkeit entfernt werden. Das war bei Pascal/Maxwellnicht nötig. Es war relativ gut erkennbar, dass es da eine Limitierung gab und iirc konnte er diese im Whitepaper sogar wiedergeben. Es tut mir leid ich bekomme es leider nicht sinnvoll wiedergegeben da es schon recht lange her ist.

[Zerozerp]

Hej ich hätte da noch ein besseres Narrativ:
Auch die Engines und die Spielentwickler selbst müssen bisschen mit DLSS im Hinterkopf optimieren/programieren. Dann sieht das dan gleichermassen gut aus. JA KLAR. Man guckt dann was mit DLSS nicht mehr so hochwertig aussieht und ändert das Rendering (nativ) an den Stellen, so daß es sich kaum noch was durch off/on an der Quali ändert :up:

Läuft. Alles wird gut.

DLSS bietet inzwischen viele Möglichkeiten der Fehlerbehandlung. Bekommt man aus DLSS nur "Matsche" raus, dann ist es nicht sauber implementiert.

Auch ist es möglich Reflexionen durch DLSS behandeln zu lassen. Mechwarrior 5 oder Wolfenstein Youngblood wären da positiv- Beispiele dafür. Die haben verstanden, dass man auch dort die Motion vectors invertiert am Leben erhalten kann. Schwierig wirds dann aber mit der Auffüllung bzw. Unterfütterung der RT Reflections mit Screenspace Reflections, welche aber eben auch nur notwendig ist, wenn man z.B. Partikel außerhalb der 3d- Passes in den Screenspace projeziert. Raytracing und diverse Raster- Fakes sind keine besonders guten Freunde.


Leider sind viele der Implementationen so unterirdisch, dass der Ruf der ganzen Technik inzwischen drunter leidet.

Da macht sich NVIDIA schon die Mühe, wirklich saubere Programmierleitfäden mitzuschicken und einige Devs gehen noch nichtmal die beigefügte Checkliste der Hauptfallstricke und Grundvorraussetzungen für eine saubere Implementierung durch (90% scheitern schon an der einfachen lodbias- Korrektur).

Dass sowas dann noch durch den NVIDIA review- Prozess kommt, lässt einen vernunftbegabten Menschen dann vollends vom Glauben abfallen.

Sehr schade - Ist das Potenzial und der Nutzen der Technik doch sehr groß und der Effizienzsprung gewaltig. Warum Pixel nochmal berechnen, die sich innerhalb der Projektionsmatrix nur hin- und herschieben?
Endlich kann dieses ineffektive bruteforce- rastern mal optimiert werden. Jeden Mist/Effekt puffert man seit langer Zeit temporal, nur bei den Pixeln selbst hat man bei jedem Frame mit dem Dampfhammer drauf.

Zudem sind ja in Zukunft ein par schöne Neuerungen in DLSS enthalten, so dass die der receiver für die motion- vectors nicht mehr 2d sondern 3d basiert arbeiten kann oder man zusätzliche Masken (unter Anderem für Partikel) und Flags erhält, mit welchen man "schwierige" Objekte gesondert behandeln kann. Das wird dann nochmal einigen der verbliebenen Restschmerzen mit der Technik beseitigen.

Aber es ist wie Du sagst:

Läuft. Alles wird gut.

[Gast]

Mit Ampere hat man eine zweite FP32 Pipeline eingebaut.

Eben nicht, man hat die INT-Einheit durch eine überbreite FP-Einheit ersetzt.

Je nach INT-Anteil ist damit eben nicht man theoretisch eine Leistungsverdopplung möglich.

In realen Spielen hat man üblicherweise INT-Anteile von 25-50%, damit ist die theoretische Leistungssteigerung pro SM von Ampere gegenüber Turing eben "nur" ca. 30-50% und nicht 100%.

[robbitop]

Selbst bei reinem FP Code (ohne INT) in dem Testprogramm in Cuda konnte der User nur unter bestimmten Voraussetzungen annähernd an die Theoriewerte rankommen. Da verhielt sich Pascal und Maxwell anders/besser. Sehr ärgerlich, dass ich diese Posts nicht mehr finde.

[Troyan]

Natürlich erreicht Ampere die doppelte FP32 Rechenleistung gegenüber Turing: https://babeltechreviews.com/the-rtx-3090-founders-edition-performance-revealed-35-games-spec-workstation-gpgpu-benchmarked/view-all/

Runterscrollen zu Aida Benchmarks.

Eben nicht, man hat die INT-Einheit durch eine überbreite FP-Einheit ersetzt.

Je nach INT-Anteil ist damit eben nicht man theoretisch eine Leistungsverdopplung möglich.

In realen Spielen hat man üblicherweise INT-Anteile von 25-50%, damit ist die theoretische Leistungssteigerung pro SM von Ampere gegenüber Turing eben "nur" ca. 30-50% und nicht 100%.

Es geht bei Ampere darum die Compute Units mit Arbeit zu befüllen. Laut nVidia kommen in Spielen auf 10 FP32 Operationen 3 INT32 Operationen im Schnitt. Das heißt, der zweite Datenpfad liegt die Mehrheit der Zeit einfach brach. Die Erweiterung bei Ampere macht also aus der Sonderstellung Volta/Turing wieder den Normalzustand, wie er bei Pascal war.

Netter Nebeneffekt: Funktionierte mit geringem Transistorenaufwand.

[robbitop]

Pascal's SMs sind dicker, mit 4 dual issue schedulers. Von Pascal zu Turing sind es dann nur noch 4 single issue scheduler, und aber auch halbierte FP32 Einheiten, so dass issue rate und FP32 Einheiten die gleiche Balance haben. Ampere hat die FP32 Zahl wieder auf den Stand von Pascal gebracht, aber trotzdem noch nur halbe issue rate. Da ist es natürlich schwieriger ans Maximum ranzukommen.


Sämtliche Messungen zu Pascal, Turing und Ampere ab https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12638004#post12638004

Gipsel schrieb dazu:

Zitat von gipsel:
aber wie mskn7 schon angedeutet hat, dürfte das oft nicht wirklich entscheidend sein (zusätzlich zu den genannten Punkten habe ich auch den leisen Verdacht, daß die Anzahl der Register-Ports bzw. -Bänke bei nV eventuell nicht ausreicht, um in jeder Situation genügend Operanden für alle ALUs ranzuschaffen; bei älteren nv-GPUs war das ja auch schon mal so; spart halt Aufwand [und Strom] bei den Registern [ein wesentlicher Stromfresser bei GPUs]).

OK es waren die Registerports. Bei gleichen Bedingungen ist es auf Ampere schwieriger die volle FP32 Leistung herauszuholen als bei Pascal. Beide haben 128 FP pro SM.


IMO ist obiges auch nicht überraschend, denn Pascal hatte in Spielen nie große Probleme ihre Rechenleistung trotz 128 SP pro auf die Straße zu bringen. Turing war gerade mal 5-10% schneller rohleistungsnormiert. Ampere hingegen hängt rohleistungsnormiert deutlich stärker zurück.

[Badesalz]

Leider sind viele der Implementationen so unterirdisch, dass der Ruf der ganzen Technik inzwischen drunter leidet.Ok. Das könnte auch mal sein. Prinzipiell ist an dem Zeug auch nichts pauschal verwerflich.
Die Krux ist halt nur, daß ein... Dienstleister ;) erstmal viel Vorleistung bringen muss, damit nachher die eigene GPU damit was anfangen kann.

[CD-LABS]

DLSS ist das Resultat von zu wenig Rohleistung.
Wenn Pascal, Turing und Ampere so gut wie Kepler und Maxwell geworden wären, hätte DLSS (2.X) zu entwickeln trotzdem Sinn gehabt, wäre aber in erster Linie als Antialiasingmethode und nicht als Performancesparmethode genutzt worden.

[Gast]

OK es waren die Registerports. Bei gleichen Bedingungen ist es auf Ampere schwieriger die volle FP32 Leistung herauszuholen als bei Pascal. Beide haben 128 FP pro SM.



Ampere ist da nicht beschränkter als Turing, es fällt eben mehr auf, weil man bei Turing eh praktisch nie genug INTs hatte um die entsprechenden Ports konstant voll auszulasten.

[Gast]

DLSS ist das Resultat von zu wenig Rohleistung.
Wir werden halt zu unserer Lebzeit immer zu wenig Rohleistung haben. Die Reduzierung von Samples im Rendering ist auch ein Bestreben seit es Rendering gibt.

Man gewöhnt sich besser daran statt es zu Bashen.

[Zerozerp]

Wenn Pascal, Turing und Ampere so gut wie Kepler und Maxwell geworden wären, hätte DLSS (2.X) zu entwickeln trotzdem Sinn gehabt, wäre aber in erster Linie als Antialiasingmethode und nicht als Performancesparmethode genutzt worden.

Die Frage ist aufgrund der Zerfaserung des Featuresets doch, welche Bemessungsgrundlage man für den Vergleich heranzieht, worin diese Karten "so gut" hätten werden können.

Die architektonischen Besonderheiten werden hier im Thread ja bereits treffend seziert.
Die Organisation auf den Karten ist offensichtlich sehr stark auf die Workloads ausgelegt, die komplexeres hybrid- Raytracing, eher noch die Variante ohne hybrid begünstigen.

Diesbezüglich ist NVIDIA frühzeitig erstaunlich radikal (vielleicht auch zu unausgeglichen?) auf die in Zukunft zu erwartende Rendertechnik umgeschwenkt.

Siehe Path- Tracing bei Minecraft RTX.
Da liefert eine 6900XT in UHD 20 FPS, eine 3090 mit DLSS Performance 118 FPS AVG (erster Test der mir in die Hände gefallen ist- in dem Fall von PC Welt).

Somit wäre NVIDIA also ab Ampere bereits in der Lage komplexe Path- Traced Spiele in hohen Auflösungen und Bildwiederholraten um die 60FPS zu stemmen. Der Polycount ist trotz der simpel wirkenden Geometrie in Minecraft nicht so niedrig, wie es scheint....

Dies natürlich auch, weil der Ballast des hybrid- Parts bei Minecraft RTX zwar nicht vollständig wegfällt, aber dennoch weitestgehend.
Diese hybrid- Methodik frisst nämlich auch nicht zu knapp Ressourcen und sorgt für diverse "stalls" der Shader bzw. die in diesem Thread herausgestellten Auslastungsschwierigkeiten.
Zudem spielt die Komplexität der Szenerie im reinen Path- Tracer eine untergeordnetere Rolle als beim Rastern.

Das wird bei einigen Kommentaren, die ich in diversen Foren lese nämlich unterschätzt.
Dort herrscht vielerorts die Meinung, dass die neuen Karten für das "richtige" Raytracing bzw. Pathtracing noch viel zu schwach seien, ohne eben zu sehen, dass die Architektur der Karten nochmal ordentlich Leistung bereitstellt, wenn man den hybrid- Part schrumpft und bereits primary rays bzw. den first hit per path- tracer rendert.
Gegen den baldigen Umschwung spricht aber natürlich die Verbreitung entsprechend leistungsfähiger Hardware. Als Entwickler würde ich einen Teufel tun, als auf Risiko einen path traced- only- Titel zu entwickeln...

[basix]

Soweit ich verstanden habe, sind Primary Rays per Raster schneller als per Path Tracing. Zumindest habe ich das als eine im Zusammenhang mit Hybrid-RT getätigte Aussage im Kopf. Deswegen macht es keinen Sinn, Primary Rays von Raster auf etwas anderes umzustellen.

[robbitop]

Ampere ist da nicht beschränkter als Turing, es fällt eben mehr auf, weil man bei Turing eh praktisch nie genug INTs hatte um die entsprechenden Ports konstant voll auszulasten.

Schau dir die Messungen von mksn7 mal genauer an. Er schiebt rein FP32 durch. Pascal verhält sich da deutlich besser als Ampere. Er erreicht volle Rohleistung als er die Aufgaben registerfreundlicher gestaltet hat.

[basix]

Bei der Nintendo Switch Pro gibt es ja Gerücht, dass Nvidias Orin als Custom Variante dafür verwendet werden soll. Und 4K Output liefern soll.

Kurze Zusammenfassung zu Orin:
- GPU = 2048 SPs (Ampere)
- CPU = 12x ARM A78
- Speicher = 256b LPDDR5 (max. 200 GByte/s)

So könnte ich mir die Switch Pro vorstellen:
- GPU = 1920 SPs
- CPU = 10C (8-9C für Spiele)
- Speicher = 12 GByte @ 192bit

1920 SPs ergeben bei 1.0GHz bereits 3.84 TFlops. Anhand der Orin Daten von 200 INT8 TOPS wird "Full Orin (2048 SPs)" bei ~1.65 GHz takten und vermutlich beinhaltet die TOPS Angabe das Sparsity Feature.

Das auf 1920 SPs und 1.0 GHz gerechnet (grob abgeschätzt ca. 20...30W inkl. CPU): 123 TOPS (Sparsity) oder 61 TOPS (Standard). Ersteres liegt im Ballpark einer RTX 2060 (115 TOPS) oder RTX 2070 (134 TOPS).

Wieso ist das nun interessant:
DLSS 2.x soll ja INT8 verwenden. Ein Orin SoC mit 1920 SPs und 1.0 GHz Takt käme inkl. Sparsity auf eine gutklassige Inferencing Leistung im Bereich von Desktop GPUs. Verwendet DLSS 2.3 oder DLSS 3.0 nun das Sparsity Feature und weitere Performance Optimierungen, wäre es ein Killervorteil für die Switch Pro. Spiele könnten in 1080p gerendert und auf 4K via DLSS Performance upsampled werden. Bei vielen Spielen würde das für 30...60fps bei relativ hohen Settings reichen, am besten via VRR Display. Bei evtl. 10-15W undocked und 25-30W docked.

Meiner Meinung nach wäre DLSS 3.0 in diesem Beispiel angebracht. Und hätte für Nvidia den Vorteil, dass ein sehr grosser Teil der Switch Spiele (und deren Konsolen/PC Geschwister) zukünftig DLSS unterstützen würden.

[wolik]

Dank DLSS 2.2 (jetzt sind schmier schleifen weg) man kann jetzt Death Stranding in 8K geniessen. Bei Control 8K bringt leider kein Grafikvorteil.

[Zerozerp]

Soweit ich verstanden habe, sind Primary Rays per Raster schneller als per Path Tracing. Zumindest habe ich das als eine im Zusammenhang mit Hybrid-RT getätigte Aussage im Kopf. Deswegen macht es keinen Sinn, Primary Rays von Raster auf etwas anderes umzustellen.

Du kriegst im Gegensatz zum Rastern mir dem primary hit aber bereits pixel perfect shadows (fast) geschenkt und kannst diesen mit DXR 1.1 per compute noch weiter durch diverse Auswertungs-/Anschlusshader jagen....

Bei Minecraft RTX geht ca. 8% des Renderbudgets für ein Frame an den primary hit. Die Kohärenz ist hoch und damit auch die Performance.

Hier ab 29:00
https://www.youtube.com/watch?v=TVtSsJf86_Y
Dort wird angedeutet, dass es per Rasterization nicht wirklich sonderlich schneller gehen würde, man sich aber dadurch eben Nachteile an Bord holt.

Das hybrid- Szenario zeichnet sich ja genau dadurch aus, dass das RT- Rendering "angeflanscht" wird und man nebst den standard Raster- Passes eben on Top noch acceleration structures nebst den ganzen RT- Passes dazukommen.

[Gast]

Schau dir die Messungen von mksn7 mal genauer an. Er schiebt rein FP32 durch. Pascal verhält sich da deutlich besser als Ampere. Er erreicht volle Rohleistung als er die Aufgaben registerfreundlicher gestaltet hat.

Deshalb schrieb ich ja, dass sich Ampere hier identisch zu Turing verhält, und Registerlimitation bei Turing nur deshalb nicht auffallen, weil der INT-Part kaum voll auszulasten ist.

Dass sowohl bei Turing als auch bei Ampere die Register limitieren können ist klar, nach dem diese gegenüber Ampere nicht vergrößert wurden.

Wie gesagt Ampere hat auf Registerseite die selben Limitierungen wie Turing mit 1x INT/FP+FP ist es nur wahrscheinlicher dass diese auch real limitieren, im Gegensatz zu INT + FP wo man in der Regel nicht den passenden Mix hat um das überhaupt auszulasten.

[basix]

Danke für den Link. Ist wirklich interessant. Bin mir zwar nicht sicher, ob der entsprechende Vorteil dann eben auch nur bei Fully Pathtraced Games ein Vorteil ist. Bei Hybrid-RT Games macht man einige Dinge ja dennoch mittels Rasterizing. Die Primary Rays von Raster nimmt man einfach gratis(?) für RT mit.

Interessant ist auch, dass RT weniger als die Hälfte der Frametime ausmacht. Der Rest ist einfach Cache und FP32 Performance.

[Gast]

Bei der Nintendo Switch Pro gibt es ja Gerücht, dass Nvidias Orin als Custom Variante dafür verwendet werden soll. Und 4K Output liefern soll.


Jaja, die nicht existente Switch Pro.
Die kommt frühestens in 3 Jahren, und dann schaut das auch schon wieder ziemlich alt aus.

[Gast]

Die Primary Rays von Raster nimmt man einfach gratis(?) für RT mit.


Entweder oder.
Entweder rasterst du oder du verschießt Primary Rays beides wäre eine Ressourcenverschwendung.

[Troyan]

Mit der 2.1.64 Version kann sich jeder mal ein Bild von den Schlieren machen: In der Back4Blood Beta schlieren die Bäume wie nichts. Sieht ziemlich fazinierend aus, da es wirklich nur schliert, wenn die Maus nicht bewegt wird...

Ansonsten kann man hier auch DLSS mit CAS kombinieren. Jedoch wirkt dann DLSS zu scharf. Imo macht es ohne Slider keinen Sinn über solchen festen Optionen nachzuschärfen.

[aufkrawall]

Dafür gibt es ja ReShade, geht in Warzone afaik auch trotz Anti-Cheat.

[aufkrawall]

Mal das Bewegtbild (konstante Seitwärtsbewegung, sieht hier, bis aufs ToD, immer ziemlich identisch aus) im Vergleich, nativ vs. 76% RS vs. DLSS 2.2.6 Q:
https://abload.de/thumb/fortniteclient-win64-sujzi.png (https://abload.de/image.php?img=fortniteclient-win64-sujzi.png) https://abload.de/thumb/fortniteclient-win64-4ok9k.png (https://abload.de/image.php?img=fortniteclient-win64-4ok9k.png) https://abload.de/thumb/fortniteclient-win64-t8k7t.png (https://abload.de/image.php?img=fortniteclient-win64-t8k7t.png)

DLSS blurt weniger als das TAA in nativen 1440p, dafür gibts hinten am Pfahl leichtes Smearing und hier und um manche Konturen mehr Verpixelung anstatt Blur-Keule.

*Finger über Kreuz* hab ich eine Lösung dafür gefunden, wenn das Spiel zufällig mit ausgetauschter DLSS-DLL kein Upsampling mehr macht: Die DLL nicht nur in den NGX-Ordner, sondern auch ins Verzeichnis der Spiel-Binary (Fortnite\FortniteGame\Binaries\Win64) kopieren. Höchst seltsam auch, dass es keinen Datei-Lock der DLL gibt, wenn das Spiel läuft. Und Anti-Cheat verbietet Tools, mit denen man nachsehen könnte, von welchem Pfad die Exe die DLL lädt. Konnte aber eindeutig feststellen, dass wenn die DLSS-Option aus dem Menü verschwand, das Kopieren in obiges Verzeichnis sie zurück brachte und das Löschen sie wiederum verschwinden ließ.

Ohne 2.2.6 würd ich das nur noch ungern spielen, es sieht wirklich wesentlich besser als mit anderen Versionen aus.

[Raff]

Zudem sind ja in Zukunft ein par schöne Neuerungen in DLSS enthalten, so dass die der receiver für die motion- vectors nicht mehr 2d sondern 3d basiert arbeiten kann oder man zusätzliche Masken (unter Anderem für Partikel) und Flags erhält, mit welchen man "schwierige" Objekte gesondert behandeln kann. Das wird dann nochmal einigen der verbliebenen Restschmerzen mit der Technik beseitigen.

Woher stammen diese Infos? Sitzt du als Entwickler an der Quelle, oder kann man die Roadmap irgendwo einsehen (gerne auch inoffiziell)? :)

MfG
Raff

[Zerozerp]

Woher stammen diese Infos? Sitzt du als Entwickler an der Quelle,
Genau

oder kann man die Roadmap irgendwo einsehen (gerne auch inoffiziell)? :)

MfG
Raff
Die Dokumente sind als "NVIDIA confidential" gekennzeichnet. Im Netz habe ich dazu "offen" nichts gefunden. Ich seh mal, was (bzw. ob) ich da tun kann...
Wenn Du zufällig Zugriff auf das developer Toolkit hast. Dort ist es unter den programming guidelines unter dem Punkt 9.3 zu finden.

[basix]

Bezüglich Temporal Upsampling hier noch ein spannendes Paper, wo man Einzelbilder zu einem Bewegtbild macht und die Zwischenbilder via AI berechnet. Ziemlich beeindruckend, dass es auch mit Reflexionen und Refraktionen funktioniert. Und das anscheinend Real Time mit 60fps: https://www.youtube.com/watch?v=-4M-xoE6iH0

Wäre der nächste Schritt nach Temporal Upsampling: Gar nicht mehr alle Frames berechnen, sondern temporal interpolieren. Bei Games stelle ich mir das noch schwierig vor, ohne dass man Zeitauflösung und Latenz schadet. Man müsste vermutlich Triple Buffering verwenden, so könnte man zumindest von 60fps auf 120fps raufskalieren. Ich frage mich aber, ob das bezüglich Spielgefühl dann wirklich was bringt. Bei Videos und Filmen wäre es genial: Man spart sich x-fach Bandbreite und hat auch sonst noch ein paar Möglichkeiten mehr, da man weiter in die Zukunft buffern kann.

Edit:
Hier noch was ähnliches, welches ebenfalls Zwischenbilder berechnet: https://www.youtube.com/watch?v=G00A1Fyr5ZQ

[aufkrawall]

Wird auf jeden Fall spannend, was Nvidia, und vielleicht auch Intel, davon zur Marktreife bringen werden.

[Gast]

Bei Videos und Filmen wäre es genial: Man spart sich x-fach Bandbreite und hat auch sonst noch ein paar Möglichkeiten mehr, da man weiter in die Zukunft buffern kann.


Macht man eh schon, die modernen Fernseher machen ja aus einer 25/30/50/60 Quelle gerne mal ein paar 100 FPS

[basix]

Intels XeSS: https://youtu.be/3jU_YhZ1NQA?t=3584

Edit: Direktvergleich 4K native, 4K XeSS, 1080p -> https://youtu.be/3jU_YhZ1NQA?t=3738
Sieht auf den ersten Blick sogar besser/schärfer/detailreicher als 4K native aus. Liegt wohl am TAA bei native. Leichte Bildunruhe ist aber zu erkennen.

Edit 2:
Video der XeSS Demo https://www.youtube.com/watch?v=Hxe4xFKMqzU

Und nochmals Bestätigung von Open Source: https://youtu.be/3jU_YhZ1NQA?t=3817

[Troyan]

Ist deutlich nachgeschärft und es ist auch nur ein 1080p Video. Muss man nur 4K und 1080p vergleichen, um zu erkennen, dass die Schärfe beim 4K Bild nicht stimmt. Selbst in den meisten UE4 Spielen ist der Unterschied zwischen 4K und 1080p TAA riesig.

[aufkrawall]

Ist deutlich nachgeschärft
Was nicht schlecht sein muss, wenn TAA in nativer Auflösung zu blurry ist. Eine Ground Truth mit 64xSSAA hat ja schließlich auch keinen AA-Blur... So weit man das mit dem Matsch-Video und der einen Content-Demo beurteilen kann, scheint es zunächst mal gut auszusehen.

[Troyan]

Ist auch okay. Aber in so einem Vergleich ist es eben trügerisch, weil es wie bei FSR eben auch einfach zu stark sein kann. Bei DLSS sieht man meisten die reine Upscaling-Qualität des Netzwerkes.

[blaidd]

Okay, das kannte ich bislang auch noch nicht. :D

Offenbar kann man mit DLSS auch den Fokus des Depth-of-Fields falsch setzten^^ (vll. ist der Radius beim DoF-Shader auch in Pixeln angegeben und deshalb aufgrund der reduzierten Auflösung zu breit)

DLSS off:
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=76491&stc=1&d=1629382317

DLSS Quality (die anderen Stufen sind auch betroffen):
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=76492&stc=1&d=1629382317

DLSS off:
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=76493&stc=1&d=1629382317

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

[gedi]

https://www.computerbase.de/2021-08/xe-ss-intels-dlss-konkurrent-mit-ki-auch-fuer-amd-und-nvidia/

[aufkrawall]

Hab ich das richtig in Erinnerung, dass sich die TCs nur via CUDA ansprechen lassen? Dann wird es wohl keine XeSS-Optimierung dafür geben, sofern Nvidia das nicht in XeSS einbauen will. Und Intel müsste natürlich den Pull Request auch noch akzeptieren.

Was dann die Frage aufwirft, welche API für das Ansprechen von Intels Matrix Engines genutzt wird.

[Gast]

Ist deutlich nachgeschärft und es ist auch nur ein 1080p Video. Muss man nur 4K und 1080p vergleichen, um zu erkennen, dass die Schärfe beim 4K Bild nicht stimmt. Selbst in den meisten UE4 Spielen ist der Unterschied zwischen 4K und 1080p TAA riesig.

4k native zeigt hier sogar deutlich mehr Schärfeartefakte als das upgescalte Bild.

Das upscaling selbst scheint auf einem vergleichbaren Niveau mit DLSS zu sein.

[iamthebear]

1.) Ich kann mir gut vorstellen, dass die Libraries von Intel je nach GPU unterschiedliche APIs nutzen.

Und Intel würde sicher eine Performanceverbesserung auf Nvidia Karten akzeptieren. Das Hauptziel von XeSS ist ja nicht, dass man besser da steht als die anderen, sondern dass man Nvidias DLSS Vorteil neutralisieren kann.

Ich denke jedoch, dass Nvidia alles tun wird, damit DLSS Konkurrenten sich nicht durchsetzen.

2.) Bei der Demo ist mir das eine Schild mit viel Text aufgefallen. Ich habe das einmal vergrößert:

XeSS 4K:
https://i.imgur.com/Kt3nzn4.png

1080p Native:
https://i.imgur.com/QrCCXa8.png

Also das kann mir niemand erzählen, dass sich das obere Bild aus dem unteren so rekonstruieren lässt. Selbst wenn man mehrere Frames kombiniert: Die Informationen sind weg.

Anhand der ersten Zeile sieht man auch sehr gut, dass die KI hier nicht irgendetwas erfindet, sondern dass hier eindeutig die richtigen Wörter stehen (links: WARNING, rechts: INSTRUCTION)

Das naheliegenste wäre, dass bei XeSS die 4K Texturen zum einsatz kamen, bei 1080p die 1080p Texturen.

TAA Unschärfe ist es denke ich nicht, denn es ist ja auch bei Standbildern unscharf.

[aufkrawall]

Negatives LOD-Bias, auch mit DLSS Q sind Texturen deshalb detaillierter als in nativer Auflösung (sofern genutzt, ist nicht mit jeder Engine kompatibel oder wird manchmal vergessen).

[Troyan]

Hab ich das richtig in Erinnerung, dass sich die TCs nur via CUDA ansprechen lassen? Dann wird es wohl keine XeSS-Optimierung dafür geben, sofern Nvidia das nicht in XeSS einbauen will. Und Intel müsste natürlich den Pull Request auch noch akzeptieren.

Was dann die Frage aufwirft, welche API für das Ansprechen von Intels Matrix Engines genutzt wird.

Jemand müsste XeSS auf Cuda bringen. Solange Microsoft noch nicht mit DirectML soweit ist, können die TensorCores nur über Cuda angesprochen werden.

Aber imo ist es für nVidia-User auch egal. XeSS ist eigentlich DLSS. Für beide Verfahren müssen die selben Voraussetzung geschaffen werden und imo baut man XeSS ein wie DLSS: Als zusätzliche Bibliothek mir Schnittstellen. Dann kann man das fröhlich zwischen GPUs tauschen und fertig.

[why_me]

2.) Bei der Demo ist mir das eine Schild mit viel Text aufgefallen. Ich habe das einmal vergrößert:

XeSS 4K:
https://i.imgur.com/Kt3nzn4.png

1080p Native:
https://i.imgur.com/QrCCXa8.png

Also das kann mir niemand erzählen, dass sich das obere Bild aus dem unteren so rekonstruieren lässt. Selbst wenn man mehrere Frames kombiniert: Die Informationen sind weg.

Das ist schon möglich, das untere Bild wird durch AA zermatscht, XeSS wird vermutlich auf den Rohdaten arbeiten.
Dazu kommt noch, dass es wie DLSS zeitliches Supersampling über eine Kamera Wackeln erzeugt und so jeden Pixel mehrfach abtasten kann.

Wie XeSS arbeitet wurde ja im Video erklärt, Screenshot davon im Anhang.

[AffenJack]

Jemand müsste XeSS auf Cuda bringen. Solange Microsoft noch nicht mit DirectML soweit ist, können die TensorCores nur über Cuda angesprochen werden.


Die Tensor cores können doch bei WinML angesprochen werden. Müsste bei Direct ML dann doch auch so sein oder gibts da Unterschiede?

[Troyan]

Über Metacommands. Aber kein Plan, inwieweit WinML/DirectML schon soweit sind, um in Spielen verwendet zu werden.

[aufkrawall]

Wie schon im anderen Thread erwähnt, ist die CyberPunk-Engine inkompatibel mit negativem LOD-Bias.
CAS via ReShade rettet es zum Glück noch, sieht mit strength 1.3 trotzdem gut aus:
https://abload.de/thumb/cyberpunk2077_2021_08kfj4z.png (https://abload.de/image.php?img=cyberpunk2077_2021_08kfj4z.png) https://abload.de/thumb/cyberpunk2077_2021_08dvklf.png (https://abload.de/image.php?img=cyberpunk2077_2021_08dvklf.png)

Mit Q (2.2.6) besser als nativ, das spieleigene TAA erzeugt selbst im Standbild widerwärtiges Gewaber und Geflimmer um feine Strukturen wie Pflanzen und Kabel. Bessere Grafik bei ~47% mehr Performance. X-D

[gedi]

Jemand müsste XeSS auf Cuda bringen. Solange Microsoft noch nicht mit DirectML soweit ist, können die TensorCores nur über Cuda angesprochen werden.

Aber imo ist es für nVidia-User auch egal. XeSS ist eigentlich DLSS. Für beide Verfahren müssen die selben Voraussetzung geschaffen werden und imo baut man XeSS ein wie DLSS: Als zusätzliche Bibliothek mir Schnittstellen. Dann kann man das fröhlich zwischen GPUs tauschen und fertig.

Nö und nö und nochmals nö! Schaue dir bitte nochmals Intels Lösung hardwareseitig an :rolleyes: Keine Ahnung wie du auf solchen Dummfug kommst.

Zudem heißt doch neuronal: Davon ausgehend dessen... - so habe ich es mal vor gefühlt 1000 Jahren in der Schule gelernt ...

[iamthebear]

Jemand müsste XeSS auf Cuda bringen. Solange Microsoft noch nicht mit DirectML soweit ist, können die TensorCores nur über Cuda angesprochen werden.

Aber imo ist es für nVidia-User auch egal. XeSS ist eigentlich DLSS. Für beide Verfahren müssen die selben Voraussetzung geschaffen werden und imo baut man XeSS ein wie DLSS: Als zusätzliche Bibliothek mir Schnittstellen. Dann kann man das fröhlich zwischen GPUs tauschen und fertig.

Wieso soll Intel hier Nvidia brauchen? CUDA ist doch eine frei zugängliche Schnittstelle. Der Algorithmus bleibt doch der gleiche wie bei Intel/AMD, nur dass dann eben eine andere Schnittstelle verwendet wird.
Das lässt sich doch sicher in einer .dll verpacken und der Code prüft zur Laufzeit, ob eine Intel, AMD oder Nvidia GPU vorhanden ist.

Und nein es ist nicht egal, wie gut XeSS auf Nvidia GPUs läuft, denn die meisten Spielehersteller wollen wahrscheinlich nicht beides integrieren, da sie dann doppelten Aufwand haben.
Falls XeSS auf Nvidia GPUs nicht brauchbar läuft, bedeutet dies auf Grund des Marktanteils, dass weiter DLSS integriert wird und nur für AMD und Intel wird man sich die Arbeit wahrscheinlich nicht antun ein 2. Verfahren zu implementieren.

Falls XeSS hingegen auf Nvidia GPUs vergleichbar mit DLSS funktioniert, so wird in vielen Fällen auf DLSS verzichtet werden.

Wobei meiner Meinung nach auch Nvidia Nutzer von einem offenen Standard profitieren würden, denn aktell besteht die Gefahr, dass Nvidia in neuen DLSS Versionen irgendwann den Support für alte Karten streichen wird, wenn sie was neues verkaufen wollen.

Das ist schon möglich, das untere Bild wird durch AA zermatscht, XeSS wird vermutlich auf den Rohdaten arbeiten.
Dazu kommt noch, dass es wie DLSS zeitliches Supersampling über eine Kamera Wackeln erzeugt und so jeden Pixel mehrfach abtasten kann.

Wie XeSS arbeitet wurde ja im Video erklärt, Screenshot davon im Anhang.

Im Fall eines Standbildes, bei der in keinem der Frames auch nur irgendwelche Konturen erkennbar sind kann auch ein temporales Verfahren etwas ausrichten.

Wenn 1080p derart vermatscht wird (wonach es aktuell aussieht), so ist das jedoch keine besondere Leistung des Upscaling Verfahrens, sondern es wird lediglich der AA Teil weniger schlecht erledigt. Ob das ausreicht um gegen DLSS zu bestehen?

Auf jeden Fall bietet sich UE5 als guter Vergleich an, sobald die Technologie frei verfügbar ist, denn diese unterstützt sowohl DLSS als auch das eigene TSR, das auch sehr gut abschneidet.

[TheAntitheist]

Die Tensor cores können doch bei WinML angesprochen werden. Müsste bei Direct ML dann doch auch so sein oder gibts da Unterschiede?
sie können auf jeden Fall ohne CUDA angesprochen werden, Spiele nutzen doch kein CUDA!?

[DrFreaK666]

...und nur für AMD und Intel wird man sich die Arbeit wahrscheinlich nicht antun ein 2. Verfahren zu implementieren...

Du vergisst die Konsolen. Sollte Xe SS auf der Xbox und PS5 laufen, dann lohnt es sich sehr wohl das einzufügen.
Gerade die Konsolen können von einem ML-Verfahren profitieren

[basix]

Auf der XBox mit hoher Wahrscheinlichkeit. Bei der PS5 bin ich mir weniger sicher.

[Ex3cut3r]

Wie schon im anderen Thread erwähnt, ist die CyberPunk-Engine inkompatibel mit negativem LOD-Bias.
CAS via ReShade rettet es zum Glück noch, sieht mit strength 1.3 trotzdem gut aus:
https://abload.de/thumb/cyberpunk2077_2021_08kfj4z.png (https://abload.de/image.php?img=cyberpunk2077_2021_08kfj4z.png) https://abload.de/thumb/cyberpunk2077_2021_08dvklf.png (https://abload.de/image.php?img=cyberpunk2077_2021_08dvklf.png)

Mit Q (2.2.6) besser als nativ, das spieleigene TAA erzeugt selbst im Standbild widerwärtiges Gewaber und Geflimmer um feine Strukturen wie Pflanzen und Kabel. Bessere Grafik bei ~47% mehr Performance. X-D

Ha! Ist ja lustig. Ich spiel das genauso. DLSS 2.2.6 dll und dazu CAS via Reshade. :smile:

[Gast]

Wobei meiner Meinung nach auch Nvidia Nutzer von einem offenen Standard profitieren würden, denn aktell besteht die Gefahr, dass Nvidia in neuen DLSS Versionen irgendwann den Support für alte Karten streichen wird, wenn sie was neues verkaufen wollen.


Nvidia-Nutzer werden vor allem dadurch profitieren dass NV ein USP wegfällt und damit ein Grund warum sie höhere Preise als die Konkurrenz verlangen können.

Sollte XeSS qualitativ und Performancemäßig mit DLSS vergleichbar sein, spricht eigentlich nichts dagegen, dass es sich langfristig gegenüber DLSS durchsetzt und zwar selbst wenn Intel-Grafikkarten ein Rohrkrepierer werden sollten.

[iamthebear]

Du vergisst die Konsolen. Sollte Xe SS auf der Xbox und PS5 laufen, dann lohnt es sich sehr wohl das einzufügen.
Gerade die Konsolen können von einem ML-Verfahren profitieren

Die PS5 kan keine INT8 Befehle verarbeiten. Da wird fürchte ich der Overhead etwas zu groß werden.

Auf der XBox könnte es eventuell funktionieren allerdings hat das denke ich wenig damit zu tun, ob es bei PC Spielen eingebaut wird oder nicht. Dafür sind die Plattformen zu verschieden.
Abgesehen davon: Für aktuelle Spiele sind die Next Gen Konsolen sowieso schnell genug und ich denke, dass Next Gen Spiele auch selbst brauchbare temporale Upscalingverfahren ähnlich wie TSR haben haben. Ich weiß nicht ob ein neuronales Verfahren ohne Tensor Cores den zusätzlichen Overhead wirklich wert ist.

Ich befürchte ja, dass der Overhead ziemlich gravierend sein könnte. Weil warum sonst sollte Intel hier solche Unmengen an Tensor Cores mit 260 TOps/s verbauen wenn das Ganze mit den 50 TOps von AMD auch wunderbar läuft?

Wobei ich hier noch ein weiteres Problem sehe:
Bei Nvidia/Intel arbeiten die Tensor Cores ja parallel zu den normapen FP32 Einheiten.
Wenn das bei AMD über die regulären FP32 Einheiten läuft, so stehen die ja für die normapen Aufgaben nicht mehr zur Verfügung. Selbst ein Overhead von 10 TOps/s würde dann einen Performanceverlust von 20% bedeuten.

sie können auf jeden Fall ohne CUDA angesprochen werden, Spiele nutzen doch kein CUDA!?

Gegenfrage: Welche Spiele nutzen denn Tensor Cores? Mir ist hier als Anwendung nur DLSS bekannt und das läuft über eine Nvidia dll. Es ist fraglich, ob Nvidia hier überhaupt eine dokumentierte Schnittstelle verwendet. Eventuell passiert hier auch einige Logik im Treiber.

Ha! Ist ja lustig. Ich spiel das genauso. DLSS 2.2.6 dll und dazu CAS via Reshade. :smile:

Cyberpunk kann doch CAS bereits nativ. Kann man das nicht parallel mit DLSS verwenden?

Nvidia-Nutzer werden vor allem dadurch profitieren dass NV ein USP wegfällt und damit ein Grund warum sie höhere Preise als die Konkurrenz verlangen können.

Das ist höchstens ein Argument für potentielle Grafikkartenkäufer. Außerdem bin ich mir nicht sicher, ob dies bei Nvidia zu einer Preiskorrektur nach unten führen würde. Ich rechne da eher mit einer AMD Preiskorrektur nach oben.

Sollte XeSS qualitativ und Performancemäßig mit DLSS vergleichbar sein, spricht eigentlich nichts dagegen, dass es sich langfristig gegenüber DLSS durchsetzt und zwar selbst wenn Intel-Grafikkarten ein Rohrkrepierer werden sollten.

Wenn sich Intel am Markt nicht halten können sollte (und dafür sehe ich bestenfalls eine 50/50 Chance), dann ist XeSS auch tot, denn irgendwer muss den Code ja auch pflegen. Da wird eher AMD mit einer eigenen Lösung auf den Markt kommen bzw. über MS in DirectX integrieren lassen bevor sie die Überbleibsel eines gescheiterten Mittbewerbers übernehmen.
Es sei denn Intel scheitert zwar im Desktopmarkt, kann sich jedoch mit Entrylösungen im Mobilmarkt halten.

[robbitop]

Ein paar Punkte:
1. DLSS läuft in der Praxis nicht parallel zum eigentlichen Rendering - man kann sich die komplette Frametime eines Frames anschauen und sieht eindeutig, dass die TC zum Ende des Frames ein paar ms arbeiten und alles andere (FPUs, INTs, RT Cores) stillsteht. Laut Dokumentation passt das auch ganz gut denn DLSS passiert nach dem der Framebuffer fertig ist aber noch vor dem Post Processing. Insofern bringt die Möglichkeit der Parallelität im Moment nichts.
2. Wenn man sich die Ergebnisse von dem besten DLSS Implementierungen vs den besten Implementierungen von heuristischen Verfahren mit temporalem Upsampling anschaut ist der Unterschied schon recht gravierend. Es scheint sich grundsätzlich zu lohnen. Andernfalls hätten wohl NV und Intel nicht so die Resourcen in das NN investiert. Das ist erheblich aufwändiger und erfordert know how was in vielen Unternehmen nicht vorliegt. Ein erheblicher Unterschied in Forschung.
3. Ob sich das auch mit (Vektor) FPUs lohnt? DLSS 1.9 lief noch auf den FPUs und war bereits umgestiegen auf temporales SS mit NN. Das war etwas weniger schnell als DLSS 2.x was über die TCs läuft aber es brachte noch einen guten Speedup.
Nicht alles ist schwarz/weiß. Wenn es nichts bringen würde, würde Intel es wohl auch nicht anbieten.
4. Natürlich kann die PS5 das INT8 Datenformat verarbekten. Aber eben nicht mit einem 4x speedup sondern nur mit einem 2x speedup.

[aufkrawall]

Sobald es noch eine weitere deutliche Reduzierung von Artefakten wie mit DLSS 2.2.6 gibt (was sicher nur eine Frage der Zeit ist, wobei Zeit leider ein dehnbarer Begriff ist...), sollte klassisches TAAU überall durch eine DL-gestützte Lösung ersetzt werden, sofern der Performance-Hit auf Nicht-Intel-Hardware nicht absurd ist. Mit etwas Glück kann XeSS diese Entwicklung einleiten, sofern es sich nicht doch noch als komplett unterlegen vs. DLSS entpuppt. Aber dass es gar weniger Artefakte als DLSS 2.2.6 produziert, würd ich auch nicht ausschließen.

Wird aber auch davon abhängen, wie Intel die XeSS-Weiterentwicklung managt. Wenn PRs möglich sind und sie diese ernstnehmen, könnte es der herstellerübergreifende Defakto-Standard werden, den AMD für FSR in Aussicht gestellt (und massiv enttäuscht) hatte.

[iamthebear]

Ein paar Punkte:
1. DLSS läuft in der Praxis nicht parallel zum eigentlichen Rendering - man kann sich die komplette Frametime eines Frames anschauen und sieht eindeutig, dass die TC zum Ende des Frames ein paar ms arbeiten und alles andere (FPUs, INTs, RT Cores) stillsteht. Laut Dokumentation passt das auch ganz gut denn DLSS passiert nach dem der Framebuffer fertig ist aber noch vor dem Post Processing. Insofern bringt die Möglichkeit der Parallelität im Moment nichts.

Ich dachte das Problem hat sich seit Ampere mit Async DLSS erledigt. Ja klar die meisten bestehenden Spiele unterstützen es noch nicht aber gerade wenn wir von Konsolen und extra auf diese Generation zugeschnittenen Engines reden, so ist das denke ich kein Hindernis.
Intel hat sich noch nicht dazu geäußert aber ich gehe dabon aus, dass die das genauso unterstützen werden.

2. Wenn man sich die Ergebnisse von dem besten DLSS Implementierungen vs den besten Implementierungen von heuristischen Verfahren mit temporalem Upsampling anschaut ist der Unterschied schon recht gravierend. Es scheint sich grundsätzlich zu lohnen. Andernfalls hätten wohl NV und Intel nicht so die Resourcen in das NN investiert. Das ist erheblich aufwändiger und erfordert know how was in vielen Unternehmen nicht vorliegt. Ein erheblicher Unterschied in Forschung.

Also mich haben die UE5 Tests mit TSR sehr überzeugt. Klar es ist immer noch etwas schlechter als DLSS aber meilenweit besser als FSR und der Performance Overhead scheint deutlich niedriger zu sein.
Wenn man sich hier noch den zusätzlichen Performance Overhead auf Grund der fehlenden Tensor Cores dazu denkt und dass XeSS wahrscheinlich auch nicht ganz an DLSS herankommen wird, dann stellt sich schon die Frage, ob es noch viel Sinn macht.

3. Ob sixh das auch mit FPUs lohnt? DLSS 1.9 lief noch auf den FPUs und war bereits umgestiegen auf temporales SS mit NN. Das war etwas weniger schnell als DLSS 2.x was über die TCs läuft aber es brachte noch einen guten Speedup.
Nicht alles ist schwarz/weiß. Wenn es nichts bringen würde, würde Intel es wohl auch nicht anbieten.

Das Problem an DLSS 1.9 war die deutlich niedrigere Bildqualität (obwohl es für ein DLSS 1.x Spiel relativ gut war). Ich kann mir das nur erklären, dass dies dadurch zu Stande kommt, dass die Rechenzeit massiv begrenzt wurde, damit die Frameraten nicht wegbrechen.
Die Performance von DLSS 1.9 war soviel ich mich erinnern kann vergleichbar mit DLSS 2.0 wenn nicht sogar etwas besser.

Um ehrlich zu sein: Ich erwarte mir von XeSS auf Konsolen nicht viel mehr Bildqualität als DLSS 1.9 und da gibt es eben schon deutlich bessere Verfahren.

4. Natürlich kann die PS5 das INT8 Datenformat verarbekten. Aber eben nicht mit einem 4x speedup sondern nur mit einem 2x speedup.

Das ist schon klar, dass man mit FP16 Einheiten auch INT8 berechnen kann. Es läuft dann halt noch um den Faktor 2 langsamer, was das ganze dann komplett sinnlos machen sollte.

[robbitop]

Schon Turing konnte die TCs parallel zu den Vektor ALUs ausführen. FP - INT - TC. 2/3 gingen parallel. Bei Ampere sind es dann 3/3.
Was sollten die FPUs rechnen, wenn bei dem Frame der Framebuffer fettig gerendert ist aber man noch auf dlss warten muss bevor es mit dem PP losgehen kann?

TSR hat aber auch (hier gibt es von einem User einen sehr guten Detailvergleich) deutliche Schwächen je nach Situation. Selbst das mit Abstand beste Verfahren (ids 8xtsaa) ist laut id ein gutes Stück dahinter.

Ob es sich lohnt oder nicht wird sich zeigen. Nicht alles ist schwarz/weiß. Es lohnt sich ggf weniger. Solange es signifikant frametime spart, lohnt es sich.

Die Frage ist ob Intels Balken bzgl frametime arbiträr waren oder das wahre Verhältnis zeigen. Sofern es letzteres ist, lohnt sich das immer noch deutlich.

[TheAntitheist]

Ein paar Punkte:
1. DLSS läuft in der Praxis nicht parallel zum eigentlichen Rendering -
meistens ja, es gibt aber Spiele die nutzen es async/parallel siehe wolfenstein youngblood, da gabs extra ein update dafür.

[Gast]

1. DLSS läuft in der Praxis nicht parallel zum eigentlichen Rendering - man kann sich die komplette Frametime eines Frames anschauen und sieht eindeutig, dass die TC zum Ende des Frames ein paar ms arbeiten und alles andere (FPUs, INTs, RT Cores) stillsteht.


Innerhalb eines Frames klar, man muss erst ein Frame fertigberechnen bevor DLSS arbeiten kann, das kann ja nicht schon bei einem halbfertigen Frame angewendet werden.
Während DLSS am Frame N arbeitet kann aber schon der Frame N+1 berechnet werden und das funktioniert auch parallel.
Es braucht allerdings ein Update für die Spiele damit das auch funktioniert, bei Wolfenstein gab es da eines welches das auch in den Update-Infos erwähnt hat. Ich vermute mal mit neueren DLSS-Spielen sollte das schon standardmäßig integriert sein.


3. Ob sich das auch mit (Vektor) FPUs lohnt? DLSS 1.9 lief noch auf den FPUs und war bereits umgestiegen auf temporales SS mit NN. Das war etwas weniger schnell als DLSS 2.x was über die TCs läuft aber es brachte noch einen guten Speedup.


Das ist immer noch Spekulation. Meines Wissens gibt es keinen definitiven Beweis dafür. Das einzige DLSS 1.9 Spiel war ja Control, und dabei habe ich in NSight definitiv Tensor-Usage gesehen, wobei das natürlich auch kein Beweis ist dass es für DLSS verwendet wird, weil du siehst auch bei normalen Shadern die FP16 verwenden Tensor-Usage.

[Gast]

Wenn sich Intel am Markt nicht halten können sollte (und dafür sehe ich bestenfalls eine 50/50 Chance), dann ist XeSS auch tot, denn irgendwer muss den Code ja auch pflegen. Da wird eher AMD mit einer eigenen Lösung auf den Markt kommen bzw. über MS in DirectX integrieren lassen bevor sie die Überbleibsel eines gescheiterten Mittbewerbers übernehmen.


Intel wird XeSS frei verfügbar machen, dann kann das jeder Maintainen, würde mich nicht wundern wenn das sogar AMD übernehmen würde, falls Intel am Grafikkartenmarkt scheitert.

[aufkrawall]

meistens ja, es gibt aber Spiele die nutzen es async/parallel siehe wolfenstein youngblood, da gabs extra ein update dafür.
Ist das irgendwo erwähnt? Die DLSS-Skalierung in Doom Eternal ist jedenfalls sehr mau.

Nochmal zum LOD-Bias: DLSS unterdrückt das Texturauschen mit extremen Werten wie -3 immer noch beeindruckend gut. Insbesondere dafür, dass es so wenig matscht. Das dürfte ohne DL komplett unmöglich sein.
Interessanterweise gehen auch in Fortnite mit zusätzlich erzwungenem negativen LOD-Bias für alle Texturen die Reflexionseigenschaften für Specular kaputt bzw. negative Werte verstärken einfach die "Glossiness". Das gibt es in diversen Spielen so zu sehen. Aber: Fortnite nutzt ja mit DLSS von sich aus negatives LOD-Bias, nur halt offenbar nicht für Specular (bzw. nur "Detailtexturen"?). Offenbar muss der Entwickler etwas Sorgfalt walten lassen, wie er negatives LOD-Bias anwendet. Bei der UE4 geht das vermutlich ziemlich einfach.

Von daher würde ich annehmen, dass es auch in Spielen ginge, wo es derzeit nicht der Fall ist oder es Probleme gibt, wenn der Entwickler sich wirklich Mühe geben würde.

[Gast]

Ist das irgendwo erwähnt? Die DLSS-Skalierung in Doom Eternal ist jedenfalls sehr mau.


Weil die Frameraten allgemein sehr hoch sind und damit die fixen DLSS-Kosten mehr ins Gewicht fallen.


Nochmal zum LOD-Bias: DLSS unterdrückt das Texturauschen mit extremen Werten wie -3 immer noch beeindruckend gut.


DLSS macht laut Nvidia für Texturen gar nichts, und das korrekte LOD ist jenes der Zielauflösung. Wobei es ja im Endeffekt sowas wie 16x SSAA ist, man dürfte also wohl meistens mit noch etwas mehr durchkommen.

[Gratzner]

Während DLSS am Frame N arbeitet kann aber schon der Frame N+1 berechnet werden und das funktioniert auch parallel.


Das glaube ich eher weniger. Man müsste ja dann im gesamten Speichersystem des Grafikchips Informationen von zwei Frames speichern (mit Speichersystem ist jetzt nicht der VRAM gemeint, sondern Register, Caches, etc). Das glaube ich nicht, dass das gut parallel funktioniert, falls man es überhaupt macht. Erzeugt ja auch ein Frame Input-lag, nur um während den 1 bis 2 ms von DLSS bissle was parallel zu berechnen

meistens ja, es gibt aber Spiele die nutzen es async/parallel siehe wolfenstein youngblood, da gabs extra ein update dafür.
Die Aussage von robbitop war ja nicht, das es nichts geht, sondern es gibt schlicht (fast) nix weiteres zu berechnen, während DLSS arbeitet. Wie er erklärt hat: DLSS kommt auf das fertig berechnetet Bild vor den Post-Processing-Effekten (PP) dran. Also muss das Bild schon bis auf PP fertig berechnet sein. PP und DLSS geht auch nicht parallel, da ja PP auf das fertige skalierte Bild von DLSS kommt

[Gast]

Das glaube ich eher weniger. Man müsste ja dann im gesamten Speichersystem des Grafikchips Informationen von zwei Frames speichern (mit Speichersystem ist jetzt nicht der VRAM gemeint, sondern Register, Caches, etc). Das glaube ich nicht, dass das gut parallel funktioniert, falls man es überhaupt macht. Erzeugt ja auch ein Frame Input-lag, nur um während den 1 bis 2 ms von DLSS bissle was parallel zu berechnen

1 Frame wird von praktisch jeder Engine im Voraus berechnet, und es gibt Engines die sogar mehrere Bilder im Voraus berechnen.

Ja es erzeugt zusätzliche Latenz, aber bei nur 1 Frame ist der Tradeoff zwischen Performanceverlust und Latenz einfach am besten.

Wenn man gar nichts Vorrendert verliert man viel zu viel Performance, jetzt ganz unabhängig von DLSS und mehr als 1 Frame erzeugt viel zu viel Latenz.

Das ist übrigens der Punkt an dem auch Nvidia Reflex ansetzt indem es den Zeitpunkt an dem begonnen wird den nächsten Frame zu rendern optimiert und damit obwohl vorgerendert wird fast keine zusätzliche Latenz erzeugt wird, bei fast keinem Performanceverlust.

[Wuge]

...da wir heutzutage eh komplett Powerlimitiert sind, ist es auch nur halb so schlimm wenn die FPUs mal für 1-2% der Zeit rumstehen - gewinnt man direkt ein paar Mhz Takt fürs nächste Frame ;D

[Gast]

Ein paar Punkte:
1. DLSS läuft in der Praxis nicht parallel zum eigentlichen Rendering - man kann sich die komplette Frametime eines Frames anschauen und sieht eindeutig, dass die TC zum Ende des Frames ein paar ms arbeiten und alles andere (FPUs, INTs, RT Cores) stillsteht. Laut Dokumentation passt das auch ganz gut denn DLSS passiert nach dem der Framebuffer fertig ist aber noch vor dem Post Processing. Insofern bringt die Möglichkeit der Parallelität im Moment nichts.
Es gibt schon noch einen Überlapp. Theoretisch könnte man da auch schon mit der UI anfangen. Da geht in der Regel nicht weniger Zeit drauf als fürs DLSS.

[Gast]

...da wir heutzutage eh komplett Powerlimitiert sind, ist es auch nur halb so schlimm wenn die FPUs mal für 1-2% der Zeit rumstehen - gewinnt man direkt ein paar Mhz Takt fürs nächste Frame ;D

Man gewinnt aber immer weniger als man vorher verliert.

[robbitop]

meistens ja, es gibt aber Spiele die nutzen es async/parallel siehe wolfenstein youngblood, da gabs extra ein update dafür.
Haben hier schon mehrere geschrieben. Ich bin da noch skeptisch, ob das in der Praxis wirklich der Fall ist. Gibt es dafür einen Beleg? Denn das würde den Overhead potenziell auf praktisch 0 senken. Entsprechend wäre im GPU Limit die Performance nahezu gleich wie als wenn ohne DLSS mit der gleichen input resolution gerendert werden würde. Also DLSS Q 4K wäre so schnell wie 1440K ohne DLSS.

Also einen screenshot aus den nvperf tools die zeigen, dass gleichzeitig die TCs zum Rest ausgelastet sind? Ich kann es mangels Karte mit TCs nicht nachprüfen. Die nvperf tools bekommt man mWn im Netz.

[Dampf]

Interessantes interview über XeSS: https://wccftech.com/intel-xess-interview-karthik-vaidyanathan/

Nutzt kein DirectML, keine Tensor-Core Beschleunigung, noch kein FP16 fallback

[TheAntitheist]

Haben hier schon mehrere geschrieben. Ich bin da noch skeptisch, ob das in der Praxis wirklich der Fall ist. Gibt es dafür einen Beleg? Denn das würde den Overhead potenziell auf praktisch 0 senken. Entsprechend wäre im GPU Limit die Performance nahezu gleich wie als wenn ohne DLSS mit der gleichen input resolution gerendert werden würde. Also DLSS Q 4K wäre so schnell wie 1440K ohne DLSS.

Also einen screenshot aus den nvperf tools die zeigen, dass gleichzeitig die TCs zum Rest ausgelastet sind? Ich kann es mangels Karte mit TCs nicht nachprüfen. Die nvperf tools bekommt man mWn im Netz.
Ich hab das Spiel und das tool nicht, es gab auf jeden Fall ein 10% fps boost dadurch. da die TCs ja auch etwas power ziehen wird es nicht ganz kostenlos werden. Auf dem Diagram konnte man auf jedenfall sehen das die TCs nach ca. 80% des frames fertig waren und danach nur noch fp32/shader liefen. Ich hab das Paper noch vor ein paar tagen gesehen, war direkt auf der nvidia Seite aber finde es gerade nicht. So lange das Postprocessing länger dauert als ca. 2ms, sollte das schon möglich sein.

[Troyan]

Computerbase hatte einen 9% Gewinn ermittelt: https://www.computerbase.de/2020-09/geforce-rtx-3080-test/6/#abschnitt_asynchrones_dlss

Man wird nicht komplett die Kosten von DLSS ausgleichen können. Aber wenn man den Leistungsverlust halbiert, wäre das schon ein guter Gewinn.

[Gast]

Ich bin da noch skeptisch, ob das in der Praxis wirklich der Fall ist. Gibt es dafür einen Beleg? Denn das würde den Overhead potenziell auf praktisch 0 senken.

Nur wenn:
- Die Tensor-Cores tatsächlich nur für DLSS verwendet werden, die werden ja auch in Shader für FP16 eingesetzt
- Auch gerade andere Arbeit für die FP32-Cores vorhanden ist.
- Register-Pressure kein Limit ist, die Tensor-Cores brauchen ja auch Daten, und gar nicht wenig, und diese müssen von den Registern bereitgestellt werden.

Also 0 Overhead wäre möglich ist aber sehr unwahrscheinlich.

[Gast]

Computerbase hatte einen 9% Gewinn ermittelt: https://www.computerbase.de/2020-09/geforce-rtx-3080-test/6/#abschnitt_asynchrones_dlss

9% FPS-Gewinn, nachdem DLSS nur einen Bruchteil eines Frames ausmacht dürfte der DLSS-Gewinn locker bei einem Faktor 2 wenn nicht mehr sein.

[iamthebear]

Auch wenn eine GPU poerlimitiert ist macht es keinen Sinn unnötig zu warten.
Man kann einer 3080 20% TDP wegnehmen und gewinnt nur ca. 4% Performance.

Also umgekehrt wenn man die GPU 20% der Zeit während DLSS warten lässt kann man 4% durch höhere Takraten zurückholen. Die restlichen 16% sind verloren

Haben hier schon mehrere geschrieben. Ich bin da noch skeptisch, ob das in der Praxis wirklich der Fall ist. Gibt es dafür einen Beleg? Denn das würde den Overhead potenziell auf praktisch 0 senken. Entsprechend wäre im GPU Limit die Performance nahezu gleich wie als wenn ohne DLSS mit der gleichen input resolution gerendert werden würde. Also DLSS Q 4K wäre so schnell wie 1440K ohne DLSS.

Also einen screenshot aus den nvperf tools die zeigen, dass gleichzeitig die TCs zum Rest ausgelastet sind? Ich kann es mangels Karte mit TCs nicht nachprüfen. Die nvperf tools bekommt man mWn im Netz.

Wir wissen nicht wie hoch der Anteil der Tensor Core Nutzung bei Nvida wirklich ist. Eventuell bestehen die Wartezeiten nur zu 30% aus Tensor Cores (da ja so schnell) und 70% Shader.

Dass es die meisten Spiele nicht tun kann schon sein. Aber das liegt eventuell einfach nur daran, dass die Engines der Spiele die wir aktuell spielen bei DLSS 2.0 Einführung alle schon fertig waren und keiner mehr nachträglich gravierende Änderungen machen wollte. Speziell RT+DLSS+Shader funktioniert ja erst seit Ampere.

[Geldmann3]

Finde es immer wieder faszinierend zu sehen, was DLSS-Ultra-Performance leisten kann.
Selbst, wenn ich es auf einem Desktop-Rechner nicht verwenden würde, da der Qualitätsverlust gegenüber der nativen Auflösung zu groß ist.

Für die nächste Switch wäre es jedoch ein Quantensprung.

Links: 720p Nativ -> Rechts: 2160p DLSS Ultra Performance

Ohne Kamerabewegung:
https://i.ibb.co/6vCTJWb/image-2021-08-27-22-49-55.png

https://i.ibb.co/RCqbYSM/image-2021-08-27-22-50-34.png

Mit Kamerabewegung:
https://i.ibb.co/CBsRjvV/image-2021-08-27-22-51-27.png

https://i.ibb.co/2YTN5m4/image-2021-08-27-22-51-45.png

https://i.ibb.co/n02HPQB/image-2021-08-27-22-53-41.png
Quelle: Digital Foundry (https://youtu.be/_ja-31bYFTs)

[Tobalt]

was sollen linke und rechte Spalte nsein?

[basix]

Er hat oberhalb der Bilder 720p -> 2160p geschrieben ;)

Links: 720p nativ
Recht: 2160p DLSS Ultra Performance (720p Renderauflösung)

[Wuge]

Maaannn ich will das für VR in DCS :motz:

[MasterElwood]

Maaannn ich will das für VR in DCS :motz:

Ich für FS2020 in VR

[hmmm]

Finde es immer wieder faszinierend zu sehen, was DLSS-Ultra-Performance leisten kann.
Selbst, wenn ich es auf einem Desktop-Rechner nicht verwenden würde, da der Qualitätsverlust gegenüber der nativen Auflösung zu groß ist.

Für die nächste Switch wäre es jedoch ein Quantensprung.

Links: 720p Nativ -> Rechts: 2160p DLSS Ultra Performance

Ohne Kamerabewegung:
https://i.ibb.co/6vCTJWb/image-2021-08-27-22-49-55.png

https://i.ibb.co/RCqbYSM/image-2021-08-27-22-50-34.png

Mit Kamerabewegung:
https://i.ibb.co/CBsRjvV/image-2021-08-27-22-51-27.png

https://i.ibb.co/2YTN5m4/image-2021-08-27-22-51-45.png

https://i.ibb.co/n02HPQB/image-2021-08-27-22-53-41.png
Quelle: Digital Foundry (https://youtu.be/_ja-31bYFTs)
Hört doch auf mit diesen zoom vergleichen, offensichtlich verstehen die immer noch nicht was für ein stuss das ist.
Wie kann das Objekt bei HD +4*Zoom genau so groß sein wie bei 4k +4*Zoom?

Und ja, das DLSS Bild ist _trotzdem_ besser.

[Dampf]

Hört doch auf mit diesen zoom vergleichen, offensichtlich verstehen die immer noch nicht was für ein stuss das ist.
Wie kann das Objekt bei HD +4*Zoom genau so groß sein wie bei 4k +4*Zoom?

Und ja, das DLSS Bild ist _trotzdem_ besser.

Das ist kein Stuss, nur so ist es überhaupt möglich, Unterschiede bei 4K zu sehen, wenn man das Video auf einem 1080p Monitor oder gar auf einem Smartphone ansieht.

Nicht jeder hat ein 4K Monitor und sieht dann bei der hohen Pixeldichte sofort Unterschiede. Deswegen sieht FidelityFX Cas bei 4K oder auch ähnlich aus wie DLSS in einigen Vergleichen, erst bei Zoom sieht man die Rekonstruktionsleistung wirklich.

[hmmm]

Das ist kein Stuss, nur so ist es überhaupt möglich, Unterschiede bei 4K zu sehen, wenn man das Video auf einem 1080p Monitor oder gar auf einem Smartphone ansieht.

Nicht jeder hat ein 4K Monitor und sieht dann bei der hohen Pixeldichte sofort Unterschiede. Deswegen sieht FidelityFX Cas bei 4K oder auch ähnlich aus wie DLSS in einigen Vergleichen, erst bei Zoom sieht man die Rekonstruktionsleistung wirklich.
Du verstehst es offensichtlich auch nicht, entweder ist der "720p" Ausschnitt 8*Zoom oder der "4k" Ausschnitt "nativ" (in dem fall DLSS).

[GerryB]

Du verstehst es offensichtlich auch nicht, entweder ist der "720p" Ausschnitt 8*Zoom oder der "4k" Ausschnitt "nativ" (in dem fall DLSS).
1+

Sehe ich auch so!
Man kann sich ja in nem 4k-Bild einen 720p-Ausschnitt rausschneiden, damits ohne ppi-Interpolation nativ bleibt.
--> Ansicht dann in nem 720p-Fenster
--> denselben Ausschnitt mit linearScaling x8 von dem 720p Bild z.Vgl.

In den meisten Threads gibts vollkommen sinnlose Diskussionen, weil die Leute net verstehen, das der Moni auch noch mal auf seine Pixel umrechnen muss.
Gerade die Leute mit WQHD haben gar keine Ahnung wie 4k tatsächlich ausschaut.
Unter Umständen wäre ein 4k-Bild auf 1080p sogar sinnvoller anzuschauen, weil die Monipixel besser passen, ... sieht dann u.U. nur
übermäßig scharf aus, weil 4 Pixel denselben Inhalt haben. --> Daher bin ich immer vorsichtig, wenn ein Reviewer ein FHD-Bildchen
als Beweis für übermäßiges Sharpen in seinem Review anführt. Im Zweifelsfall hilft nur selber testen@real 4k-Moni.
(bei PCGH gibts oft auch die richtigen 4k-Pics als download, ...sollte man sich dann anschauen)

In dem Sinne, sprich Kontrolle der Schärfe, wäre es auch besser gewesen, wenn Intel das Demovideo in 4k gedreht hätte und den 1080p-Part linear gescaled, ... So bleiben halt noch Fragen, bis man selber testen kann, wie es Monitorpixelgetreu ausschaut

[robbitop]

Bei gleichem FOV und gleichem Monitor ist das gleiche Objekt auflösungsunabhängig gleich groß. Aber unterschiedlich aufgelöst.

[hmmm]

1+

Sehe ich auch so!
Man kann ja in nem 4k-Bild sich einen 720p-Ausschnitt rausschneiden, damits ohne ppi-Interpolation nativ bleibt.

In den meisten Threads gibts vollkommen sinnlose Diskussionen, weil die Leute net verstehen, das der Moni auch noch mal auf seine Pixel umrechnen muss.
Gerade die Leute mit WQHD haben gar keine Ahnung wie 4k tatsächlich ausschaut.
Man kann einfach kein 1:1 Pixel Vergleich machen, wenn die Auflösung unterschiedlich ist.

ZB: Warum verkleinert ihr das DLSS (4k) Bild nicht auf 720p, dann könnt ihr Pixel vergleich machen. - Versteht ihr es jetzt?

[hmmm]

Bei gleichem FOV und gleichem Monitor ist das gleiche Objekt auflösungsunabhängig gleich groß. Aber unterschiedlich aufgelöst.
Wenn das ein 4k Monitor ist und das 720p Bild das ganze Display ausfüllt, dann wird das schon skaliert.

[robbitop]

Ja das schon. Aber die Größe (in mm) bleibt gleich. Aber es hat den Nachteil, dass es skaliert wird. Das stimmt.
Je höher die Auflösung des Monitors desto kleiner der Impact allerdings.

[aufkrawall]

Niemand spielt das Spiel in 720p ohne TAAU oder DLSS, solche unsinnigen Vergleiche sollte man sich einfach sparen...

[robbitop]

Es ging auch gar nicht konkret darum dass das jemand macht sondern um zu untersuchen ob das eine sinnvolle Option für die Switch 2 wäre.

Mit einem mobile SoC ist Rechenleistung potenziell limitiert. Wenn man im Docked mode dann 4K TVs füttern will, wäre halbwegs passable bq schon sinnvoll.

DF war überrascht was DLSS aus 720p herausholt mit dem UP mode.

[Gast]

Die einzig sinnvollen Vergleiche sind bei gleich großer physischen Auflösung, unabhängig von der Renderauflösung.


Wenn beides auf dem selben Display betrachtete wird bedeutet das zwangsläufig, dass für eine Seite die Pixelauflösung so angepasst werden muss, damit das Bild auf dem Vergleichsbildschirm gleich groß ist.

[GerryB]

Es ging auch gar nicht konkret darum dass das jemand macht sondern um zu untersuchen ob das eine sinnvolle Option für die Switch 2 wäre.

Mit einem mobile SoC ist Rechenleistung potenziell limitiert.

trifft gleichermaßen auf Valves steam deck zu, ... da könnte FSR oder Intels DP4a nach m.E. die Nutzbarkeit deutlich verbessern
(k.A. ob DP4a@Linux works)

[robbitop]

trifft gleichermaßen auf Valves steam deck zu, ... da könnte FSR oder Intels DP4a nach m.E. die Nutzbarkeit deutlich verbessern
(k.A. ob DP4a@Linux works)
Absolut. Das habe ich mir beim Release schon gedacht/gewünscht. Gerade bei solchen Geräten würde es so viel Potenzial haben und auf den relativ kleinen Monitoren fallen auch die Nebenwirkungen nicht ganz so auf.

Ich bin wirklich gespannt darauf, ob und wie schnell es XeSS Implementierungen es für AMD und NV geben wird und wie flott sie sein werden. Soweit ich das Interview von DF an Intel verstanden habe, kommt das SDK gegen Ende des Jahres für DP4a.
Das Problem ist, dass Intel das nicht über DirectML umgesetzt hat, sondern über ihre eigenen Schnittstellen. Bedeutet also potenziell eine gewisse zusätzliche Arbeit, das entsprechend auf DirectML umzustricken.

[basix]

Absolut. Das habe ich mir beim Release schon gedacht/gewünscht. Gerade bei solchen Geräten würde es so viel Potenzial haben und auf den relativ kleinen Monitoren fallen auch die Nebenwirkungen nicht ganz so auf.

Ich bin wirklich gespannt darauf, ob und wie schnell es XeSS Implementierungen es für AMD und NV geben wird und wie flott sie sein werden. Soweit ich das Interview von DF an Intel verstanden habe, kommt das SDK gegen Ende des Jahres für DP4a.
Das Problem ist, dass Intel das nicht über DirectML umgesetzt hat, sondern über ihre eigenen Schnittstellen. Bedeutet also potenziell eine gewisse zusätzliche Arbeit, das entsprechend auf DirectML umzustricken.

Wieso eigene Schnittstellen? Shader Model 6.4 ist nötig und DP4a wird doch einfach via Compute Shader ausgeführt?

[robbitop]

Schau dir das Interview an. Das hat Tom Petersen dort gesagt.
https://www.youtube.com/watch?v=9pVO1siJt50

[aufkrawall]

Da hat er das gesagt, was basix anmerkte: DP4a als Fallback für andere über bereits existierende Möglichkeiten in D3D/HLSL, für ihre eigenen XMX-Cores eine eigene API.

[Troyan]

In "Deliver us the Moon" kann man TAAU mit DLSS vergleichen. DLSS ist qualitativ (leicht) besser von 1080p -> 2160p, TAAU dafür leicht schneller (ca. 0,2ms).

Das zeigt schon, wie absurd es ist sowas wie XeSS über DP4a umsetzen zu wollen, was erheblich langsamer als UE4 TAAU ist.

[aufkrawall]

DLSS ist garantiert nicht nur "leicht" besser als UE4 TAAU von 1080p -> 2160p, da liegen in Fortnite Welten zwischen (ja, ich habs auf nem 4k Screen gesehen)...

[Geldmann3]

Wow, DLSS hat einen ganz schönen Overhead in 8k.

Hier ein paar Messungen aus dem Bright Memory Infinite Raytracing Benchmark.
Die interne Auflösung liegt immer bei 4k, ledigleich die Ausgabeauflösung habe ich mit DLSS Qualität auf 6k bzw. mit DLSS Performance auf 8k gesteigert.

https://i.ibb.co/jycqQwv/DLSS-Resolution.png

Beim Sprung von 4k auf 6k sinkt die Performance um 10% bei gleichzeitiger Steigerung des Vram-Verbrauchs um 27%, wohlbemerkt ohne Änderung der internen Renderauflösung.
DLSS frisst hier 3GB Vram. Wobei eine höhere Ausgabeauflösung natürlich naturgemäß einen größeren Framebuffer benötigt.

Der Sprung von 6k auf 8k kostet noch einmal 11% Performance und 18% mehr Vram.
Hier ,,frisst" DLSS bereits 5,5GB Vram.

DLSS Performance erzeugt in diesem Benchmark in 8k einen Performance-Overhead von 24% gegenüber TAA mit gleicher, interner Auflösung. Wobei ich sagen muss, dass TAA optisch deutlich von DLSS überboten wird.
Hochfrequente Details schimmern nicht mehr im geringsten.
Dafür erzeugt DLSS am Bildrand Artefakte.
Wahrscheinlich weil die dort bei Kameradrehungen neu erscheinenden Pixel keine ,,Vorgängersamples" haben.

Aus Interesse habe ich den Benchmark mal in 8k ohne DLSS ausgeführt.
Dabei habe ich dann noch 1-3FPS sowie einen Vram Verbrauch von 24,2GB, bevor der Benchmark abstürzt.
Wahrscheinlich aufgrund des Vram-Überlaufs.
24GB sind eben nicht immer genug für 8k. ;D

Okay, aus Neugierde habe ich den Benchmark nun noch einmal in 6k + TAA laufen lassen.
Hier bekomme ich mit der übertakteten RTX 3090 noch 10FPS und verzeichne 19GB Vram Verbrauch.

[basix]

Interessant sind weniger die FPS und prozentuale Framedrop als der Unterschied in der Frametime:
- 4K native = 47.6ms
- 6K DLSS Quality = 52.6ms -> +5.0ms
- 8K DLSS Performance = 58.8ms -> +11.2ms

60fps Gaming ist damit in 8K faktisch ausgeschlossen. Da bliebe nur noch 5.4ms fürs eigentliche Rendering. Ich hoffe, dass DLSS 3.0 hier Nutzung vom Sparsity Feature auf Ampere+ machen kann. Mehr oder minder "gratis" ein 2x Performance-Boost (1.7...1.9x in realen ML/AI Anwendungen laut Nvidia Messungen). Das zusammen mit Lovelace mit nochmals doppelt so schneller GPU und 8K mit DLSS Performance würde nur noch ~3ms Frametime kosten. Für 60fps kann das dann klappen (70-75fps Grundperformance bei 4K native).

[robbitop]

Der Overhead (in Proportion zur Outputresolutiom) war ja schon zur Vorstellung des UP Modes auffällig sichtbar. 8K war trotz nur 1440p inputresolution nicht wirklich schnell. Das NN erfordert offenbar schon einiges an Rechenleistung pro Pixel.
Ggf erhöht NV zu Lovelace die TC Performance um den Drop zu verringern.

[robbitop]

Da hat er das gesagt, was basix anmerkte: DP4a als Fallback für andere über bereits existierende Möglichkeiten in D3D/HLSL, für ihre eigenen XMX-Cores eine eigene API.
Ich finde minute 18-20 da relativ schwammig (die API ist erstmal nicht zwingend abhängig vom Datenformat imo). Er redet davon dass es jetzt Intel APIs sind und irgendwann mal MS APIs sein werden. Wenn diese mal besser werden usw. Als wenn es dafür nicht nur Zeit braucht sondern auch noch Ramdbedingungen seitens MS zu erfüllen gibt. Leider hakt DF da nicht richtig nach, so dass es IMO nicht 100% eindeutig ist.

[Geldmann3]

Interessant sind weniger die FPS und prozentuale Framedrop als der Unterschied in der Frametime:
- 4K native = 47.6ms
- 6K DLSS Quality = 52.6ms -> +5.0ms
- 8K DLSS Performance = 58.8ms -> +11.2ms

60fps Gaming ist damit in 8K faktisch ausgeschlossen. Da bliebe nur noch 5.4ms fürs eigentliche Rendering. Ich hoffe, dass DLSS 3.0 hier Nutzung vom Sparsity Feature auf Ampere+ machen kann. Mehr oder minder "gratis" ein 2x Performance-Boost (1.7...1.9x in realen ML/AI Anwendungen laut Nvidia Messungen). Das zusammen mit Lovelace mit nochmals doppelt so schneller GPU und 8K mit DLSS Performance würde nur noch ~3ms Frametime kosten. Für 60fps kann das dann klappen (70-75fps Grundperformance bei 4K native).

Man sollte nicht vergessen, dass sogar das TAA ja schon minimal Performance kostet. 0,5ms vielleicht?
Lässt sich in dem Benchmark leider nicht deaktivieren.

[Tobalt]

XeSS sieht ja erstmal sehr gut aus. Dass Intel das gleich mit dem ersten Aufschlag bringt, iat doppelt peinlich für AMD..:-(

[robbitop]

Ich finde auch, dass sie da wirklich gepennt haben. Ja das ist rnd aufwändig und kann nicht jeder und ja Intel ist ein powerhouse. Aber AMD ist seit >30 Jahren dabei und will vorne mitspielen.

Ich würde mich aber nicht wundern, wenn das RnD für ein ähnliches Verfahren bereits läuft. In Form von FSR 2.0 oder ähnlich.

[basix]

Ich denke, AMD hat erst nach dem Release von DLSS 2.0 verstärkt R&D für ein entsprechendes Upsampling Verfahren investiert. TAUU war jetzt nicht so der Bringer und DLSS 1.0 sowieso nicht, wenn selbst CAS gut damit mithalten konnte. Intel selbst ist laut Interview mit einem Intel Mitarbeiter auch schon einige Jahre mit den Grundlagen rund um XeSS beschäftigt. Das dauert halt einfach.

AMD hat aber eine etwas erschwerte Aufgabenstellung, auf welche Weise sie FSR 2.0 implementieren. Der Grund ist die relativ heterogene HW-Basis und dass sie keine Matrix-Beschleunigung besitzen. Max. DP4a ist möglich. Und sie wollen es für APUs als auch High End GPUs haben. Bei den APUs ist Vega die Baseline. Hier hat man max. packed FP16. Navi 10 ebenfalls. Playsation 5 könnte ebenfalls nur FP16 bieten. Wie löse ich das nun? FP16 only? DP4a mit FP16 Fallback? Entsprechende Optimierungen am DNN, damit es auch mit FP16 und/oder DP4a performant läuft, dafür aber schlechter aussieht? AMD hat historisch gesehen halt eher sparsam ML/AI Beschleunigung in die HW eingebaut.

Intel hat den Vorteil, dass sie XeSS auf XeHPG abstimmen können und iGPU Xe unterstützt soweit ich mindestens DP4a. Oder man kann die Skylake-CPU dafür zweckentfremden.

Nvidia hat bei Pascal ebenfals 4x INT8 Beschleunigung und seit Turing Tensor Cores. Mehr Hardware hilft hier.

[hmmm]

Oder aber die Hölle friert ein weiteres mal zu und Intel & AMD stecken unter einer Decke.
:O

[Tobalt]

AMD wird mittelfristig nicht um dedizierte LowPrec Einheiten drumherum kommen. Das ist halt einfach der Wind der in Consumrtgraphics spätestens seit DLSS 2 weht.

Danach könnten sie aber durchaus gewillt sein XeSS zu supporten um eigene Entwicklung zu sparen. Fragt sich in dem Fall ob sie die Größe besitzen und sagen wir nutzen ein gutes Verfahren der Konkurrenz weil es gut ist. Oder ob sie in nV Manier das umbenennen, eine markeneigene Bezeichnung einführen, und dann behaupten dass man besser und sowieso auch erster damit ist selbstverständlich.

[basix]

AMD wird XeSS zu 100% supporten. Ist eher die Frage, ob sie einen FP16 Pfad einbauen, wenn DP4a nicht von der HW unterstützt wird. Und lohnt es sich dann noch bezüglich Performance?

Edit:
XeSS kann AMD auch von Seiten APU gefährlich werden. Für iGPUs ist sowas wie XeSS oder DLSS 2.0 Gold wert, und zwar in doppelter Hinsicht: Performance und Energieeffizienz.

[Dampf]

XeSS könnte durchaus die eierlegende Wollmilchsau der Upscaling Verfahren werden. Doch dafür muss Intel eben die HW-Beschleunigung der AI Berechnungen von anderen GPU Herstellern unterstützen.

[GerryB]

AMD wird XeSS zu 100% supporten. Ist eher die Frage, ob sie einen FP16 Pfad einbauen, wenn DP4a nicht von der HW unterstützt wird. Und lohnt es sich dann noch bezüglich Performance?

AMD hat ggü. CB bestätigt das DP4a mit rapidmath funzt. Performancewise spielen 5% weniger als mit XeSS keine Rolle.
(die Frage wurde ja schon aufgeworfen ob 5% mehr Shader oder extra XeSS-Cores auf dem Chip sinnvoller sind)

[robbitop]

Ich denke, AMD hat erst nach dem Release von DLSS 2.0 verstärkt R&D für ein entsprechendes Upsampling Verfahren investiert. TAUU war jetzt nicht so der Bringer und DLSS 1.0 sowieso nicht, wenn selbst CAS gut damit mithalten konnte. Intel selbst ist laut Interview mit einem Intel Mitarbeiter auch schon einige Jahre mit den Grundlagen rund um XeSS beschäftigt. Das dauert halt einfach.

AMD hat aber eine etwas erschwerte Aufgabenstellung, auf welche Weise sie FSR 2.0 implementieren. Der Grund ist die relativ heterogene HW-Basis und dass sie keine Matrix-Beschleunigung besitzen. Max. DP4a ist möglich. Und sie wollen es für APUs als auch High End GPUs haben. Bei den APUs ist Vega die Baseline. Hier hat man max. packed FP16. Navi 10 ebenfalls. Playsation 5 könnte ebenfalls nur FP16 bieten. Wie löse ich das nun? FP16 only? DP4a mit FP16 Fallback? Entsprechende Optimierungen am DNN, damit es auch mit FP16 und/oder DP4a performant läuft, dafür aber schlechter aussieht? AMD hat historisch gesehen halt eher sparsam ML/AI Beschleunigung in die HW eingebaut.

Intel hat den Vorteil, dass sie XeSS auf XeHPG abstimmen können und iGPU Xe unterstützt soweit ich mindestens DP4a. Oder man kann die Skylake-CPU dafür zweckentfremden.

Nvidia hat bei Pascal ebenfals 4x INT8 Beschleunigung und seit Turing Tensor Cores. Mehr Hardware hilft hier.

Nunja Hardware ist ja ständig in Evolution. Die Frage ist, ob sie für ihre (Gaming) GPU IP HW Units für Tensor in der Pipeline haben. Das kann entscheidend sein, wenn man ein NN haben will für das clamping.

Wenn das der Fall ist, würde ich es so machen wie Intel. 2x Pfade: INT8 und Tensor. INT8 ließe sich sicherlich auch mit FP16 umsetzen, so dass doch eine Menge HW noch halbwegs Speedup bekommt.

Alte Hardware läuft halt langsamer. Aber wenn man Innovationen will, muss man halt manchmal alte Zöpfe abschneiden. Vega fliegt dieses Jahr auch endlich aus den APUs raus und wir haben wenigstens RDNA2 Level im Productstack.


-----------

Ich denke auch, dass sie XeSS supporten werden. Die Frage ist, wie gut und optimiert das sein kann, wenn DirectML noch so sehr hinterher hängt.
Aber ich vermute, dass sie auch ein eigenes Süppchen kochen werden - denn am Ende will man ggf auch nicht abhängig sein. Intel könnte jederzeit entscheiden, Innovationen ab einem gewissen Punkt nicht mehr in den Open Source Zweig zu gießen. Oder aber sie stark zu verzögern.
Dazu kommt, dass man immer vom neuronalen Netzwerk des anderen abhängig ist. Vermutlich hat man dazu praktisch keinen richtigen Zugriff.
So schön open source ist - ich vermute, dass das eigentlich Komplexe das NN ist. Wenn da kein vollständiger freier Zugang besteht (so dass man dieses auch abändern, anders tranieren, weiterentwickeln kann), hat man immer die Abhängigkeit und man hinkt potenziell immer hinterher.
Ich vermute, man wird XeSS supporten aber dennoch ein eigenes, freies FSR 2.0 entwickeln. Was wiederum dann potenziell auch von NV und Intel supportet wird.

[basix]

AMD hat ggü. CB bestätigt das DP4a mit rapidmath funzt. Performancewise spielen 5% weniger als mit XeSS keine Rolle.
(die Frage wurde ja schon aufgeworfen ob 5% mehr Shader oder extra XeSS-Cores auf dem Chip sinnvoller sind)

Nur Navi 12, 14 und RDNA2 (ausser PS5). Alle anderen GPUs nicht. Ein FP16 Pfad ist nochmals nur noch halb so schnell.

Hast du keine DP4a Beschleunigung (4x INT8), hat man bald deutlich erhöhte Execution Time, insbesodere auch verglichen mit Intels XMX Lösung. Sind Intels XMX Einheiten relativ gesehen gleich ausgebaut wie bei Turing / Ampere, erreicht die 512er HPG Version ~280 TOPS bei 2.2 GHz. Navi 10 mit FP16 erreicht gerade mal 20 TFLOPS. Dito PS5.

Nehmen wir an, XeSS benötigt 2ms Ausführungszeit auf der 512er Version (1080p -> 4K). Das ist ähnlich wie bei DLSS 2.0 auf einer RTX 3090 (~300 TOPS). Navi 10 würde bei linearer Skalierung satte 28ms für XeSS benötigen. Da kann man es gleich sein lassen. Ich denke zwar, dass XeSS weniger Ausführungszeit benötigt, da es auch auf ihren iGPUs mit weniger Rechenleistung funktionieren soll. Mit XMX/Tensor Cores kann man aber den Kunkurrenten ein Bein stellen, da nützen dann auch +5% Shader Cores nicht um den Performancenachteil auszugleichen. Das ist dann besser in Matrix-Cores investiert (und öffnet auch abseits von Games Anwendungsfälle).

AMD will mit FSR 2.0 zwingend auch die PS5/XBSX bedienen. Hier ergibt sich automatisch eine Baseline, welche AMD erreichen will. Da ist eine DP4a/FP16 Implementation naheliegend. Bei 20-40 T(FL)OPS hat man da ein deutlich engeres Budget. Dabei ist auch 60fps das Target und somit max. 16.67ms Frametime. Da wären 5ms fürs Upsampling zu viel. Kommen die APUs noch ins Spiel: Sehr eng. Van Gogh und Rembrandt bieten RDNA2 (8-15 TOPS INT8) und Vega 7...11 noch weniger (3-5 TFLOPS FP16). Bei den APUs kann man noch sagen, dass eher 1080p das Target sind und somit ~3-4x weniger Performance benötigen als Upsampling auf 4K. Im Endeffekt bleibt die Baseline von 20-40 T(FL)OPS für Upsampling auf 4K bestehen. Damit muss AMD auskommen.

Edit:
Achja, Samsungs Exynos 2200 soll 6 RDNA2 CUs bei 1.3 GHz bieten. Macht 4 TOPS. Wäre für 1080p evtl. noch knapp denkbar / auf Augenhöhe mit den Vega iGPUs.

[Troyan]

Samsung hat eigene TensorCores. Niemand benutzt die normalen Recheneinheiten für DL Techniken.

[Gast]

Danach könnten sie aber durchaus gewillt sein XeSS zu supporten um eigene Entwicklung zu sparen. Fragt sich in dem Fall ob sie die Größe besitzen und sagen wir nutzen ein gutes Verfahren der Konkurrenz weil es gut ist.


Das liegt nicht in der Entscheidungsgewalt von AMD oder Nvidia, sondern sondern von den jeweiligen Softwareherstellern.

Wie auch DLSS muss auch XeSS von der jeweiligen Software eingebaut werden, im Gegensatz zu Nvidia schreibt Intel aber keine Beschränkung auf die eigene Hardware vor. Trotzdem liegt es aber in der Verantwortung des jeweiligen Entwicklers auf welcher Hardware er XeSS umsetzen möchte.

[Dampf]

Samsung hat eigene TensorCores. Niemand benutzt die normalen Recheneinheiten für DL Techniken.

Eine sehr interessante Überlegung. Könnte man die NPUs in modernen Smartphone SoCs für ein DLSS/XeSS mobile nutzen? Oder wäre die Latenz zu groß? Der Exynos 2100 hat ja bereits 26 TOPS.

[Gast]

Oder wäre die Latenz zu groß? Der Exynos 2100 hat ja bereits 26 TOPS.

Was für eine Latenz? Die SoCs haben alle Unified Memory, ob da die CPU, GPU, NPU, DSP oder was auch immer zugreift ist völlig egal.

[Gast]

Ich finde auch, dass sie da wirklich gepennt haben.

Das kann mal passieren, man kann nicht alles vorhersehen.

Peinlich ist es eher, dass sie sowas wie FSR als "Alternative" anbieten, anstatt einfach einzugestehen, dass sie was verschlafen haben.

[GerryB]

Lass mal die Kirche im Dorf!

...spiele gerade MYST mit 4k@FSR und sooo schlecht siehts gar net aus.
FSR 1.0 musste halt kompatibel mit der PS5 sein.

Wenn Sony evtl. nen eigenen Weg geht, kann AMD dann 2.0 einfach an DP4a ausrichten für die Xbox+PC,
... Das wird schon noch dieses Jahr klappen.

[robbitop]

AMD will mit FSR 2.0 zwingend auch die PS5/XBSX bedienen. Hier ergibt sich automatisch eine Baseline, welche AMD erreichen will. Da ist eine DP4a/FP16 Implementation naheliegend. Bei 20-40 T(FL)OPS hat man da ein deutlich engeres Budget. Dabei ist auch 60fps das Target und somit max. 16.67ms Frametime. Da wären 5ms fürs Upsampling zu viel. Kommen die APUs noch ins Spiel: Sehr eng. Van Gogh und Rembrandt bieten RDNA2 (8-15 TOPS INT8) und Vega 7...11 noch weniger (3-5 TFLOPS FP16). Bei den APUs kann man noch sagen, dass eher 1080p das Target sind und somit ~3-4x weniger Performance benötigen als Upsampling auf 4K. Im Endeffekt bleibt die Baseline von 20-40 T(FL)OPS für Upsampling auf 4K bestehen. Damit muss AM
PS5 hat das Problem, dass IIRC keine 4x INT8 rate vorliegt.

Am Ende muss man sich überlegen, ob man wirklich alle Hardware bedient oder halt mal alte Zöpfe abschneidet.

NN könnte es für ältere HW einfach nicht mehr praktikabel machen. Entsprechend ist dann temporales Supersampling mit Heuristik an der Tagesordnung. So wie UE 5.0 TSR. Ob AMD das zwangsweise liefern muss, wenn die meisten Engines bereits eine art temporales Upscaling haben?

Dann könnte man FSR 2.0 mit 2x clamping Verfahren ausliefern: Heurisik und NN. Aber wie gesagt: mit Heuristik gibt es das in den meisten Engines schon. Ich würde mich auf eine NN Variante fokussieren.
Der alte Kram läuft dann halt mit FSR 1.0 oder TSR oder Checkerboarding oder TAUU oder oder oder.

Für die Konsolen ist AMD ja auch nicht unbedingt verantwortlich was SW angeht. Da gibt es gute Studios und da gibt es mit Sony und MS auch sehr sehr gute Vendors die an ihren eigenen Verfahren forschen. Bei MS erwarte ich ein NN basiertes temporales SS Verfahren. Bei Sony mangels INT8 Beschleunigung bleibt es ggf. bei guten Heuristiken. (wobei ids TSSAA und Epics TSR zeigen, dass das nicht schlecht sein muss - man kommt nicht an NN Verfahren heran - aber manchmal sind 80% auch nicht schlecht)

Ich sehe nicht, dass man mit diesem Thema unbedingt "one size fits all" machen muss. Dann endet man nur mit faulen Kompromissen.

Samsung hat eigene TensorCores. Niemand benutzt die normalen Recheneinheiten für DL Techniken.
Die sind aber nicht im GPU Teil. Entsprechend ist die Anbindung zwischen GPU IP Block und deren Tensor Cores im SoC ggf dafür gar nicht ausgelegt. Die sind bis dato ja schon für eher andere Applikationen dimensioniert.

Das kann mal passieren, man kann nicht alles vorhersehen.

Peinlich ist es eher, dass sie sowas wie FSR als "Alternative" anbieten, anstatt einfach einzugestehen, dass sie was verschlafen haben.
FSR 1.0 ist erstmal eine Baseline, die nicht mit DLSS 2.x konkurrieren kann. Aber man hat erstmal was, was überall läuft. IMO war das ein taktischer Zug von AMD. Man hat erkannt, dass DLSS 2.x wirklich bedrohlich sein kann, wenn immer mehr Benchmarks mit DLSS vs AMD vanilla getätigt werden. FSR ist nicht vergleichbar, bekam aber aufgrund dessen, dass es überall läuft erstmal gute Presse. Und es kann gut sein, dass DLSS gegen FSR gebencht werden wird. Zumindest bei einer Teilmenge der Influencer. Damit hat man sich schonmal Zeit erkauft für FSR 2.0. Ich hätte es genau so gemacht.
Kein Mensch hat, wie du sagst, damit gerechnet, dass mit einem NN das temporale super sampling so extrem gut funktionieren kann. Zu AMDs Glück ist es noch nicht immer ideal implementiert und es fehlen noch ein paar kleinere Evolutionsschritte.
Doch wer gute Implementierungen gesehen hat und verstanden hat, wie es funktioniert - dem ist klar, was für ein Potenzial darin steckt und warum es so gut aussehen kann. Die meisten der derzeit sichtbaren Artefakte werden deutlich weniger werden und es wird sich nativ immer weiter annähern (und stellenweise besser aussehen). Mit steigender Tensor Leistung ist auch im grundsätzlichen NN Teil sicher noch einiges an Luft nach oben. Im Prinzip hat man ja gerade erst angefangen NN wirklich in größerem Maßstab zu nutzen.

[GerryB]

Das jetzt sozusagen Äpfel mit Birnen verglichen werden, ...hat ja schon angefangen:
https://www.igorslab.de/performance-boost-mit-fsr-und-dlss-necromunda-hired-gun-im-praxistest/

...für ein Teil der Leser zählen am Ende die fps halt mehr als Quality
und nach 2-3h spielen fällts auch net mehr auf

Eigentlich schade, das Igor net die W/fps noch zusätzlich ermittelt hat, was Er sonst eigentlich immer drin hat.
Das wäre für mich die interessanteste Bewertung@10m²-Office, weils am Ende entscheidend ist für längere Spielzeiten.
(gerne auch mit CPU+GPU-gesamt, ... GPU einzeln finde ich immer zuwenig aussagekräftig, ...So ähnlich wie PCGH mit 60fps-4k,
sollte sich doch ne normierte Aussage leicht treffen lassen, die dann alle Overheads verbrauchsmäßig mit erfasst)

[Gast]

...spiele gerade MYST mit 4k@FSR und sooo schlecht siehts gar net aus.

Aber auch nicht besser als bereits seit Jahren vorhandene Upscaling-Techniken.

[Gast]

FSR 1.0 ist erstmal eine Baseline, die nicht mit DLSS 2.x konkurrieren kann.

Finde ich nicht, man hat den Namen FSR damit schon mal verbrannt.

Den Ruf schlechte Qualität zu liefern muss man erst mal loswerden, selbst wenn FSR 2.0 hochwertig werden sollte.

[robbitop]

Das ist ein bisschen die Nerd Filterblase. In den Medien und der breiten Öffentlichkeit scheint FSR anscheinend kein negatives Image zu haben.
Und selbst wenn sich das ändern sollte: ein neuer Name ist schnell erfunden. RdnaSS zum Beispiel :D

[GerryB]

Da kann man leicht die Threadseiten mit lustigen Namensvorschlägen füllen, ...hoffentlich net.

Mir würde der kleinste gemeinsame Nenner reichen = DP4aTSR.
... besagt Methode und temporale Komponente in Einem
(falls = hoffentlich, AMD auf den Inteltrain aufspringt)

[DrFreaK666]

..Den Ruf schlechte Qualität zu liefern muss man erst mal loswerden, selbst wenn FSR 2.0 hochwertig werden sollte.

Nvidia hats ja auch geschafft. DLSS 1 kam allgemein nicht so gut an

[BlacKi]

habt ihr schon neuere dlss versionen genutzt, die schlechter geworden sind als die alte?

[GerryB]

Immer dieses sinnlose güne Rangezoome und Haar in der Suppe suchen.(von Auftragsschreiberlingen und Fanboys)

In der Mehrheit kommt 24/7, realitätsnah "ohne Zoomen", FSR 1.0 ganz gut bei den Leuten an.
Der Nutzen ist einfach schon deutlich spürbar.

[BlacKi]

das ranzoomen verdeutlicht nur das, was man oft nur gefühlt wahrnimmt. aktuell ist es doch egal, fast kein spiel kann beides um überhaupt eine wahl zu haben.

soweit ich mich richtig erinnere soll mit bf2042 beides möglich sein. dann wird man sich auch entscheiden können was man nimmt, und was wirklich besser aussieht, im detail und vom spielgefühl her.

[Gast]

Nvidia hats ja auch geschafft. DLSS 1 kam allgemein nicht so gut an

Gerade DLSS ist das perfekte Beispiel dafür, wie oft wird heute noch die exzellente Bildqualität von DLSS 2.x kritisiert, nur weil diese von DLSS 1.x nicht so prächtig war?

FSR hat noch einen weiteren Nachteil. DLSS war damals zumindest besser wie bestehende Upscaling-Techniken, auch wenn es ganz klar nicht das Versprechen "fast native Qualität" einlösen konnte, zumindest nicht in Battlefield, das mit Abstand schlechteste DLSS 1.x Spiel. Andere DLSS 1.x Spiele waren bedeutend besser und wurden großteils trotzdem gleich schlecht als Battlefield beurteilt.

FSR ist dagegen nicht besser als bisherige Upscaling-Techniken, sondern maximal gleich gut, und dabei mein ich nicht DLSS das läuft durch die Limitierung auf Nvidia-Hardware außer Konkurrenz, sondern Upscaling-Techniken die Spiele seit Jahren implementiert haben.

Von daher hat sich FSR aktuell den Ruf eines völlig unnötigen Features eigehandelt. Und den wird man nicht mal so eben los.

[GerryB]

Vergleichen kannste doch schon:
https://www.youtube.com/watch?v=KmaifRsJs2E

[Geldmann3]

Das Video hat mich überrascht. Ich finde FSR ist hier auf einem Level mit DLSS.
Die Texturen gefallen mir mit FSR besser, wahrscheinlich aufgrund des integrierten Sharpenings, dafür schimmert die Waffe mit FSR an manchen Stellen, was mit DLSS nicht vorkommt.
Interessant.

Ich schätze, das Spiel bietet unter der Haube eine solide, temporale Kantenglättung, was meine Beobachtung in GTA V (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12780944&postcount=1471) bestätigt.
Wenn man FSR mit sehr gut geglätteten Input füttert, performt es im besten Fall sehr nah in DLSS.
Weist der Input jedoch Artefakte oder Aliasing auf, kann FSR nicht viel tun und versagt entsprechend.
Doch ich vermute Necromunda Hired Gun zeigt auch einfach nicht ausreichend hochfrequente Details, wo DLSS eventuell mehr glänzen würde.
Denn theoretisch sollte FSR keine Chance gegen DLSS haben, da es nicht über eine temporale Komponente verfügt.

[DrFreaK666]

...Von daher hat sich FSR aktuell den Ruf eines völlig unnötigen Features eigehandelt. Und den wird man nicht mal so eben los.

Ich glaube nicht dass es global so gesehen wird. DLSS ist unnötig, da es nur mit RTX-Karten funktioniert.
Ich hoffe dass XeSS was taugt, dann kann Nvidia DLSS beerdigen

[robbitop]

Gerade DLSS ist das perfekte Beispiel dafür, wie oft wird heute noch die exzellente Bildqualität von DLSS 2.x kritisiert, nur weil diese von DLSS 1.x nicht so prächtig war?

FSR hat noch einen weiteren Nachteil. DLSS war damals zumindest besser wie bestehende Upscaling-Techniken, auch wenn es ganz klar nicht das Versprechen "fast native Qualität" einlösen konnte, zumindest nicht in Battlefield, das mit Abstand schlechteste DLSS 1.x Spiel. Andere DLSS 1.x Spiele waren bedeutend besser und wurden großteils trotzdem gleich schlecht als Battlefield beurteilt.

FSR ist dagegen nicht besser als bisherige Upscaling-Techniken, sondern maximal gleich gut, und dabei mein ich nicht DLSS das läuft durch die Limitierung auf Nvidia-Hardware außer Konkurrenz, sondern Upscaling-Techniken die Spiele seit Jahren implementiert haben.

Von daher hat sich FSR aktuell den Ruf eines völlig unnötigen Features eigehandelt. Und den wird man nicht mal so eben los.
Ich habe nicht den Eindruck dass das der Kernbotschaft entspricht, was der Großteil der Redaktionen und Influencer über FSR verbreitet haben. Die Presse war erstaunlich gut zu FSR.
Das ist eher der Eindruck, den eine Minderheit von uns Nerds haben. :) Das ist aber völlig irrelevant für den Massenmarkt.

@Geldmann3
GTA5 hat einzig TXAA wenn es temporales AA sein soll. Und das ist uralt und ist temporal IMO klar erkennbar. Bei GTA5 flimmert nich ein Haufen Schatten auch mit TXAA. Dazu kommt noch ein ordentlicher Schärfeverlust. Das ist auch kein Wunder wenn man bedenkt, wie alt TXAA schon ist. Da war TAA noch in den Kinderschuhen.

[iamthebear]

Gerade DLSS ist das perfekte Beispiel dafür, wie oft wird heute noch die exzellente Bildqualität von DLSS 2.x kritisiert, nur weil diese von DLSS 1.x nicht so prächtig war?

FSR hat noch einen weiteren Nachteil. DLSS war damals zumindest besser wie bestehende Upscaling-Techniken, auch wenn es ganz klar nicht das Versprechen "fast native Qualität" einlösen konnte, zumindest nicht in Battlefield, das mit Abstand schlechteste DLSS 1.x Spiel. Andere DLSS 1.x Spiele waren bedeutend besser und wurden großteils trotzdem gleich schlecht als Battlefield beurteilt.

FSR ist dagegen nicht besser als bisherige Upscaling-Techniken, sondern maximal gleich gut, und dabei mein ich nicht DLSS das läuft durch die Limitierung auf Nvidia-Hardware außer Konkurrenz, sondern Upscaling-Techniken die Spiele seit Jahren implementiert haben.

Von daher hat sich FSR aktuell den Ruf eines völlig unnötigen Features eigehandelt. Und den wird man nicht mal so eben los.

Ich denke hier muss man grundsätzlich unterscheiden:
.) Der Fokus von FSR war von Anfang an, dass es möglichst einfach in Spiele zu integrieren ist. Dieses ist für Spiele gedacht, die eben noch kein brauchbares Upscalingverfahren haben. Alle vergleichbaren bisherigen Upscalingverfahren waren immer ein Feature der Engine und waren nicht portabel.
Die Umsetzung von FSR war sehr gut, nur ist die erreichbare Qualität eben sehr begrenzt, da man eben nur Upscaling macht und kein AA. Wenn das spieleigene AA schon flimmernde Texturen bzw. ein von TAA zermatschtes Bild liefert dann kann FSR da nicht mehr viel retten.
Generell hilft FSR auch nur bei der Schärfe. Falls das Hauptproblem der niedrigen Auflösung jedoch gar nicht die Schärfe sondern Ghosting (z.B. RDR2) oder flimmernde Kanten sind, dann hilft es hier wenig.
.) Bei DLSS ist wesentlich mehr Potential da, da es viel tiefer in der Engine integriert ist und es Upscaling und AA als ein Problem betrachtet. Bei DLSS 1 war das Problem die Umsetzung was mit DLSS 2 deutlich verbessert wurde. Dieser Qualitätsgewinn ist jedoch mit FSR nicht zu erwarten, da es gar nicht die notwendigen Rohdaten zur Verfügung hat.
Natürlich könnte AMD nun ein ähnliches Verfahren bringen, das TAA und Upscaling in einem Schritt übernimmt. Das muss nicht zwangsläufig auf einem neuralen Netzwerk basieren, jedoch entfällt dann der Vorteil der einfachen Integration.

Langfristig gesehen ist der sinnvollere Ansatz natürlich der von DLSS dass die AA Lösung das Upscaling gleich mit übernimmt. Ob man dafür unbedingt ein neuronales Netzwerk braucht oder ob es nicht besser ist das Ganze bei etwas niedrigerer Qualität mit traditionellen Algorithmen zu lösen und dafür statt den Tensor Cores ein paar Shader mehr zu verbauen bzw. auf Grund des geringeren Overheads bei der Renderauflösung eine Stufe höher zu schalten wird sich erst zeigen müssen. Genauso ist fraglich, ob es hier überhaupt eine portable Technologie eines Grafikkartenherstellers braucht oder ob es nicht sinnvoller ist, wenn sich das jeder große Enginehersteller selbst baut und dafür die kleineren Spielestudios einfach die Engines der größeren übernehmen. Cyberpunk wäre vermutlich besser dran gewesen wenn sie auf ihren langsamen verbuggten Eigenbau verzichtet hätten.

Ich habe nicht den Eindruck dass das der Kernbotschaft entspricht, was der Großteil der Redaktionen und Influencer über FSR verbreitet haben. Die Presse war erstaunlich gut zu FSR.
Das ist eher der Eindruck, den eine Minderheit von uns Nerds haben. :) Das ist aber völlig irrelevant für den Massenmarkt.

Der Großteil der Influencer hat FSR gehyped weil es von AMD kommt und AMD bei den meisten Zusehern ein positives Image hat. Die wenigsten haben sich überhaupt mit der Qualität auseinander gesetzt bzw. ob es überhaupt besser als bestehende Upscalingverfahren ist. Meistens wurde nur gesagt: Leute das ist dasselbe wie DLSS nur von AMD und Open Source und läuft jetzt überall, sogar auf den alten Pascal Karten und ihr bekommt eine Menge fps mehr.

Für den Massenmarkt (sofern dieser in einer Zeit von 1K Grafikkarten überhaupt noch existiert) sind die Features sowieso uninteressant. Da wird bestenfalls bei den Reviews auf den Gesamtscore geschaut und am Schluss freut man sich da die neue Karte schneller ist als die alte GTX 760.

[robbitop]

Völlig irrelevant wie gesagt. Relevant ist nur was Marktwirksam ist. Wir Nerds machen 0,000000001% des Marktes aus. ;)

[Geldmann3]

@Geldmann3
GTA5 hat einzig TXAA wenn es temporales AA sein soll. Und das ist uralt und ist temporal IMO klar erkennbar. Bei GTA5 flimmert nich ein Haufen Schatten auch mit TXAA. Dazu kommt nich ein ordentlicher Schärfeverlust. Das ist auch kein Wunder wenn man bedenkt, wie alt TXAA schon ist. Da war TAA nich in den Kinderschuhen.

Ich stimme zu, TXAA ist ziemlich suboptimal gegen heutige, temporale Kantenglättungsverfahren, im Prinzip jittert der Treiber hier nur die Samplepositionen der MSAA-Samples, um diese temporal besser auszunutzen und das ist das größte Problem von FSR in GTA V. Auch kostet TXAA im Gegensatz zu TAA sehr viel Performance, wahrscheinlich eben wegen seinem MSAA-Core.

Mich hat es auch überrascht, wie gut FSR angekommen ist, denn für mich war es eigentlich eine große Enttäuschung, denn ich dachte mir ,,Ey Leute, das ist nur ein Single-Image-Upscaler, auch wenn man dabei natürlich nur den finalen Image-Output hätte, könnte man es sogar in einen TV oder HDMI-Kabel implementieren". Bei DLSS wäre das nicht möglich, aufgrund der temporalen Komponente, es hat wesentlich mehr Potenzial. Dennoch nice, dass es das jetzt gibt und ich muss doch zugeben, in den letzten Tagen immer wieder überrascht gewesen zu sein, von der Qualität her.

[ChaosTM]

Das flimmern bringt man mit Oversampling (2x) recht gut in den Griff. Hab das Spiel gerade am neuen Laptop installiert. Dank 3080er bleiben immer noch >50fps übrig bei 1200p(2400p)

[Gast]

I
.) Der Fokus von FSR war von Anfang an, dass es möglichst einfach in Spiele zu integrieren ist. Dieses ist für Spiele gedacht, die eben noch kein brauchbares Upscalingverfahren haben. Alle vergleichbaren bisherigen Upscalingverfahren waren immer ein Feature der Engine und waren nicht portabel.

Nur ist gerade das eben ziemlich unnötig Upscaling-Verfahren die besser als bilinear sind, sind seit Ewigkeiten in praktisch allen Engines integriert. FSR bringt hier nicht wirklich einen Vorteil.

[Gast]

Nur ist gerade das eben ziemlich unnötig Upscaling-Verfahren die besser als bilinear sind, sind seit Ewigkeiten in praktisch allen Engines integriert. FSR bringt hier nicht wirklich einen Vorteil.
FSR macht schon einiges mehr als einfaches spatial Upscaling.
So dreht es bei dem angenäherten Lanczos2 Filter noch die Skalierachsen in Richtung der erkannten Kante. Daher hat man an kontrastreichen Kanten, die in Spielen ja häufig vorkommen, eine gute Kantenqualität mit wenig Treppenstufeneffekt hervorgerufen durch die Skalierung.
Das Ringing wird durch eine Limitierung auf den Kontrast der Umgebung in der Quelle "abgeschaltet".
Dann kommt halt abseits des Skalierens noch das CAS dazu, um die Detailschärfe zu erhöhen und so mehr Details vorzugaukeln.

Kann man recht gut in der offiziellen GPUOpen Doku nachlesen, ist ja alles offen, oder auch schön mit Folien vom Entwickler selbst:

http://advances.realtimerendering.com/s2021/index.html
unter "Improved Spatial Upscaling through FidelityFX Super Resolution for Real-Time Game Engines "

[robbitop]

Ich stimme zu, TXAA ist ziemlich suboptimal gegen heutige, temporale Kantenglättungsverfahren, im Prinzip jittert der Treiber hier nur die Samplepositionen der MSAA-Samples
Hier bin ich mir nicht ganz sicher. Denn laut einigen Berichten im Netz hilft die Aktivierung von MFAA auch bei TXAA (was ja nichts anderes ist als das MSAA Pattern zu jittern) bei GTA5. Ich hab das nachgestellt und hatte subjektiv den Eindruck, dass es hilft.
Auch habe ich AF über den Treiber erzwungen und es scheint etwas globaler bei GTA5 zu wirken und beides in Kombination macht das Game für mich weniger flimmernd (die decals auf den Straßen - also die Fahrbahnmarkierung und die Schatten auf der Fahrbahn waren vorher auffälliger).

Das flimmern bringt man mit Oversampling (2x) recht gut in den Griff. Hab das Spiel gerade am neuen Laptop installiert. Dank 3080er bleiben immer noch >50fps übrig bei 1200p(2400p)
Ja aber 2x2 Oversampling kostet halt ordentlich Leistung und ist halt echt ineffizient. Dazu kommt dass man Artefakte auf so einem kleinen Laptopdisplay (und dann auch noch mit hoher Auflösung) viel weniger sieht als auf einem richtigen Monitor. :)

[ChaosTM]

Ich spiel hier auf einem (16 Jahre alten) 24er 16:10 Dell. Daher auch die 2400p ;)

Skalierung 1.5 macht eh mehr Sinn. Ich wollte nur 4800p mit 8x AA ausprobieren. (17GB VRAM ...) (GTA5)

[robbitop]

2x2 macht mehr Sinn als 1,5x1,5. Zumindest was Schärfe angeht. Mit 1,5x tastest du halt den Nachbarpixel mit ab und das bringt Unschärfe.

[GerryB]

Im uralten Call of Juarez - Benchmark war 1,5*1,5 = 2,25 aber bereits ausreichend gegen Vegetationsflimmern.(x)
(dummerweise läuft der Bechmark net mehr auf W10, wo Jeder mal schauen/vgl. könnte)

(x) also gar net so abwegig bei ollen Games mit Kantenflimmern (Dishonored etc.)
Von daher kann man schonmal ein wenig Downsampling betreiben, ...in neueren Games reicht oft auch der inGame-slider auf 130%.

Ältere Games haben auch noch kein TAA, so das die Textureschärfe sogar besser ist als neuere Games@TAA, wo dann nur Tricks
wie Sharpen etwas Qualität zurückholen.

[robbitop]

1,5x1,5 ist recht ineffizient was jaggies angeht - aber es beruhigt temporal ja. Aber es erzeugt halt Unschärfe. Es ist nicht mehr als ein Kompromiss verglichen mit geraden Faktoren (oder echtem SGSSAA :)).

[Troyan]

TAAU@85%, FSR@UQ und DLSS@Q in einem kurzen Vergleich in Enlisted:
https://www.filemail.com/d/hzwhwayydzpgqtp
Ich denke, es ist offensichtlich, welches Verfahren den letzten Platz einnimmt.

[ChaosTM]

1,5x1,5 ist recht ineffizient was jaggies angeht - aber es beruhigt temporal ja. Aber es erzeugt halt Unschärfe. Es ist nicht mehr als ein Kompromiss verglichen mit geraden Faktoren (oder echtem SGSSAA :)).


Das hab ich jetzt auch mitbekommen bei Metro. THX.

[Andron]

TAAU@85%, FSR@UQ und DLSS@Q in einem kurzen Vergleich in Enlisted:
https://www.filemail.com/d/hzwhwayydzpgqtp
Ich denke, es ist offensichtlich, welches Verfahren den letzten Platz einnimmt.

Bis auf das stärkere flimmern an den Fensterläden (durch vermutlich mittelmäßiges TAA) liegen die Beispiele gar nicht so weit auseinander. In den restlichen Bildbereichen sieht FSR hier ziemlich gut aus.
Eigentlich ist es schon recht erstaunlich, dass FSR bei höheren Auflösungen und mit gutem TAA näher an DLSS rankommt, als man bei der Ankündigung geglaubt hätte. Bei niedrigen Ausgangsauflösungen ist DLSS natürlich trotzdem klar im Vorteil.

[ChaosTM]

DLSS vs TAA @ RDR2 .. TAA gewinnt aber sowas von.. ist aber auch ein unfairer Vergleich weil ich kein 2400p Oversamling schaffe momentan. K.A. warum

[Geldmann3]

TAAU@85%, FSR@UQ und DLSS@Q in einem kurzen Vergleich in Enlisted:
https://www.filemail.com/d/hzwhwayydzpgqtp
Ich denke, es ist offensichtlich, welches Verfahren den letzten Platz einnimmt.

Wäre nice, wenn die Dateinamen so gewählt wären, dass man weiß, welches Verfahren man vor sich hat. :wink:

[TheAntitheist]

DLSS vs TAA @ RDR2 .. TAA gewinnt aber sowas von.. ist aber auch ein unfairer Vergleich weil ich kein 2400p Oversamling schaffe momentan. K.A. warum
also DLSS sieht bei mir viel schärfer aus. Auch die meisten tests die ich laß sprachen von einem Vorteil für DLSS

[Troyan]

Wäre nice, wenn die Dateinamen so gewählt wären, dass man weiß, welches Verfahren man vor sich hat. :wink:

Na, man sollte es sich eben uneinvorgenommen anschauen.

Das FSR nichts anderes wie ein glofizierter Nachschärfefilter ist, sollte ja bekannt sein. Aber mit dem ins negative verschobenen Bias ist das an Absurdität einfach nicht mehr zu toppen. In Enlisted ist FSR eine Flimmerhölle sondersgleichen.

[Gast]

Das FSR nichts anderes wie ein glofizierter Nachschärfefilter ist, sollte ja bekannt sein.

Wie oft willst du diesen Schwachsinn denn noch wiederholen?

[Geldmann3]

Also ganz unvoreingenommen, das File mit der 07 am Ende flimmert schrecklich, die anderen beiden geben sich nicht soo viel.
08 am Ende sieht am besten aus.

Nehme an 07 ist FSR?

[ChaosTM]

Spiel mich gerade mit RDR2 und DLSS am 4K Schirm. Ernüchternd bisher. Bäume flimmern wie blöd und der Nebel ist fast weg. Schade,.

Die 3080 Mobile ist aber auch so schnell genug. Hätte ich ned gedacht. Braucht allerdings jedes Watt ;)

Automatisch schaut fast besser aus als Ultra. Komisch..

[aufkrawall]

Das Spiel taugt nicht, um DLSS zu bewerten. Eher dazu, was man bei einer schlechten Implementierung wie in diesem Fall bekommt.

[ChaosTM]

Eine hauch besser als TAA scheint es aber schon zu sein. Das ist wiederum sehr soft. Muss ich mal in einer Stadt ausprobieren.

[aufkrawall]

Ja, DLSS zermatscht die Texturen/Vegetation weniger und hat viel weniger Motion Blur. Das Problem ist aber, dass bestimmte Render-Effekte wie die volumetrischen Wolken mit dieser DLSS-Implementierung keinen Extra-Pass abbekommen und dann fies flimmern. Da wurde irgendwas vergeigt, in Fortnite etwa glättet DLSS genau so wie das TAA die Schatten vs. kein AA. Zusätzlich gibt es in RDR2 mit DLSS noch seltsames Corona-Aufleuchten in Bewegung, was es in Fortnite oder Doom Eternal ebenfalls komplett gar nicht gibt.
Für RDR2 empfiehlt sich gegen das zermatschte Gemüse SSAA via die in-game Resolution Scale Option. Mit der 6900 XT hat man sogar mit >4k genug Leistung dafür. "Holzhammer" wäre allerdings noch eine Untertreibung für dieses Vorgehen. ;D