Diskussion zu: Custom DSR Tool bietet bis zu 40x Downsampling Anti-Aliasing

[Leonidas]

Link zur News:
http://www.3dcenter.org/news/custom-dsr-tool-bietet-bis-zu-40x-downsampling-anti-aliasing

Update 28. Juni:
Titel und Nachricht gefixt hin zu 40x DSR

[Buchbichler]

"während die ansonsten erzeugten (extrem) hohen Frameraten sowieso wirkungslos am VSync verpuffen würden."

Die FPS würden nicht verpuffen, sondern gar nicht berechnet werden. Ganz umsonst gibt es die zusätzliche Qualität auch nicht, der Stromverbrauch der GPU wird um einiges ansteigen. Ohne Vsync würde die Aussage natürlich stimmen, aber wer spielt schon ohne Vsync :-) Mein Monitor macht zum Beispiel ganz grauselige Effekte wenn er 800 Fps an den Kopf geworfen bekommt, und die Hütte ist auch warm wenn die GPU kocht:smile:

Ich sehe das Feature primär bei der Erstellung möglichst hochwertiger Screenshots, da ist die Bildrate egal.

[aths]

Ich bin gespannt, ob 9x DSR ordentlich funktioniert. Damit hätte man eine durchweg gute Glättung.

edit: Man kann bis 40x einstellen. Getestet hab ich erst mal 9x in Doom 3.

Das ist schon geil, wenn man noch 4x AA im Spiel einschaltet.

[Leonidas]

Wirklich bis 40x ???

[Gast]

Aber genau hier liegt schließlich ein bekannter Zweitnutzen von Downsampling Anti-Aliasing – alte Spieletitel bestmöglich zu verschönern, welche auf heutiger Hardware extreme und damit auch extrem sinnlose Frameraten auswerfen

Mit Framelimiter bzw. Vsync wird der Spieler bei alten Spielen mit Kepler und insbesondere mit Maxwell-Karten mit einem sehr niedrigen Stromverbrauch belohnt, je nach Kühldesign kann die Kühlung sogar passiv bleiben.

Klar ist eine Verbesserung der Bildqualität immer wünschenswert, aber es ist fraglich ob solch extreme Einstellungen wirklich noch eine sichtbare Qualitätsverbesserung bringen und nicht nur sinnlose Stromvergeudung und damit Hitze.

Zumal DX9-Spiele soweit ich weiß auf 8k pro Achse limitiert sind.

[aths]

Ja.

Sinnvoll wäre natürlich nur 25x und 36x.

[Raff]

9x und 16x sehen hier an 30 Zoll mit nativen 1600p brutal geil aus. Allein der Mauszeiger ist kaputt (riesig, falsch skaliert). Brutal ist auch die Speicherauslastung und natürlich der Hunger nach Rohleistung. Gefällt mir, genau mein Ding. :biggrin:

aths, check mal Max Payne 2 mit Extrem-DSR (falls du das nicht schon gemacht hast)! :up:

MfG,
Raff

[Blackhand]

Also ich würde den Faktor ganz gerne eingeben können. 6,25 trifft man einfach nicht und 9x ist nur mit dem Mausrad erreichbar. Wenn man jetzt noch den Auflösungen direkt verschiedene Smoothnesswerte geben könnte, wär das erstmal auch nicht schlecht seitdem es da keinen pauschal tollen Wert mehr gibt ganze quadratische Faktoren anders runterskalieren (Ist es denn so bei 9x/16x? OK, werds gleich noch selber testen)

@Buchbichler
Gibt ne Menge Leute, die ohne VSync zocken. VSync hat nur für den Betrachter etwas, für den Spieler bringt es lag. Sich keinen 60Hz Krüppelbildschirm hinzustellen hilft hier enorm und resultiert in weniger und schwächerem Tearing!

[aths]

9x und 16x sehen hier an 30 Zoll mit nativen 1600p brutal geil aus. Allein der Mauszeiger ist kaputt (riesig, falsch skaliert). Brutal ist auch die Speicherauslastung und natürlich der Hunger nach Rohleistung. Gefällt mir, genau mein Ding. :biggrin:

aths, check mal Max Payne 2 mit Extrem-DSR (falls du das nicht schon gemacht hast)! :up:

MP2 spiele ich eigentlich mit 8x SGSAA da man bei Downsampling das Monitorverhältnis hat und das Fov in MP2 fest auf 4:3 eingestellt ist.

[Raff]

Guter Punkt, mache ich eigentlich auch so (3.840 × 2.880), aber im Kurztest mit 16× DSR war das schon heftig. :D

MfG,
Raff

[OC_Burner]

Wirklich bis 40x ???

Eigentlich geht es sogar hoch bis zu Faktor 64x. Das Tool unterstützt aber nicht mehr wie 40x. Vielleicht kann Orbmu2k ja eine aktualisierte Version nachschieben. Mehr wie Faktor 25x ist aber eh nicht sinnvoll, da es dann wieder zu flimmern beginnt.

