AMDs FidelityFX Super Resolution (FSR) [Archiv] - Seite 9

Gast

2022-04-04, 12:58:25

mMn wird der DNN-Kernel inkl. dem Netzwerk nicht Open Source sein und die XMX-Implementation auch nicht aber das Gerüst rundherum.

Dann wäre eine Tensorcore-Implementierung ohne aufwändiges Reverse engineering auch nicht möglich.

Oder auch ein Nachteil, wenn XeSS qualitative Vorteile hätte.

Das dürfte kaum möglich sein, DLSS ist qualitativ schon so weit fortgeschritten, dass hier keine großen Sprünge mehr drinnen sind.
Und falls XeSS kleinere Vorteile hat, wird es eher in Nvidias Interesse sein, bei DLSS selbst entsprechend nachzubessern, anstatt die Konkurrenztechnologie zu pushen.

Evtl. sogar mit dem Vorteil, dass via Streamline die DLSS-DLL Version dann direkt vom Treiber gehandled wird.

Das geht schon heute, diverse Treiber "upgraden" die DLSS Implementierungen diverser Spiele automatisch, ohne Update vom Spiel.

Ich stell mir eher die Frage ob es nicht sinnvoller wäre, dass die "DLSS-DLL" gar nicht mehr mit dem Spiel ausgeliefert wird sondern direkt in den Treiber integriert ist. Evtl. ist Streamline auch dafür vorbereitet.

Schlussendlich Win-Win für Nvidia und Intel. Für AMD wäre es auch kein Nachteil, wenn sie FSR 2.0 mittels Streamline anbieten würden. Dann hat man FSR 2.0 auch automatisch in Games, welche XeSS und DLSS unterstützen.

Für eine möglichst breite Marktunterstützung wäre das Streamline-Framework sicher für alle von Vorteil.

DLSS läuft auf AMD nicht und XeSS auf RDNA2 vermutlich relativ langsam. Und für Nvidia wäre das auch ein Vorteil. Sonst kann es sein, dass FSR 2.0 aufgrund der breiten HW-Basis und Konsolen-Unterstützung den Markt "übernimmt", was ein Vorteil für AMD wäre.

Die Große Frage bei FSR2.0 sehe ich eher in der erreichbaren Qualität. Wie wir mittlerweile wissen setzt dies ja auf keinerlei ML, sondern herkömmliche Heuristiken, und zumindest bisher kann keine TAA Implementierung ohne NN dahinter nur ansatzweise mit DLSS mithalten.
Wenn FSR2.0 signifikant schlechtere Qualität als die anderen beiden bringt sehe ich eher kaum bis gar keine Daseinsberechtigung.
Wenn die Intel-Benchmarks zu XeSS vertrauenswürdig sind, dürfte der Performancenachteil von DP4a eher vernachlässigbar sein, und bei höherer Qualität immer den Vorzug gegenüber FSR2.0 bekommen.
AMD verliert damit gegenüber NV/Intel vielleicht 5-10%, zumindest in Bereichen <100FPS, wobei man ehrlicherweise sagen muss, so lange sie keine eigenen Matrixcores verbauen gibt es ja gar keine andere Möglichkeit. Das was FSR2.0 weniger an Leistung kostet wird es wohl auch an Qualität einsparen.

Insofern sehe ich mit XeSS einer Lösung die auf allen Karten läuft eher ein schweres Standbein für FSR2.0, das eigentlich nur eine Berechtigung hat falls XeSS nicht verfügbar ist (Steam Deck evtl.).

robbitop

2022-04-04, 13:03:14

Ich würde mich nicht wundern, wenn wir auch noch ein FSR 3.0 mit ML sehen werden und RDNA 3 oder 4 dann Matrixcores bekommt. IMO ist FSR bis dato von (sinnvollen) Zwischenschritten geprägt um möglichst viel Unterstützung für breite Hardware zu bekommen. Ich vermute außerdem, dass AMD was NN Forschung angeht weniger Fokus darauf gelegt hat als NV und dort etwas hinterher hängt.

Savay

2022-04-04, 13:22:32

deswegen nehme ich an, dass es ähnlich viel Ausführungszeit wie DLSS benötigt (2080 Ti = 240 TOPS, 3090 = 320 TOPS).

Wieso geht ihr eigentlich davon aus, dass die Rohleistung dieser Matrixeinheiten die dicht an den GPU ALUs sitzen auch wirklich voll ausgereizt wird durch DLSS und XeSS? :wink:

Wenn ich das hier ansehe ist das schon bei nem auf fp16 basierten DNN, welches neben Vectoreinheiten auch über Matrixeinheiten beschleunigt werden kann, nicht zwingend gesetzt:
78944

Offensichtlich gibt es da ja auch potenziell signifikante Bottlenecks, die durch andere Eigenschaften von RDNA2 erstaunlich gut abgefangen werden. (Evtl. der Cache?!)
Grade wenn man es Rohleistungsnormiert betrachtet und man bedenkt, dass schon die Navi21 Karte bei der Ausführung nicht wirklich voll ausgelastet wird. (gibt max. einige kurze Spikes auf ~150W bei ner TGP von 300W)
Das Problem, dass da in der Tabelle gelöst wird (Demosaicing) ist m.E. ja eh sehr ähnlich zu dem was das Clamping dieser Verfahren machen muss. (Auch wenn es nicht Echtzeitfähig sein muss)

Bei Cyberpunk ist die 3080 knapp 60% vor der 6800XT.
Das ist meilenweit von 3-4mal schneller weg, aber "überraschend gering" ist es auch nicht.

Was hat die RT Performance denn eigentlich mit DLSS, XeSS oder FSR zu tun?! :freak:
Am Denoiser scheint es ja eher nicht zu klemmen bei AMD und das ist ja das einzige was bei RT auf nV über die TC läuft soweit ich weiß.

Die RT Cores sind einfach etwas schwächer und beschleunigen bekanntlich auch nicht den gleichen Umfang.
Wie man davon dann auf die Ausführung von Upsampling Verfahren schließen will erschließt sich mir grade einfach nicht.

Gast

2022-04-04, 14:41:20

Am Denoiser scheint es ja eher nicht zu klemmen bei AMD und das ist ja das einzige was bei RT auf nV über die TC läuft soweit ich weiß.

Nur die Denoiser fürs Offline-Rendering.
Die in Spielen eingesetzten Denoiser verwenden keine Tensor-Cores.
Außer als Nebeneffekt, durch das in DLSS eingesetzte Jittering bekommt man nämlich ein gewisses Denoising quasi gratis dazu.

Andron

2022-04-04, 14:55:15

Wieso geht ihr eigentlich davon aus, dass die Rohleistung dieser Matrixeinheiten die dicht an den GPU ALUs sitzen auch wirklich voll ausgereizt wird durch DLSS und XeSS? :wink:

Darüber hinaus wird hier nur mit Leistungsangaben von TU102/GA102 GPUs um sich geworfen. DLSS ist selbst auf einer RTX 2060/3050 mobile noch lauffähig, bei deutlich geringerer Rohleistung. Intels XeSS soll sogar auf der Arc A350M lauffähig sein, welche nochmals nur ein Bruchteil der Tensorleistung liefert.

basix

2022-04-04, 19:25:26

Dann wäre eine Tensorcore-Implementierung ohne aufwändiges Reverse engineering auch nicht möglich.

Wenn DP4a Implementation Quelloffen ist und man DP4a via Tensor Cores laufen lassen kann, wieso sollte man das nicht umsetzen können. Schlussendlich sind Matrix-Berechnungen einfach eine Gruppierung von DP4a Befehlen. Da die DP4a Umsetzung auf einer Matrix-Umsetzung beruht, sollte das prinzipiell möglich sein. Ob Informationen für diese Gruppierung der Vektoren fehlen steht auf einem anderen Blatt. Durch das Analysieren der DP4a Datenflows wäre es aber mit Reverse Engineering vermutlich möglich, diese Gruppierungen rauszufinden. Wenn Nvidia XeSS nicht interessiert, Pech gehabt.

Das dürfte kaum möglich sein, DLSS ist qualitativ schon so weit fortgeschritten, dass hier keine großen Sprünge mehr drinnen sind.
Und falls XeSS kleinere Vorteile hat, wird es eher in Nvidias Interesse sein, bei DLSS selbst entsprechend nachzubessern, anstatt die Konkurrenztechnologie zu pushen.

Besser geht immer ;) Aber ich stimme zu, dass Nvidia am ehesten an DLSS weiterwerkelt und verbessert.

Ich stell mir eher die Frage ob es nicht sinnvoller wäre, dass die "DLSS-DLL" gar nicht mehr mit dem Spiel ausgeliefert wird sondern direkt in den Treiber integriert ist. Evtl. ist Streamline auch dafür vorbereitet.

Genau das hatte ich im Sinn.

Die Große Frage bei FSR2.0 sehe ich eher in der erreichbaren Qualität. Wie wir mittlerweile wissen setzt dies ja auf keinerlei ML, sondern herkömmliche Heuristiken, und zumindest bisher kann keine TAA Implementierung ohne NN dahinter nur ansatzweise mit DLSS mithalten.
Wenn FSR2.0 signifikant schlechtere Qualität als die anderen beiden bringt sehe ich eher kaum bis gar keine Daseinsberechtigung.
Wenn die Intel-Benchmarks zu XeSS vertrauenswürdig sind, dürfte der Performancenachteil von DP4a eher vernachlässigbar sein, und bei höherer Qualität immer den Vorzug gegenüber FSR2.0 bekommen.
AMD verliert damit gegenüber NV/Intel vielleicht 5-10%, zumindest in Bereichen <100FPS, wobei man ehrlicherweise sagen muss, so lange sie keine eigenen Matrixcores verbauen gibt es ja gar keine andere Möglichkeit. Das was FSR2.0 weniger an Leistung kostet wird es wohl auch an Qualität einsparen.

