News F1 2020: Patch 1.08 bringt DLSS 2.0 für GeForce RTX

[Nolag]

Man sieht ja auch schön an DLSS2.0, dass problematische Informationen, wie z.B. Texturen (Ölgemäldeeffekt) ausgeklammert wurden.

DLSS 2.0 hat kein Problem mit Texturen. Wie ich mehrfach versucht habe zu erklären, ist es ein Multi-Frame Super-Resolution Verfahren. Es werden Bewegungsvektoren von Pixeln mit Sub-Pixel-Genauigkeit berechnet, was dazu führt, dass man nach einigen Frames in Bewegung mehr Informationen über einen Pixel hat. Solche Verfahren sind im Prinzip seit fast 40 Jahren bekannt, waren aber bisher nicht in Echtzeit verwendbar. Hollywood ist so begeistert davon, dass wir seit den 80ern andauernd gezeigt bekommen, wie unlesbare Nummernschilder lesbar werden. Es ist also seit fast 40 Jahren bekannt, und inzwischen mehrfach wissenschaftlich belegt, dass man aus einer Serie von niedrig aufgelösten Bildern ein höher aufgelöstes Bild erzeugen kann:

• https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8052084
• http://breckon.eu/toby/publications/papers/mise13superresolution.pdf
• http://people.duke.edu/~sf59/SRfinal.pdf

DLSS 2.0 darf halt nicht mit Verfahren für statische Bilder wie ESRGAN verwechselt werden. Die statische Rekonstruktion allein könnte z.B. nicht die völlig unleserliche Schrift, wie z.B. die Städtenamen in Figure 8 auf Seite 9 des Facebook Papers rekonstruieren:

 

[DerKonfigurator]

Kleinigkeiten wie zum Beispiel in My Team. Beim Wechsel des Motors ändert sich der Sound nicht. Beim Logo war auch ein Problem. So zieht sich das durch. Gibt auch einige Dinge, die in F1 2019 schon okay waren und in F1 2020 wieder schlechter. Warum weiß ich auch nicht.

Danke für die Info. Werde ich mal beobachten.

 

[.Sentinel.]

DLSS 2.0 hat kein Problem mit Texturen.

Ja, weil es, wie ich bereits beschrieben habe, die Texturen außen vor lässt.

Man hat eben bis jetzt noch kein "GAN"- Verfahren integriert und die Frage, ob dies bei Bewegtbildern so sinnvoll wäre, ist für mich auch offen, stellt sich da ja unter Anderem die Frage der Perspektivkorrektur der Pixeltapete.

Eher sehe ich den Einsatz der Texturoptimierung bzw. Generierung "on the fly" z.B. durch Mustererkennung oder vielleicht sogar Attributierung.
Sprich ein Objekt wird als Berg erkannt oder ein Attribut dafür gesetzt und die KI füllt das dann mit einer "gelernten" Textur aus.

Es sind diesbezüglich noch viele spannenden Verfahren im Umlauf. Deswegen ist der gesamte Ansatz ja auch so interessant. DLSS2.0 ist mit Sicherheit nicht das letzte Wort.

 

[Nolag]

Ja, weil es, wie ich bereits beschrieben habe, die Texturen außen vor lässt.

Dafür hätte ich gerne eine Quelle. DLSS 2.0 ist darauf trainiert aus einer Serie von niedrig aufgelösten Bildern mit Hilfe von Bewegungsvektoren ein Bild mit höherer Auflösung zu erzeugen. Das funktioniert für Kanten und texturierte Flächen gleichermaßen gut (siehe DLSS 2. 0 A big leap in AI rendering ). In den Videos und Screenshots zu Control kann man auch erkennen, das dort sogar die Flächendetails teilweise besser sind als im Original.

 

[.Sentinel.]

Dafür hätte ich gerne eine Quelle.

So wird das gemacht:

ENGINE INTEGRATION

DLSS is not designed to enhance texture resolution.
Mipbias should be set so textures have the same resolution as
native rendering•Mipbias = Native bias + Log2(Render Res/Native Res)

Bereich Engine Integration ab Seite 78 (das PDF sollte eigentlich Pflichtlektüre für Interessierte sein):
http://behindthepixels.io/assets/files/DLSS2.0.pdf

Du wählst wenn Du die Szene an den convonutional autoencoder schickst die Texturauflösung so, dass sie bei Auflösungswechsel mit einer Verkleinerung quasi das Original erreicht.

Das macht man deshalb, weil Texturierung an sich kaum Leistung kostet bzw. bei DLSS bringt, aber bei einer Abweichung einen hohen visuellen Impact haben kann, wie man bei der Erstimplementation von DLSS1.0 sehen konnte.
Nachteil- Die gleichbleibenden Texturen gehen natürlich dann wieder auf den VRAM, eben wie im Original.
Somit fällt da eine Ersparnis weg.

Ergeben sich Änderungen im Texturbild, dann ist das durch post- processing so gewollt. Hat aber mit DLSS an sich wenig zu tun.
Die Bewegungsvektoren brauchst Du nur, um die Informationen des Jitters auf das sich in Bewegung befindende Bild richtig koordiniert einordnen zu können.

Musst Dir das so vorstellen, dass Du ein Puzzle hast, was laufend in Bewegung ist. Legst Du nun ein Puzzlestück an einen Ort, aber jemand hat den Tisch auf dem das Puzzle aufgebaut ist verschoben, gibt es Falschinformation bzw. das Puzzlestück passt nicht.

Dadurch, dass ich Dir aber mitteile, in welche Richtung der Tisch verschoben wurde (motion Vektoren), kannst Du die richtige Stelle schnell finden. Somit sind diese wichtig für eine genaue und richtige Akkumulation der Pixeldaten, die Du brauchst, um einen Auflösungsnachteil auszugleichen und im Idealfall das native Bild zu übertrumpfen.

 

[Nolag]

Ok, ich hatte mich gewundert, was du meinst, weil klar ist, dass DLSS Screen Space only ist. Es wäre auch völliger Quatsch erst im VRAM die Texturen mit ESRGAN oder ähnlichem zu verhunzen um danach zu versuchen mit den kaputten Texturen noch zusätzlich mit Multi Frame Super Resolution falsche Details aus der Bewegung zu rekonstruieren.