[Blackhand]

Also, bei 9x und 16x wird leider auch nur Gauß + NN verwendet, die Smoothness kann mit höherer Auflösung aber scheinbar geringer gewählt werden. Wenn meine Vorstellung vom 13tap-Gaußfilter richtig ist, müssten ab Faktoren >49 berechnete Pixelinformationen durch NN doch regelrecht komplett verloren gehen, oder nicht?

Allerdings sind Faktoren>4x i.d.R. wirklich nutzlos, da man in älteren Spielen dann einfach SGSSAA nehmen kann. Und mit 8xSGSSAA + 4x DSR kriegt man die Performance auch in ziemlich alten Spielen runter.

[OC_Burner]

Also, bei 9x und 16x wird leider auch nur Gauß + NN verwendet, die Smoothness kann mit höherer Auflösung aber scheinbar geringer gewählt werden. Wenn meine Vorstellung vom 13tap-Gaußfilter richtig ist, müssten ab Faktoren >49 berechnete Pixelinformationen durch NN doch regelrecht komplett verloren gehen, oder nicht?

Allerdings sind Faktoren>4x i.d.R. wirklich nutzlos, da man in älteren Spielen dann einfach SGSSAA nehmen kann. Und mit 8xSGSSAA + 4x DSR kriegt man die Performance auch in ziemlich alten Spielen runter.

Ich bin mir nicht sicher ob man noch von 13-tap sprechen kann. Meiner Überlegung nach nein. Die 13 taps des Gaußfilter passen nicht in das 5x5 Raster von Faktor 25x. Das Bild sollte eigentlich wegen ungefilterter Sampels bei NN-Verschnitt anfangen zu flimmern, jedoch tut es das nicht. Könnte die Kernelgröße auf 25taps erweitert worden sein?

http://www.grafik-feti.de/ftp/3D-Center/Downsampling/Nvidia_Downsampling_exploration/Maxwell_DSR/DSR_improvements/DSR_13taps_or_25taps.png

[Blackhand]

Die Frage ist, wie man hier 13-tap interpretieren soll. Das konnte doch noch keiner hier so exakt beantworten, oder?

Meine ziemlich grob überdachte Halbwissenspekulationsannahme (wird ziemlich sicher nicht genau so und fehlerhaft sein) geht eher in die Richtung, dass 2 identische, separierbare 1D-Filter jeweils in x- und y-Richtung hintereinander über das Bild gejagt werden, was auch Rechenzeit sparen dürfte. So ein 1D-Filter könnte so aussehen: 1/64*[1 6 15 20 15 6 1], was einen 7x7 2D-Filterkernel ergeben würde. Die Hintereinanderausführung spart allerdings Operationen. So sind statt 49 Multiplikationen und 48 Additionen lediglich 14 Multiplikationen und 12 Additionen pro Pixel (ca. 13-tap) auszuführen. Gekreuzt und gefärbt sieht das dann eher so aus, wie das Ding, was du unter 25x (5x5) dargestellt hast (13 eingefärbte Pixel).

Die andere Frage wäre dann, in wie weit der Kernel mit der Auflösung skaliert. (Gerade noch den VSR vs DSR Thread überflogen und deinen damaligen Link zur Gaußimplementation auch nochmal überflogen, worin die Hintereinanderausführung der 1D-Filter auch nochmal beschrieben steht, komplett durchgestiegen bin ich da aber nicht, müsste mich ma eingehender mit befassen, aber keine Zeit i.d.R.). Laut Gipsel sollte man den Filterkernel optimalerweise auf die Ausgabeauflösung eichen. Leider blieb da auch die Frage offen, wie es denn genau in GeDoSaTo implementiert wurde, kann den Quellcode leider nicht interpretieren. Nur für den Fall, dass der Filter nicht mit der Auflösung skaliert, dürften irgendwann ab hohen Faktoren Pixel kein Gewicht mehr fürs Downscaling haben. In dem Fall dürfte selbst bei 100% Smoothness das Bild bei 49x eher leicht grobkörnig wirken. Vielleicht könntest du das testen?

Eine andere Auflösung für 13-tap wäre ja vielleicht, dass zuerst NN durchgeführt wird und dann bestimmte Pixel bei der Berechnung außen vorgelassen werden und man am Ende grob auf eine 2D-Filtermaske kommt, wie bei dir unter 13tap dargestellt. Aber wie gesagt ist die direkt Anwendung eines 2D-Filterkernels eher rechentechnisch ungünstig, wie auch bei deinem damaligem Link ausgeführt, das wirds denke ich so direkt nicht sein.

[aths]

Guter Punkt, mache ich eigentlich auch so (3.840 × 2.880), aber im Kurztest mit 16× DSR war das schon heftig. :D

MfG,
Raff
Kann man 4:3-Auflösungen mit DSR auch auf Breitbild-Monitoren verwenden (mit Balken links und recht)?