Insofern sehe ich mit XeSS einer Lösung die auf allen Karten läuft eher ein schweres Standbein für FSR2.0, das eigentlich nur eine Berechtigung hat falls XeSS nicht verfügbar ist (Steam Deck evtl.).

Diese "Intel-Benchmarks" sind PowerPoint Folien welche eher einen qualitativen denn quantitativen Charakter haben. Es geht ums darstellen des Prinzips und nicht der real erreichten Performance.

Wenn XeSS via DP4a wirklich auf allen Karten gut performt (sagen wir mal ähnlich zu FSR 2.0) dann entscheided die Qualität. Aber beide diese Faktoren sind momentan unbekannt, von XeSS wie auch FSR 2.0.

Wieso geht ihr eigentlich davon aus, dass die Rohleistung dieser Matrixeinheiten die dicht an den GPU ALUs sitzen auch wirklich voll ausgereizt wird durch DLSS und XeSS? :wink:

Wenn ich das hier ansehe ist das schon bei nem auf fp16 basierten DNN, welches neben Vectoreinheiten auch über Matrixeinheiten beschleunigt werden kann, nicht zwingend gesetzt:
78944

Offensichtlich gibt es da ja auch potenziell signifikante Bottlenecks, die durch andere Eigenschaften von RDNA2 erstaunlich gut abgefangen werden. (Evtl. der Cache?!)
Grade wenn man es Rohleistungsnormiert betrachtet und man bedenkt, dass schon die Navi21 Karte bei der Ausführung nicht wirklich voll ausgelastet wird. (gibt max. einige kurze Spikes auf ~150W bei ner TGP von 300W)
Das Problem, dass da in der Tabelle gelöst wird (Demosaicing) ist m.E. ja eh sehr ähnlich zu dem was das Clamping dieser Verfahren machen muss. (Auch wenn es nicht Echtzeitfähig sein muss)

Das ist ein guter Punkt. Da wir noch keine Benchmarks zur Verfügung haben, sind die Rohdatenwerte momentan einfach der verlässlichste Anhaltspunkt ;)

Darüber hinaus wird hier nur mit Leistungsangaben von TU102/GA102 GPUs um sich geworfen. DLSS ist selbst auf einer RTX 2060/3050 mobile noch lauffähig, bei deutlich geringerer Rohleistung. Intels XeSS soll sogar auf der Arc A350M lauffähig sein, welche nochmals nur ein Bruchteil der Tensorleistung liefert.
Was man hier beachten muss:

DLSS wird beschleunigt. Von Nvidia Karten --> Gute Performance
XeSS wird beschleunigt. Von Intel Karten --> Gute Performance
AMD/Nvidia Karten @ XeSS: Keine Matrix-Beschleunigug --> Weniger gute Performance (das Ausmass werden wir noch sehen)
Kleinere Karten laufen in niedrigeren Auflösungen, was ~linearen Zusammenhang mit der Ausführungszeit von DLSS, XeSS und FSR 2.0 hat. Ergo wird weniger Rohleistung benötigt. Eine 3050 verwendest du eher für 1080p anstatt 4K. Und schau mal: Die 3050 hat 80 Tensor Cores, eine 3090 hat 328 Tensor Cores. Macht einen Faktor von 4.1x. 4K zu 1080p sind was? 4.0x Pixel. Relativ zur Ausgabeauflösung haben beide Karten also sehr ähnliche Berechnungszeiten für DLSS.
Kleinere Karten liefern oftmals noch darüber hinaus geringere FPS. Da DLSS und Co. fixe Ausführungszeiten haben, hat das aufgrund der höheren Frametimes ein geringeres (relatives) Gewicht.

aufkrawall

2022-04-04, 19:50:35

Wenn XeSS via DP4a wirklich auf allen Karten gut performt (sagen wir mal ähnlich zu FSR 2.0)
Das ist wohl ziemlich unwahrscheinlich, wenn DLSS trotz FF-Hardware schon mehr Leistung kostet als TAAU.

Gast

2022-04-04, 21:36:03

Wenn DP4a Implementation Quelloffen ist und man DP4a via Tensor Cores laufen lassen kann, wieso sollte man das nicht umsetzen können.

Klar davon hängt es ab, wie gesagt, ist das nach der Intel Formulierung aber noch offen, aber natürlich auch nicht ausgeschlossen.

Besser geht immer ;) Aber ich stimme zu, dass Nvidia am ehesten an DLSS weiterwerkelt und verbessert.

Klar, die Schritte werden nur immer kleiner und Nvidia ist schon ziemlich weit.

Einzig bei noch höheren Upscalingfaktoren wie Ultra Performance gibt es noch ordentlich an Qualität zu holen.

Diese "Intel-Benchmarks" sind PowerPoint Folien welche eher einen qualitativen denn quantitativen Charakter haben. Es geht ums darstellen des Prinzips und nicht der real erreichten Performance.

Diese Benchmarks haben genau die Kosten von XeSS mit XMX und DP4a gezeigt, und auch wenn XMX das XeSS doppelt so schnell erledigt, ist DP4a mit <10% Renderzeit immer noch nicht zu verachten.

Wobei es bei höheren Frameraten natürlich relevanter wird, wenn man das Ganze nutzen will um z.B. 240FPS zu erreichen macht das natürlich schon einen Unterschied.
Wenn es aber "nur" darum geht spielbare 60FPS zu erreichen, dürfte DP4a weitaus schnell genug sein.

Wenn XeSS via DP4a wirklich auf allen Karten gut performt (sagen wir mal ähnlich zu FSR 2.0) dann entscheided die Qualität. Aber beide diese Faktoren sind momentan unbekannt, von XeSS wie auch FSR 2.0.

Meine Erwartung wäre eher, dass FSR 2.0 besser performt als DLSS und XeSS (egal ob mit oder ohne Matrixbeschleunigung), aber vor allem in Bewegung eine signifikant schlechtere Qualität zeigt.
Aber wie du sagst, über XeSS und FSR2.0 wissen wir noch nicht wirklich viel, vor allem qualitativ.

Rumbah

2022-04-04, 21:45:26

FSR hat immer noch den enormen Vorteil, dass es auf fast allen Karten und auf den Konsolen läuft (die PS5 kann kein DP4a). Damit auch auf dem Steam Deck und mit der Vulkan Version eventuell sogar auf der Switch.

Andron

2022-04-04, 21:48:39

DLSS wird beschleunigt. Von Nvidia Karten --> Gute Performance
XeSS wird beschleunigt. Von Intel Karten --> Gute Performance
AMD/Nvidia Karten @ XeSS: Keine Matrix-Beschleunigug --> Weniger gute Performance (das Ausmass werden wir noch sehen)
Kleinere Karten laufen in niedrigeren Auflösungen, was ~linearen Zusammenhang mit der Ausführungszeit von DLSS, XeSS und FSR 2.0 hat. Ergo wird weniger Rohleistung benötigt. Eine 3050 verwendest du eher für 1080p anstatt 4K. Und schau mal: Die 3050 hat 80 Tensor Cores, eine 3090 hat 328 Tensor Cores. Macht einen Faktor von 4.1x. 4K zu 1080p sind was? 4.0x Pixel. Relativ zur Ausgabeauflösung haben beide Karten also sehr ähnliche Berechnungszeiten für DLSS.
Kleinere Karten liefern oftmals noch darüber hinaus geringere FPS. Da DLSS und Co. fixe Ausführungszeiten haben, hat das aufgrund der höheren Frametimes ein geringeres (relatives) Gewicht.

Grundsätzlich alles richtig, allerdings hast du bei Punkt 4 eine wichtige Variable vergessen: Gerade moderne Spiele mit RTRT sind, was die Leistungsanforderungen angeht, extrem skalierbar.

Nehmen wir z.B. Cyberpunk: In Full HD ist eine RTX 3080 inkl. allen RT-Features exakt so schnell wie eine RTX 2060! ohne RT (46,7 zu 48,8 FPS avg.) Quelle (https://www.computerbase.de/2022-02/cyberpunk-2077-patch-1.5-benchmark/#abschnitt_raytracing_benoetigt_mehr_optimierung)

in WQHD und mittleren RT-Details sind es noch 39 FPS auf der 3080, welche man durch Reduzierung der Raster-Details in etwa auch auf der RTX 2060 erreicht. In beiden Fällen wäre DLSS aber exakt gleich teuer, da Auflösung und Bildrate identisch sind. Die RTX 2060 profitiert in WQHD und den genannten Bildraten trotzdem ähnlich viel von DLSS wie die deutlich schnellere RTX 3080 im CB-Test:

b4_P8rm-mkc

Wenn DLSS in den gängigen Auflösungen und Bildraten wirklich mit der Tensorleistung der großen Chips skalieren würde, dürfte die RTX 2060 in diesem Szenario eigentlich kein Land gegen die RTX 3080 sehen. Ab einem gewissen Punkt wird es sicherlich Unterschiede geben, die sind mMn. aber nicht so groß, wie von einigen angenommen.

DrFreaK666

2022-04-04, 22:42:17

Ich finde DLSS auch toll und XeSS spannend, aber könnte ihr darüber in den anderen Threads diskutieren?
Dachte echt dass es neue Infos zu FSR 2.0 gibt, dabei wird es hier nur am Rande erwähnt

Gast

2022-04-05, 00:05:11

Wenn DLSS in den gängigen Auflösungen und Bildraten wirklich mit der Tensorleistung der großen Chips skalieren würde, dürfte die RTX 2060 in diesem Szenario eigentlich kein Land gegen die RTX 3080 sehen. Ab einem gewissen Punkt wird es sicherlich Unterschiede geben, die sind mMn. aber nicht so groß, wie von einigen angenommen.

DLSS hat fixe Kosten pro Frame, je niedriger die Framerate desto mehr profitiert man deshalb von DLSS bzw. umso geringer fallen die Kosten von DLSS ins Gewicht.

Langsamere Grafikkarten profitieren deshalb generell mehr davon, einfach weil deren Grundframerate geringer ist.

basix

2022-04-05, 07:19:13

Das ist wohl ziemlich unwahrscheinlich, wenn DLSS trotz FF-Hardware schon mehr Leistung kostet als TAAU.

Bin derselben Meinung ;)

Andron

2022-04-05, 15:32:00

DLSS hat fixe Kosten pro Frame, je niedriger die Framerate desto mehr profitiert man deshalb von DLSS bzw. umso geringer fallen die Kosten von DLSS ins Gewicht.

Die Kosten für DLSS/XeSS/FSR(1.0/2.0) sind zwar fix pro Frame auf gleicher Hardware, aber umso teurer je langsamer die verwendete Hardware ist.

Bei FSR und XeSS im DP4A Modus bedeutet das, dass die zusätzliche Berechnungszeit immer on Top kommt und sich die Framerate somit verringert. Je aufwendiger das Verfahren, desto geringer sind die Performancevorteile durch die Reduzierung der Grundauflösung.

DLSS und (vermutlich auch XMX beschleunigtes XeSS) können allerdings in Teilen parallel ausgeführt werden. Solange die Tensor-Leistung im Überschuss vorhanden ist und keinen limitierenden Faktor darstellt, unterscheiden sich in diesem Fall die Frametime-Kosten kaum zwischen einer 3050/2060 und einer 3090Ti. Genau das zeigt sich in einigen Beispielen, in denen beide Leistungsklassen bei gleicher Auflösung und ähnlicher Ausgangs-Bildrate ähnlich stark profitieren, FSR 2.0 wahrscheinlich nicht der Fall sein wird. Bei sehr hohen Frameraten wird sich auch bei DLSS zusätzliche Tensorleistung bemerkbar machen, in dem Cyberpunk-Beispiel allerdings noch nicht sehr stark.

Langsamere Grafikkarten profitieren deshalb generell mehr davon, einfach weil deren Grundframerate geringer ist.

Das ist in vielen Fällen sicherlich richtig, bei modernen Spielen inkl. RTRT aber nicht mehr die Regel. Spiele wie Cyberpunk oder Control können über die Grafikeinstellungen problemlos eine 3090Ti und eine RTX2060 auf ein ähnliches FPS-Niveau bei gleicher Auflösung bringen. In diesen Fällen würde die langsamere Karte deutlich weniger profitieren, wenn DLSS linear mit der Rohleitung skalieren würde.

basix

2022-04-05, 16:15:01

DLSS und (vermutlich auch XMX beschleunigtes XeSS) können allerdings in Teilen parallel ausgeführt werden. Solange die Tensor-Leistung im Überschuss vorhanden ist und keinen limitierenden Faktor darstellt, unterscheiden sich in diesem Fall die Frametime-Kosten kaum zwischen einer 3050/2060 und einer 3090Ti. Genau das zeigt sich in einigen Beispielen, in denen beide Leistungsklassen bei gleicher Auflösung und ähnlicher Ausgangs-Bildrate ähnlich stark profitieren, FSR 2.0 wahrscheinlich nicht der Fall sein wird.

FSR 2.0 kann auch parallel ausgeführt werden, nämlich via Async Compute. Das haben die Entwickler bei der GDC Präsentation gezeigt. Die ALUs sind selten 100% occupied und wenn man es mit was in der Grafik-Pipeline zusammenlegt, was neben dem FSR Async Compute ohne Limitiationen vorbei geht (auch das wurde im GDC Talk angesprochen) ist die Rechenlast von FSR 2.0 in dieser Hinsicht fast kostenlos stemmbar. Um das Post Processing in höherer Auflösung kommt man aber nicht herum.

Ich nehme an, dass sich das bei paralleler DLSS / XeSS Ausführung in den Matrix Beschleunigern ähnlich verhalten kann.

Gast

2022-04-05, 17:24:39

FSR 2.0 kann auch parallel ausgeführt werden, nämlich via Async Compute.

Async Compute bringt keine zusätzlichen Ressourcen, Async Compute kann lediglich Stalls in der Renderpipeline ausnutzen. Idealerweise gibt es diese Stalls aber gar nicht, weil genügend Threads vorhanden sind um diese zu füllen.

Tensorcores bei Nvidia bzw. die XMX Cores sind aber zusätzliche Ressourcen, die ohne DLSS kaum oder gar nicht verwendet werden (NVidia verwendet sie für auch generelle FP16 Berechnung, möglicherweise sieht es bei Intel ähnlich aus) und daher quasi immer zur Verfügung stehen.

Andron

2022-04-05, 20:19:39

FSR 2.0 kann auch parallel ausgeführt werden, nämlich via Async Compute.

Das stimmt zwar, ist aber auch eher für die größeren GPUs relevant. Gerade die kleinen GPUs mit wenigen ALUs können meist besser ausgelastet werden und Async Compute hat einen geringeren Einfluss. Außerdem wird auf RDNA 2 DXR afaik per Async Compute beschleunigt und je nach Engine/Spiel auch noch andere Effekte. Ab einem gewissen Punkt sind die ALUs ausgelastet und weitere Parallelisierung bringt nicht mehr viel. Die Performancevorteile dürften also von Fall zu Fall variieren.

Async Compute bringt keine zusätzlichen Ressourcen, Async Compute kann lediglich Stalls in der Renderpipeline ausnutzen. Idealerweise gibt es diese Stalls aber gar nicht, weil genügend Threads vorhanden sind um diese zu füllen.

Letzteres ist aber ein kaum erreichbarer Idealzustand. Gerade Ampere zeigt, wie schlecht die Verdopplung der FP32 Einheiten skaliert und wie schwierig es ist, diese in Spielen auszulasten.

RDNA 2 profitiert z.B. sehr stark von Async Compute, in Halo Infinite sind es bis zu 15% Leistungsplus. Da könnte FSR 2.0 schon sehr von profitieren, gerade auf den dicken GPUs.

Tensorcores bei Nvidia bzw. die XMX Cores sind aber zusätzliche Ressourcen, die ohne DLSS kaum oder gar nicht verwendet werden (NVidia verwendet sie für auch generelle FP16 Berechnung, möglicherweise sieht es bei Intel ähnlich aus) und daher quasi immer zur Verfügung stehen.

Trotzdem teilen sich auch die Tensor-/XMXcores Ressourcen mit den restlichen Einheiten, welche dann eben an anderer Stelle fehlen können. Wenn Speicherbandbreite oder Caches knapp werden, kosten die zusätzlichen Berechnungen unter Umständen Leistung an anderer Stelle. Im Beispiel in Post #2003 von Savay sieht man ja auch ganz schön, dass die theoretische Leistung (je nach Anwendung) nicht viel aussagt.

Gast

2022-04-05, 22:07:47

Letzteres ist aber ein kaum erreichbarer Idealzustand. Gerade Ampere zeigt, wie schlecht die Verdopplung der FP32 Einheiten skaliert und wie schwierig es ist, diese in Spielen auszulasten.

Das hat nicht das geringste mit der Auslastung zu tun, sondern dass die 2. Hälfte FP32 INT auch noch stemmen muss. Ampere performt genau so wie man es erwarten würde und nicht nur blind auf die reine FP-Leistung schaut.
Die Auslastung dürfte kaum bis gar nicht hinter Turing liegen.

RDNA 2 profitiert z.B. sehr stark von Async Compute, in Halo Infinite sind es bis zu 15% Leistungsplus.

Jap, AMD Architekturen sind traditionell eher schlecht ausgelastet und profitieren deshalb von Async Compute ziemlich stark. Wobei es mit RDNA deutlich besser wurde, GCN war noch deutlich schlechter ausgelastet und hat dementsprechen noch mehr von Async Compute profitiert.

Trotzdem teilen sich auch die Tensor-/XMXcores Ressourcen mit den restlichen Einheiten, welche dann eben an anderer Stelle fehlen können. Wenn Speicherbandbreite oder Caches knapp werden, kosten die zusätzlichen Berechnungen unter Umständen Leistung an anderer Stelle.

Grundsätzlich ja aber die Bandbreite und Caches sind logischerweise so dimensioniert um auch die Tensorcores parallel füttern zu können.

Das Limit sind in aller Regel die Scheduler, und dagegen hilft Async Compute nichts, weil auch die asynchronen Befehle logischerweise in die Pipeline scheduled werden müssen.

Der einzige Vorteil von Async Compute ist, dass die Befehle jederzeit abgearbeitet werden können, während in der Grafikpipeline zeitliche Abhängigkeiten bestehen.

Im Prinzip machst du nichts anderes, als einzelne Threads als unabhängig zu markieren, und die Hardware kann sie dann jederzeit ausführen.

nalye

2022-04-06, 08:36:35

Ich finde DLSS auch toll und XeSS spannend, aber könnte ihr darüber in den anderen Threads diskutieren?
Dachte echt dass es neue Infos zu FSR 2.0 gibt, dabei wird es hier nur am Rande erwähnt
Daran halten wir uns jetzt, kthxbye.

robbitop

2022-04-07, 08:08:52

Das hat nicht das geringste mit der Auslastung zu tun, sondern dass die 2. Hälfte FP32 INT auch noch stemmen muss. Ampere performt genau so wie man es erwarten würde und nicht nur blind auf die reine FP-Leistung schaut.
Die Auslastung dürfte kaum bis gar nicht hinter Turing liegen.