[OC_Burner]

Die Frage ist, wie man hier 13-tap interpretieren soll. Das konnte doch noch keiner hier so exakt beantworten, oder?

Meine ziemlich grob überdachte Halbwissenspekulationsannahme (wird ziemlich sicher nicht genau so und fehlerhaft sein) geht eher in die Richtung, dass 2 identische, separierbare 1D-Filter jeweils in x- und y-Richtung hintereinander über das Bild gejagt werden, was auch Rechenzeit sparen dürfte. So ein 1D-Filter könnte so aussehen: 1/64*[1 6 15 20 15 6 1], was einen 7x7 2D-Filterkernel ergeben würde. Die Hintereinanderausführung spart allerdings Operationen. So sind statt 49 Multiplikationen und 48 Additionen lediglich 14 Multiplikationen und 12 Additionen pro Pixel (ca. 13-tap) auszuführen. Gekreuzt und gefärbt sieht das dann eher so aus, wie das Ding, was du unter 25x (5x5) dargestellt hast (13 eingefärbte Pixel).

Die andere Frage wäre dann, in wie weit der Kernel mit der Auflösung skaliert. (Gerade noch den VSR vs DSR Thread überflogen und deinen damaligen Link zur Gaußimplementation auch nochmal überflogen, worin die Hintereinanderausführung der 1D-Filter auch nochmal beschrieben steht, komplett durchgestiegen bin ich da aber nicht, müsste mich ma eingehender mit befassen, aber keine Zeit i.d.R.). Laut Gipsel sollte man den Filterkernel optimalerweise auf die Ausgabeauflösung eichen. Leider blieb da auch die Frage offen, wie es denn genau in GeDoSaTo implementiert wurde, kann den Quellcode leider nicht interpretieren. Nur für den Fall, dass der Filter nicht mit der Auflösung skaliert, dürften irgendwann ab hohen Faktoren Pixel kein Gewicht mehr fürs Downscaling haben. In dem Fall dürfte selbst bei 100% Smoothness das Bild bei 49x eher leicht grobkörnig wirken. Vielleicht könntest du das testen?

Eine andere Auflösung für 13-tap wäre ja vielleicht, dass zuerst NN durchgeführt wird und dann bestimmte Pixel bei der Berechnung außen vorgelassen werden und man am Ende grob auf eine 2D-Filtermaske kommt, wie bei dir unter 13tap dargestellt. Aber wie gesagt ist die direkt Anwendung eines 2D-Filterkernels eher rechentechnisch ungünstig, wie auch bei deinem damaligem Link ausgeführt, das wirds denke ich so direkt nicht sein.

Das zwei 1D-Filter hintereinander über das Bild gejagt werden um eine bessere Performance zu gewährleisten sehe ich auch so allerdings scheinst du da den besseren Überblick zu haben. Mit Faltungsmasken habe ich mich noch nie direkt beschäftigt und steige auch kaum durch wenn ich mir Lektüre wie diese hier anschaue.: https://zenodo.org/record/14709/files/Haussecker_BV1995a.pdf

Faktor 49x könnte ich die Tage mal testen und anschauen. Jedenfalls tut Faktor 36x schon überaus deutlich flimmern. Übrigens hat Nvidia es unterbunden das der Gaussfilter auch bei nativer Auflösung mit dem Faktor 1x Trick angewendet wird. Ein direktes anschauen des Gaussfilters ist so leider nicht mehr möglich.

Kann man 4:3-Auflösungen mit DSR auch auf Breitbild-Monitoren verwenden (mit Balken links und recht)?

Mit dem Tool von Orbmu2k kannst du deine Zielauflösung einstellen und so abweichend von deiner nativen Auflösung DSR betreiben. Deine dort eingetragene Auflösung muss aber eine sein die auch von Windows (1024x768, 1440x1080 etc.) angeboten wird, da sonst DSR nicht funktioniert.

[Orbmu2k]

Also ich würde den Faktor ganz gerne eingeben können. 6,25 trifft man einfach nicht und 9x ist nur mit dem Mausrad erreichbar.

Mit den Pfeiltasten (Hoch/Runter) auf der Tastatur kannst du die Einzelschritte genau ansteuern. :)

[no.this.is.patrick!]

hey orbmu2k,

ist es irgendwie möglich, auch dsr für custom resolutions zu nutzen, besonders für verschiedene seitenverhältnisse (z.b. 3:4 hochkant, 1:1 square, 2:1 oder 3:1)?

das hier


Mit dem Tool von Orbmu2k kannst du deine Zielauflösung einstellen und so abweichend von deiner nativen Auflösung DSR betreiben. Deine dort eingetragene Auflösung muss aber eine sein die auch von Windows (1024x768, 1440x1080 etc.) angeboten wird, da sonst DSR nicht funktioniert.

bringt mir leider nichts...


edit: 3:4 geht über 4:3 mit pivot