IIRC hatte das nicht nur mit den INTs zu tun. Die Breite der Schedulers und die Register sind bei Ampere trotz gleicher FP Anzahl pro SM nur halb so viel wie Pascal. Hier mal ein paar Untersuchungen von mksn7 vor einer Weile dazu:

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.

Wir hatten mal eine Diskussion, warum Ampere keine 100% zulegt in Spielen, trotz der verdoppelten FP32 Einheiten. Die Diskussion hatten wir im RDNA3 thread, aber weil das dort eigentlich fehl am Platz war verlager ich das mal hier her.

Wir waren uns (fast) alle einig, dass reiner FP32 Durchsatz schlicht und einfach meistens nicht der limiter ist, und dass es genug andere Flaschenhälse gibt.

Gipsel hatte damals eine Vermutung angestellt:

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]).

Dazu hab ich mittlerweile ein paar interessante Daten dazu. Wir haben hier im Rechenzentrum mit 3-4 Monaten Verspätung ein paar neue nodes mit RTX 3080 bekommen. Um zu testen, ob es mit 8 Stück davon in einem Node mit Temperatur und Throttling Probleme gibt, hab ich einen Code geschrieben, der maximal Strom verbrauchen und maximalen FP32 Durchsatz (ist nicht unbedingt das Gleiche) haben soll. Mit meinem bisherigen Code, der bei Turing und Volta gut funktioniert hat:

for (int i = 0; i < N; i++) {
v = v * a - b;
}

(N ist groß und zur Compilezeit bekannt, wird komplett geunrolled vom Compiler)

hab ich nur 15.6 TFlop/s erreicht, also etwa die Hälfte des möglichen (Ppeak). Das gleiche haben wir mit CUBLAS SGEMM (ohne TC) gemessen.
Das Problem an dem Code ist, dass er eine lange Abhängigkeitskette auf v erzeugt, so dass es innerhalb eines threads keine zwei unabhängigen Instruktionen gibt die gleichzeitig ausgeführt werden können (Anscheinend müssen die beiden Befehle die der scheduler nacheinander issuen kann aus dem gleichen thread kommen)
Also hab ich zwei Summen draus gemacht:

for (int i = 0; i < N; i++) {
v = v * a - b;
v2 = v2 * a2 - b2;
}

So dass es immer zwei unabhängige Befehle gibt. Das hat den Durchsatz auf 20.6 TFlop/s gesteigert, oder fast genau 2/3 Ppeak.

Der code erzeugt folgenden Assambler:

FFMA R17, R10, R17, -R8 ;
FFMA R16, R11, R16, -R9 ;

mit drei Quellregistern. Weil das doch sehr nach einer Registerbandbreitenlimitierung riecht, wie Gipsel vermutet hat, hab ich den Code nochmal geändert und das b weggelassen:

for (int i = 0; i < N; i++) {
v = v * a - a;
v2 = v2 * a2 - a2;
}

Das erzeugt dann

FFMA R14, R8, R14, -R8 ;
FFMA R9, R7, R9, -R7 ;

mit nur zwei Quellregistern. Und, siehe da, damit hab ich dann 29.7 TFlop/s oder 93% Ppeak erreicht. Damit von den zusätzlichen FP32 Einheiten was dabei rumkommt, muss also sowohl genug ILP, also parallel ausführbare Befehle innerhalb eines threads vorhanden sein, und diese Befehle dürfen nur begrenzt viele Register verwenden. Ersteres wird sicherlich öfter mal vorkommen, zweiteres ist schon spezieller. Für FADD oder FMUL ist das aber kein Problem.

TL; DR: NVIDIAS groß angepriesene zusätzliche FP32 Einheit kann nur in speziellen Fällen wirklich genutzt werden.

Gast

2022-04-07, 08:36:54

Als er dann die Berechnung umgestellt hat, dass es weniger Register brauchte sprang die Auslastung bei Ampere deutlich hoch.

Das ist klar, die Register sind die selben wie bei Turing.

Pascal hat 16k Register für 32 Threads.
Turing 16k Register für 32 Threads (16INT + 16FP + 32FP16)
Ampere ebenfalls 16k Threads für 32Threads (16INT/FP + 16FP + 32FP16)

Es gibt hier also keinen Fortschritt, aber auch keinen Rückschritt.
Wenn der Register Preasure zu hoch ist um ausreichend Threads in Flight zu halten sinkt logischerweise die Auslastung.

Der einzige "Vorteil" von Turing ist, nur dass man in der Regel gar nicht genug Threads für INT zur Verfügung hat, die dann natürlich auch weniger Register konsumieren. Fehlende INTs führen bei Turing aber immer zu schlechter Auslastung, mit FP32 alleine kann man bei Turing gar nicht über 50% kommen.

Ampere ist da viel flexibler, ausreichend Register vorausgesetzt, kann Ampere immer auf volle Auslastung kommen, wenn der FP32-Anteil zwischen 50 und 100% liegt.
Turing kann nie auf volle Auslastung kommen wenn der FP32-Anteil >50% ist.

Alternativ können beide auch mit 50% INT32 und 50% FP16 auch volle Auslastung kommen (wobei FP16 doppelt so viele Threads pro Takt verarbeiten kann).

Es gibt in jedem Fall viel mehr Situationen in denen ein Ampere SM voll ausgelastet werden kann, als ein Turing SM, insbesondere bei hohem FP32 Anteil hat ein Turing SM immer viel Leerlauf.

robbitop

2022-04-08, 06:34:53

Gast

2022-04-08, 12:26:50

Nicht nur Register. Pascal hat auch doppelt so dicke sheduler pro SM. 4x double issue vs 4x single bei Ampere. Pascal schafft es die 128x fps pro scheduler viel einfacher und öfter auszulasten als Ampere. Ich vergleiche Pascal mit Ampere weil beide gleich viele fp Ausführungsresourcen haben.

https://imgur.com/a/znx4XFO

Der Gundblock unterscheidet sich hier nicht so großartig.
In allen Fällen können max. 32Threads/Clock hinein bzw. 32Threads/clock wieder raus.
Diese 32 Threads haben in allen 3 Architekturen die gleiche Registergröße zur Verfügung.

Den einzigen "Vorteil" den Turing hier hat, ist dass der INT Part meist unterbeschäftigt ist und damit natürlich weniger Ressourcen braucht, womit relativ gesehen mehr Ressourcen für den FP Part vorhanden sind.
Ich sehe das aber nicht als Vorteil, sondern als Nachteil, weil der INT Part für den praktischen Einsatz ganz einfach überdimensioniert ist und damit brach liegt und nur mit FP32 die 32 Threads/clock gar nicht ausgenutzt werden können.

Pascal hat gegenüber den Nachfolgearchitekturen noch den Vorteil der 2. dispatch unit, mit der man Threads aus unterschiedlichen Warps gleichzeitig issuen kann. Das ist aber nur relevant wenn es in einem Thread keine 2 unabhängigen Befehle gibt.

PS: Wenn ich von Auslastung spreche, dann mein ich immer wieviele Befehle/clock retired werden können. Fast alle Architekturen, egal ob CPU oder GPU, haben deutlich mehr ALUs als Befehle im Frontent reinkommen bzw. übers Backend wieder die ALU Stage verlassen können, von daher macht es kaum Sinn bei der Auslastung von den ALUs zu sprechen, da die prinzipbedingt gar nie voll ausgelastet werden können.
Volle Auslastung ist also erreicht wenn 32threads/clock durch die Pipeline gehen können, und dass ist bei Ampere deutlich öfter der Fall als beispielsweise bei Turing.

robbitop

2022-04-09, 11:21:34

Die Messungen von mksn7 haben jedenfalls gezeigt, dass man schon auf ein paar Sachen achten muss bei Ampere um die 128 FPs/SM auf die Straße zu bringen und bei Pascal ging es in allen Lebenslagen. Ich kann mir gut vorstellen, dass das bei Spielen schonmal ähnlich der Fall sein kann und es würde mich auch nicht überraschen, wenn die Lovelace SMs entsprechend nachgerüstet werden.

Gast

2022-04-09, 15:31:02

Die Messungen von mksn7 haben jedenfalls gezeigt, dass man schon auf ein paar Sachen achten muss bei Ampere um die 128 fps auf die Straße zu bringen und bei Pascal ging es in allen Lebenslagen.

Auch bei Pascal bekommst du die nicht in allen Lebenslagen auf die Straße, die Registerlimitierungen sind genau die selben. Die 2. Dispatch Unit kann in sehr speziellen Fällen (wie hier gezeigt) was bringen.
Bei Turing bekommst du mit reinem FP32 praktisch immer den vollen Durchsatz, aber dann auch nur 16Threads/Clock anstatt 32, im gesamten also deutlich weniger.

https://i.imgur.com/to4Fbqu.png

Ich kann mir gut vorstellen, dass das bei Spielen schonmal ähnlich der Fall sein kann und es würde mich auch nicht überraschen, wenn die Lovelace SMs entsprechend nachgerüstet werden.

Ich geh mal davon aus, dass das Register-File für Lovelace vergrößert wird um hier die Abhängigkeit etwas zu verringern.

DrFreaK666

2022-04-09, 16:20:27

Juckt keine Sau, dass ein Mod gesagt hat, man solle beim Thema bleiben...
:rolleyes:

Klärt das per pm oder macht einen Thread auf!

mksn7

2022-04-11, 21:15:38

Um die Kurve vielleicht ein klein wenig zurück zu bekommen:

Ich wollte schon länger mal was zu dem oft genannten Konzept schreiben, dass DLSS ja auf den TC's läuft, und daher quasi umsonst neben dem normalen Rendering laufen kann. Weswegen DLSS mit TC performance mäßig gegenüber FSR überlegen sei, was ja auf den Shadern läuft. (On-Topic genug, oder?)

Das klingt immer so als wären die TC's seperate Einheiten neben dem SMs auf dem Chip, die irgendwas für sich alleine ausführen können. DLSS läuft nicht "auf den TCs". Stattdessen läuft DLSS auch nur als normales Shaderprogram auf den SMs. Das besteht aus jede Menge Instruktionen, von denen eben manche auf den TCs ausgeführt werden.

Das Shaderprogram belegt aber trotzdem SM Ressourcen, insbesondere Register, Cache Kapazität, Bandbreite, und auch Vektorinstruktionseinheiten und issue slots. Ein anderes Shaderprogram läuft also nicht einfach unbeeinträchtigt nebenher.

Das andere Shaderprogram wird lediglich etwas seltener "execution unit busy" oder "not selected" als stall reason haben, weil das DLSS shader program vielleicht (wir haben ja alle keine Ahnung wieviel DLSS wirklich rechnet) nicht ganz so oft auf den normalen units issued. Für den Großteil aller Shaderprogramme dürfte aber "long scoreboard" (warten auf eine load/store operation) als stall reason überwiegen. Und das behebt man nur mit mehr warps auf der SM, was aber eine ressource ist die auch von den DLSS warps belegt wird.

Es gibt also bei weitem keine kostenlose coexecution, nur weil DLSS die TCs nutzt.

TheAntitheist

2022-04-11, 22:26:16

Um die Kurve vielleicht ein klein wenig zurück zu bekommen:

Ich wollte schon länger mal was zu dem oft genannten Konzept schreiben, dass DLSS ja auf den TC's läuft, und daher quasi umsonst neben dem normalen Rendering laufen kann. Weswegen DLSS mit TC performance mäßig gegenüber FSR überlegen sei, was ja auf den Shadern läuft. (On-Topic genug, oder?)

Das klingt immer so als wären die TC's seperate Einheiten neben dem SMs auf dem Chip, die irgendwas für sich alleine ausführen können. DLSS läuft nicht "auf den TCs". Stattdessen läuft DLSS auch nur als normales Shaderprogram auf den SMs. Das besteht aus jede Menge Instruktionen, von denen eben manche auf den TCs ausgeführt werden.

Das Shaderprogram belegt aber trotzdem SM Ressourcen, insbesondere Register, Cache Kapazität, Bandbreite, und auch Vektorinstruktionseinheiten und issue slots. Ein anderes Shaderprogram läuft also nicht einfach unbeeinträchtigt nebenher.

Das andere Shaderprogram wird lediglich etwas seltener "execution unit busy" oder "not selected" als stall reason haben, weil das DLSS shader program vielleicht (wir haben ja alle keine Ahnung wieviel DLSS wirklich rechnet) nicht ganz so oft auf den normalen units issued. Für den Großteil aller Shaderprogramme dürfte aber "long scoreboard" (warten auf eine load/store operation) als stall reason überwiegen. Und das behebt man nur mit mehr warps auf der SM, was aber eine ressource ist die auch von den DLSS warps belegt wird.
niemand behauptet desweieteren das die TCs umsonst arbeiten, wir können doch ganz einfach die kosten ermitteln und dies wurde auch schon getan.

Es gibt also bei weitem keine kostenlose coexecution, nur weil DLSS die TCs nutzt.
Whitepaper bitte, denn das widerspricht ja allem was wir wissen. In jedem Blockdiagramm werden sie extra neben den FPs und INTs gezeigt...
und niemand sagt sie sind neben den SMs, sie sind ein TEIL davon...

Savay

2022-04-11, 22:43:38

Whitepaper bitte

Häh!?
Schaust du eigentlich einfach nur zwei Beiträge oben drüber... :tongue:

Gast

2022-04-12, 10:27:23

Integration von FSR 2.0 in Deathloop
https://youtu.be/Vn4Q4XeMyBk?t=2440

Das ist jetzt der neueste Stand:
Im Prinzip geht es darum die rechenaufwendigen Ausgangsdaten (Pre-upscale post-processing) möglichst schnell zu löschen bzw. zu verkleinern und die Pipeline mit weniger komplexen Daten in dem Output Buffer zu füllen. Dann wird TAA inkl. Schärfefilter ersetzt.
Am Ende, also nach FSR 2.0 im Post-upsclae post-processing werde teilweise Daten gelöscht bzw. zerstört, um die Verarbeitung sehr schlank zu halten. Dafür muss geprüft werden ob die Daten auch noch zu gebrauchen sind.

Das ist sozusagen eine registrierte Sprungvorhersage in der rendering Pipeline mit dem Ende der Frame n+2

Die Bewegungsvektoren werden ab Vega uArch mit der doppelten Geschwindigkeit berechnet fp16.

Die Farb-Qualität der erzeugten Bilder bleibt sehr hoch, weil die Farbechtheit inkl. HDR 10/11bit: R11G11B10_FLOAT von den vorhergegangenen multipliziert wird.

Unter der Prämisse, dass AMD zuerst HDR-Rendering in schneller hoher Präzision aka fp16 (rapid packed math) seit 2016 eingeführt hat, ist bei FSR 2.0 eine höhere Imagequalität, insbesondere bei den Farben als bei DLSS 2.0 zu erwarten.

mksn7

2022-04-12, 11:01:41

Whitepaper bitte, denn das widerspricht ja allem was wir wissen. In jedem Blockdiagramm werden sie extra neben den FPs und INTs gezeigt...
und niemand sagt sie sind neben den SMs, sie sind ein TEIL davon...

Die Ausführungseinheiten selbst sind auch tatsächlich separat.

Aber INT, FP oder Tensor Einheiten führen keine Programme aus. Das macht die ganze Maschinerie um die Recheneinheiten außen rum, zusammen mit den Recheinheiten.

Ein Programm, das unter anderem auch Tensor Instruktionen verwendet, teilt sich die ganzen anderen Instruktionen trotzdem noch mit Programmen die keine Tensor Instruktionen verwendet.

Ich weiß wirklich nicht was DLSS tatsächlich rechnet. Wenn es sehr große, quadratische Matrizzen sind, könnte viel Zeit in den HMMA Instruktionen stecken. Wenn ich das richtig sehe, ist der TC in einem Scheduler bei Ampere mit einer HMMA.1688 Instruktion 4 Takte beschäftigt. Dann wären 3 von 4 issue slots noch frei. Das würde aber sehr viele Register belegen, so dass nicht mehr viel Platz für was anderes auf der SM wäre.

Wenn aber viele kleine, oder langgezogene Matrixmultiplikationen berechnet werden, braucht es gleich ein Handvoll Instruktionen (Addressberechnung + Load) für das Laden oder Berechnen der Inputs für die TC Instruktionen. Dann sind keine Issueslots mehr frei, wenn die TC voll ausgelastet werden sollen.

Ich behaupte ja nicht dass es keinen speedup gäbe, wenn auf der gleichen SM ein anderes shader program noch in parallel läuft, dass hier und da die vector units nutzen kann, die von dem TC-lastigen Program nicht so stark verwendet werden. Aber das ist eher in der Größenordnung was man sonst so von Async Compute kennt.

Lurtz

2022-04-19, 13:34:54

Ist bekannt wann das "Embargo" für erste Spiele mit FSR 2.0 fällt?

Raff

2022-04-19, 13:36:13

Es gibt keinen Termin abseits von "Q2", also auch kein Embargo. Wenn am 10. Mai die neuen Radöner erscheinen, wäre das ein naheliegendes Coverage-Zeitfenster.

MfG
Raff

Lurtz

2022-04-22, 09:15:59

AMD hat für Deathloop jetzt auch 1440p und 1080p als Zielauflösung bereitgestellt:
https://gpuopen.com/fidelityfx-superresolution-2/

Redneck

2022-04-22, 11:35:29

AMD hat für Deathloop jetzt auch 1440p und 1080p als Zielauflösung bereitgestellt:
https://gpuopen.com/fidelityfx-superresolution-2/

hab mir mal das 300mb package heruntergeladen und teilweise verglichen..
meine Fresse sieht das gut aus.. selbst in Balanced .. auch in Performance.
Sieht ganz leicht weichgezeichneter aus (wahrscheinlich aufgrund das hinzugefügten AA, welches beim nativen Standbild evtl nicht vorhanden ist ? )

Gratzner

2022-04-22, 12:13:10

AMD hat für Deathloop jetzt auch 1440p und 1080p als Zielauflösung bereitgestellt:
https://gpuopen.com/fidelityfx-superresolution-2/
Habe mal Vergleichsbilder mit Schieberegler auf imgsli daraus erstellt:

1. Szene
Output Resolution 1080p (https://imgsli.com/MTA1MTky)
Output Resolution 1440p (https://imgsli.com/MTA1MTk0)
Output Resolution 2160p (https://imgsli.com/MTA1MTk2)

2. Szene
Output Resolution 1080p (https://imgsli.com/MTA1MTkz)
Output Resolution 1440p (https://imgsli.com/MTA1MTk1)
Output Resolution 2160p (https://imgsli.com/MTA1MTk3)

Hier mal ein Vergleich von [1080p nativ] vs. [1440p Quality (= 960p input)] vs. [4k performance (= 1080p input)]:
1. Szene (https://imgsli.com/MTA1MTk4)
2. Szene (https://imgsli.com/MTA1MTk5)

Edit:
Imgsli hat einen schlechten downscaler. Wer bspw. auf ein 1440p Monitor 4k Screenshots anschaut, wird starke Bildqualitätsverbesserungen durch Heranzoomen feststellen

Edit2: Hier mal noch eine Bemerkung von AMD bezüglich niedriger inputresolutions
Please note: At low resolutions (under 720p), DEATHLOOP can sometimes not render certain small objects at far distances, such as the light bulbs shown in the 1080p comparison images. When targeting 1080p output, the FSR 2.0 internal render resolution is 1280 x 720 or below, which results in the missing objects shown here — this issue is therefore not related to FSR 2.0.

robbitop

2022-04-22, 12:13:34

Die Crux wird Bewegung sein. Statisch und mit wenig Bewegung ist es deutlich einfacher artefaktarm viele nutzbare Samples zu akkumulieren. DF zeigte das mit TSR in einem Video was neulich kam. Mit wenig Bewegung und statisch sah es super aus. Mit Bewegung wurde es dann schlechter und DLSS lag deutlich vorn.
https://youtu.be/FbFMafKzJyY?t=392

Auch Transparenz und Partikeleffekte hatten bei TSR deutliche Schwächen. Da FSR 2.0 und TSR sehr ähnlich funktionieren, kann es sein, dass das Ergebnis bzw die Charakteristik der Stärken/Schwächen ähnlich ist. Auf die müsste man zumindest bei der Bewertung achten.
Bin gespannt auf die erste Analyse von DF sobald FSR 2.0 nutzbar ist.

vinacis_vivids

2022-04-22, 13:12:41

Gibs doch schon in Bewegung...

oKD98lTqilQ

... und ist ziemlich geil :biggrin:

Die Präzision bei der Berechnung ist mit hauptsächlich echten fp16 ohnehin höher als DLSS, welches int8 reinmischt.

robbitop

2022-04-22, 13:41:14

Aber ohne Analyse und mit youtube Komprimierung und mit recht starrer langsamer vorhersehbarer Bewegung. Da kann man leider gar nichts draus entnehmen.

basix

2022-04-22, 13:58:01

Habe mal Vergleichsbilder mit Schieberegler auf imgsli daraus erstellt:

1. Szene
Output Resolution 1080p (https://imgsli.com/MTA1MTky)
Output Resolution 1440p (https://imgsli.com/MTA1MTk0)
Output Resolution 2160p (https://imgsli.com/MTA1MTk2)

2. Szene
Output Resolution 1080p (https://imgsli.com/MTA1MTkz)
Output Resolution 1440p (https://imgsli.com/MTA1MTk1)
Output Resolution 2160p (https://imgsli.com/MTA1MTk3)

Hier mal ein Vergleich von [1080p nativ] vs. [1440p Quality (= 960p input)] vs. [4k performance (= 1080p input)]:
1. Szene (https://imgsli.com/MTA1MTk4)
2. Szene (https://imgsli.com/MTA1MTk5)

Edit:
Imgsli hat einen schlechten downscaler. Wer bspw. auf ein 1440p Monitor 4k Screenshots anschaut, wird starke Bildqualitätsverbesserungen durch Heranzoomen feststellen

Was ich nicht verstehe: Hier nehmen die Schattendetails mit FSR 2.0 ab. Die Screenshots aus anderen Präsentationen wie bei der GDC zeigen das nicht, selbst bei Ultra Performance (ab Seite 65):
https://gpuopen.com/gdc-presentations/2022/GDC_A_Guided_Tour_Of_Blackreef.pdf

Auch hier ist diese Degradation nicht zu beobachten:
https://community.amd.com/t5/gaming/amd-fidelityfx-super-resolution-2-0-updated-deathloop-preview/ba-p/521756

Tobalt

2022-04-22, 14:31:40

1. Szene
Output Resolution 1080p (https://imgsli.com/MTA1MTky)

Zuerst dachte ich dass es super aussieht.

Dann sind mir über dem linken Dach die Buchstaben auf dem entfernten Dach aufgefallen.

OMG! Das ist ja die absolute Sharpening-Artefakt-Hölle. Führte bei mir direkt zum Ragequit.

@AMD: Bitte das absurde hässliche Sharpening abstellen. Dann ist die Lösung doch ganz supi.

Gratzner

2022-04-22, 15:04:31

Was ich nicht verstehe: Hier nehmen die Schattendetails mit FSR 2.0 ab. Die Screenshots aus anderen Präsentationen wie bei der GDC zeigen das nicht, selbst bei Ultra Performance (ab Seite 65):
https://gpuopen.com/gdc-presentations/2022/GDC_A_Guided_Tour_Of_Blackreef.pdf

Auch hier ist diese Degradation nicht zu beobachten:
https://community.amd.com/t5/gaming/amd-fidelityfx-super-resolution-2-0-updated-deathloop-preview/ba-p/521756

Also ich habe in den von dir zitierten Beitrag, die Bilder von der AMD-Website gedownloadet.
---

Die RT-Schattendetails in den von dir Verlinkten Quellen nehmen sehr wohl ab. Hier ein Vergleich von 2 Bildern aus der Community-Website:
https://imgsli.com/MTA1MjEy

Hier ein Vergleich nach der Quelle. Beide Bilder haben FSR2 Performance. Einmal stammt das Bild von der Community-Website und das zweite mal das Bild von AMDs Website:
https://imgsli.com/MTA1MjEz
-> Imho sind die Bilder identisch abseits des Ausschnittes und der Schriftzüge

Man darf nicht vergessen, bei so ein Schieberregler-Vergleich von Standbildern, wo man auch noch ranzoomen kann, ist der krasseste Vergleich, den man so machen kann. Da werden selbst kleinste Unterschiede stark verstärkt und sichtbar. Hat nur wenig damit zu tun, wie man die Unterschiede in einem Spiel wahrnehmen wird. Merkt man ja schon, wenn man die Standbilder nebeneinander stellt, werden Unterschiede weitaus schwieriger zu erkennen. Das wird wahrscheinlich das Problem sein.
---

[In der Pdf sind die Bilder kompromiert und damit nicht so aussagekräftig, weshalb ich aus Deinem unteren Link folgendes Bild aus AMD Community Seite für den Schieberegler-Vergleich genommen habe: https://community.amd.com/t5/gaming/amd-fidelityfx-super-resolution-2-0-updated-deathloop-preview/ba-p/521756?lightbox-message-images-521756=66865i67126253C876C099 , natürlich habe ich es in voller 4k-Auflösung gedownloadet und nicht das Vorschaubild heruntergeladen]

basix

2022-04-22, 15:18:57

Die vorhin angegebenen Screenshots waren doch nicht die, die ich noch in Erinnerung hatte.

Ich hatte bei mir lokal noch die alten Deathloop Screenshots vorhanden. Die waren an der selben Stelle auf der FSR 2.0 Entry Page verlinkt wie die neuen. Das sieht deutlich anders aus bei den Schatten. Da kannst du reinzoomen wie du willst, der visuelle Eindruck ist sehr ähnlich (einzig die Bildschärfe nimmt mit abnehmender Renderauflösung auch ab). Auch generell scheint die Qualität des Upsamplings etwas besser zu sein.
https://imgsli.com/MTA1MjE0
https://imgsli.com/MTA1MjE1

Das ist das, was ich nicht verstehe. Anhand der alten Screenshots sah es so aus, als hätte AMD oder Arkane Lyon das Schatten-Problem irgendwie gefixt. Die neuen zeigen aber wieder die selbe Abnahme der Qualität.

Gratzner

2022-04-22, 15:27:28

Achso, Du hattest das mit den alten Bildern verglichen, ich habe sie neu gedownloadet.

Hast natürlich recht, auf den Alten Bildern (von dir verlinkt und wahrscheinlich in der gpu-open pdf), ist der Verlust der Schattenqualität zwischen FSR-Stufen weitaus weniger gering, als auf den neuen Screenshots (von der AMD-Website und der Community-Website)

basix

2022-04-22, 15:34:59

Raff

2022-04-22, 15:36:01

Die Präzision bei der Berechnung ist mit hauptsächlich echten fp16 ohnehin höher als DLSS, welches int8 reinmischt.

Alter ... langsam wird's richtig kurios.

MfG
Raff

Gratzner

2022-04-22, 15:53:50

Hmm, evtl. ist bei den alten Screenshots RT deaktiviert. Das wird vermutlich der Grund für diesen Unterschied sein. Sieh dir die Schatten an den Wänden und am Boden in der linken Bildhälfte an. Da ist bereits nativ zwischen alt/neu ein grosser Unterschied vorhanden.
Shadow Maps / Cube Maps können so wie es "verlustfrei" upsampled werden, was bei RT Effekten anscheinend (noch) nicht geht.

Edit:
Dafür sind diese einzelnen schwarzen Pixel auf den Steintexturen bei den neuen Screenshots verschwunden ;)

Hier können mal die alten mit den neuen Screenshots verglichen werden:
Part 1, jeweils 4k sowie nativ und perf:
https://imgsli.com/MTA1MjE3/0/2
Part 2, jeweils 4k sowie quality und balanced:
https://imgsli.com/MTA1MjE4/0/2

Die Schatten haben sich eindeutig verändert. Ich bin mir absolut sicher, das bei den alten Screenshots hieß, die seien mit Raytracing Schatten.

Edit: Hier mal das AMD-Deathloop Video von damals. Da steht ebenfalls "with RT". https://www.youtube.com/watch?v=oKD98lTqilQ
Kann natürlich sein, dass RT-Schatten aus sind und sich das "with RT" auf andere Effekte bezieht. Deathloop hat bspw. noch RT AO

Edit2:yup, die schwarzen Punkte sind jetzt weg

aufkrawall

2022-04-22, 17:01:47

robbitop

2022-04-22, 18:14:54

Alter ... langsam wird's richtig kurios.

MfG
Raff
Ja ich glaube da wurde ein Zusammenhang zwischen Genauigkeit des neuronalen Netzwerks und der Genauigkeit des eigentlichen Processing der Farbwerte für die Samples für den Framebuffer hergeleitet, der so natürlich nicht da ist. :)
DLSS wurde offenbar nicht verstanden.

basix

2022-04-22, 18:53:32

Wenn man sich 1080p mit 1440p FSR-Q vergleicht: Deutlich bessere Bildqualität bei wohl vermutlich fast identischer Performance. Jeder der ernsthaft spielt, sollte man sich spätestens jetzt mindestens einen 1440p Monitor zulegen. Auch wenn man eine Low End / Mainstream Karte besitzt, ist der Qualitätsgewinn enorm und mittels FSR und Co. benötigt man dafür nur Rechenleistung 1080p nativ.

vinacis_vivids

2022-04-22, 19:15:19

Die Bewegungsvektoren werden bei FRS 2.0 mit mindestens fp16 berechnet.

Hier sind die Quellen:
https://gpuopen.com/gdc-presentations/2022/GDC_FidelityFX_Super_Resolution_2_0.pdf
https://abload.de/img/2022-04-2219_09_17-poqwkwp.png

Bei DLSS wird vermutlich gemogelt bei den Bewegungsvektoren mit int8, das dann nach wie vor Schlieren verursacht. :D
Die grünen haben auch im Pro Bereich schon versucht halbgares fp32 für fp64 zu verkaufen.

robbitop

2022-04-22, 19:18:42

Quelle für die INT8 der Bewegungsvektoren bei DLSS?
Bisher ist gerade in Bewegung DLSS ungeschlagen (was aber eher mit der Trefferrate des Clampings [dank NN] zusammenhängt). Zumal nach meinem Verständnis die Bewegungsvektoren vom Spiel an DLSS beigestellt werden. Entsprechend hat DLSS außer dass es diese nutzt mit den Bewegungsvektoren wenig zu tun.

basix

2022-04-23, 00:21:49

Witzig, bei den neuen 1440p-Screenshots sieht jetzt nativ überschärfter aus als FSR 2.0.
Es sieht mit Q immer noch erstaunlich gut aus. Blamage für DLSS incoming? Ich kann es noch nicht so recht glauben...

Für uns Gamer wäre ein gutes FSR 2 ja ein Segen ;) Auf PC wie auch Konsole.

In Bewegung trennt sich dann aber die Spreu vom Weizen. TSR sieht bei Standbildern auch ganz gut aus und in Bewegung ist DLSS dann doch einiges vorne.

Dampf

2022-04-23, 14:09:52

Cool, dass sie endlich 1440p und 1080p geliefert haben. Sieht besser aus als ich es erwartet hab.

Nur warum verschwinden Lampen und andere Details in niedrigeren Auflösungen? Die Texturqualität scheint auch deutlich abzunehmen, ich frage mich ob da der LOD Bias nicht richtig gesetzt wurde. Aber da das ein Ideal-Szenario von AMD selbst ist, bezweifle ich das irgendwie. Hmm.

mboeller

2022-04-23, 14:33:33

Nur warum verschwinden Lampen und andere Details in niedrigeren Auflösungen?

Please note: At low resolutions (under 720p), DEATHLOOP can sometimes not render certain small objects at far distances, such as the light bulbs shown in the 1080p comparison images. When targeting 1080p output, the FSR 2.0 internal render resolution is 1280 x 720 or below, which results in the missing objects shown here — this issue is therefore not related to FSR 2.0.

text

robbitop

2022-04-23, 17:06:56

Dann muss man das Geometrie LoD und das Textur LoD halt anheben wenn temporales Upsampling zum Einsatz kommt. Ich verstehe nicht, warum sowas nicht gleich berücksichtigt wird.

aufkrawall

2022-04-23, 17:10:15

Dann muss man das Geometrie LoD und das Textur LoD halt anheben wenn temporales Upsampling zum Einsatz kommt. Ich verstehe nicht, warum sowas nicht gleich berücksichtigt wird.
Hatten Entwickler wohl bislang nicht genügend auf dem Schirm. Wenn FSR 2.0 und XeSS nun hoffentlich häufiger auf den Konsolen anzutreffen sein wird, wird sich das hoffentlich ändern.

basix

2022-04-25, 22:32:25

Habe gerade gesehen, dass Variable Rate Shading auch für adaptives/selektives Supersampling verwendet werden kann. Also nicht nur reduzierte Shading Rate. Das wäre genau das, was ich mir unter "Importance Sampling" oder eben Content Adaptive Rendering vorstellen würde. Dinge mit hoher Komplexität oder was sich schnell bewegt / neu im Bild erscheint wird höher abgetastet. Das in Kombination mit Temporal Upsampling wie FSR 2 oder DLSS wäre eigentlich genau das richtige.

Edit:
Und es gibt neu auch noch VRCS - Variable Rate Compute Shader. Das funktioniert für Deferred Lightning als auch andere Screen Space Effekte. In den Beispielen war der Performancegewinn ~2x! Und umso höher die Auflösung, desto höher ist tendentiell der Performancegewinn.
https://developer.microsoft.com/en-us/games/blog/variable-rate-compute-shaders-on-xbox-series-xs/
Und anscheinend ist der Implementationsaufwand sehr gering, wenn man VRS schon hat.

VRCS könnte auch das Problem lösen, dass Schatten und Reflexionen bei DLSS / FSR niedriger aufgelöst werden und an Qualität verlieren.

Gast

2022-04-28, 10:29:41

Habe gerade gesehen, dass Variable Rate Shading auch für adaptives/selektives Supersampling verwendet werden kann. Also nicht nur reduzierte Shading Rate. Das wäre genau das, was ich mir unter "Importance Sampling" oder eben Content Adaptive Rendering vorstellen würde. Dinge mit hoher Komplexität oder was sich schnell bewegt / neu im Bild erscheint wird höher abgetastet.

Naja, dabei wird auch nur in der höchstmöglichen Auflösung gerastert, und mit VRS das Shading generell mit niedrigerer Auflösung durchgeführt bzw. nur selektiv mit voller Auflösung.

VRCS könnte auch das Problem lösen, dass Schatten und Reflexionen bei DLSS / FSR niedriger aufgelöst werden und an Qualität verlieren.

Dazu braucht es kein VRS, man darf einfach nicht die entsprechenden Buffer mit der Renderauflösung skalieren sondern muss es mit der Ausgabeauflösung machen.

In Guardians of the Galaxy funktioniert die DLSS Rekonstruktion beispielsweise auch in den Reflexionen.

Gast

2022-04-28, 10:30:39

Die neue Overwatch Beta unterstützt nun auch FSR 1.0 beim Upscaling.

basix

2022-04-29, 09:23:58

Naja, dabei wird auch nur in der höchstmöglichen Auflösung gerastert, und mit VRS das Shading generell mit niedrigerer Auflösung durchgeführt bzw. nur selektiv mit voller Auflösung.

Grundsaätzlich hast du recht. Es spielt keine Rolle, ob via VRS under- oder oversampled wird. Im Falle von DLSS und Co. wäre der Supersampling Ansatz aber interessanter, da eh schon in einer möglichst niedrigen Grundauflösung gerendert wird. Ist einfach eine Frage der Integration und Umsetzung. Ging prinzipiell auch anders rum.

Dazu braucht es kein VRS, man darf einfach nicht die entsprechenden Buffer mit der Renderauflösung skalieren sondern muss es mit der Ausgabeauflösung machen.

In Guardians of the Galaxy funktioniert die DLSS Rekonstruktion beispielsweise auch in den Reflexionen.
Gut, dass es in GotG funktioniert ;) Und wenn es "nur" diese Buffer sind: Wieso sieht man das in fast keinem Spiel? HZD ist meines Wissens nach auch gut umgesetzt.

Das ist aber nicht der Punkt von VRCS. Evtl. muss man VCRS und Outputauflösung getrennt betrachten, das kann sein. Ein Zusammenspiel wird es aber dennoch geben. Es gibt nämlich bestimmt Bildteile, welche die höhere Auflösung nicht benötigt. Reflexionen über das gesamte Bild mit voller Render-Auflösung zu rendern macht nicht überall Sinn. Und deswegen könnte man mit VCRS massig Performance sparen. Und insbesondere bei Systemen, welche allenfalls schlecht von DLSS und Co. rekonstruiert werden können, kann diese Mehrperformance in erhöhte Renderauflösung investiert werden, wo es sinnvoll ist.

Gast

2022-04-29, 10:21:11

Grundsaätzlich hast du recht. Es spielt keine Rolle, ob via VRS under- oder oversampled wird. Im Falle von DLSS und Co. wäre der Supersampling Ansatz aber interessanter, da eh schon in einer möglichst niedrigen Grundauflösung gerendert wird. Ist einfach eine Frage der Integration und Umsetzung. Ging prinzipiell auch anders rum.

Es spielt schon eine Rolle, weil immer mit der vollen Auflösung gerendert wird und damit das Einsparungspotential im Verhältnis zu dynamic-resolution/upscaling extrem limitiert ist.

Das neue Update vom Steam Deck ermöglicht es VRS generell in 2x2 zu erzwingen, und zeigt damit den größtmöglichen Geschwindigkeitsgewinn ohne Rücksicht auf die Qualität. Und der ist nun mal fast vernachlässigbar im niedrigen 1-stelligen Prozentbereich.

Gut, dass es in GotG funktioniert ;) Und wenn es "nur" diese Buffer sind: Wieso sieht man das in fast keinem Spiel?

Weil die Engines offenbar nicht mit dem Gedanken an unterschiedliche Render- und Outputresolutions entwickelt wurde und anscheinend diverse Interne Settings einfach direkt von der Renderauflösung ableitet.

Der zweite Punkt ist natürlich auch der Geschwindigkeitsgewinn den man realisieren will. Wenn man diverse Puffer nicht runterskaliert ist dieser logischerweise auch geringer.

Wobei GotG meiner Meinung eine neue Version von DLSS verwendet, die auch bei den Spiegelungen funktionieren. Es sieht so aus, als würden die Spiegelungen nicht einfach weiter in der vollen Auflösung, bzw. wir sollten eigentlich sagen in der ursprünglichen Auflösung, die meisten Spiele mit RT-Spiegelungen berechnen diese auch nativ in geringerer Auflösung, berechnet, sondern man sieht auch in den Spiegelungen teilweise den typischen Gewinn an feinen Details von DLSS.

DrFreaK666

2022-05-10, 15:12:12

FSR 2.0 startet diese Woche. Bin gespannt auf die Ergebnisse
https://www.computerbase.de/2022-05/amd-fsr-2.0-start-am-12.-mai-in-deathloop-weitere-spiele-ankuendigungen/

Lehdro

2022-05-10, 16:26:04

FSR 2.0 startet diese Woche. Bin gespannt auf die Ergebnisse
https://www.computerbase.de/2022-05/amd-fsr-2.0-start-am-12.-mai-in-deathloop-weitere-spiele-ankuendigungen/
Bitte nicht versauen AMD!

DrFreaK666

2022-05-10, 16:46:59

schlechter als FSR wird es nicht werden. Aber vielleicht etwas schlechter als DLSS 2

Redneck

2022-05-11, 08:56:53

Bis auf FS2020 liest sich die Palette der anfangs unterstützten Spiele aber etwas sehr mau.
Hier muß mehr vom Marketing finanziell reingebuttert werden , damit es einige Tripple A showcases gibt.

DrFreaK666

2022-05-11, 11:21:27

Ich denke dass noch von ein paar MS Studios Patches kommen werden. Bisher sind es immerhin schon drei

Platos

2022-05-11, 12:23:45

Also wie gut es sein kann (!), haben wir ja schon lange gesehen. Aber ok, wenns dann nur in wenigen Spielen kommt, ist es natürlich ein KO-Kriterium. Das muss jetzt ab sofort in jedem Spiel kommen. Immerhin sind sie mit dem ganzen bald 2 Jahre hinter nvidia (mit DLSS 2.0).

basix

2022-05-11, 13:02:52

Am besten würde AMD auch Spiele mitnehmen/antriggern, welche bereits DLSS 2.0 integriert haben. Wenn das nur 1-2d Aufwand sind, ist Aufwand/Ertrag für AMD extrem gut. Und nimmt Nvidia bereits massiv Wind aus den Segeln.

DrFreaK666

2022-05-11, 13:35:48

Mich wundert auch dass besonders von MS-Studios so wenig kommt

Dampf

2022-05-11, 13:48:18

Hmm, die Auswahl ist schon mau. Flight Simulator ist das einzige Spiel, das mich aus dieser Liste zufrieden stimmt.

Aber man muss sich keine Sorgen machen. Ich gehe davon aus, dass wir eine breite Unterstützung sehen, besonders wenn FSR 2.0 gut wird. Dann wird jeder die Entwickler nerven, doch bitte FSR 2 zu integrieren.

vinacis_vivids

2022-05-11, 14:08:47

FSR ist bereits überall implementiert als RSR mit FSR Technologie.

Bei vielen Engines und Studios, die noch auf älterer DX11 Technik, Single-Core und Single Thread aufbauen wird nach und nach verbessert werden.

AMD wird schon ein Blick drauf werfen und schauen wo es schwach läuft um zu schauen wo die Stellschraube gelöst werden kann.
Oftmals ist es gar nicht die Hardware and sich, sondern auch das Betriebssystem und/oder die API.

DrFreaK666

2022-05-11, 15:10:57

FSR2.0 funktioniert aktuell auch nur mit DX12. Das schränkt auch ein. Die ganzen PlayStation-Umsetzungen laufen meines Wissens mit DX11

dargo

2022-05-11, 16:22:00

FSR2.0 funktioniert aktuell auch nur mit DX12. Das schränkt auch ein. Die ganzen PlayStation-Umsetzungen laufen meines Wissens mit DX11
Falsch... HZD hat bsw. nur einen D3D12 Renderer. GoW und Days Gone dafür leider nur einen D3D11 Renderer.

Gast

2022-05-11, 17:11:31

FSR ist bereits überall implementiert als RSR mit FSR Technologie.

Damit hast du aber unscharfe HUDs und nicht nur eine unscharfe 3D-Welt.

TheAntitheist

2022-05-11, 17:12:39

Gratzner

2022-05-11, 17:38:38

FSR2.0 funktioniert aktuell auch nur mit DX12. Das schränkt auch ein. Die ganzen PlayStation-Umsetzungen laufen meines Wissens mit DX11
Dx12 wurde im Sommer 2015(!) released. Das heißt, dass Dx12 bald sein 10 jähriges Jubiläum feiert. Höchsten Vulkan-Spiele sind eingeschränkt (von denen es aber nur sehr wenige gibt). Spiele, die auf dx11 oder älter setzen, sind heutzutage einfach nur Retrospiele oder technisch komplett veraltet.

Bis auf FS2020 liest sich die Palette der anfangs unterstützten Spiele aber etwas sehr mau.
Hier muß mehr vom Marketing finanziell reingebuttert werden , damit es einige Tripple A showcases gibt.
FSR 2.0 ist noch nicht open source (stand 11.05.) [gpuopen.com (https://gpuopen.com/fidelityfx-superresolution-2/)]. Nachdem es open source geht, sollte die Verbreitung sich verbessern

aufkrawall

2022-05-11, 17:42:06

Spiele, die auf dx11 oder älter setzen, sind heutzutage einfach nur Retrospiele oder technisch komplett veraltet.

Nö, es erscheinen immer noch selbst viele UE4-Spiele mit D3D11.

Gratzner

2022-05-11, 17:44:43

Ja, es werden immernoch viele dx11 Spiele veröffentlicht. Man merkt aber denen an, das die technisch nicht mehr konkurrenzfähig sind, sondern eher veraltet (fehlen von Raytracing-Effekte bspw.)

Platos

2022-05-11, 17:51:52

Nö, es erscheinen immer noch selbst viele UE4-Spiele mit D3D11.

Also DX11 only oder zweigleisig?

aufkrawall

2022-05-11, 17:55:06

Durch schlechtes TAA und weniger fps machen die aber auch nicht mehr Spaß. ;)
SW3 skaliert wie bekloppt mit der Auflösung, DLSS hatte mir hier für den 144Hz-Monitor die Spielerfahrung extrem aufgewertet. In GoW hatte ich die Leistung auch gut gebrauchen können. Wird es solche Fälle in Zukunft weiterhin geben? Wahrscheinlich. Kein D3D11-Support ist/wäre mehr als eine kleine Unschönheit. Hoffen wir mal, dass man es AMD-typisch bislang nur mal wieder "vergessen" hat zu erwähnen und es nachgeschoben wird.

DrFreaK666

2022-05-11, 18:00:13

... Spiele, die auf dx11 oder älter setzen, sind heutzutage einfach nur Retrospiele oder technisch komplett veraltet...

Sorry, aber :ugly:
Es gibt DX11-Spiele mit DLSS 2. Und nicht jeder hat eine 3080 oder schneller

Gratzner

2022-05-11, 18:24:58

Schön, dass du lesen gelernt hast, jetzt lerne bitte noch das Gelesene richtig zu verstehen:freak:

Es wurde von mir nirgends behauptet, dass dx11 und dlss nicht möglich seien. Es wurde von mir auch nicht behauptet, dass alte Spiele keine moderne Ideen umgesetzt haben dürfen oder neue Spiele keine alte Ideen aufgreifen dürfen.

Ich wollte darauf hinaus, dass dx12 (im Kontext sich rasant entwickelter Hardware und Software) sehr, sehr alt ist. Dadurch sollte es doch akzeptable sein, noch viel ältere Schnittstellen (directx 11 wurde 2009 released) nicht mit neuester State-of-the-Art "Technologien" (am Release-Tag) zu unterstützen

DrFreaK666

2022-05-11, 18:29:28

Schön, dass du lesen gelernt hast, jetzt lerne bitte noch das Gelesene richtig zu verstehen:freak:...

Es wurde behauptet dass DX11-Spiele "Retrospiele" sind "oder technisch komplett veraltet" :rolleyes:
Dass das Schwachsinn ist, weißt du selbst

Gratzner

2022-05-11, 19:04:50

Ok, nach deiner Logik sind DirectX 9 Spiele auch noch State-of-the-Art. Bspw. Lost Ark wurde ja erst 2022 (EU) released. Directx 11-Support kam erst mit einem Patch, Lost Ark war tatsächlich erstmal ein DirectX 9 Spiel. Eine gut funktionierende Kantenglättung hat das Spiel ebenfalls nicht, also muss ja schlechte Kantenglättung quasi State-of-the-Art sein. Als Beweis, warum das Spiel modern sein soll, führt man dann einfach das Releasedatum an (oder die Monetarisierung).

Jetzt mal Ernsthaft: Directx 11 Spiele führen Bottlenecks mit sich rum, die nicht mehr nötig sind. Das Lösen von Bottlenecks in draw-calls wurden damals beispielsweise groß beworben oder der "viel bessere" Multicore support (Nach deiner Logik wäre schlechte Kernskalierung gut und modern, weil es werden ja immer noch einige/viele Spiele mit schlechter Kernskalierung released). Inzwischen ist das einbauen von Raytracing-Effekten in tripple-A Spielen weit verbreitet. Directx-11 hat hierfür keine Unterstützung. Die Schnittstelle ist einfach längst überholt. Directx 12 wurde auch schon von directx 12 ultimate ersetzt

Mag sein, das es noch einige Entwickler gibt, die an komplett veraltete Sachen festhalten und damit noch heute Spiele releasen. Die Definition von technisch modern ist aber nicht, dass das Spiel frisch released wurde