Catalyst Omega, AMD VSR vs. Nvidia DSR

[OC_Burner]

nearest neighbor hat man wenn die smoothness auf 0 ist, dann verschwinden in bewegung ganze pixelreihen und solche späße. ich weiß auch nicht wie ihr darauf kommt, dass sich der filter bei verschiedenen faktoren verändert. eine langsame steierung der smoothness sieht, zumindest auf aktuellen treibern auf fermi, so aus wie ein sich vergrößernder gauss-filterkern und das auf allen faktoren.

wenn eine schwarze pixelreihe beispielweise zwischen 2 rasterstufen liegt (und damit auf 0% unsichtbar ist) wird die mit steigender smoothness langsam sichbar und läuft dann über mehrere pixel aus.

Das was NVIDIA macht kannst du auch nachstellen und kommst damit auf ähnliche Ergebnisse. Ohne genauen Sigmawert und Shadercode des Gaußfilters wird man aber nicht auf gleiche Ergbenisse kommen. Man nehme ein Bild in 2880x1620, appliziere darauf einen Gaußfilter und stampfe das Bild mit Nearest Neighbor auf 1920x1080 ein.

[von Richthofen]

Einfach drüberinstallieren hat nicht geklappt. Hat zwar alles auf den ersten Blick sauber gemacht und die Versionen hochgezogen, den Punkt zum Aktivieren von Downsampling aber nicht angezeigt.
Mit DDU deinstalliert und neu draufgemacht. Voila.
Vllt. beisst sich das doch mit den Downsampling Custom Registryhacks.?

[fondness]

ja. deswegen ist smoothness 0 auch totaler unsinn und wohl nur "vollständigkeitshalber" drin. alles unter ~15 artefaktet wie verrückt, so um 20-25 rum ist es dann wie bilinear und ab ~28 etwa ist es flimmerärmer als normales AF ohne DS.

Und warum genau ist das jetzt besser als ein bi-Filter? Hört sich für mich ziemlich suboptimal an was NV da aufführt aber war wohl die billigste Lösung über die Shader.

[Blaire]

Man könnte auch fragen warum Nvidia bei allen Faktoren (außer 4.00x) Nearest Neighbor nimmt.

Man kann auch einfach mal zufrieden sein. ;) Genug Flexibilität wird immerhin geboten, daß kann man nun NV nicht zum Nachteil auslegen bzw. muss man nicht jedes, vom "Treiber-Default" abweichende Detail ausklamüsern. Wenn du es AMD-like haben möchtest, verwendest halt die alte DS-Methode über Custom Resolution oder ziehst den DSR Smoothness-Slider weiter nach links.
Am Ende sollte man froh sein, das NVIDIA hier den ersten Schritt gewagt hat, sonst wäre es wohl kaum zu dieser kanadischen "Not-Reaktion" gekommen. :D

[deekey777]

ATi bzw. AMD haben auch nicht so viel Erfahrung mit OGSSAA wie Nvidia.

[samm]

ATi bzw. AMD haben auch nicht so viel Erfahrung mit OGSSAA wie Nvidia.Seh die Logik nicht - VSR sieht besser aus aus DSR :confused:
Am Ende sollte man froh sein, das NVIDIA hier den ersten Schritt gewagt hat, sonst wäre es wohl kaum zu dieser kanadischen "Not-Reaktion" gekommen. :DDie frühe Veröffentlichung war das einzige reflexhafte daran, in Entwicklung war das schon vor der Veröffentlichung DSR.
Aber jup, bin auch froh, hat nVidia hier AMD gezeigt, dass sie nicht ewig mit ihrer Treiber-Downsampling-Lösung zuwarten können. Jetzt müssen sie's nur noch nVidia-artig auch über die Shader erlauben, damit ich auch davon profitieren kann in den paar AA-losen/PP-AA-only Spielen, die mit Registry-DS noch bescheiden aussehen

[phoenix887]

Man kann auch einfach mal zufrieden sein. ;) Genug Flexibilität wird immerhin geboten, daß kann man nun NV nicht zum Nachteil auslegen bzw. muss man nicht jedes, vom "Treiber-Default" abweichende Detail ausklamüsern. Wenn du es AMD-like haben möchtest, verwendest halt die alte DS-Methode über Custom Resolution oder ziehst den DSR Smoothness-Slider weiter nach links.
Am Ende sollte man froh sein, das NVIDIA hier den ersten Schritt gewagt hat, sonst wäre es wohl kaum zu dieser kanadischen "Not-Reaktion" gekommen. :D

Stimme ich dir zu, bin dankbar und nutze gern DSR, aktuell in Far Cry 4. Zudem kann ich es auch ohne Probleme an meinem 55 Zoll TV nutzen, was vorher nicht ging mit dem Old-School DS. Einfach Haken anklicken und schon hat man einen DS ähnlichen Effekt. Außerdem mag ich den Gauß-Filter und dessen Effekt. ist mir lieber als ein überschärftes Bild. Naja 1st World Probleme....

Muss auch sagen, habe auch keine Lust mehr jede Einstellungen zu hinterfragen, nehme es so wie es ist und gut ist. Wenn ich mir über so Sachen ständig den Kopf mache, komme ich kaum noch zum Zocken in der wenigen Zeit die ich habe.
Finde es manchmal übertrieben wie jeden Einstellung auseinander genommen wird, oder alles nachgemessen. Aber vielleicht bin ich ja nicht freaking genug. Keine Ahnung:freak:

[Blackhand]

Und warum genau ist das jetzt besser als ein bi-Filter? Hört sich für mich ziemlich suboptimal an was NV da aufführt aber war wohl die billigste Lösung über die Shader.

Hab ich schon weiter oben im Thread erklärt. Flimmerneigung ist reduziert. Und ja, es ist suboptimal, was nVidia da abliefert, solltest du auch schonmal gelesen haben weiter oben im Thread. Und nein, es performt sogar einen Tick schlechter als der bilineare Filter bzw. klassisches NV-DS.


Desweiteren habe ich mit UT3 halt einfach getestet, dass sowohl DS mit herkömmlicher Methode als auch bilinear über Gedosato selbst bei 4x Auflösung stärker flimmert als native Auflösung ohne 3rd Party Post Processing (Wobei es auch am Ingame Post Processing liegen könnte, das verhält sich im Ergebnis ja durchaus auch mal anders je nachdem ob es auf die erhöhte Auflösung angewendet wird oder nicht). Auch wenn es eigentlich nicht sein sollte, ich habe es nunmal so beobachtet. Erklären kann ichs auch nicht.

Wie Gedosato nun genau im Detail Lanczos bzw. bilinear filtert weiß ich nicht. Vielleicht könnt ihr das Tool ja mit euren Filtertestern zum laufen kriegen, falls das überhaupt Sinn macht.

[Grestorn]

Und warum genau ist das jetzt besser als ein bi-Filter? Hört sich für mich ziemlich suboptimal an was NV da aufführt aber war wohl die billigste Lösung über die Shader.

Es geht nicht ohne Sticheln, wie?! :) Jedenfalls bist Du konsistent.

[Gipsel]

Gauß-Filter per Shader ist sicherlich nicht die billigste Variante (vom Rechenaufwand). Gerade deswegen wundert mich die Wahl doch etwas, da es bessere Alternativen gibt, die weniger Schärfe verlieren (bei gleicher Flimmerunterdrückung) als dieser doch sehr weichzeichnende Filter. Also da ist normalerweise irgendeine Tent-Filter-Abwandlung (z.B. Faltung von Box mit tent, da kann man resourcenschonend den bilinearen Filter der TMUs mitnutzen) normalerweise die bessere Wahl (oder man nimmt gleich einen bikubischen Filter oder Lanczos oder was auch immer). Und da läßt sich die "Smoothness" natürlich auch über die Größe des Kernels einstellen.

[OC_Burner]

Man kann auch einfach mal zufrieden sein. ;) Genug Flexibilität wird immerhin geboten, daß kann man nun NV nicht zum Nachteil auslegen bzw. muss man nicht jedes, vom "Treiber-Default" abweichende Detail ausklamüsern. Wenn du es AMD-like haben möchtest, verwendest halt die alte DS-Methode über Custom Resolution oder ziehst den DSR Smoothness-Slider weiter nach links.
Am Ende sollte man froh sein, das NVIDIA hier den ersten Schritt gewagt hat, sonst wäre es wohl kaum zu dieser kanadischen "Not-Reaktion" gekommen. :D

Ich bin ja auch zufrieden, nur mag ich auch gerne die Details aufzeigen. Wünschenswert wäre aber ein stärkerer Gaußfilter für noch höhere DSR-Faktoren. Das erhöhen des Sigmawertes (smoothness) über 100% hinaus via Registry-Editor bringt es nicht. Mehr als 13-Taps wären dafür notwendig.

[Nakai]

Gauß-Filter per Shader ist sicherlich nicht die billigste Variante (vom Rechenaufwand). Gerade deswegen wundert mich die Wahl doch etwas, da es bessere Alternativen gibt, die weniger Schärfe verlieren (bei gleicher Flimmerunterdrückung) als dieser doch sehr weichzeichnende Filter. Also da ist normalerweise irgendeine Tent-Filter-Abwandlung (z.B. Faltung von Box mit tent, da kann man resourcenschonend den bilinearen Filter der TMUs mitnutzen) normalerweise die bessere Wahl (oder man nimmt gleich einen bikubischen Filter oder Lanczos oder was auch immer). Und da läßt sich die "Smoothness" natürlich auch über die Größe des Kernels einstellen.

Keine Ahnung wie AMD dann downsampled. Ein Nearest Neighbor wird es nicht sein, Bilinear vergleicht imo zu wenig Nachbarn, Bikubisch wäre irgendwie zu langsam. Es wird wohl eine Art Gauß- bzw. Meanfilter sein, welche dynamisch zur Auflösung parametrisiert sein werden. Würde man von einer hohen Auflösung auf eine kleine runterskalieren, müsste man mehr Pixelnachbarn vergleichen. Wär interessant zu wissen, welche Art von Downsamplingfilter die verwenden. Bilinear wäre aber wohl das wahrscheinlichste oder sogar Trilinear. Eventuell kann man es durch die TMUs prügeln.

[Thunder99]

@Blaire:
Kritisieren soll auch eine Aufmunterung sein was zu verbessern :). Was Gipsel da geschrieben hat hört sich nach Möglichkeiten an das Feature besser aus sehen zu lassen als jetzt. Warum es nvidia nicht macht oder jetzt nur nicht wissen nur sie selber. Aber Verbesserungen kann man ja immer bringen sofern es technisch möglich ist (gibt es da Limitierungen?)

Fakt ist das FC4 mit 1620p bzw 4k (aber zu langsam) einfach deutlich besser aussieht als 1080p :D :up:

Und wie wir wissen, Konkurrenz belebt das Geschäft

[von Richthofen]

Zweites Spiel getestet aber leider schon den ersten Nachteil gefunden.
In Far Cry 4 mit VSR ist der Randlosmodus nun unbrauchbar. Dieser wird benötigt um das Stottern und Zuckeln in Bewegung auch bei hoher Framerate weitgehend zu minimieren. Das linke, obere Bildausschnitt wird auf das volle Maß des Bildschirms gestreckt.
Früher musste ich dazu die Aufskalierung aktivieren und konnte DS per Registry nutzen. Dies geht nun nicht mehr: Entweder Stottern und VSR im Vollbildmodus oder flüssig (Randlos) und FullHD. :(

Das erste Spiel funktioniert jedoch um so besser: Alien Rage bringt gleichmal die dreifachen Frameraten. 2560 und 8x AA mit ständig über 100 fps. Das ging sonst grad mal mit höchstens 2x flüssig überall. Muss wohl ein Treiberproblem gewesen sein. Allerdings zeigen auch Benchmarks nicht diese hohen Werte (https://translate.google.de/translate?hl=de&sl=ru&tl=de&u=http%3A%2F%2Fgamegpu.ru%2Faction-%2F-fps-%2F-tps%2Falien-rage-test-gpu.html).

[Mr.Magic]

Bei DSR kann man erst die Desktopauflösung ändern, und dann das Spiel im Fenstermodus starten. Das schon bei VSR versucht?

[von Richthofen]

So geht's, Danke.
In irgendeinem anderen Thread, den ich jetzt nicht raussuchen möchte, hab ich das erst kürzlich als Lösung für ein ähnliches Problem gepostet.......und prompt wieder vergessen :freak:

[aufkrawall]

Keine Ahnung wie AMD dann downsampled. Ein Nearest Neighbor wird es nicht sein, Bilinear vergleicht imo zu wenig Nachbarn, Bikubisch wäre irgendwie zu langsam. Es wird wohl eine Art Gauß- bzw. Meanfilter sein, welche dynamisch zur Auflösung parametrisiert sein werden. Würde man von einer hohen Auflösung auf eine kleine runterskalieren, müsste man mehr Pixelnachbarn vergleichen. Wär interessant zu wissen, welche Art von Downsamplingfilter die verwenden. Bilinear wäre aber wohl das wahrscheinlichste oder sogar Trilinear. Eventuell kann man es durch die TMUs prügeln.
Wieso wäre bikubisch zu langsam?
Trine 2 macht das, auch bei Serious Sam 3 kann man es auswählen. Runterskalieren kostet im Vergleich zu hochskalieren kaum Leistung, bestimmt auch nicht per ALUs.

[deekey777]

Gauß-Filter per Shader ist sicherlich nicht die billigste Variante (vom Rechenaufwand). Gerade deswegen wundert mich die Wahl doch etwas, da es bessere Alternativen gibt, die weniger Schärfe verlieren (bei gleicher Flimmerunterdrückung) als dieser doch sehr weichzeichnende Filter. Also da ist normalerweise irgendeine Tent-Filter-Abwandlung (z.B. Faltung von Box mit tent, da kann man resourcenschonend den bilinearen Filter der TMUs mitnutzen) normalerweise die bessere Wahl (oder man nimmt gleich einen bikubischen Filter oder Lanczos oder was auch immer). Und da läßt sich die "Smoothness" natürlich auch über die Größe des Kernels einstellen.

Da muss ich an CFAA denken. Wenn DAAMIT keinen hochwertigen Filter wie einen der CFAA-Modi verwendet, wäre das schade. Oder bin ich im falschen Film?

[robbitop]

AMD nutzt im Moment den HW Scaler der Grafikkarte mit. Das ist fixed function Kram. Aber in Phase 2 werden sie sicherlich das ganze über die Shader laufen lassen. Ich hoffe, dass sie dann gleich einen vernünftigen Filterkernel nehmen.

Selbst ein Lanczos Filter sollte eigentlich gemessen an der Gesamtrechenleistung einer aktuellen High End Karte wirklich wenig Aufwand bedeuten. Bei 60 fps hat die GPU 16 ms Zeit für das Rendern eines Bildes. Was sind dagegen vieleicht 10...100 µsek für's Downsampling? IMO nicht der Rede wert, ob es nun 10 µsek für einen einfachen Filter oder 100 µsek für einen komplexen Filter sind.

Schön wäre es, wenn man dem User die Wahl lässt, ob er einen aufwendigen DS Filter will oder einen einfachen.

[M4xw0lf]

AMD nutzt im Moment den HW Scaler der Grafikkarte mit. Das ist fixed function Kram. Aber in Phase 2 werden sie sicherlich das ganze über die Shader laufen lassen. Ich hoffe, dass sie dann gleich einen vernünftigen Filterkernel nehmen.

Selbst ein Lanczos Filter sollte eigentlich gemessen an der Gesamtrechenleistung einer aktuellen High End Karte wirklich wenig Aufwand bedeuten. Bei 60 fps hat die GPU 16 ms Zeit für das Rendern eines Bildes. Was sind dagegen vieleicht 10...100 µsek für's Downsampling? IMO nicht der Rede wert, ob es nun 10 µsek für einen einfachen Filter oder 100 µsek für einen komplexen Filter sind.

Schön wäre es, wenn man dem User die Wahl lässt, ob er einen aufwendigen DS Filter will oder einen einfachen.
Auf auf, tipp das nochmal ins AMD-Feedback-Formular ^^

[blaidd]

Schön wäre es, wenn man dem User die Wahl lässt, ob er einen aufwendigen DS Filter will oder einen einfachen.

Ich hab bei GeDoSaTo von Nearest Neighbour zu Lanzcos maximal einen halben Frame Leistungsunterschied beim DS von 3840×2400 zu 1.920 × 1.200. Ich weiß zwar nicht, ob sich das direkt vergleichen lässt (Durante scheint der Meinung zu sein), aber theoretisch könnte AMD (und auch Nvidia) beim Filter quasi "Nuts" gehen... Wer sich um das bisschen Leistung Sorgen machen muss, braucht mit dem Downsampling gar nicht erst anzufangen. :cool:

Der Lanzcos-Filter bietet aber klar die beste Bildqualität, das kann ja jeder mit GeDoSaTo selbst mal ausprobieren, einfach setNextScaling in den Keybindings aktivieren und im Spiel dann mit dem Hotkey mehrfach die Filter durchschalten. Der ist nicht nur schärfer, er zeigt auch mehr Details vom runtergerechneten Bild und wirkt auch frabgenauer. Ein auswählbarer und eventuell konfigurierbarer Filter wäre meiner Meinung das Optimum, vielleich plus die Option, bei VSR zusätzlich MLAA oder SMAA zu aktivieren (wobei ich mich da natürlich täuschen kann, weil ich ziemlich offensichtlich immer wieder die Intelligenz und/oder das Können des durchschnittlichen Users überschätze - den generellen PC-User, bevor hier einer eine Steilvorlage für einen AMD-User-Witz wittert :tongue:.) Ich hab da bei AMD schon mal diesbezüglich freundlich nachgetreten und werd auch das auch mal beim Treiber-Feedback angeben...

[robbitop]

Zumal es im Treiber vermutlich noch schneller geht, als wenn sich da eine 2. Applikation (Gedotosa) irgendwie mit "reindrängelt".

Ich denke auch, dass beide IHVs da nochmal in die Filter-Kiste greifen sollten. :)

[Hübie]

Ich bin mir gerade nicht sicher, aber könnte es sein dass register-space dann verknappt (bilinear is da ja relativ simpel gestrickt)? Also wenn über ALUs skaliert wird...
Sorry, falls brainfart ;D

[DrFreaK666]

Auf auf, tipp das nochmal ins AMD-Feedback-Formular ^^

Wo finde ich ihn? Bin zwar aktuell NV-User, aber irgendwann ist auch meine GTX780 zu langsam (oder 3GB zu wenig (kommt jetzt schon manchmal vor))

[Nakai]

Wieso wäre bikubisch zu langsam?
Trine 2 macht das, auch bei Serious Sam 3 kann man es auswählen. Runterskalieren kostet im Vergleich zu hochskalieren kaum Leistung, bestimmt auch nicht per ALUs.

Bikubisch nutzt Splines um Werte zu interpolieren. Je nach Spline-Funktion kann das schon etwas mehr kosten. Wenn man es einfach linear macht, dann kostet es nicht soviel, klar.
Man muss eben pro Ausgabepixel eine bestimmte Anzahl an Operationen durchführen, um den neuen Farbwert zu berechnen.

AMD nutzt im Moment den HW Scaler der Grafikkarte mit. Das ist fixed function Kram. Aber in Phase 2 werden sie sicherlich das ganze über die Shader laufen lassen. Ich hoffe, dass sie dann gleich einen vernünftigen Filterkernel nehmen.

Selbst ein Lanczos Filter sollte eigentlich gemessen an der Gesamtrechenleistung einer aktuellen High End Karte wirklich wenig Aufwand bedeuten. Bei 60 fps hat die GPU 16 ms Zeit für das Rendern eines Bildes. Was sind dagegen vieleicht 10...100 µsek für's Downsampling? IMO nicht der Rede wert, ob es nun 10 µsek für einen einfachen Filter oder 100 µsek für einen komplexen Filter sind.

Schön wäre es, wenn man dem User die Wahl lässt, ob er einen aufwendigen DS Filter will oder einen einfachen.

Da hast du schon recht, vor allem, wenns über den Treiber gelöst wird. Ich hoffe jedoch nicht, dass es hierbei zu Gräbenkämpfen zwischen AMD und NV-Fanboys kommt, weil eine Implementierung eben schneller, langsamer, besser oder schlechter läuft.

Ich denke auch, dass beide IHVs da nochmal in die Filter-Kiste greifen sollten.

Naja die sollten schon was passendes finden.

[von Richthofen]

Der Lanzcos-Filter bietet aber klar die beste Bildqualität, das kann ja jeder mit GeDoSaTo selbst mal ausprobieren, einfach setNextScaling in den Keybindings aktivieren und im Spiel dann mit dem Hotkey mehrfach die Filter durchschalten. Der ist nicht nur schärfer, er zeigt auch mehr Details vom runtergerechneten Bild und wirkt auch frabgenauer.

So gehen die Meinungen auseinander.....ich hab eine ganze Reihe an Spielen mit GeDoSaTo verschönern dürfen - die Wahlmöglichkeit der Filter ist Klasse - und mich bei keinem für den Lanczos-Filter entschieden. Der ist wirklich um einiges schärfer, kostet im Gegensatz zu den beiden anderen das ein oder andere Frame (nicht mehr als FXAA low) mehr, bringt schonmal ein weisses Bild und fördert mehr Details zu Tage, die aber im Bewegtbild (wieder mal die Vegetationsdarstellung) zu Flimmern beginnen. Auch in "vegetationsfreien", wenig detailreichen Spielen wie Dishonored (Entschuldigung bitte) entscheide ich mich klar gegen den Lanczos.
Von den anderen blurrt manchmal der bilineare mehr (Legend of Grimrock 2), meistens aber der bikubische (Risen 3, Dishonored, Might and Magic X,....)

Die Wahlmöglichkeit des Filters wäre natürlich das Sahnehäubchen. Im Moment braucht es aber einfach noch mehr an Wahlmöglichkeiten bei den Unterteilungen der Auflösungen und natürlich der Unterstützung von Grafikkarten.

[robbitop]

Ich bin mir gerade nicht sicher, aber könnte es sein dass register-space dann verknappt (bilinear is da ja relativ simpel gestrickt)? Also wenn über ALUs skaliert wird...
Sorry, falls brainfart ;D
Ich denke nicht. Je komplexer der Filter, in desto mehr Operationen wird er aufgespalten. Analog zu Taylorreihen.
Die ALU führt also eine Reihe Rechenoperationen hintereinander aus, um das Ergebnis zu ermitteln. Aber jede Teilrechnung benötigt nicht mehr Register als andere Operationen.

Außerdem ist der Gesamtaufwand, ein Bild einer aktuellen 3D Anwendung zu rastern, zu texturieren, zu beleuchten etc um viele Größenordnungen höher als einfach nur 1x ein 2 dimensionales Bild aus ein paar Millionen Pixeln downzusamplen.

[Gipsel]

So gehen die Meinungen auseinander.....ich hab eine ganze Reihe an Spielen mit GeDoSaTo verschönern dürfen - die Wahlmöglichkeit der Filter ist Klasse - und mich bei keinem für den Lanczos-Filter entschieden. Der ist wirklich um einiges schärfer, kostet im Gegensatz zu den beiden anderen das ein oder andere Frame (nicht mehr als FXAA low) mehr, bringt schonmal ein weisses Bild und fördert mehr Details zu Tage, die aber im Bewegtbild (wieder mal die Vegetationsdarstellung) zu Flimmern beginnen. Auch in "vegetationsfreien", wenig detailreichen Spielen wie Dishonored (Entschuldigung bitte) entscheide ich mich klar gegen den Lanczos.
Von den anderen blurrt manchmal der bilineare mehr (Legend of Grimrock 2), meistens aber der bikubische (Risen 3, Dishonored, Might and Magic X,....)

Die Wahlmöglichkeit des Filters wäre natürlich das Sahnehäubchen. Im Moment braucht es aber einfach noch mehr an Wahlmöglichkeiten bei den Unterteilungen der Auflösungen und natürlich der Unterstützung von Grafikkarten.Bei einem Filterkernel kann man die Form (also die Art des Filters [Tent, Gauß, Lanczos, whatever]) und Breite (Menge der zur Berechnung einbezogenen Pixel) typischerweise unabhängig wählen. Macht man den Lanczos-Kernel größer, filtert er hohe Frequenzen stärker (unterdrückt also Flimmern auf Kosten von Details), bleibt aber trotzdem noch schärfer als z.B. Gauß. Wenn man nicht mutwillig und unnötig blurren will, ist Gauß eine schlechte Wahl. So oder so hat man bei einer optimalen Lösung nicht nur die Wahl zwischen verschiedenen Filtern sondern auch eine Einstellmöglichkeit zur Wahl der Größe dieser (als Standard eben 1 Pixel in der letztendlich ausgegebenen Auflösung [mehr in der zwischendurch gerenderten], bei "guten" Filtern werden aber immer auch Samples außerhalb der nominellen Breite genommen und mitverrechnet [bei Lanczos2 wären es standardmäßig [um auf der Nyquist-Grenze zu liegen] alle Samples innerhalb eines 4x4 Pixel großen Fläche der Ausgabeauflösung, also bei 4k auf 1080p Downsampling 64 Samples, bei Vergrößerung des Kernels zur stärkeren Flimmerunterdrückung entsprechend mehr]).
Edit:
Bei 4k=>1080p Downsampling mit Lanczos2 wären das also 128MSamples pro Frame, bei 60fps ~7,7 GSamples/s. Bei einer GPU mit 128TMUs bei 1GHz würde also allein das harte TMU-Limit etwa 6% der GPU-Zeit erfordern (1ms pro Frame). Mit Lanczos3 wären es bereits ~14%, mit zusätzlicher Flimmerunterdrückung mehr. Erforderliche ALU-Resourcen sind dabei noch nicht berücksichtigt. Eventuell kann man bei alten Games mit 32bit Framebuffer mit fetch4 rumtricksen und das etwas reduzieren, aber keine Ahnung.

[Knuddelbearli]

AMD nutzt im Moment den HW Scaler der Grafikkarte mit. Das ist fixed function Kram. Aber in Phase 2 werden sie sicherlich das ganze über die Shader laufen lassen. Ich hoffe, dass sie dann gleich einen vernünftigen Filterkernel nehmen.

Selbst ein Lanczos Filter sollte eigentlich gemessen an der Gesamtrechenleistung einer aktuellen High End Karte wirklich wenig Aufwand bedeuten. Bei 60 fps hat die GPU 16 ms Zeit für das Rendern eines Bildes. Was sind dagegen vieleicht 10...100 µsek für's Downsampling? IMO nicht der Rede wert, ob es nun 10 µsek für einen einfachen Filter oder 100 µsek für einen komplexen Filter sind.

Schön wäre es, wenn man dem User die Wahl lässt, ob er einen aufwendigen DS Filter will oder einen einfachen.


Wieso versteift ihr euch so auf die Taktzyklen? Ich würde darauf tippen das der cache / register usw viel stärker limitiert muss ja bei 60 fps oder gar mehr ordentlich was durchgeschaufelt werden wobei gerade da eventuell die neuen Komprimierungsalgorythmen gut was bringen.

Klar ists dann sicher immer noch billig aber kommt mal vom Tunnelblick auf dei ALUs weg

[Gipsel]

Ich habe doch schon geschrieben, wie stark allein die Fetches bei einer klassischen Pixelshaderimplementierung (was wohl dieses Gedotosa macht) limitieren würden. Gute Filter sind schon bandbreitenintensiv, zumindest hin zu den Caches, die da schon recht gut was abfangen sollten (benachbarte Pixel nutzen zum großen Teil die gleichen Samples, nur anders gewichtet). Man kann natürlich auch versuchen, das etwas cleverer zu machen (Daten über local memory wieder benutzen anstatt für jeden Ausgabepixel Alles neu Laden oder gleich mehrere Ausgabepixel in jedem workitem/"thread" berechnen).

[aufkrawall]

Jemand müsste eine Art "DS-Tester" in der Art des Filtertester schreiben. Ansonsten fürchte ich, werden die IHVs wieder ewig ihre Praktikanten dran rumdoktorn lassen. Kennt man ja schon, das Prozedere.

[Gipsel]

Jemand müsste eine Art "DS-Tester" in der Art des Filtertester schreiben. Ansonsten fürchte ich, werden die IHVs wieder ewig ihre Praktikanten dran rumdoktorn lassen. Kennt man ja schon, das Prozedere.
Einfach senkrecht auf die (verkleinerte) ground2-Textur blicken, die dabei ein wenig hin und her fährt? Dann sehen, wer da mehr Details und weniger Flimmern bietet. Leider kann man da kaum eine Referenzimplementation im Splitscreen daneben hauen, die würde ja durch das herstellerspezifische Downsampling ebenfalls beeinflußt.

[aufkrawall]

Leider sind Treiberentwickler ziemlich stur und unwillig, irgendwas zu ändern, so lange das Resultat nicht "Error" ist, oder sie nicht den direkten Vergleich gebuttert in einem Splitscreen-Fenster serviert bekommen.
So habe ich das zumindest mehrmals mitbekommen. Und eine gewisse Firma, die sich nun mit User-Nähe brüstet, reagierte selbst auf Reports für Dummies nicht...

[robbitop]

Wieso versteift ihr euch so auf die Taktzyklen? Ich würde darauf tippen das der cache / register usw viel stärker limitiert muss ja bei 60 fps oder gar mehr ordentlich was durchgeschaufelt werden wobei gerade da eventuell die neuen Komprimierungsalgorythmen gut was bringen.

Klar ists dann sicher immer noch billig aber kommt mal vom Tunnelblick auf dei ALUs weg
60 Bilder in der Sekunde downzusamplen ist kein Problem.

Ich habe das Gefühl, dass das Verhältnis unklar ist. Wie lange und aufwändig es ist ein 3D Bild zu rechnen und wie pupsig es ist das fertige Frame durch einen Filter zu jagen. Shadercode für Beleuchtung ist eine ganz andere Größenordnung was Verzweigung, Hitrate, Abhängigkeit und Fragmentierung angeht.

Mal grob überschlagen:
Ein 4K Bild ist ca 32 MiB groß. Das sind bei 60 fps lächerliche 2 GiB/s. Und das st eine Aufgabe die auch wunderbar unfragmentierten Verkehr erzeugt.

Und selbst der heftigste Filter sollte in 100 Takten durch sein (wobei das schon eine sehr sehr pessimistische Annahme ist - vermutlich sind es eher 10..50 Takte). Und dann hast du eine Last von 50 GFLOPs/sek. Und auch hier ist das fluffiger Code, der einfach durchläuft. Keine Verzweigungen, kein gar nichts.

Die Kosten sollten also im 0,x fps Bereich liegen, wenn das direkt über den Treiber läuft.

Das sind jeweils 2 Größenordnungen unter den Leistungen einer Grafikkarte. Die GeDoToSa Messungen bestätigen das ja. Dort kostet es ein kleines bisschen mehr, weil sich ein (sicher nicht optimal programmiertes) externes Programm noch dazwischendrängelt.

[Tesseract]

Einfach senkrecht auf die (verkleinerte) ground2-Textur blicken, die dabei ein wenig hin und her fährt? Dann sehen, wer da mehr Details und weniger Flimmern bietet.

das flimmern ist schräg viel größer als senkrecht, dazu muss man auch nix skalieren. einfach so testen wie bisher auch, dann sieht man die unterschiede sofort.

[Gipsel]

das flimmern ist schräg viel größer als senkrecht, dazu muss man auch nix skalieren. einfach so testen wie bisher auch, dann sieht man die unterschiede sofort.Beim Downsampling ändert man ja nix am Rest. Man skaliert nur ein Bild von einer Auflösung auf eine andere. Wenn man das also möglichst getrennt von AF untersuchen will, helfen irgendwelche ominösen Winkel gar nichts sondern stören eher.

@robbitop:
Man benötigt schon recht viele Samples für gute Filter. Und das dauert dann auch schon deutlich länger als 10 bis 50 Takte, um z.B. 64 Samples pro ausgegebenem Pixel beim Lanczos2 oder gar 144 Samples pro Pixel eines Lanczos3-Filters beim 4k zu 1080p Downsampling zu verrechnen. Erstmal müssen die ganzen Samples von irgendwo kommen. Wenn man zudem nicht die numerisch vereinfachte Variante eines separierbaren Filters nehmen will (Skalierung in x- und y-Richtung sind unabhängig voneinander und auch getrennt durchführbar, ergibt bei Lanczos aber z.B. Artefakte, Tent-Filter haben keine Probleme damit, die sind immer separierbar [mit ein Grund, warum die so beliebt sind, die sind billig und trotzdem nicht zu schlecht]), ist das auch numerisch durchaus nicht ganz unaufwendig, da man im worst-case wirklich den Abstand des Samples zum Pixelzentrum ausrechnen muß (das ist jeweils eine inverse squareroot pro Sample, also schon mal mindestens 4 Takte ALU pro Sample bei GCN und das ist ja längst noch nicht Alles, weil man ja auch noch pro Sample das Filtergewicht in Abhängigkeit von diesem Abstand berechnen und schlußendlich die Samples damit verrechnen muß, da kann man am Ende locker auf mehr als 1000 Takte pro Pixel kommen), zumindest wenn man auch alle "krummen" Downsampling-Auflösungen erlauben will und nicht nur eine feste 1:2 lineare Skalierung (oder sehr wenige feste).
Oder natürlich, man spart irgendwo und macht Kompromisse. Eine Abwägung, welche numerischen Ungenauigkeiten man sich erlauben kann, ohne zu viel Qualität zu verlieren wird dann schon wichtig.

[Tesseract]

Beim Downsampling ändert man ja nix am Rest. Man skaliert nur ein Bild von einer Auflösung auf eine andere. Wenn man das also möglichst getrennt von AF untersuchen will, helfen irgendwelche ominösen Winkel gar nichts sondern stören eher.

die frequenzen im bild sind höher und das ganze ist außerdem praxisnäher. probier es halt aus und überzeug dich selbst davon.

[Gipsel]

die frequenzen im bild sind höher und das ganze ist außerdem praxisnäher. probier es halt aus und überzeug dich selbst davon.Man kann in ein Bild beliebige Frequenzen einbauen, unabhängig von irgendwelchen Winkeln. Das letztendliche Downsampling ist nur die Auflösungsverringerung einer flachen 2D-Grafik. Will man das explizit testen, macht man genau das. ;)

[von Richthofen]

Vllt. mal ein Screenshot-Vergleich zwischen Custom DS und VSR.
Sind "nur" komprimierte Fraps-Shots mit Kompression aber trotzdem sieht man Unterschiede.
1600p 8x MSAA Custom (links) und VSR.


Im VSR-Bild "franst" es am Geländer ziemlich aus. Das ist auch mit bloßem Auge im Rest des Spieles zu erkennen, wenn man's weiss. Mglw. hat das mit der höheren Schärfe von VSR zu tun. Die sieht man aber in 3D (bislang) nicht - in Windows fällt das jedoch sofort auf.

http://abload.de/thumb/custommnucv.jpg (http://abload.de/image.php?img=custommnucv.jpg) http://abload.de/thumb/vsrtwusr.jpg (http://abload.de/image.php?img=vsrtwusr.jpg)


Hat jemand Custom-Auflösungen nebst VSR lauffähig gebracht? Das beisst sich hier und hat leider höhere Auflösungen als 1600p gekostet.

[Tesseract]

Man kann in ein Bild beliebige Frequenzen einbauen, unabhängig von irgendwelchen Winkeln.

man kann auch einfach die vorhandene infrastruktur nehmen und gut ist's. im filtertester bekommt man diese frequenzen ohne winkel jedenfalls nicht hin, da müsste man die ground2-textur wo anders rein laden, händisch die größe anpassen und dann irgendwie eine konstante, nachvollziehbare bewegung hin bekommen. willst du das machen? ;)

[Gipsel]

man kann auch einfach die vorhandene infrastruktur nehmen und gut ist's. im filtertester bekommt man diese frequenzen ohne winkel jedenfalls nicht hin, da müsste man die ground2-textur wo anders rein laden, händisch die größe anpassen und dann irgendwie eine konstante, nachvollziehbare bewegung hin bekommen. willst du das machen? ;)Bis auf den Winkel ist das (also Größenanpassung und Bewegung) bereits in den AF-Tester eingebaut. Das ist also nur ein Schieberegler für den Winkel mehr. Das dauert vermutlich keine 5 Minuten, das hinzuzufügen. ;)

[Tesseract]

nochmal: das texture scaling erzeugt bei 90° keine frequenzen die so hoch sind wie bei ganz normalen, gekippten texturen mit 16xAF. probier es doch einfach aus statt dauernd dagegen zu reden dann wüstest du das bereits.
die problematik zeigt sich genau da wo auch damals das fehlerhafte AF geflimmert hat, jedoch auch mit codas referenzimplementierung, d.h. es hat nix mit AMDs filterung zu tun, sehr wohl jedoch mit dem bilinearen filter, denn mit dem gauss flimmert in der gleichen situation nix. (und da der defaultwert beim gauss nur ~3-5% über der flimmerschwelle liegt nehme ich an nvidia hat sich bei dem wert etwas gedacht)

[samm]

Vllt. mal ein Screenshot-Vergleich zwischen Custom DS und VSR.
Sind "nur" komprimierte Fraps-Shots mit Kompression aber trotzdem sieht man Unterschiede.
1600p 8x MSAA Custom (links) und VSR.Im VSR-Shot ist kein MSAA mehr aktiv, oder? VSR @"1800p" bietet so ja nur minimalste Zusatzglättung gegenüber 1600p (1.125x1.125 OGSSAA) - Treppe und Geländer zeigen deutlich Treppenmuster.

[edit]
Hab's wohl falsch verstanden, der VSR-Shot ist wohl nicht 1800p @1600p sondern 1600p @1080p. Screenshot ist trotzdem in der höheren Auflösung und soweit ich das sehen kann ohne AA.

[von Richthofen]

Hab's wohl falsch verstanden, der VSR-Shot ist wohl nicht 1800p @1600p sondern 1600p @1080p. Screenshot ist trotzdem in der höheren Auflösung und soweit ich das sehen kann ohne AA.

Beide sind 1600p @1200p 8x MSAA.
Das Bild wird in beiden Fällen gut geglättet. Auf Screenshots sieht man erst das Ausfransen. Man sieht's auch im Spiel, wenn man es weiss. Ist nicht störend, aber der Fakt irritiert etwas.

[aths]

In Bezug auf den Streit einige Seiten vorher im Thread: Auch wenn die AMD-Lösung später kam und noch nicht so flexibel ist wie die NV-Lösung, raffe ich nicht, wie es jemandem die Zeit und Energie wert sein kann, Häme auszuschütten.

Die NV-Lösung kam ja auch Jahre zu spät, dass AMD noch einige Monate länger brauchte fällt da nicht groß ins Gewicht.

Der neue Omega-Treiber bringt neue Features die sich direkt in mehr BQ umsetzen lassen auch für bestehende Graka-Modelle. Das ist doch rein positiv.

[-/\-CruNcher-/\-]

Sie marketing mit Rubys neuer incarnation aber die neue Ruby Demo haben sie immernoch nicht Released, langsam aber sicher setzt die Staub an (Ilfonic und Cryteks Auftragsarbeit) ;)

Vor allem die Video feature enhancements hören sich interessant an ;)

[Noebbie]

Sie marketing mit Rubys neuer incarnation aber die neue Ruby Demo haben sie immernoch nicht Released ;)

Auf die wär' ich auch scharf! ;)

[Gipsel]

Das wird jetzt zwar etwas OT, aber einmal versuche ich es noch.nochmal: das texture scaling erzeugt bei 90° keine frequenzen die so hoch sind wie bei ganz normalen, gekippten texturen mit 16xAF.Das stimmt so nicht. Die maximalen Frequenzen im Bild sind erst mal unabhängig vom AF. Bei sehr hohen Anisotropien (und korrekter AF-Filterung) fehlen sogar tendentiell sehr hohe Frequenzen durch die Limitierung auf 16xAF (um das klar zu zeigen benötigt man allerdings etwas konstruierte Szenarien).
probier es doch einfach aus statt dauernd dagegen zu reden dann wüstest du das bereits.Ich kenne den AF-Tester und weiß, was ich weiß.
Ich vermute aber nach dieser Passage:
die problematik zeigt sich genau da wo auch damals das fehlerhafte AF geflimmert hat, jedoch auch mit codas referenzimplementierung, d.h. es hat nix mit AMDs filterung zu tun, sehr wohl jedoch mit dem bilinearen filter, denn mit dem gauss flimmert in der gleichen situation nix. (und da der defaultwert beim gauss nur ~3-5% über der flimmerschwelle liegt nehme ich an nvidia hat sich bei dem wert etwas gedacht)daß wir immer noch aneinander vorbei reden.
Mein Punkt war, daß wenn man die Qualität des Downsampling testen will, dies möglichst unbeeinflußt von anderen Faktoren machen sollte.
Wenn bei AF was in Bewegung flimmert, ist es nicht primär Ausdruck für hohe Frequenzen im Bild, sondern für eine suboptimale Filterung, die es nicht schafft, alle in den Texturen vorhandenen Frequenzen oberhalb der Nyquist-Grenze abzuschneiden. Diese sind im fertigen Bild nicht darstellbar und werden auf den niedrigeren (darstellbaren) Frequenzbereich zurückgefaltet (dies ergibt eine Art Moiree-Effekt). In Bewegung flimmert es dann (ständiger Wechsel der Moiree-Muster von Frame zu Frame, also mit der Zeit [dazu sind nicht zwingend hohen Ortsfrequenzen im fertigen Bild nötig!]), jeder einzelne Frame für sich betrachtet enthält aber faktisch natürlich nur darstellbare Frequenzen. Das Kind ist sozusagen bereits in den Brunnen gefallen. Beim AF ergibt sich das "Restflimmern" sowohl durch nicht Nyquist-konform gefilterte MipMaps als auch die suboptimale AF-Filterung selber. Die ist ja praktisch eine Faltung eines Tent- mit einem Box-Filter. Das geht besser (mit mehr Rechenaufwand), was das AF-Flimmern bei Erhalt der Schärfe (fast) komplett eliminiert (selbst getestet mit Faltung aus Lanczos und tent [bilinear] statt Box und Tent [Codas Referenz und das, was GPUs tun]). Der bilineare Filter ist überhaupt kein Problem für die Flimmerneigung, wenn der Rest stimmt.
Der entscheidende Punkt ist, daß es beim AF auch Unterschiede zwischen den Herstellern gibt. Testet man also DSR/VSR mit aktivem AF am "AF-Flimmern" so kann man den AF-Filter-Algo nicht gut vom Downfilter-Algo trennen (beide filtern höher aufgelöste Bildinformationen auf eine niedrigere Auflösung herunter, nur nacheinander). Supersampling/Downsampling hilft zwar meist auch gegen das AF-Flimmern etwas, wie gut der Filter des Downsamplings funktioniert, vergleicht man aber besser isoliert davon, also ohne Unterschiede im AF-Filter. Daß man zwei unterschiedliche Sachen besser getrennt testet und bewertet als irgendeine undefinierte Mischung sollte eigentlich irgendwo im kleinen Einmaleins des Testens vermerkt sein.

Ein durchaus denkbares Ergebnis wäre es ja z.B. daß man AMD attestieren kann, daß ihr Downsampling-Filter bessere Ergebnisse liefert als der von nV (getestet mit dem hypothetischen DS-Tester mit senkrechtem Blick auf Flächen), nV beim AF-Filter in Grenzfällen vorne liegt (AF-Tester) und es beim Gesamtbildeindruck je nachdem, was in der konkreten Szene wichtiger ist, mal der eine, mal der andere vorne liegt oder Gleichstand herrscht (getestet mit Spielen oder auch AF-Tester mit aktiviertem DS).

[Grestorn]

In Bezug auf den Streit einige Seiten vorher im Thread: Auch wenn die AMD-Lösung später kam und noch nicht so flexibel ist wie die NV-Lösung, raffe ich nicht, wie es jemandem die Zeit und Energie wert sein kann, Häme auszuschütten.

+1

[Tesseract]

Die maximalen Frequenzen im Bild sind erst mal unabhängig vom AF. Bei sehr hohen Anisotropien (und korrekter AF-Filterung) fehlen sogar tendentiell sehr hohe Frequenzen durch die Limitierung auf 16xAF (um das klar zu zeigen benötigt man allerdings etwas konstruierte Szenarien).
es geht überhaupt nicht um die maximalen frequenzen im bild sondern darum, dass die textur von oben, egal ob mit oder ohne skalierung, nicht detailiert genug ist um das problem aufzuzeigen, in der schräge jedoch schon.

Der entscheidende Punkt ist, daß es beim AF auch Unterschiede zwischen den Herstellern gibt.
um das geht es nicht. AMD-AF und codas implementierung flimmern auf nativer auflösung beide fast garnicht, mit VSA aber beide vergleichbar stark. der unterschied zwischen native und VSA ist um ein vielfaches größer als der zwischen den verschiedenen AF-implementierungen. außerdem sieht man das problem auch bei sich bewegender schrift oder anderen 2D-interfaceelementen mit hohen kontrasten die in bewegung stärker "rummorphen" als mit gauss@33%.

Supersampling/Downsampling hilft zwar meist auch gegen das AF-Flimmern etwas, wie gut der Filter des Downsamplings funktioniert, vergleicht man aber besser isoliert, also ohne Unterschiede im AF-Filter davon.
dann vergleich beides mit codas implementierung. macht absolut keinen signifikanten unterschied.
du kannst auch ein bild vom filtertester machen und das statische bild dann rum schieben - flimmert mit (ungeradem) VSA ebenfalls rum.

Ich vermute aber nach dieser Passage:
daß wir immer noch aneinander vorbei reden.
bingo, und so lange du dich weigerst dir das problem selbst anzusehen um überhaupt zu verstehen was ich meine wird sich das wohl auch nicht ändern.

[Gipsel]

es geht überhaupt nicht um die maximalen frequenzen im bild sondern darum, dass die textur von oben, egal ob mit oder ohne skalierung, nicht detailiert genug ist um das problem aufzuzeigen, in der schräge jedoch schon.Korrektes AF schließt das gerade aus. AF verhindert gegenüber bi-/trilinearem Filter nur den Schärfeverlust bei schrägem Blick auf Flächen, absolut schärfer wird es nicht (kann es nicht werden). Die erkennbaren Details werden auch nicht unbedingt kleiner (in Pixeln im fertig gerendertem Bild) als bei senkrechtem Blick, es sei denn man startet mutwillig mit einer low-frequency Textur.
Btw. warst Du der Erste, der von hohen Frequenzen im Bild geredet hat.
um das geht es nicht.Mir schon. Einstieg war ja aufkrawalls Vorschlag eines DS-Testers, der isoliert die AMD- und nV-Lösungen zum Downsampling möglichst unter gleichen Ausgangsbedingungen vergleicht.
AMD-AF und codas implementierung flimmern auf nativer auflösung beide fast garnicht, mit VSA aber beide vergleichbar stark. der unterschied zwischen native und VSA ist um ein vielfaches größer als der zwischen den verschiedenen AF-implementierungen. außerdem sieht man das problem auch bei sich bewegender schrift oder anderen 2D-interfaceelementen mit hohen kontrasten die in bewegung stärker "rummorphen" als mit gauss@33%.Ich dachte, wir hätten bereits vor ein paar Seiten im Thread festgestellt, daß bisher suboptimale Downfilter benutzt werden. Bei AMD ist doch sogar unbekannt, was benutzt wird (oder hat sich das geändert?), nV nutzt (bei krummen Verhältnissen) offenbar Gauß/Nearest neighbor, bei geraden Verhältnissen wohl Box. Gut ist was Anderes. Ein Blurfilter kann ja kaum die Lösung sein. Da verliert man gleich wieder Details, die man mit viel Aufwand durch die höhere interne Auflösung erkämpft hat.
dann vergleich beides mit codas implementierung. macht absolut keinen signifikanten unterschied.
du kannst auch ein bild vom filtertester machen und das statische bild dann rum schieben - flimmert mit (ungeradem) VSA ebenfalls rum.Weil das bisher eben alle noch nicht gut genug machen. Das kann sich aber ändern. Muß man ein prinzipiell schlechteres Testverfahren wählen, nur weil im momentanen Zustand entsprechende Unterschiede noch nicht erkennbar sind?
bingo, und so lange du dich weigerst dir das problem selbst anzusehen um überhaupt zu verstehen was ich meine wird sich das wohl auch nicht ändern.Ich verstehe Dich schon, keine Angst.

[Tesseract]

selbe textur, selbe einstellung, anderer winkel:
http://i.imgur.com/D1rvVa9.png

[Gipsel]

Und?
Ist übrigens auch insgesamt eine deutlich andere Skalierung, also nicht nur Winkel anders.

[Tesseract]

ist es nicht. ich hab einen screenshot gemacht, das bild gekippt und noch einen screenshot gemacht.

so, und jetzt sag ich es zum letzten mal: mach das verdammte programm auf und überzeug dich selbst, wenn du mir nicht glaubst.

[aths]

ist es nicht. ich hab einen screenshot gemacht, das bild gekippt und noch einen screenshot gemacht.

so, und jetzt sag ich es zum letzten mal: mach das verdammte programm auf und überzeug dich selbst, wenn du mir nicht glaubst.
Durch das Kippen verschiebt man doch die Perspektive. Man dürfte es lediglich stauchen. Wenn die Textur vorher schon an der Grenze ist, wird sie gestaucht mit AF auch maximal an der Grenze sein, aber nicht schärfer – es sei denn, der anisotrope Filter ist, äh, "optimiert".

[Tesseract]

Wenn die Textur vorher schon an der Grenze ist
ist sie nicht, genau das ist der punkt.

[Hübie]

Der Abstand zur Textur muss konstant sein. Nicht der Radius vom Mittelpunkt aus. Und so wie es aussieht hast du den Abstand verändert. Damit bildet sich ja automatisch ein anderes Gefüge.

[robbitop]

Beim Downsampling ändert man ja nix am Rest. Man skaliert nur ein Bild von einer Auflösung auf eine andere. Wenn man das also möglichst getrennt von AF untersuchen will, helfen irgendwelche ominösen Winkel gar nichts sondern stören eher.

@robbitop:
Man benötigt schon recht viele Samples für gute Filter. Und das dauert dann auch schon deutlich länger als 10 bis 50 Takte, um z.B. 64 Samples pro ausgegebenem Pixel beim Lanczos2 oder gar 144 Samples pro Pixel eines Lanczos3-Filters beim 4k zu 1080p Downsampling zu verrechnen. Erstmal müssen die ganzen Samples von irgendwo kommen. Wenn man zudem nicht die numerisch vereinfachte Variante eines separierbaren Filters nehmen will (Skalierung in x- und y-Richtung sind unabhängig voneinander und auch getrennt durchführbar, ergibt bei Lanczos aber z.B. Artefakte, Tent-Filter haben keine Probleme damit, die sind immer separierbar [mit ein Grund, warum die so beliebt sind, die sind billig und trotzdem nicht zu schlecht]), ist das auch numerisch durchaus nicht ganz unaufwendig, da man im worst-case wirklich den Abstand des Samples zum Pixelzentrum ausrechnen muß (das ist jeweils eine inverse squareroot pro Sample, also schon mal mindestens 4 Takte ALU pro Sample bei GCN und das ist ja längst noch nicht Alles, weil man ja auch noch pro Sample das Filtergewicht in Abhängigkeit von diesem Abstand berechnen und schlußendlich die Samples damit verrechnen muß, da kann man am Ende locker auf mehr als 1000 Takte pro Pixel kommen), zumindest wenn man auch alle "krummen" Downsampling-Auflösungen erlauben will und nicht nur eine feste 1:2 lineare Skalierung (oder sehr wenige feste).
Oder natürlich, man spart irgendwo und macht Kompromisse. Eine Abwägung, welche numerischen Ungenauigkeiten man sich erlauben kann, ohne zu viel Qualität zu verlieren wird dann schon wichtig.

Selbst 1000 Takte pro Pixel sind noch zu verschmerzen. Die Sache ist halt, dass es nur 60x pro Sekunde getan werden muss. Dann kostet es halt 1 fps. Wenn man sich 4x Downsampling leisten kann, dann kann man 1-2 fps auch noch verschmerzen.

Vielleicht verbaut ja mal ein IHV Fixed Function Hardware dafür.

[Locuza]

Damit hat PCGH die Antwort von AMD nicht falsch interpretiert:
Question: Will there be support of 4K VSR (3840x2160) on Hawaii R9 290X/290 in the future?
Robert Hallock: We do intend to extend 4K downsampling to all R9 and R7 Series products, 260 and up, with a driver in the Jan/Feb timeframe.

http://hardforum.com/showpost.php?p=1041284038&postcount=105

Ebenso untersucht man weitere Auflösungsmöglichkeiten mit unterschiedlichen Refreshrates.

Man darf gespannt sein.

[Gipsel]

Wenn die Textur vorher schon an der Grenze ist, wird sie gestaucht mit AF auch maximal an der Grenze sein, aber nicht schärfer – es sei denn, der anisotrope Filter ist, äh, "optimiert".Mein Reden (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=10450815#post10450815).
Man braucht kein AF, um irgendwas im Bild an die Grenze (oder drüber, z.B. per LOD-Bias oder - als Beispiel einer ganz andere Baustelle - Shaderflimmern) zu bringen.
ist sie nicht, genau das ist der punkt.Das ist nicht der Punkt. Dann nimmst Du eben eine andere Textur, im Zweifel ein Schachbrett. Ist doch total irrelevant für das allgemeine Prozedere. Es stört nur, falls es Unterschiede beim AF gibt, wenn man DS isoliert bewerten will. Das war der Ausgangspunkt, die Minimierung möglicher Störeinflüsse auf die Bewertung.

[Tesseract]

Das ist nicht der Punkt. Dann nimmst Du eben eine andere Textur, im Zweifel ein Schachbrett.

doch, genau das ist der punkt:

Bis auf den Winkel ist das (also Größenanpassung und Bewegung) bereits in den AF-Tester eingebaut.

das texture scaling erzeugt bei 90° keine frequenzen die so hoch sind wie bei ganz normalen, gekippten texturen mit 16xAF.

und abgesehen davon, dass man auch mit mit der maxfreq-textur im tester keine maximale frequenz auf 90° hin bekommt ist ein schachbrett vollkommen praxisfern. die frage ist nicht welcher filter mit einem schachbrett- sondern welcher mit echten, sinnvollen texturen besser zurecht kommt. das schachbrett flimmert weniger, je mehr man es mit dem gauss vorher zu brei zermatscht. was genau soll das über sinnvolle schwellwerte für texturen aussagen?

[Grestorn]

das schachbrett flimmert weniger, je mehr man es mit dem gauss vorher zu brei zermatscht. was genau soll das über sinnvolle schwellwerte für texturen aussagen?

Der Witz dabei ist doch, dass die einzig korrekte Abbilung eines Schachbretts bei Unterabtastung eben die gleichförmige, einfarbig graue Fläche ist. Denn mehr Information enthält das Schachbrett nicht.

Generell finde ich die Aussage, dass etwas "unscharf" wirkt, nur weil man nicht genügend harte, kontrastreiche Kanten an Pixelrändern sieht, völlig fehl am Platz.

[robbitop]

Wenn NV bei DSR bei krummen Faktoren erst einen Gausfilter appliziert und dann per Nearest Neighbor downsamplet müsste das Ergebnis doch ziemlich suboptimal sein (1440p@4K) oder?
Heißt das im Umkehrschluss nicht, dass auch bei DSR aktuell nur gerade Faktoren Sinn ergeben?

Vieleicht müsste z.B die PCGH mal ein Special dazumachen, welches die IHVs animiert etwas bessere DS Filter anzubieten?

[Gipsel]

Wir kommen irgendwie vom Thema ab.

@Tesseract: Lies Dir den Anfang nochmal durch (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=10450341#post10450341), der Punkt war genau, was ich vorhin gerade geschrieben hatte, eine möglichst spezifische Testprozedur zum Vergleich von AMDs und nVs Downsampling-Lösungen. Meine Sichtweise habe ich ausführlich dargestellt und begründet und ich bin recht sicher, daß diese auch korrekt ist. AF kann allgemein gesehen keine Frequenzen im Bildraum erzeugen, die höher sind als man bei senkrechtem Blick auf eine Fläche (ohne AF) auch hinbekommt. Man muß also die Situation nicht unnötig verkomplizieren und damit den DS-Vergleich weniger aussagekräftig machen.

Der Witz dabei ist doch, dass die einzig korrekte Abbilung eines Schachbretts bei Unterabtastung eben die gleichförmige, einfarbig graue Fläche ist. Denn mehr Information enthält das Schachbrett nicht.Unterabtastung ist generell kein korrektes Verfahren und ergibt dann Moirees bzw. Flimmern in Bewegung. Die Frage ist, wie gut bekommt man eine graue Fläche ohne Moirees (wenn die Felder <1 Pixel im fertigen Bild sind) und wie klein können Felder werden, ohne daß es ein einfarbiges Grau wird (eventuell zu früh und damit zu weichgezeichnet?) oder anfängt zu flimmern (Unterfilterung, hohe Frequenzen ungenügend unterdrückt?). Bei AF ist dies eine Frage des AF-Filter-Algos. Bei AF+Downsampling haben beide Filter-Algos Einfluß. Bei senkrechten Blick auf eine Fläche spielt AF offensichtlich keine Rolle mehr (es wird ja rein bi-/trilinear gefiltert, per LoD-Bias kann man hier die Flimmerneigung sehr gut einstellen) und man kann den DS-Filter isoliert vom AF-Filter bewerten.
==================================

Wenn NV bei DSR bei krummen Faktoren erst einen Gausfilter appliziert und dann per Nearest Neighbor downsamplet müsste das Ergebnis doch ziemlich suboptimal sein (1440p@4K) oder?Das würde ich mit einem klaren Ja beantworten. Man benötigt einen vernünftigen Rekonstruktionsfilter. Gauß ist wie schon gesagt relativ schlecht. Er unterdrückt Flimmern typischerweise mit unnötig starkem Blur. Außerdem wird nV den vermutlich ziemlich früh abschneiden oder nicht alle Samples im Footprint nehmen (damit die Anzahl der Samples nicht explodiert, die nehmen ja offenbar nur [maximal?] 13), was allgemein der Unterdrückung hoher Frequenzen nicht förderlich ist. Man kombiniert also suboptimale Schärfe mit wahrscheinlich suboptimaler Flimmerunterdrückung. Da gibt es sicher bessere Kompromisse.
Heißt das im Umkehrschluss nicht, dass auch bei DSR aktuell nur gerade Faktoren Sinn ergeben? Vieleicht müsste z.B die PCGH mal ein Special dazumachen, welches die IHVs animiert etwas bessere DS Filter anzubieten?Nach dem, was ich gesehen habe, liefert es bei geraden Verhältnissen bessere Ergebnisse. Für die krummen Verhältnisse benötigt man tatsächlich einen guten Filter (der eben auch etwas mehr Aufwand kostet). Wenn das entsprechend thematisiert wird, kann das sicher nicht schaden.

edit:
Gerade mal ein wenig drüber nachgedacht, wie nV auf ihren "13 tap" Gauss Filter kommt und wie man das mit den Beobachtungen bei verschiedenen Smoothness-Einstellungen und DS-Auflösungen überein bekommt.
Das intern in höherer Auflösung berechnete Bild wird zuerst mit diesem Gauß-Filter geblurrt. Der Footprint des Filters sieht dabei so aus:
http://abload.de/img/nv_ds_gauss-patterncecs3.png

Das Blurring erfolgt dabei vermutlich "in place", es wird also eine geblurrte Kopie des Framebuffers erzeugt. Der Gaußfilter wird somit nicht direkt als Rekonstruktionsfilter genutzt. Der Vorteil ist, daß dies numerisch sehr einfach geht. Es werden nur 4 verschiedenen Filtergewichte (abhängig von der Smoothness) als Parameter an den Shader gegeben (für die schwarz, rot, grün, blau markierten Samples) und die Werte direkt damit multipliziert und dann addiert. Es stellt also lediglich die Abfolge von 13 Multiply-Adds (pro Komponente) dar. Das geht recht schnell.
Für das danach folgende Downsampling wird dann offenbar nearest Neighbor (Pointsampling) benutzt. Das ist der allereinfachste und mithin auch so ziemlich der schlechteste Rekonstruktionsfilter (falls man es überhaupt Filter nennen will). Anders kann man aber kaum erklären, daß ganze Pixelreihen verschwinden können. Vorteil ist hier wieder die einfache numerische Umsetzung. Der Nachteil natürlich, daß teilweise Sampelwerte genommen werden, die deutlich von der eigentlichen Pixelposition entfernt liegen. Dies führt zu zusätzlichem Flimmern in Bewegung, weil praktisch von Pixel zu Pixel schlicht einen Offset der Sampleposition gibt. Das vorhergehende Gauß-Blurring schafft hier keine wirkliche Abhilfe ohne exzessiv Schärfe zu verlieren (das würde nur ein vernünftiger Rekonstruktionsfilter tun, der den vermutlichen Farbwert an der echten Pixelposition berechnet). Nur bei 4x Downsampling wird offenbar bilinear gesampelt (ein Tent-Filter der hier praktisch zum Box-Filter degeneriert, da alle 4 Samples pro Pixel gleich weit vom Pixelzentrum entfernt liegen), was schon besser als Pointsampling ist (aber natürlich noch nicht perfekt). Der Grund dürfte darin liegen, daß ein bilinearer Filter (oder Tent oder im Deutschen Kegelfilter) zwar schon ein Rekonstruktionsfilter ist, dieser aber insbesondere bei geringen Faktoren ein merkliches Blurring verursachen könnte, welches vor allem in regelmäßigen Mustern variiert, z.B. bei 1,5x1,5 Downsampling nur jede zweite Pixelreihe auftritt (hier könnte/müßte man einen kleinen Offset von 0,25 Pixeln zwischen den Pixel- und Sampleraster einführen, um das möglichst gleichmäßig zu gestalten).
Zur Performanceoptimierung dürfte nV das Blurring praktisch nur an den per nearest neighbor ermittelten Positionen machen, also den Gaußfilter nur an den Positionen drüberjagen, die auch gesampelt werden. Das läuft dann in einen einzigen Resolve-Pass ab, also ohne eine physische Kopie des geblurrten Framebuffers hoher Auflösung zu machen. Für die Qualität ist das aber unerheblich.

[OC_Burner]

edit:
Gerade mal ein wenig drüber nachgedacht, wie nV auf ihren "13 tap" Gauss Filter kommt und wie man das mit den Beobachtungen bei verschiedenen Smoothness-Einstellungen und DS-Auflösungen überein bekommt.
Das intern in höherer Auflösung berechnete Bild wird zuerst mit diesem Gauß-Filter geblurrt. Der Footprint des Filters sieht dabei so aus:
http://abload.de/img/nv_ds_gauss-patterncecs3.png

Ist schon eine komische Definition von Nvidia bei einem 5x5 Footprint/Kernel von 13-tap zu sprechen. http://rastergrid.com/blog/2010/09/efficient-gaussian-blur-with-linear-sampling/

Was ich aber nicht verstehe, ist dieser komische Rastereffekt der zusammen (siehe Spoiler) mit dem Gaussianfilter auftritt.

source (http://www.grafik-feti.de/ftp/3D-Center/Downsampling/Nvidia_Downsampling_exploration/Maxwell_DSR/smoothness_comparison/smoothness000-100/test/)


http://www.grafik-feti.de/ftp/3D-Center/Downsampling/Nvidia_Downsampling_exploration/Maxwell_DSR/smoothness_comparison/smoothness000-100/test/Nvidiaoriginal___DSR-Factor_1.00x_Smoothness_033.png


http://www.grafik-feti.de/ftp/3D-Center/Downsampling/Nvidia_Downsampling_exploration/Maxwell_DSR/smoothness_comparison/smoothness000-100/test/ImageMagick___DSR-Factor_1.00x_Smoothness_033(-gaussian-blur%2013x0.5050).png


http://www.grafik-feti.de/ftp/3D-Center/Downsampling/Nvidia_Downsampling_exploration/Maxwell_DSR/smoothness_comparison/smoothness000-100/test/difference___Nvidiaoriginal%23%23%23-%23%23%23ImageMagick___DSR-Factor_1.00x_Smoothness_033.png



http://www.grafik-feti.de/ftp/3D-Center/Downsampling/Nvidia_Downsampling_exploration/Maxwell_DSR/smoothness_comparison/smoothness000-100/test/Nvidiaoriginal___DSR-Factor_2.25x_Smoothness_033.png

[Gipsel]

Ist schon eine komische Definition von Nvidia bei einem 5x5 Footprint/Kernel von 13-tap zu sprechen. http://rastergrid.com/blog/2010/09/efficient-gaussian-blur-with-linear-sampling/Die machen das vermutlich etwas anders als in Deinem Link und schneiden bei Radius 2 ab. Dadurch werden die Pixel in den Ecken nicht gesampelt. Zähle mal die von mir eingemalten Kreise im 5x5 Pixelraster! Das sind 13 ;).
Was ich aber nicht verstehe, ist dieser komische Rastereffekt der zusammen (siehe Spoiler) mit dem Gaussianfilter auftritt.Der kommt durch das Aliasing des Samplegrids (also der höheren internen Auflösung) mit dem Pixelgrid (der letztendlich ausgegebenen Auflösung) zu Stande. Bei 2,25 Downsampling sitzt nur jeder zweite ausgegebene Pixel in jeder Richtung genau auf einem Sample (Pixel der internen höheren Auflösung), jeder zweite genau zwischen zweien. Es gibt also 4 Kombination in einem Schachbrettmuster: exakt auf Sample, in x-Richtung drauf aber in y-Richtung um 0,5 Pixel verschoben, in x-Richtung um 0,5 Pixel verschoben aber in y-Richtung drauf oder in beiden Richtungen um 0,5 Pixel verschoben. Genau dieses kann man dann bei einigen Testbildern bewundern.
Um das gleichmäßiger zu gestalten, könnte man versuchen, das Pixel- leicht gegen das Samplegrid zu verschieben (also bei 1,5 x 1,5 Supersampling um 0,25 Pixel in x- und y-Richtung). Damit erreicht man einen konstanten Abstand der Sample- zu den Pixelpositionen (immer 0,25 Pixel neben dem Zentrum in beiden Richtungen). Dann sind die Modulationen vielleicht kleiner. Keine Ahnung, warum nV das nicht macht bzw. was die da genau machen.

Edit:
Also hier mal zur Veranschaulichung. Links ist es so, wie nV das vermutlich macht mit den vier unterschiedlichen Klassen an Pixeln (schwarz: exakt auf Sample; grün: in x-Richtung drauf aber in y-Richtung um 0,5 Pixel verschoben, blau: in x-Richtung um 0,5 Pixel verschoben aber in y-Richtung drauf; rot: in beiden Richtungen um 0,5 Pixel verschoben). Rechts wäre die meiner Meinung nach etwas bessere Lösung. Damit ist jeder Pixel immer gleich weit von den Samplepositionen weg (0,25 Pixel in x und y-Richtung), was gleichmäßiger aussehen könnte, zumindest mit einen "richtigen" Rekonstruktionsfilter. Bilinear würde es fast schon tun, aber man müßte eigentlich die Größe des Kernels anpassen [dann wird es ein Tent-Filter], damit alle Pixel immer gleichmäßig beitragen. Durch die besondere Anordnung der Samplepositionen im linken Fall ist dieser gleichmäßige Beitrag sogar schon beim Einsatz eines einfachen bilinearen Filters der Fall. Es dürfte aber im Zweifelsfall Flimmern, es wird zu wenig gefiltert. Im linken Layout variiert bei Einsatz eines bilinearen Filters das Gesamtgewicht eines Samples zu den verschiedenen Pixeln um bis zu Faktor 4 (es gibt die Gewichte 0.25, 0.5 oder 1), je nach Lage, im rechten Fall nur etwa um Faktor 2,25 (es gibt die Abstufungen 0.25, 0.375, 0.5625, wobei die allermeisten Samples mit 0,375 oder 0,5625 gewichtet werden, also deutlich geringere Variationen, Durchschnittsgewicht ist in allen Fällen immer 0,444). Bilinear nutzt eben einen zu kleinen Kernel.

http://abload.de/img/ogssaa_2.25_pixel_patrez6j.png

[Blackhand]

Also hochfrequente Texturen unter einem gewissen Winkel in Bewegung zu betrachten finde ich absolut sinnvoll Gipsel. Du solltest wirklich mal mehr der Praxis frönen.

Wenn ich von Flimmerneigung spreche, dann untersuche ich in der Regel im Flyby folgende Szene in UT3:

https://dl.dropboxusercontent.com/u/48866901/4k%20bicubic%20%2B%20FXAA.png


Da es schwer ist, dort einen fixen Punkt zu finden und ich ohnehin keine Capturekarte und auch so gut wie keine Erfahrung im Gameszenen aufnehmen habe, verzichte ich auf Videos, obwohl ich erwarten würde, dass sich die Effekte, die ich im folgenden beschreibe damit einfangen lassen dürften.

Auf dem Bild ist eine in Frontrichtung halbwegs hochfrequente Textur (Die Holzlatten), die unter nativer Auflösung in Bewegung nicht flimmert. Setzt man mit Gedosato (oder herkömmliches) Downsampling an, dann fängt diese Textur in Bewegung an zu flimmern, was es für mich etwas interessanter macht, als wenn man eine ohnehin flimmernde Textur untersuchen würde (was man vielleicht auch noch mal machen sollte). Dabei flimmert der bikubische Filter mit steigender Auflösung immer mehr, der bilineare Filter bietet unter 4xAuflösung sein bestes Ergebnis, flimmert dann aber immer noch mehr als der bikubische. Lanczos flimmert immer am meisten. Es scheint so, dass beim Downsampling die höheren Frequenzen eben nicht wie von Gipsel beschrieben wie beim AF soweit rausgefiltert werden, dass man ein sauberes Ergebnis bekommt (Auch ohne AF hat man dieses Ergebnis, wenn auch wesentlich schwächer ausgeprägt).

Und jetzt muss ich Hübie doch mal recht geben, mit FXAA lässt sich dieses Flimmern doch wieder vermindern. 4xDS mit bilinearem Downfilter+FXAA (Ultra via Gedosato)flimmern in dieser Szene auch wieder nicht. Je höher das DS, desto weniger matscht FXAA und am Ende braucht man scheinbar doch irgendeine Art Tiefpass um das Flimmern loszuwerden. 4xDSR bietet bei 20% Smoothness in der Hinsicht ein sauberes Ergebnis ohne PostAA. Niedrigere Stufen brauchen ein paar Prozent mehr, ich nehme dann einfach 25%. Aber optimal ist das alles nicht und sieht auch wieder etwas matschig aus.

Vielleicht wäre leichtes (bzw. einstellbares) Gaußian Blur mit anschließendem bikubischem Runtersampeln eine gute Lösung.

[Geldmann3]

Vom Prinzip her, wenn man drüber nachdenkt, ist ein bilinearer Filter oft genug hintereinander geschaltet wie in GeDoSaTo eigentlich schon das Optimum für's Downsampling. Solange darauf geachtet wird, dass die interne Auflösung ein 2^n faches der Nativen ist. Je größer n, desto flimmerfreier das Ergebnis. Bei unpassenden Auflösungen kommt es eben noch zusätzlich zu einem Flimmern, da ein Sample dann in mehreren Pixeln vorkommen kann. Was aber auch mit steigender Auflösung besser werden müsste.

[Hübie]

Es hat sich in der Praxis einfach so ergeben dass DS+FXAA das für mich beste Ergebnis darstellt, wenn SGSSAA nicht angeboten wird. Zusätzlich schalte ich je nach Spiel "driver controlled LOD bias" ab und verschiebe die Samples leicht um - 0,25. Smoothness steht meistens auf 17%. Das empfinde ich meistens als angenehm.

[aufkrawall]

17% ist definitiv zu wenig mit Faktoren kleiner 4x.

[Rente]

Wird eigentlich bei 0% Smoothing bei 4xDSR immer noch der Gauss-Filter appliziert?

[Hübie]

Ich mags etwas schärfer. Geht's aber auf die Augen zieh ich auf 25% hoch.

[aufkrawall]

Wird eigentlich bei 0% Smoothing bei 4xDSR immer noch der Gauss-Filter appliziert?
Nein, ist nur noch nn.

[Blackhand]

Unter 4x eben genau nicht nn. Wahrscheinlich bilinear und 0% beteutet vermutlich immer, dass kein Gauß verwendet wird.
@Geldmann
Wie ich schrieb, liefert der bilineare Filter selbst in 4x Auflösung eben nicht immer ein optimales Ergebnis

[Geldmann3]

Wenn bei 0% smoothing nur noch Nearest Neighbor angewendet wird, dürfte es ja so gut wie überhaupt keinen Glättungseffekt mehr geben, trifft das zu? Falls auch bei 0% noch Kanten geglättet werden, kann es kein reines nearest neighbor sein. Denn nearest neighbor verwendet unabhängig von der internen Auflösung nur so viele Samples, wie der Monitor Pixel hat. Effektiv würde bei reinem nearest neighbor das Flimmern nicht verringert werden, egal wie hoch die interne Auflösung ist. Mit dem Gauß Filter glättet es nur, weil dieser zuvor bereits die Farbwerte mehrerer Pixel vermischt, sodass nn. zwar auch hier nur so viele Samples verwendet, wie die native Monitorauflösung, jedoch sind deren Farbwerte ja bereits vom Gaußfilter vermischt, sodass nearest neighbor hier am Ende doch wieder ähnlich arbeitet wie ein bilinearer Filter.

[aufkrawall]

Wenn bei 0% smoothing nur noch Nearest Neighbor angewendet wird, dürfte es ja so gut wie überhaupt keinen Glättungseffekt mehr geben, trifft das zu?
Dann muss es doch bilinear sein.
Auch bei genau 4x bringt nn Downscaling keine Glättung, stimmt.

[aufkrawall]

Habe mal ein 60fps RGB Video von Filtertester ground2 gefrapst.
Einzig linear & bilinear erzeugen Flimmern durchs Runterskalieren, mit allen anderen Algorithmen von madVR lässt sich das Bild beliebig (krumm, absurd hohe Faktoren) runterskalieren, ohne, dass jedwedes Flimmern auftritt.
Mitchel-Netravali finde ich bezüglich AA übrigens recht ansprechend.

Einfach armselig von NV & AMD. :frown:

[Gipsel]

Also hochfrequente Texturen unter einem gewissen Winkel in Bewegung zu betrachten finde ich absolut sinnvoll Gipsel. Du solltest wirklich mal mehr der Praxis frönen.Ich glaube, ich habe bis auf ein oder zwei Ausnahmen mehr Erfahrung mit der praktischen Implementation des Resamplings von Daten als Andere hier im Thread. :rolleyes:

Ich kann hier nur noch mal ganz pauschal anmerken, daß der Ausgangspunkt für die Diskussion der Wunsch aufkrawalls war, mit einem "DS-Tester" die Downsamplingqualität zwischen verschiedenen Anbietern (also nV und AMD) zu vergleichen. Und Downsampling ist schlicht die Reskalierung eines 2D-Bildes zu einer anderen Auflösung. Will man das vergleichen, so sollten die verschiedenen Anbieter möglichst das gleiche Bild für das Downsampling angeboten bekommen. Dies ist bei AF-gefilterten Szenen nicht immer der Fall (sonst wären ja die ganzen Diskussionen um die AF-Filter für die Katz). Dies sollte man also vermeiden. Man kann genauso (oder sogar "schlimmere") flimmerkritische Situationen auf vollkommen ohne AF erzeugen (die bi-/trilinearen Filter arbeiten [beinahe?] identisch [vor ein paar Jahren gab es afair 1 Bit Unterschied in der Auflösung der Filtergewichte, das war meßbar, aber praktisch nie sichtbar; es spielt sowieso nur bei den 4xFP16- oder 4xFP32-Framebufferformat eine Rolle, bei RGBA8888 arbeiten die afaik bitidentisch, aber keine Ahnung, wie es bei den neueren GPUs ist]). Dies ist also vorzuziehen, wenn man das DS isoliert im Vergleich zwischen nV und AMD bewerten will.
Auf dem Bild ist eine in Frontrichtung halbwegs hochfrequente Textur (Die Holzlatten), die unter nativer Auflösung in Bewegung nicht flimmert. Setzt man mit Gedosato (oder herkömmliches) Downsampling an, dann fängt diese Textur in Bewegung an zu flimmern, was es für mich etwas interessanter macht, als wenn man eine ohnehin flimmernde Textur untersuchen würde (was man vielleicht auch noch mal machen sollte).Im Optimalfall unterdrückt Downsampling Flimmern. Wenn Flimmern dazukommt, ist der Downsampling-Filter suboptimal.
Dabei flimmert der bikubische Filter mit steigender Auflösung immer mehr, der bilineare Filter bietet unter 4xAuflösung sein bestes Ergebnis, flimmert dann aber immer noch mehr als der bikubische. Lanczos flimmert immer am meisten. Es scheint so, dass beim Downsampling die höheren Frequenzen eben nicht wie von Gipsel beschrieben wie beim AF soweit rausgefiltert werden, dass man ein sauberes Ergebnis bekommt (Auch ohne AF hat man dieses Ergebnis, wenn auch wesentlich schwächer ausgeprägt).Dann hat das vermutlich jemand so implementiert, das es (auf Kosten der Qualität) rechentechnisch möglichst einfach wird oder er hat schlicht nicht drauf geachtet, daß Downsampling Nyquist-konform filtern sollte. Technisch ist AF-Filterung und der Downsampling-Filter sehr nah verwandt. AF benutzt einen 1D-Filter (bzw. die Faltung eines 1D-Filters mit dem 2D-bilinearen Filter [bilinear ist ein Spezialfall des Tent-Filters]), DS einen 2D-Filter, beide verrechnen mehrere Samples höherer Auflösung zu dem Farbwert für einen Pixel.
Entscheidend ist, daß die Größe des Filterkernels nicht irgendeine feste Größe in der höheren internen Auflösung besitzt, sondern daß er eine bestimmte Größe in der Ausgabeauflösung besitzt. Dann flimmert da auch nichts. Bei AF klappt es ja auch zum allergrößten Teil, obwohl dort eigentlich relativ simple Filter eingesetzt werden (bilinear/Tent quer zur Line of Anisotropie, Box entlang der LoA [bzw. Faltung von 1D-Box mit 2D-Tent]).

Mal ganz allgemein gesprochen, hängt (wie schon erwähnt) die Flimmerneigung nicht nur von der Art des Filters ab, sondern ganz entscheidend von der gewählten Größe des Kernels. Das ist ja mitnichten fest miteinander verbunden. Jeder Filter beschreibt gewissermaßen eine Kurve in einer durch Flimmerneigung und Bildruhe definierten Ebene (ist natürlich kein vollständiges Bild, einige Filter können zur Ausbildung spezifischer Artefakte führen, aber das ist hier erstmal egal):

http://abload.de/img/filter_compromisesysau.png

Die Wahl des Filters bestimmt erst mal nur die Kurve, auf der man sich bewegt. Wo man sich auf der Kurve befindet, wird durch die Kernelgröße festgelegt (das wären die schwarzen Punkte). Ist die falsch (zu klein) gewählt, kann auch ein an sich sehr guter Filter (z.B. der durch die grüne Kurve symbolisierte) stark flimmern. Gleichzeitig kann man mit jedem Filter durch Vergrößerung des Kernels mehr Unschärfe generieren. Der Gaußfilter tut dies übrigens exzessiv, das wäre also eher die rote Kurve ;).
Vielleicht wäre leichtes (bzw. einstellbares) Gaußian Blur mit anschließendem bikubischem Runtersampeln eine gute Lösung.Eine gute Lösung wäre z.B., direkt einen bikubischen Filter mit passender (eventuell auch vom Nutzer an seine persönlichen Vorlieben anpaßbarer) Kernelgröße als Rekonstruktionsfilter zum Downsampling zu benutzen, ohne den Gaussian Blur.
Vom Prinzip her, wenn man drüber nachdenkt, ist ein bilinearer Filter oft genug hintereinander geschaltet wie in GeDoSaTo eigentlich schon das Optimum für's Downsampling. Solange darauf geachtet wird, dass die interne Auflösung ein 2^n faches der Nativen ist. Je größer n, desto flimmerfreier das Ergebnis. Bei unpassenden Auflösungen kommt es eben noch zusätzlich zu einem Flimmern, da ein Sample dann in mehreren Pixeln vorkommen kann. Was aber auch mit steigender Auflösung besser werden müsste.Bilinear bzw. Tent ist zwar längst nicht optimal (man opfert man etwas zu viel Schärfe, bis auch wirklich die Flimmerneigung getilgt ist), aber oft annehmbar. Bei hohen DS-Faktoren ist für die Rechenzeitersparnis allerdings auch eine Kombination von bilinear mit einem "guten" Filter ohne große Verluste möglich.
Habe mal ein 60fps RGB Video von Filtertester ground2 gefrapst.
Einzig linear & bilinear erzeugen Flimmern durchs Runterskalieren, mit allen anderen Algorithmen von madVR lässt sich das Bild beliebig (krumm, absurd hohe Faktoren) runterskalieren, ohne, dass jedwedes Flimmern auftritt.
Mitchel-Netravali finde ich bezüglich AA übrigens recht ansprechend.

Einfach armselig von NV & AMD. :frown:Ja, wenn das gut implementiert ist (passende Kernelgrößen), bringen die entsprechenden Filter einen fast optimalen Kompromiß zwischen Bildschärfe und Flimmerneigung. Man kann tatsächlich relativ niedrige Flimmerneigung mit hoher Schärfe kombinieren.
Bei Mitchell-Netravali ([bi]kubisch) muß man übrigens etwas aufpassen, das ist nicht nur ein Filter. Den kann man über zwei Parameter zwischen Blur-Filter und schärfeerhaltendem Filter variieren (oder auch unsinnige Parameterkombinationen wählen, die artefakten wie die Hölle). Was MadVR standardmäßig nutzt, keine Ahnung. Die Version in GIMP ist relativ nahe an einem Lanczos2-Filter, die Version in Paint.NET blurrt dagegen recht stark. Oft wird irgendwas dazwischen empfohlen. Allerdings besitzt nur die GIMP-Version (wie auch bilinear, Box und die separierbaren Lanczos-Filter) eine interessante Eigenschaft: Wendet man die für ein 1:1 Resampling an, erhält man wieder exakt das Ausgangsbild (wenn man die nominelle Filterbreite von einem Pixel benutzt, also keine zusätzliche Unschärfe einführt [der Footprint der Filter ist außer bei Box größer als 1 Pixel]). Dies ist bei den (meisten) anderen Filtern nicht der Fall.

[Geldmann3]

Man sieht, du kennst dich aus.

Bilinear bzw. Tent ist längst nicht optimal. Da opfert man etwas zu viel Schärfe, bis auch wirklich die Flimmerneigung getilgt ist.
Aber ist es in der Realität nicht das originalgetreuste was man tun kann, wenn man bei der 4 fachen Auflösung immer die Farbwerte von 4 Pixeln verrechnet und diese dann auf einem Pixel abbildet?

Ist etwas anderes nicht eine Verfälschung des Bildes? Ok, um Kanten zu glätten oder Flimmern zu vermeiden gibt es sicher bessere Methoden, doch wenn man ein Bild möglichst originalgetreu auf 1/4 der Auflösung abbilden möchte, sollte das doch schon das Optimum sein, oder nicht?

Beim Upsampling ist das natürlich wieder etwas anderes, da will man keine Treppen generieren.

[Gipsel]

Aber ist es in der Realität nicht das originalgetreuste was man tun kann, wenn man bei der 4 fachen Auflösung immer die Farbwerte von 4 Pixeln verrechnet und diese dann auf einem Pixel abbildet?Könnte man denken, ist aber nicht so. Der Box-Filter (bzw. macht in diesem Spezialfall bilinear genau das Gleiche) entfernt die in dem Bild höherer Auflösung enthaltenen hohen Ortsfrequenzen nur unzureichend. Es können sich unschöne Moiree-Muster bilden, die gegebenfalls auch flimmern. Um diese höheren Frequenzen stärker zu unterdrücken, müssen mehr als nur 4 Samples für einen ausgegebenen Pixel betrachtet werden (ein Lanczos2- oder auch ein bikubischer Filter [wenn richtig implementiert] würde 64 nehmen, die Kernelgröße für die nominelle Breite beträgt 4x4 Pixel in der Ausgabeauflösung betragen [x4, um alle Samples darin mitzunehmen], mehr, wenn eine zusätzliche Unschärfe/mehr Bildruhe gewollt ist). Durch die zusätzliche Information außerhalb des eigentlichen Pixels in diesem größeren Footprint können die Filter die zu hohen, nicht mehr im ausgegebenen Bild darstellbaren Frequenzen besser entfernen und so ohne unnötigen Schärfeverlust (wenn man z.B. 3x3 Samples mitteln würde statt 2x2, also immer noch die Hälfte der benachbarten Pixel mitnimmt) Artefakte wie Moirees oder Flimmern unterdrücken.
Ist etwas anderes nicht eine Verfälschung des Bildes? Ok, um Kanten zu glätten oder Flimmern zu vermeiden gibt es sicher bessere Methoden, doch wenn man ein Bild möglichst originalgetreu auf 1/4 der Auflösung abbilden möchte, sollte das doch schon das Optimum sein, oder nicht?Was sind Verfälschungen des Bildes? Ein Moiree-Pattern durch das Aliasing von hohen, in der Ausgabeauflösung nicht mehr darstellbaren Ortsfrequenzen mit dem Pixelraster sind auch Bildverfälschungen. Ein guter Filter unterdrückt diese möglichst selektiv, ohne Artefakte (bzw. möglichst wenige) hervorzurufen.
Beim Upsampling ist das natürlich wieder etwas anderes, da will man keine Treppen generieren.Lustigerweise sind die Kriterien für gutes Up- und Downsampling beinahe die gleichen. Man kann also auch die gleichen Filter benutzen. Beim Upsampling fällt nur schneller als beim 2x2 Downsampling auf, daß Box eigentlich ziemlich mies ist (bei "krummen" DS-Auflösungen ist Box immer mies).

[Geldmann3]

Durch die zusätzliche Information außerhalb des eigentlichen Pixels in diesem größeren Footprint können die Filter die zu hohen, nicht mehr im ausgegebenen Bild darstellbaren Frequenzen besser entfernen und so ohne unnötigen Schärfeverlust (wenn man z.B. 3x3 Samples mitteln würde statt 2x2, also immer noch die Hälfte der benachbarten Pixel mitnimmt) Artefakte wie Moirees oder Flimmern unterdrücken.

Das Flimmern wird dadurch natürlich besser unterdrückt, wenn man noch mehr Farbwerte von Nachbarpixeln in einen Pixel vereint, aber sind das nicht Farbwerte, die da gar nicht reingehören, sondern eigentlich zum Nachbarpixel gehören. Also eigentlich ein leichtes Verblurren mit dem Nachbarpixel?

[OC_Burner]

Nein, ist nur noch nn.

Unter 4x eben genau nicht nn. Wahrscheinlich bilinear und 0% beteutet vermutlich immer, dass kein Gauß verwendet wird.


Nicht nur wahrscheinlich bilinear, sondern definitiv bilinear. Der Gaußfilter wirkt bei 4.00x DSR erst ab 11%. Wirklich sichtbar aber erst ab 20%.

Effektiv würde bei reinem nearest neighbor das Flimmern nicht verringert werden, egal wie hoch die interne Auflösung ist. Mit dem Gauß Filter glättet es nur, weil dieser zuvor bereits die Farbwerte mehrerer Pixel vermischt, sodass nn. zwar auch hier nur so viele Samples verwendet, wie die native Monitorauflösung, jedoch sind deren Farbwerte ja bereits vom Gaußfilter vermischt, sodass nearest neighbor hier am Ende doch wieder ähnlich arbeitet wie ein bilinearer Filter.

NN erhöht das Flimmern sogar. Davon ab ist NN + smoothness 17% ungefähr mit bilinear vergleichbar.

[aufkrawall]

Es klappt übrigens erstaunlich gut, das Bild vor der DSR-Skalierung mit Lumasharpen vorzuschärfen. Post-AA sollte noch eingeschaltet sein.
Es sieht dann trotz 25% Smoothness recht scharf aus, hat aber nicht, wie eine niedrigere Einstellung, das Problem mit dem Flimmern.
Gibt auch demnächst einen neuen SweetFX-Injector, der u.a. auch OpenGL unterstützen soll:
http://forums.guru3d.com/showthread.php?p=4979923#post4979923
Damit wird man Lumasharpen hoffentlich in jeder Anwendung nutzen können.

DSR ist für mich schon so sehr praktikabel. Bei der derzeitigen AMD-Lösung finde ich diese Einschränkungen mit Refreshraten und nativer Auflösung viel schlimmer, flimmerfrei ist es ja auch nicht.

[Gipsel]

Das Flimmern wird dadurch natürlich besser unterdrückt, wenn man noch mehr Farbwerte von Nachbarpixeln in einen Pixel vereint, aber sind das nicht Farbwerte, die da gar nicht reingehören, sondern eigentlich zum Nachbarpixel gehören. Also eigentlich ein leichtes Verblurren mit dem Nachbarpixel?Die Samples da gehen im Zweifelsfall sogar mit negativem Gewicht ein, also kein Blurring, sondern gewissermaßen sogar das Gegenteil. ;)
http://abload.de/img/filter_weight_bc4mon0.png

Die Verläufe sind jeweils für eine Breite von 1 Pixel der Ausgabeauflösung angegeben, also die nominelle Grenze, um das Nyquist-Shannon-Theorem zu erfüllen (was je nach Filter unterschiedlich gut gelingt). Der Abstand zum Pixelzentrum ist übrigens in Pixeln der Ausgabeauflösung angegeben. Das ist somit unabhängig von den DS-Faktoren (und so muß das auch implementiert werden, dann flimmert es auch nicht [so stark]).

Die graue Mitchell-Netravali-Variante ist übrigens die GIMP-Version. Wie schon erwähnt, ist die sehr ähnlich zu Lanczos2. Der andere Mitchell-Netravali-Filter ist ein oft empfohlener Kompromiss, der bereits etwas blurrt.

Im AF-Tester-Thread gibt es hier im letzten Spoiler (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=9954551#post9954551) auch noch 2D-Plots der Gewichte für die 2D-Filter. Dort aber für AF mit Anisotropie 4. Die Tent- und Lanczos-Filter muß man aber nur horizontal um diesen Faktor stauchen, dann sehen sie so aus, wie man sie für das Downsampling benutzen würde.

Es klappt übrigens erstaunlich gut, das Bild vor der DSR-Skalierung mit Lumasharpen vorzuschärfen. Post-AA sollte noch eingeschaltet sein.
Es sieht dann trotz 25% Smoothness recht scharf aus, hat aber nicht, wie eine niedrigere Einstellung, das Problem mit dem Flimmern.Nun, es mag ja subjektiv bessere Ergebnisse als der Standard liefern, aber erst künstlich zu schärfen, um irgendwie den nachträglichen Blur zu kompensieren ist irgendwie nicht überzeugend. Das in einem Schritt gleich richtig zu machen, wäre vermutlich die elegantere (und auch performantere) Lösung.

[OC_Burner]

Die machen das vermutlich etwas anders als in Deinem Link und schneiden bei Radius 2 ab. Dadurch werden die Pixel in den Ecken nicht gesampelt. Zähle mal die von mir eingemalten Kreise im 5x5 Pixelraster! Das sind 13 ;).

Gezählt hatte ich deine Grafik, nur war meine definition von Tap bisher immer eine andere. Bei 13-Tap verstehe ich Pixelzentrum und jeweils in jede Richtung 6 benachbarte Pixel. Damit wären das aber 85 Sampels die mit den Testbildern aber nicht übereinkommen. Dein 5x5 Pixelraster würde demnach 5-Tap sein. In den Bezeichnugen bin ich aber bei weitem kein Experte und scheinbar gibt es da keine feste Definition.

Der kommt durch das Aliasing des Samplegrids (also der höheren internen Auflösung) mit dem Pixelgrid (der letztendlich ausgegebenen Auflösung) zu Stande. Bei 2,25 Downsampling sitzt nur jeder zweite ausgegebene Pixel in jeder Richtung genau auf einem Sample (Pixel der internen höheren Auflösung), jeder zweite genau zwischen zweien. Es gibt also 4 Kombination in einem Schachbrettmuster: exakt auf Sample, in x-Richtung drauf aber in y-Richtung um 0,5 Pixel verschoben, in x-Richtung um 0,5 Pixel verschoben aber in y-Richtung drauf oder in beiden Richtungen um 0,5 Pixel verschoben. Genau dieses kann man dann bei einigen Testbildern bewundern.
Um das gleichmäßiger zu gestalten, könnte man versuchen, das Pixel- leicht gegen das Samplegrid zu verschieben (also bei 1,5 x 1,5 Supersampling um 0,25 Pixel in x- und y-Richtung). Damit erreicht man einen konstanten Abstand der Sample- zu den Pixelpositionen (immer 0,25 Pixel neben dem Zentrum in beiden Richtungen). Dann sind die Modulationen vielleicht kleiner. Keine Ahnung, warum nV das nicht macht bzw. was die da genau machen.

Edit:
Also hier mal zur Veranschaulichung. Links ist es so, wie nV das vermutlich macht mit den vier unterschiedlichen Klassen an Pixeln (schwarz: exakt auf Sample; grün: in x-Richtung drauf aber in y-Richtung um 0,5 Pixel verschoben, blau: in x-Richtung um 0,5 Pixel verschoben aber in y-Richtung drauf; rot: in beiden Richtungen um 0,5 Pixel verschoben). Rechts wäre die meiner Meinung nach etwas bessere Lösung. Damit ist jeder Pixel immer gleich weit von den Samplepositionen weg (0,25 Pixel in x und y-Richtung), was gleichmäßiger aussehen könnte, zumindest mit einen "richtigen" Rekonstruktionsfilter. Bilinear würde es fast schon tun, aber man müßte eigentlich die Größe des Kernels anpassen [dann wird es ein Tent-Filter], damit alle Pixel immer gleichmäßig beitragen. Durch die besondere Anordnung der Samplepositionen im linken Fall ist dieser gleichmäßige Beitrag sogar schon beim Einsatz eines einfachen bilinearen Filters der Fall. Es dürfte aber im Zweifelsfall Flimmern, es wird zu wenig gefiltert. Im linken Layout variiert bei Einsatz eines bilinearen Filters das Gesamtgewicht eines Samples zu den verschiedenen Pixeln um bis zu Faktor 4 (es gibt die Gewichte 0.25, 0.5 oder 1), je nach Lage, im rechten Fall nur etwa um Faktor 2,25 (es gibt die Abstufungen 0.25, 0.375, 0.5625, wobei die allermeisten Samples mit 0,375 oder 0,5625 gewichtet werden, also deutlich geringere Variationen, Durchschnittsgewicht ist in allen Fällen immer 0,444). Bilinear nutzt eben einen zu kleinen Kernel.

http://abload.de/img/ogssaa_2.25_pixel_patrez6j.png

Hm... Ich weiß nicht so recht. Daher habe ich ja auch das Differenzbild zu DSR 1.00x (kein Downsampling, Gauss only via Registryeditor) gepostet. Das merkwürdige daran ist ja, dass nicht das gesamte Bild betroffen ist, sondern nur (in diesem Beispiel) das obere Drittel. Bei 100% (http://www.grafik-feti.de/ftp/3D-Center/Downsampling/Nvidia_Downsampling_exploration/Maxwell_DSR/smoothness_comparison/smoothness000-100/test/Nvidiaoriginal___DSR-Factor_1.00x_Smoothness_100.png) läßt sich der Effekt sogar ohne Differenzbild beobachten. Mit verschieben des Bildes wandert der Effekt. Andere DSR-Faktoren zeigen den Effekt ausgeprägter. Könnte natürlich wieder ein Bug sein (Mauscursorbug läßt grüßen) oder aber gewollt. Zumindest läßt sich durch diesen einen Effekt des Gaussfilters kein Bild (mit z.B. DSR-Faktor 2.25x) genau nachstellen.

[Gipsel]

Gezählt hatte ich deine Grafik, nur war meine definition von Tap bisher immer eine andere. Bei 13-Tap verstehe ich Pixelzentrum und jeweils in jede Richtung 6 benachbarte Pixel.Das stimmt für einen 1D-Filter. In 2D ist es kleiner. Allgemein ist ein Tap eine Sampleposition. NVidias "13-tap" meint also, dass insgesamt 13 Samples benutzt werden.
Hm... Ich weiß nicht so recht. Daher habe ich ja auch das Differenzbild zu DSR 1.00x (kein Downsampling, Gauss only via Registryeditor) gepostet. Das merkwürdige daran ist ja, dass nicht das gesamte Bild betroffen ist, sondern nur (in diesem Beispiel) das obere Drittel. Bei 100% (http://www.grafik-feti.de/ftp/3D-Center/Downsampling/Nvidia_Downsampling_exploration/Maxwell_DSR/smoothness_comparison/smoothness000-100/test/Nvidiaoriginal___DSR-Factor_1.00x_Smoothness_100.png) läßt sich der Effekt sogar ohne Differenzbild beobachten. Mit verschieben des Bildes wandert der Effekt. Andere DSR-Faktoren zeigen den Effekt ausgeprägter. Könnte natürlich wieder ein Bug sein (Mauscursorbug läßt grüßen) oder aber gewollt. Zumindest läßt sich durch diesen einen Effekt des Gaussfilters kein Bild (mit z.B. DSR-Faktor 2.25x) genau nachstellen.Achso, ich dachte Du bezogst Dich auf die bei 2,25 Downsampling deutlich stärkeren Unregelmäßigkeiten (meine Antwort bezog sich explizit darauf).
Wodurch dieser komische Effekt auch bei 1x-Downsampling verursacht wird, bin ich überfragt. Vermutlich ein kleiner Bug oder irgendeine verquere Implementation, die nV da auf die Welt losgelassen hat.

Übrigens nochmal zur Erinnerung, mit einem vernünftigen bikubischen (GIMP-Version, B=0, C=0.5) oder Lanczos-Filter (auch bei bilinear/Tent-Filter) würde bei 1x standardmäßig (ohne Pixeloffset und Breite des Filterkernels auf Nyquist-Grenze) exakt das gleiche Bild unverändert rauskommen, komplett ohne Blurring oder zusätzliche Artefakte (weil die Filtergewichte in den Abständen 1 und 2 vom Pixel jeweils genau eine Nullstelle haben).

[aufkrawall]

Nun, es mag ja subjektiv bessere Ergebnisse als der Standard liefern, aber erst künstlich zu schärfen, um irgendwie den nachträglichen Blur zu kompensieren ist irgendwie nicht überzeugend. Das in einem Schritt gleich richtig zu machen, wäre vermutlich die elegantere (und auch performantere) Lösung.
So suboptimal ist das gar nicht. Durch den Gauß-Blur sind trotz Sharpening Jaggies geringer ausgeprägt und Lumasharpen kostet vielleicht ~2-3%.

Meine Güte, es ist auch zum Haare raufen, dass die IHVs nicht einfach die SweetFX-Shader in den Treiber einbauen. Postfilter-Infrastruktur haben sie mit MLAA/FXAA ja schon implementiert. Wäre einfach ein paar Shader mit Checkboxes im Control Panel dazupacken...

[Ex3cut3r]

Meine Güte, es ist auch zum Haare raufen, dass die IHVs nicht einfach die SweetFX-Shader in den Treiber einbauen. Postfilter-Infrastruktur haben sie mit MLAA/FXAA ja schon implementiert. Wäre einfach ein paar Shader mit Checkboxes im Control Panel dazupacken...

Wäre wirklich toll. Sehr gute idee imo :up:

[Geldmann3]

Die Idee hatte ich auch schon vor langer Zeit, aber könnte es da vielleicht Probleme mit den Open Source Lizenzen geben?

[samm]

Die Idee hatte auch AMD schon vor langer Zeit, damals hiess es "Smartshader" ;) Wurde wie's scheint kaum benutzt und ist deswegen wieder aus dem CCC rausgeflogen. Der Ansatz wäre jedenfalls für die Treiber-Devs zumindest kein unbekanntes Konzept.

[DrFreaK666]

Ich habs gerne genutzt. Diablo 2 sah damit genial aus. Denke ATI war damals der Zeit voraus

[RavenTS]

Hat eigentlich noch jemand das Problem mit dem neuen Treiber, dass das System mit einem BlueScreen abstürzt wenn es aus dem Modus "Monitor abgeschaltet" aufwachen soll?

Bei Karten ab der 7xxx-Generation sollte dann ja afair der ganze Chip abgeschaltet werden. Bei meiner 6870 sollte das nicht der Fall sein, trotzdem hab ich dann reproduzierbar einen Dump.

[Geldmann3]

Das Problem habe ich nicht. Wenn ich allerdings eine der neuen VSR Auflösungen auswähle, läuft der TV nur noch mit 50Hz. Ich muss dann manuell über Erweiterte Einstellungen->Alle Modi auflisten->Meine gewünschte Auflösung in 60Hz auswählen. Das ist schon nervig, wahrscheinlich laufen dann auch Games nur mit 50Hz. :mad: Falls das noch niemanden aufgefallen ist.

AMD: Bitte fixen :frown:

Fällt jemanden eine Möglichkeit ein, wie ich den Rechner dazu bringen kann immer 60Hz auszuspucken?

[von Richthofen]

....Wenn ich allerdings eine der neuen VSR Auflösungen auswähle, läuft der TV nur noch mit 50Hz. Ich muss dann manuell über Erweiterte Einstellungen->Alle Modi auflisten->Meine gewünschte Auflösung in 60Hz auswählen.

Das Problem gibt's hier nicht.
Monitor zeigt 60 Hz an. Allerdings ist auch kein zweites Ausgabegerät angeschlossen.

[Geldmann3]

Bei mir ist auch nur der TV angeschlossen, über HDMI.

[von Richthofen]

Vllt. ändert er die Refreshrate bei jedem Auflösungswechsel, nicht nur bei Wechsel auf VSR. Denkt HDMI=TV --> da mach ich mal 50 Hz draus.

[Geldmann3]

Nein, er gibt 50Hz aus. Denn wenn ich auf dem Desktop einen Rechtsklick mache -> Bildschirmauflösung -> Erweiterte Einstellungen -> Alle Modi Auflisten ist zu sehen, dass Windows momentan auf 50Hz steht.

Hab ich falsch verstanden. Ja, das macht er zwar bei jedem Auflösungswechsel, doch nur wenn VSR im CCC aktiviert ist.

[Blackhand]

Die Samples da gehen im Zweifelsfall sogar mit negativem Gewicht ein, also kein Blurring, sondern gewissermaßen sogar das Gegenteil. ;)
http://abload.de/img/filter_weight_bc4mon0.png

Die Verläufe sind jeweils für eine Breite von 1 Pixel der Ausgabeauflösung angegeben, also die nominelle Grenze, um das Nyquist-Shannon-Theorem zu erfüllen (was je nach Filter unterschiedlich gut gelingt). Der Abstand zum Pixelzentrum ist übrigens in Pixeln der Ausgabeauflösung angegeben. Das ist somit unabhängig von den DS-Faktoren (und so muß das auch implementiert werden, dann flimmert es auch nicht [so stark]).

Die graue Mitchell-Netravali-Variante ist übrigens die GIMP-Version. Wie schon erwähnt, ist die sehr ähnlich zu Lanczos2. Der andere Mitchell-Netravali-Filter ist ein oft empfohlener Kompromiss, der bereits etwas blurrt.

Im AF-Tester-Thread gibt es hier im letzten Spoiler (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=9954551#post9954551) auch noch 2D-Plots der Gewichte für die 2D-Filter. Dort aber für AF mit Anisotropie 4. Die Tent- und Lanczos-Filter muß man aber nur horizontal um diesen Faktor stauchen, dann sehen sie so aus, wie man sie für das Downsampling benutzen würde.

Nun, es mag ja subjektiv bessere Ergebnisse als der Standard liefern, aber erst künstlich zu schärfen, um irgendwie den nachträglichen Blur zu kompensieren ist irgendwie nicht überzeugend. Das in einem Schritt gleich richtig zu machen, wäre vermutlich die elegantere (und auch performantere) Lösung.

Die Filterkurven sind ja schonmal interessant zu sehen. Wenn es stimmt, was du sagst, dann müsste die Filterung ja tatsächlich suboptimal in GeDoSaTo umgesetzt sein. Kann man denn einen Fehler hier im Code entdecken? https://github.com/PeterTh/gedosato/blob/master/source/scaling.cpp

[Nightspider]

Soll VSR zukünftig eigentlich auch mit höheren Frequenzen funzen?

Würde gerne mit meinem QNIX in 3200*1800 oder 4K mit 96/120Hz spielen.

Schon jemand probiert ob VSR mit dem Custom Resolution Tool pimpbar ist bzgl. Hz-Zahl?

[horn 12]

AMD sollte nun nach dem GTX 960 Launch reagieren und sofort den Omega "Phase 2" nachschmeissen und die R9 280(X) und die Karten darunter, sowie weitere Auflösungen unterstützen
Dies würde den GTX-en etwas Wind aus den Segeln nehmen und AMD wäre mal für Kurze Zeit in Aller Munde,- und dies würde den Abverkauf mehr als nur guttun und enorm ankurbeln!
ABER wie ich AMD kenne verschlafen jene nicht nur dies, sondern verzetteln noch den Treiber auf Frühjahr 2015 :-( :-(
Die ZEIT IST JETZT REIF, NICHT IN 2 MONATEN!

[Hübie]

AMD braucht schon etwas mehr als nur Phase zwei mit DSR was auf GeForce schon seit Äonen einfacher funzt.
Ich bin übrigens mehr gespannt was AMD bringt, als das was nVidia uns wieder vorsetzt.

[HarryHirsch]

AMD sollte nun nach dem GTX 960 Launch reagieren und sofort den Omega "Phase 2" nachschmeissen und die R9 280(X) und die Karten darunter, sowie weitere Auflösungen unterstützen
Dies würde den GTX-en etwas Wind aus den Segeln nehmen und AMD wäre mal für Kurze Zeit in Aller Munde,- und dies würde den Abverkauf mehr als nur guttun und enorm ankurbeln!
ABER wie ich AMD kenne verschlafen jene nicht nur dies, sondern verzetteln noch den Treiber auf Frühjahr 2015 :-( :-(
Die ZEIT IST JETZT REIF, NICHT IN 2 MONATEN!

Wozu sollten sie halbfertige, verbuggte Treiber veröffentlichen? Wegen der 960 ;D?
Alte gebrauchte karten sind schneller und günstiger.

[Nightspider]

Ich bin übrigens mehr gespannt was AMD bringt, als das was nVidia uns wieder vorsetzt.

Auf jeden Fall ein bessres Preis/Leistungsverhältnis!

[Marty98]

Wozu sollten sie halbfertige, verbuggte Treiber veröffentlichen? Wegen der 960 ;D?
Alte gebrauchte karten sind schneller und günstiger.

Es gibt ein grosses Risiko gebrauchte Karten zu kaufen. Oft werden sie dann verkauft wenn die Lüfter anfangen zu leiern.

[Blediator16]

Also, unrelated, when will VSR be coming to the 7 series?
VSR will not be introduced to the HD 7000 Series.

http://forums.overclockers.co.uk/showpost.php?p=27747834&postcount=81

Kein VSR für AMDs 7000er Serie. :freak:

[Screemer]

r9 280/x? gilt wohl auch für freesync... (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10547576#post10547576)

[Unicous]

Ist das gleiche Problem, wenn ich das richtig interpretiere. Die 7790/260X wird es wohl können (bzw. zumindest auf Hawaii Level VSR-fähig sein).

[Isen]

Verstehe ich ebenso
http://forums.overclockers.co.uk/showpost.php?p=27748113&postcount=95

[Scarred]

r9 280/x? gilt wohl auch für freesync... (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10547576#post10547576)

AMD’s implementation of Virtual Super Resolution uses an AMD Radeon graphics card’s hardware scaler to perform downsampling on a game’s rendered output before it reaches the user’s displays. These hardware scalers have varying capabilities across the AMD Radeon R9 and R7 Series, and the supported resolutions reflect these capabilities.

AMD intends to deploy a “phase 2” update to Virtual Super Resolution in the near future that will explore alternative implementations to enable Virtual Super Resolution on all AMD Radeon™ R7 260 (or higher) GPUs with a variety of downsampling options. This includes the R9 280/280X.

http://forums.overclockers.co.uk/showpost.php?p=27748460&postcount=106

Vielleicht kann ich ja meine alte HD7950 umflashen oder per Inf-Manipulation irgendwie den Treiber überzeugen. Fände es aber mies, wenn die R9 280 unterstützt würde und die HD7950 nicht.

[Troyan]

Liest man sich den Thread durch, dann sieht es so aus, dass sich an den VSR Modi überhaupt nichts ändern wird:


Yes, both cards will have similar VSR functionality as the 290X.
http://forums.overclockers.co.uk/showpost.php?p=27748113&postcount=95

Up to 3200x1800.
http://forums.overclockers.co.uk/showpost.php?p=27748146&postcount=97

[Isen]

Is the R7 260x/HD 7790 getting VSR?

War die Frage... du schließt also von denen, auf alle? ... Interessant.....
Eher berücksichtigt, Matt, den 19.03 Treiber.... und da heißt es eben " bis zu "

[Unicous]

Ich frage mich sowieso, welches "Troyan Horse" sich hinter dem Account mal wieder verbirgt. In der letzten Zeit gab es so viele sock puppet accounts, man weiß gar nicht mehr, wer jetzt die Marionette/Zweiter Account von wem ist.

[Troyan]

Is the R7 260x/HD 7790 getting VSR?

War die Frage... du schließt also von denen, auf alle? ... Interessant.....
Eher berücksichtigt, Matt, den 19.03 Treiber.... und da heißt es eben " bis zu "

Ich schließe daraus, dass sich am Verhalten VSR basierend auf GCN 1.1 mit dem Treiber nichts ändern wird.

Im Posting 309 wird auf folgende Aussagen von AMD verlinkt:
http://hardforum.com/showpost.php?p=1041284038&postcount=105

Es ist also für mich überraschend, dass mit dem neuen Treiber zur zeit keine Änderung vorgenommen wird.

[Kartenlehrling]

Ich glaube das können wir uns abschminken, das HD7xxx noch VSR bekommen.
Ich hatte es ja schon mal geposte, da sind unterschiedlich Hardware Scalern verbaut, darum können wohl die HD7xxx auch kein Spiele freesync.

Auf Nachfrage verriet AMD, dass die GPUs mit unterschiedlichen „Hardware Scalern“, die für das Downsampling genutzt werden, ausgestattet sind.
Und offenbar ist nur die neuste Ausbaustufe der Tonga-GPU (R9 285) dazu in der Lage, von 3.840 × 2.160 auf 1.920 × 1.080 herunter zu skalieren.

[Isen]

Du schließt aus der Aussage von, Matt im OC-UK forum, auf die Frage " Is the R7 260x/HD 7790 getting VSR? "

Weil hier:
http://hardforum.com/showpost.php?p=1041284038&postcount=105 ( vom 12-09-2014 )<- wann kam Omega Stage "1" nochmal? .... Hardwarescaler war eher die Geschichte von wegen Omega Stage "1", dass Tonga eben mehr kann, und deswegen Stage "2" mehr bieten wird...


Und meinst deswegen nun, dass sich bei allen "oberen" Karten ( GCN 1.1 ), der VSR-Support nicht ändert?


Okaaay....... ich glaub du vermischst nen paar alte Aussagen, die nur Stage "1" betrafen, wegen dem Hardwarescaler, was, Matt im Verlauf beim OC-UK, bzgl. R7 260(o.H)/R9 280x/HD 7790, auch nennt wieso:

http://forums.overclockers.co.uk/showpost.php?p=27749135&postcount=108
http://forums.overclockers.co.uk/showpost.php?p=27749483&postcount=110

AMD intends to deploy a “phase 2” update to Virtual Super Resolution in the near future that will explore alternative implementations to enable Virtual Super Resolution on all AMD Radeon™ R7 260 (or higher) GPUs with a variety of downsampling options. This includes the R9 280/280X.

There are board and bios level differences between the 7xxx series and the 280/280X series. The R9 280/280X should get VSR support in the future, the 7xxx series will not.



Ich lese da nichts, dass es generell GCN 1.1 betrifft.:confused:

[Thunder99]

Am 19.3. sind wir schlauer, davor mache ich mir keine Gedanken ob nun 4k Support für R9 280/290(x) geht oder nicht

[Unicous]

Unfortunately a bios flash will not overcome a hardware limitation on the scaler used on the older 7xxx series chips.

We're exploring alternative methods to bring VSR to the R9 280/280 cards but this will not arrive on the 7xxx series.



The 7790 'Bonaire' part is the only exception to this because it's actually GCN 1.1, same as the R9 290X. This is why it shares the same functionality on VSR and FreeSync as our Hawaii and Vesuvius parts.

We still intend to deploy a Phase 2 driver update to improve on our VSR technology Benny. You're correct though, this is different from our Phase 2 FreeSync driver which is scheduled to arrive in our April Catalyst update.

There is no set date for the VSR Phase 2 driver yet, but we're working on it diligently behind the scenes.

Robert posted the JAN/FEB time frame for a Phase 2 update as a rough estimate. It's not quite ready yet so rather than release it we decided to spend more time ensuring it's up to the incredibly high standards we've set with 14.12 Omega.

Hope this clears things up a bit.
http://forums.overclockers.co.uk/showpost.php?p=27751030&postcount=128

[M4xw0lf]

We're exploring alternative methods to bring VSR to the R9 280/280 cards but this will not arrive on the 7xxx series.
Seems legit.

[Lurtz]

Seems legit.
Fuuu AMD :mad:

[Unicous]

Ihr geht immer davon aus, dass das wirklich nur plumpe Rebrands sind. Aber das sind sie oft nicht. Eine 280X ist nicht unbedingt eine HD 7970 1:1. Im Zweifelsfall ist es nämlich auch ein metal respin um den Yield zu erhöhen, bei dem man vllt. noch den ein oder anderen Fehler ausgemerzt hat bzw. wird Altes mit Neuem vermischt.

Ob AMD zu faul ist, die 7000er Serie zu unterstützen lasse ich aber mal dahingestellt.:tongue:

[mironicus]

Ich habe ein HIS R280x-Bios auf eine Sapphire 7970 geflasht (wegen UEFI-Boot), bin gespannt ob das trotzdem funktioniert mit VSR.

[von Richthofen]

http://www.pcgameshardware.de/AMD-Freesync-Hardware-259942/News/VSR-Treiber-Crossfire-1153089/

Also am 19. März nur FreeSync-Treiber. VSR später? Hoffentlich gelingt eine breitere Unterstützung.

[Isen]

Super -.-

[horn 12]

Erneut ein Fail von AMD
Versprochen im Februar 2015, oder zumindest "in Aussicht" gestellt,- und nun kommt der Treiber vielleicht erst Ende März, oder gar April daher...
Na Na Na, dies geht langsam echt nimmer gut mit AMD!

[boxleitnerb]

Ich möchte wirklich offen sein und mir auch mal wieder eine AMD kaufen, aber solche Sachen machen es mir dabei echt nicht einfach. Bei Nvidia funktioniert das alles schon seit Monaten.

[Raff]

Jetzt wartet halt mal ab. Fiji ist noch nicht da. Wenn der Treiber zum Launch immer noch auf kurios limitiertes VSR beschränkt ist, kann man immer noch weinen. 3.200 x 1.800, nutzbar auf einer 290(X), ist schon gigantisch viel besser als nix (= Stand vor dem Omega). Natürlich wär's schön, wenn AMD endlich zu Potte käme, aber ein weiterer halbgarer Release würde niemandem helfen. Besser, die Funktion reift und funktioniert am Ende optimal. Ich hoffe indes sehr, dass mit der nächsten High-End-GPU keine Limits mehr vorherrschen (Rechenleistung und Speichermenge ausgenommen ;)).

MfG,
Raff

[boxleitnerb]

Schon klar, aber spätestens zu GTA 5 wird gekauft, und wer dann nix hat, bekommt von mir kein Geld. Schade eigentlich, denn seit 2006 war ich nie so nah, wieder rot zu kaufen. Vielleicht kommt AMD aber wider Erwarten rechtzeitig zum Release. Gerade in 4K dürften viele Leute wegen dem Spiel aufrüsten wollen schätze ich. Ich werde dann auch mal schauen, was an dem 4K-Hype dran ist ;)

[aufkrawall]

Ich möchte wirklich offen sein und mir auch mal wieder eine AMD kaufen, aber solche Sachen machen es mir dabei echt nicht einfach. Bei Nvidia funktioniert das alles schon seit Monaten.
Stimmt, die Distribution hat NV quasi vorbildlich gelöst.
Qualitätsmäßig ist aber auch noch eine Menge Luft nach oben.

Finde AMDs Ausflüchte ziemlich arm. Natürlich kann auch eine 7970 problemlos und schnell den Faktor 4x bilinear über die TMUs downsamplen und andere Faktoren gingen wie bei NV halt auch via Blur.
Der Grund ist wohl eher, dass man einfach keine Ressourcen lockermachen möchte/kann.

[Raff]

GTA V kommt schon in 5 Wochen auf den PC. Es sieht nicht danach aus, dass AMD bis dahin liefern kann. Genauso wenig sieht es danach aus, dass GTA V am PC ein Hardwarekiller wird. Von daher: Stark sein und abwarten. ;)

MfG,
Raff

[Unicous]

AMD hat sich mal wieder überstreckt. Sie haben sehr viele Ressourcen in Mantle und dann Vulkan gesteckt, was man auch daran sehen kann, dass Graham Sellers anscheinend das letzte Jahr (laut eigener Aussage bei der GDC) daran gearbeitet hat die vorläufige Spec auszuarbeiten. Das "Omega-Projekt" hat sicherlich auch Ressourcen gebunden und die Geschichte um Adaptive Sync hat offensichtlich auch länger gedauert als gedacht.

2014 war jedenfalls kein entspanntes Jahr für die GPU-Sparte und 2015 fängt auch nicht sehr rosig an.

[boxleitnerb]

GTA V kommt schon in 5 Wochen auf den PC. Es sieht nicht danach aus, dass AMD bis dahin liefern kann. Genauso wenig sieht es danach aus, dass GTA V am PC ein Hardwarekiller wird. Von daher: Stark sein und abwarten. ;)

MfG,
Raff

4k + 60 fps + max Details? Ich Gurke mit einer 970 rum...

[aufkrawall]

Wenn es auf der PS4 in 1080p nur mit 30fps läuft, brauchst du für die doppelten fps bei vierfacher Auflösung sicher mehr als eine 970. Die Details auf dem PC werden ja höher sein.

[dildo4u]

Das Game ist klar CPU Limitiert auf PS4 daraus würde ich keine Schlüsse ziehen.
Ginge das Game auf die GPU würde die Xbox One Version nicht mit 1080p laufen.
Das große Probleme wird die CPU last vorallem wenn das LOD auf PC besser ist,in der Nähe sehen die Screens nich großartig anders aus als die PS4 Version.

[aufkrawall]

Und warum sollte man dann so mit AF geizen?

[von Richthofen]

3.200 x 1.800, nutzbar auf einer 290(X), ist schon gigantisch viel besser als nix (= Stand vor dem Omega).

Stimmt, vorausgesetzt man nutzt einen Monitor mit passendem Seitenverhältnis (16:9) - ansonsten gibt es nur eine einzige DS-Auflösung (z.B. 1600p ;()

[aufkrawall]

Mit 75Hz@1440p gibts gar gar nix...

[Grestorn]

Ich möchte wirklich offen sein und mir auch mal wieder eine AMD kaufen, aber solche Sachen machen es mir dabei echt nicht einfach. Bei Nvidia funktioniert das alles schon seit Monaten.

SLI + GSync + DSR geht weiterhin nicht zusammen. Und es ist unklar, ob es jemals gehen wird. Nicht alles ist immer eitel Sonnenschein...

[boxleitnerb]

Ist das zumindest geplant? Falls nicht und es bei AMD gehen würde, ist das natürlich wieder ein Argument für rot. Wobei ich sowieso auf einen 4k Monitor schiele, da verliert DSR langsam an Bedeutung für mich. Vor 1-2 Jahren war das noch anders.

Geht klassisches DS mit SLI+G-Sync?

[dargo]

Erneut ein Fail von AMD
Versprochen im Februar 2015, oder zumindest "in Aussicht" gestellt,- und nun kommt der Treiber vielleicht erst Ende März, oder gar April daher...
Na Na Na, dies geht langsam echt nimmer gut mit AMD!
Nicht schön, aber wenn man Prioritäten setzen muss würde ich genauso handeln. Freesync ist imo viel wichtiger als der weitere Ausbau von VSR.

[Grestorn]

Ist das zumindest geplant? Falls nicht und es bei AMD gehen würde, ist das natürlich wieder ein Argument für rot. Wobei ich sowieso auf einen 4k Monitor schiele, da verliert DSR langsam an Bedeutung für mich. Vor 1-2 Jahren war das noch anders.

Geht klassisches DS mit SLI+G-Sync?

Versprochen ist es, aber ich bin mir nicht sicher, ob es technisch machbar ist. Die Tatsache, dass es schon so lange auf sich warten lässt, lässt es mir wahrscheinlich erscheinen, dass es da heftige technische Hürden gibt.
Und auch die Tatsache, dass AMD selbst Probleme zu haben scheint, Crossfire und Freesync gleichzeitig anzubieten (immerhin nimmt man sich für die Implementierung gehörig Zeit) weist für mich darauf hin, dass das technisch nicht so trivial ist.

Klassisches Downsampling geht zumindest auf meinem ROG Swift nicht, weil der keine Custom Resolutions > der native Resolution kann. Ich denke, das ist eine Limitierung des GSync Scalers.

Aber GeDoSaTo funktioniert natürlich auch mit SLI und GSync, aber eben nur bei DX 9 Spielen.

[M4xw0lf]

Ist das zumindest geplant? Falls nicht und es bei AMD gehen würde, ist das natürlich wieder ein Argument für rot. Wobei ich sowieso auf einen 4k Monitor schiele, da verliert DSR langsam an Bedeutung für mich. Vor 1-2 Jahren war das noch anders.
Ja, echte Pixel (bzw. Pixeldichte) > virtuelle Pixel.

[boxleitnerb]

Ja, echte Pixel (bzw. Pixeldichte) > virtuelle Pixel.

Bedingt. Bei echten Pixeln habe ich keine Mittelung der Farbwerte und könnte mir vorstellen, dass der Glättungseffekt (AA) geringer ausfällt als mit nativen 4k. Die alte Diskussion eben. Ich behalte meinen alten Monitor noch und schau mir das dann mal direkt nebeneinander an. Bin gespannt, wie ich das dann wahrnehme.

[dargo]

Mal eine Frage zu VSR.

Ich habe aktuell einen Full-HD Bildschirm. Würde gerne die GPU-Last von 2560x1080 simulieren. Geht das irgendwie mit VSR?

[horn 12]

Im Kontrollcenter CCC das Skalierungsfenster, beides Mal aktiv setzen.
Dann kannst mit der R290 bis 2560 x 1600 gehen, wenn gar nicht 3200 x 1600

[dargo]

Das weiß ich ja. 2560x1080 ist aber nicht dabei.
51974

Edit:
Egal... dann nehme ich halt 2048x1536. Sind ja bloß ~14% mehr Pixel als 2560x1080. Ist zwar ein anderes Format, grob dürfte die GPU-Last aber vergleichbar sein.

[robbitop]

Wenn das FOV da nicht mit reinspielt. Ein höheres FOV heißt sowohl für CPU als auch GPU mehr Arbeit. Andererseits hast du ja in deinem Test 14 % mehr Pixel. Im Groben wird das schon passen.

[y33H@]

Ich frage mich ja, was die da für ein Deck ausgegraben haben: http://videocardz.com/56182/amd-officially-confirms-vsr-support-for-radeon-r9-300-and-r7-300-graphics-cards

http://abload.de/thumb/amd-virtual-super-reswnkh7.jpg (http://abload.de/image.php?img=amd-virtual-super-reswnkh7.jpg)

Bei mir sieht diese Slide so aus: http://www.golem.de/news/a10-7870k-amds-kaveri-refresh-bietet-mehr-takt-und-kuehlung-1505-114309.html

http://abload.de/thumb/amd-a10-7870k-15mpjq3.jpg (http://abload.de/image.php?img=amd-a10-7870k-15mpjq3.jpg)

Was sagt uns das?

[Thunder99]

Chance auf full 4k@ Hawaii? :confused:

[aufkrawall]

VSR "Phase 2" scheint im Sand zu verlaufen, mit dem Hawaii Rebrand-Treiber soll auch kein 4x gehen...

[ChaosTM]

Chance auf full 4k@ Hawaii? :confused:

Das wäre nett...

[Thunder99]

Im überfliegen des CB Testes soll in Sachen VSR noch was kommen, nur wann ist halt die große Unbekannte...

Nice!!!!
Ansonsten beherrscht das komplette Portfolio alle aktuellen Features von AMD, darunter volle Freesync-Kompatibilität und True Audio. Für VSR ("Virtual Super Resolution") bietet AMD jetzt eine Shader-Lösung an, wie sie auch Nvidia nutzt. Dadurch können sämtliche 300er-Radeons Downsampling über den Treiber anbieten, wohingegen es vorher nur die R9 285 von Full HD auf 4K und die R9 290(X) auf 1800p schafften. Schuld daran waren die unterschiedlichen Displayengines, die für die Skalierung zuständig waren (anstelle der Shader). Jetzt wirbt AMD bei den R9-Modellen mit 1080p @ 4K und bei den R7 mit 1080p @ 1440p – bei Letzteren fehlt schlichtweg die Rohleistung für mehr.
Quelle PCGH (http://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/Specials/Radeon-R9-390X-Test-1162303/)

[derF]

Dann nehme ich an, dass das auch für die 290er gelten wird mit kommenden Treibern.
AMD kann ja nicht davon ausgehen, dass jemand von ner 290 auf ne 390 wechselt, nur um endlich 4k VSR zu bekommen... :freak:

[aufkrawall]

Golem Schreibt:
Abseits überarbeiteter, schnellerer Hardware hat AMD die Software teilweise verbessert: Treiber-Downsampling beherrscht der Grenada-Chip weiterhin nur bis 3.200 x 1.800 statt bis 3.840 x 2.160 Pixel...
http://www.golem.de/news/radeon-r9-390-im-test-amds-neue-alte-grafikkarten-bekommen-einen-nitro-boost-1506-114750-2.html

[derF]

Auch grad gelesen, wtf Oo

[aufkrawall]

Hat sich PCGH wohl einen Patzer erlaubt.

[derF]

Und AMD erst. Nach dem Omega wurde nunmal deutliche Hoffnung auf Besserung gemacht. Dass es so lange dauern würde, damit hat anfangs niemand gerechnet. Anschließend war dann die Erwartungshaltung zumindest bei mir, dass es einen entsprechenden Treiber mit dem Release der 300er gibt.

[Thunder99]

Naja wenn es wirklich über die Shader nun gehen soll müsste 4k gehen, zumindest bald...

[y33H@]

Mööööp ...

[Mr. Lolman]

Pff, es gibt ja angeblich schon Mod-Treiber, wo man auch als 290 User 3840*xxxx nutzen kann. Sobald das Downsampling übern Shader rennt, seh ich auch keinen Grund, warum es auf ner 290 nicht gehen sollte.

[aufkrawall]

Naja wenn es wirklich über die Shader nun gehen soll müsste 4k gehen, zumindest bald...
Sagt noch wer irgendwas mit Shadern, außer PCGH?

[dargo]

Hier wirbt club3d mit 4K @1080p und der R9 390.
http://www.club-3d.com/index.php/produkte/leser.de/product/RADEON-R9-390-8gb-royalqueen.html

[aufkrawall]

Da hat man wohl einfach die Bildchen von der Tonga-Karte genommen, nicht umsonst steht da "bis zu":
http://www.club-3d.com/index.php/produkte/leser.de/product/RADEON-R9-380-4gb-royalqueen.html

[nagus]

Pff, es gibt ja angeblich schon Mod-Treiber, wo man auch als 290 User 3840*xxxx nutzen kann. Sobald das Downsampling übern Shader rennt, seh ich auch keinen Grund, warum es auf ner 290 nicht gehen sollte.

kann ich bestätigen, hatten einen solchen treiber drauf vor ein paar wochen... inkl. 4K downsampling!

[dr_AllCOM3]

Lässt sich DSR nur global einstellen und nicht einzeln per Spiel?

[Grestorn]

Lässt sich DSR nur global einstellen und nicht einzeln per Spiel?

Aktives DSR stellt nur die höheren Auflösungen zur Verfügung. Ob sie verwendet werden und welche genau, musst Du immer im jeweiligen Spiel einstellen.

Was aber (bei nVidia) leider noch global ist, ist die "Smoothness"-Einstellung bei DSR.

[dr_AllCOM3]

Aktives DSR stellt nur die höheren Auflösungen zur Verfügung. Ob sie verwendet werden und welche genau, musst Du immer im jeweiligen Spiel einstellen.

Was aber (bei nVidia) leider noch global ist, ist die "Smoothness"-Einstellung bei DSR.
Ah, ok. Danke. Dann hatte ich DSR also noch gar nicht aktiv, als ich im Spiel nur 1080p eingestellt hatte.

[robbitop]

Ich frage mich, warum AMD so hadert, das über die ALUs laufen zu lassen. Gerade da ist ja viel noch unageschöpftes Potenzial vorhanden. Die ALUs bekommen ihre Rechenleistung in Non-Computeanwendungen eh nicht auf die Straße. Insofern könnte ich mir vorstellen, dass Downsampling über Compute nicht all zu weh tun sollte. NV wählt mit gewichtetem Pointsampling ja den billigen Weg. AMD könnte sich ggf. eine bessere Alternative leisten.

[Raff]

Ah, ok. Danke. Dann hatte ich DSR also noch gar nicht aktiv, als ich im Spiel nur 1080p eingestellt hatte.

Geforce: DSR-Downsampling für Fermi/Kepler/Maxwell - So geht's, das bringt's (http://www.pcgameshardware.de/Nvidia-Geforce-Grafikkarte-255598/Specials/DSR-Downsampling-1140676/)

Dort steht alles, was du wissen solltest. :)

MfG,
Raff

[aufkrawall]

Ich habe mal alle DSR-Faktoren überprüft.
Seit r352 ist es ja nicht mehr so, dass 25% für alle Faktoren ausreichen.
Ziel ist, dass es mit dem gewählten Smoothness-Wert möglichst wenig flimmert und der Wert dabei nicht höher ist als nötig.
Getestet mit Ground2 Textur im Filtertester.

Die Ergebnisse:
1,2x: 100% (Restflimmern) <- unnütz
1,5x: 100% fast flimmerfrei, aber sehr unscharf <- weitestgehend unnütz
1,78x: relativ starkes Flimmern, trotz 100% <- unnütz
2x: flimmerfrei mit 30%
2,25x: flimmerfrei mit 25%
3x: Restflimmern, trotz 100% <- unnütz
4x: flimmerfrei, Smoothness optional und je nach Vorliebe

Also eigentlich sind nur 2x, 2,25x und 4x gut. Mit denen sieht es seit r352 mit der richtigen Smoothness aber auch recht oder ziemlich scharf aus, ohne dabei schrottig zu sein.

[N0Thing]

War es nicht schon immer so, dass nur 2,25 und 4x eine vernünftige Glättung gebracht haben? Das waren zumindest die empfohlenen Einstellung zum Zeitpunkt der Vorstellung von DSR.

Habe selber kaum herum probiert, da DSR nicht zusammen mit selbst erstellten Auflösungen funktioniert und man immer hin und her wechseln müsste.

[Armaq]

Die Lösung von AMD ist einfach super praktisch und auch für Laine ohne Probleme durchführbar.

[Ex3cut3r]

Ich habe mal alle DSR-Faktoren überprüft.
Seit r352 ist es ja nicht mehr so, dass 25% für alle Faktoren ausreichen.
Ziel ist, dass es mit dem gewählten Smoothness-Wert möglichst wenig flimmert und der Wert dabei nicht höher ist als nötig.
Getestet mit Ground2 Textur im Filtertester.

Die Ergebnisse:
1,2x: 100% (Restflimmern) <- unnütz
1,5x: 100% fast flimmerfrei, aber sehr unscharf <- weitestgehend unnütz
1,78x: relativ starkes Flimmern, trotz 100% <- unnütz
2x: flimmerfrei mit 30%
2,25x: flimmerfrei mit 25%
3x: Restflimmern, trotz 100% <- unnütz
4x: flimmerfrei, Smoothness optional und je nach Vorliebe

Also eigentlich sind nur 2x, 2,25x und 4x gut. Mit denen sieht es seit r352 mit der richtigen Smoothness aber auch recht oder ziemlich scharf aus, ohne dabei schrottig zu sein.

Danke für die Mühe, hatte mal wieder DSR probiert und mich schon gewundert warum es mit 20% so scheiße aussieht. Was mich mometan tierisch stört, ist das CP bei Nvidia, das ist trotz SSD und i7 arsch träge.

[aufkrawall]

Die Lösung von AMD ist einfach super praktisch und auch für Laine ohne Probleme durchführbar.
Die AMD-Lösung ist ein Witz, weil sie hier überhaupt nicht funktioniert, während ich bei NV für alten Gammel sogar 5k auswählen kann.

[Ex3cut3r]

Die AMD-Lösung ist ein Witz, weil sie hier überhaupt nicht funktioniert, während ich bei NV für alten Gammel sogar 5k auswählen kann.

Vorallem, kein 21:9 Support, will mir doch demnächst einen 3440x1440 holen. :(

[aufkrawall]

Selbst mit 16:9 gäbe es bei 75Hz kein VSR mit dem Monitor.

[Ex3cut3r]

Oh Mann, das ist enttäuschend und peinlich, aber irgendwie muss da ein Problem sein bei AMD. Ich mein sonst hätten sie es doch wie Nvidia gemacht.

[Novum]

Ich frage mich, warum AMD so hadert, das über die ALUs laufen zu lassen. Gerade da ist ja viel noch unageschöpftes Potenzial vorhanden. Die ALUs bekommen ihre Rechenleistung in Non-Computeanwendungen eh nicht auf die Straße. Insofern könnte ich mir vorstellen, dass Downsampling über Compute nicht all zu weh tun sollte. NV wählt mit gewichtetem Pointsampling ja den billigen Weg. AMD könnte sich ggf. eine bessere Alternative leisten.
Jeder digitale resampling Filter benutzt gewichtetes Pointsampling. Die Anzahl der Samples ist ausschlaggebend für die Qualität und Performance.

[M4xw0lf]

Ich frage mich, warum AMD so hadert, das über die ALUs laufen zu lassen. Gerade da ist ja viel noch unageschöpftes Potenzial vorhanden. Die ALUs bekommen ihre Rechenleistung in Non-Computeanwendungen eh nicht auf die Straße. Insofern könnte ich mir vorstellen, dass Downsampling über Compute nicht all zu weh tun sollte. NV wählt mit gewichtetem Pointsampling ja den billigen Weg. AMD könnte sich ggf. eine bessere Alternative leisten.
Oh Mann, das ist enttäuschend und peinlich, aber irgendwie muss da ein Problem sein bei AMD. Ich mein sonst hätten sie es doch wie Nvidia gemacht.
Fehlende Manpower wirds sein, wie so oft.

[Thunder99]

Die AMD-Lösung ist ein Witz, weil sie hier überhaupt nicht funktioniert, während ich bei NV für alten Gammel sogar 5k auswählen kann.
Für die Auflösungen die VSR bietet funktioniert es einfach, gut und dabei ohne gefrickel immer gleich scharf :wink:. Bei deinen Kritikpunkten bin ich sonst bei dir :)

Evt AMD bisher die Scaler Lösung verwendet da es die bessere Lösung bei gleichbleibender Qualität bietet :confused: . Die kommende Shader Lösung arbeitet wohl (wenn sie wirklich kommen soll) anscheinend nicht zufriedenstellend. Nur die nvidia Lösung zu kopieren wäre nicht ausreichend gut um sich abzusetzen ;)

[Frosty]

Für die Auflösungen die VSR bietet funktioniert es einfach, gut und dabei ohne gefrickel immer gleich scharf :wink:. Bei deinen Kritikpunkten bin ich sonst bei dir :)

Evt AMD bisher die Scaler Lösung verwendet da es die bessere Lösung bei gleichbleibender Qualität bietet :confused: . Die kommende Shader Lösung arbeitet wohl (wenn sie wirklich kommen soll) anscheinend nicht zufriedenstellend. Nur die nvidia Lösung zu kopieren wäre nicht ausreichend gut um sich abzusetzen ;)


nach allem, was ich gesehen habe, sind zumindest die vsr auflösungen 2560x1440 und 3840x2160 hervorragend scharf und es hat in bisher allen spielen funktioniert. 3200x1800 hab ich bisher noch nicht probiert, deutlich lieber hätte ich stattdessen 2880x1620 gesehen, wie bei nvidia möglich:)

[Tesseract]

Für die Auflösungen die VSR bietet funktioniert es einfach, gut und dabei ohne gefrickel immer gleich scharf :wink:.

VSR flimmert nach wie vor deutlich mehr als die native auflösung und sieht dadurch sehr oft schlechter aus. von "gut" kann überhaupt keine rede sein.

[Raff]

VSR flimmert nach wie vor deutlich mehr als die native auflösung und sieht dadurch sehr oft schlechter aus. von "gut" kann überhaupt keine rede sein.

Huh? Auf welcher Grafikkarte hast du das getestet? Zumindest auf GCN 1.2 sieht's scheh aus.

MfG,
Raff

[Frosty]

VSR flimmert nach wie vor deutlich mehr als die native auflösung und sieht dadurch sehr oft schlechter aus. von "gut" kann überhaupt keine rede sein.


bei nvidia hat man eben den vorteil des frei wählbaren schärfe-reglers, aber ich fand die darstellung von höheren auflösungen als meiner nativen bisher nicht wirklich flimmrig, habe schon crysis 1-3, fear 1-3 und noch ein paar andere spiele getestet. kann schon sein dass vsr in der theorie bisher weit von perfektion entfernt ist, aber da kann ja durchaus noch was kommen.

[Tesseract]

Huh? Auf welcher Grafikkarte hast du das getestet? Zumindest auf GCN 1.2 sieht's scheh aus.

MfG,
Raff

hawaii, ich kann mir aber absolut nicht vorstellen, dass 1.2 sich da irgendwie anders verhält. wenn man ungerade auflösungen downsampelt ohne mit einem gauss oder sonstwas drüber zu gehen ist das auch absolut naheliegend. texturen in spielen haben genau das gleiche problem wie schrift im browser: in bewegung morpht es rum und sieht mies aus.

[Achill]

... deutlich lieber hätte ich stattdessen 2880x1620 gesehen, wie bei nvidia möglich:)

Schau mal hier: VSR / Zusätzliche Auflösungen (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=564951)

[aufkrawall]

hawaii, ich kann mir aber absolut nicht vorstellen, dass 1.2 sich da irgendwie anders verhält. wenn man ungerade auflösungen downsampelt ohne mit einem gauss oder sonstwas drüber zu gehen ist das auch absolut naheliegend. texturen in spielen haben genau das gleiche problem wie schrift im browser: in bewegung morpht es rum und sieht mies aus.
War mir im Filtertester so nicht aufgefallen. Allerdings ist es auch verdammt schwer, bei AMD damit eine Aussage zu treffen, weil da eben eh schon zu viel flimmert.

[Tesseract]

War mir im Filtertester so nicht aufgefallen. Allerdings ist es auch verdammt schwer, bei AMD damit eine Aussage zu treffen, weil da eben eh schon zu viel flimmert.

bei 3200x1800->2560x1440 beispielsweise ist die filterung gefühlt schlechter als alles was diverse filterprobleme (z.B. HD5000) jemals auf den schirm "gezaubert" haben. hawaii auf native hingegen ist, abgesehen von der imho nicht ganz optimalen samplegewichtung, nahezu makellos.

ich würde z.B. die genannten 3200x1800 niemals nativen 2560x1440 vorziehen - nichtmal wenn sie absolut gratis wären.

[aufkrawall]

hawaii auf native hingegen ist, abgesehen von der imho nicht ganz optimalen samplegewichtung, nahezu makellos.

Du siehst doch wahrscheinlich sofort einen Unterschied zwischen TMU und Referenz per ALU (ground2)?
Manches fällt auch bei niedrigerer Scroll-Geschwindigkeit stärker auf.

[Tesseract]

Du siehst doch wahrscheinlich sofort einen Unterschied zwischen TMU und Referenz per ALU (ground2)?

ja, allerdings auch zwischen nvidia und ALU. GCN und nvidia neigen an den gleichen stellen unruhig zu werden, ALU hingegen ist anders implementiert. die unterschiede zwischen GCN und nvidia liegen fast ausschließlich in der samplegewichtung. da finde ich die von nvidia etwas besser gewählt, aber vergleichen mit dem was wir in der vergangenheit schon an flimmerorgien bekommen haben ist das kritik auf einem relativ hohen niveau.
mit VSR flimmert/morpht btw. auch ALU weil das problem nicht die filterung ist sondern das downsampling. das thema hatten wir in der vergangenheit schon mal und ich bin nach wie vor der meinung, dass nvidia den gauss gewählt hat um genau dieses flimmern/morphen zu unterdrücken von dem ich spreche, es tut effektiv nämlich genau das.

[aufkrawall]

ja, allerdings auch zwischen nvidia und ALU.
GCN und nvidia neigen an den gleichen stellen unruhig zu werden, ALU hingegen ist anders implementiert.

Nö. ;)
Falls du mit Kepler testest oder getestet hast: Du musst Q nutzen und tril. Optm. deaktivieren, dann sieht man keinen Unterschied mehr bei Ground2 zwischen TMU und ALU.
NV hatte irgendeine komische Sache mit HQ bei Kepler gemacht. G80 sah anders aus, übrigens immer noch pixelidentisch zu Maxwell 2. Bei Letzterem ist HQ mit aktuellen Treibern wieder so, wie er sein sollte.

Mir fällt aber gerade mal so ein, dass man natürlich ALU-Referenz zum testen von DS verwenden könnte...

[N0Thing]

Nö. ;)
Falls du mit Kepler testest oder getestet hast: Du musst Q nutzen und tril. Optm. deaktivieren, dann sieht man keinen Unterschied mehr bei Ground2 zwischen TMU und ALU.
NV hatte irgendeine komische Sache mit HQ bei Kepler gemacht. G80 sah anders aus, übrigens immer noch pixelidentisch zu Maxwell 2. Bei Letzterem ist HQ mit aktuellen Treibern wieder so, wie er sein sollte

Wurde das bei Kepler nicht mit einem Treiber behoben? Habe ich das mit den Meldungen zu Maxwell verwechselt?

[aufkrawall]

Da kann man ja auch einiges verwechseln.
Bei Kepler wurde damals per Treiber für D3D10+ negatives LOD-Bias gefixt, wahrscheinlich auch für Fermi (Dank unserer Petition für Kontrolle übers LOD-Bias für D3D10+ übrigens).
Der HQ-Modus von Kepler sah und sieht unabhängig vom LOD-Bias aber anders aus als bei G80, wie halt von Tesseract beschrieben (etwa sichtbar unschärfer in HL2 Train-Szene). Workaround ist Q ohne tril. Optm., damit hat man das HQ von G80 (pixelidentisch).
Bei GM204 (GM106 weiß ich nicht) war dann HQ noch kaputter, weshalb sie es per Treiber fixen mussten (gab etwa üble Moires in Watch Dogs). Dabei haben sie es wieder auf den Stand von G80 gebracht (pixelidentisch), nur, dass halt zusätzlich noch das negative LOD-Bias weiterhin gefixt ist.

[N0Thing]

Okay, danke. Dann habe ich das wirklich mit den Meldungen zu Maxwell vermischt.

[Mr. Lolman]

ich würde z.B. die genannten 3200x1800 niemals nativen 2560x1440 vorziehen - nichtmal wenn sie absolut gratis wären.

Pff, 3200-> irgendwas war schon immer schiach. 2560-> 1920 hingegen, ist perfekt.

[robbitop]

Jeder digitale resampling Filter benutzt gewichtetes Pointsampling. Die Anzahl der Samples ist ausschlaggebend für die Qualität und Performance.
Für gerade Faktoren wird ein bilinearer Filter genutzt. Für ungerade Gauß + Pointsampling. Über GeDoSaTo stehen Bilinear, Lanczos und Bikubische Filter bereit.
Der Qualitätsunterschied - vor allem hinsichtlich Flimmern und Schärfe ist schon signifikant.

Allerdings kosten ordentliche Filter laut Gipsel und Co. fast 2 Größenordnungen mehr an Rechenzeit.

[Grestorn]

Was sind "gerade Faktoren"? 2x kann ja eigentlich kein gerader Faktor sein, da jede Achse nur um einen Faktor von Wurzel(2) vergrößert wird.

Der einzig gerade Faktor ist 4x.

[robbitop]

y*y wenn y element n ist
2x2, 3x3, 4x4 usw.

(3x3 und 4x4 usw sind offiziell ohne Tool bei DSR nicht nutzbar - mit Tool schon. Auch GeDoSaTo kann das)

[Novum]

Für gerade Faktoren wird ein bilinearer Filter genutzt. Für ungerade Gauß + Pointsampling. Über GeDoSaTo stehen Bilinear, Lanczos und Bikubische Filter bereit.
Der Qualitätsunterschied - vor allem hinsichtlich Flimmern und Schärfe ist schon signifikant.

Allerdings kosten ordentliche Filter laut Gipsel und Co. fast 2 Größenordnungen mehr an Rechenzeit.
Jeder der dort aufgezählten Filter-Varianten ist gewichtetes Pointsampling, denn jeder digitale Resampling-Filter ist gewichtetes Pointsampling ;)

Welche der beiden Parteien verwendet deiner Meinung nach bilinear? Ich bezweifle das. Das ist ein richtig schlechter Rekonstruktionsfilter und würde Aliasing begünstigen. Nicht ohne Grund gibt es die "Schärfe"-Einstellung bei NVIDIA, die hätte bei bilinear überhaupt keinen Sinn.

Das wird mit großer Sicherheit ein Lanczos- oder Mitchell-Filter sein.

[robbitop]

Jeder der dort aufgezählten Filter-Varianten ist gewichtetes Pointsampling, denn jeder digitale Resampling-Filter ist gewichtetes Pointsampling ;)

Welche der beiden Parteien verwendet deiner Meinung nach bilinear? Ich bezweifle das. Das ist ein richtig schlechter Rekonstruktionsfilter und würde Aliasing begünstigen. Nicht ohne Grund gibt es die "Schärfe"-Einstellung bei NVIDIA, die hätte bei bilinear überhaupt keinen Sinn.

Das wird mit großer Sicherheit ein Lanczos- oder Mitchell-Filter sein.
Nope.
Entschuldige ich meine Nearest Neighbor, nicht Pointsampling.

Gerade Faktoren bei NV: bilenear + gauß
ungerade gauß + nearest neigbour.

Wurde entsprechend analysiert, insofern gibt es nicht mehr viel zu vermuten. ;)

Hier kannst du es nachlesen - leider fehlen die ganzen eingefügten Grafiken. Ab Seite 12 in diesem Thread einfach nochmal reinschauen:


Mit Registry-Hack geht auch mehr als 4x



Das stimmt nicht. Bei 4-facher Auflösung (XY x2) gibt es mit bilinear kein gefördertes Flimmern. Nur abseits in allen anderen Auflösungen. Außerdem sollte man zwischen precise und interpolation unterscheiden wenn man bilinear und bicubic erwähnt. Bicubic interpolation only hat die gleichen Nachteile wie Bilinaer interpolation only.



Ja ich war das.:) Stieß aber auf wenig Interesse.

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10408463&postcount=106

Bei DSR kommt erst ein Blurfilter zum Einsatz und anschließend wird das Bild verkleinert.

-Faktor 4.00x = Blur-->Bilinear interpolation only
-Alle anderen offiziellen Faktoren = Blur-->Nearest Neighbor


Also ganz allgemein ist ein Gaußfilter eigentlich ziemlich übel. Es ist ein relativ schlechter Kompromiß zwischen Bildschärfe und Flimmerneigung. Bilinear erhält deutlich mehr Bildschärfe bei im Vergleich nur etwas höherer Flimmerneigung. Nicht umsonst setz man zur Texturfilterung bis heute immer noch bilineare Filterung ein (das ist im Prinzip auch eine Art Re-/Downsampling). Paßt man die Größe des Filterkernels bzw. die Gewichte am Rand des Kernels entsprechend an (narrow/wide Tent, bilinear kann man auch Tent nennen), ist Gauß eigentlich immer blurrier, wenn man vergleichbare Flimmerneigung erreicht.
Den besten Kompromiß zwischen Bildschärfe und Flimmerneigung produziert übrigens tatsächlich meist der Lanczos-Filter (oder andere Filterkernel mit sehr ähnlich verlaufenden Gewichten, die sind mit bloßem Auge oft kaum zu unterscheiden). Der ist auch zur Flimmerunterdrückung besser als bilinear, erhält dabei aber gleichzeitig mehr Bildschärfe (oder läßt sie unverändert). Zumindest wenn man die Größe des Kernels nicht mutwillig so wählt (zu klein), daß man eine "Überschärfung" erhält, was dann in Bewegung zu Flimmern führt (was viele Bildbearbeitungsprogramme wohl tun).
Warum nV also einen "13tap Gauss filter" (was ein ausgesprochener Blurfilter ist) für DSR wählt statt einen anderen, der bei gleicher Flimmerunterdrückung (das ist bei allen [auch bei Lanczos], ganz einfach über die Größe des Filterkernels einstellbar, wenn man per Shader downsampelt, ist das eigentlich ziemlich einfach zu machen, aufwändige Filter kosten halt nur entsprechend Rechenzeit und gegebenenfalls Bandbreite) mehr Schärfe erhält, kann ich mir nicht erklären.

In Bezug auf Texturfilterung wurde das übrigens schon mal hier diskutiert (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=9953776#post9953776) (inklusive Video mit Lanczos2-Filter in Bewegung, der ohne Schärfeverlust weniger flimmert als HQ-AF auf nVidia ;)).

Man könnte auch fragen warum Nvidia bei allen Faktoren (außer 4.00x) Nearest Neighbor nimmt. Der Grund für den Einsatz des Gaußfilters wird definitiv Nearest Neighbor sein. Wenn wegen der Performance dies so sein sollte ist auch klar warum Nearest Neighbor und nicht Bilinear genutzt wird. Bilinear fängt nunmal mächtig an zu flimmern sobald der Achsenfaktor nicht mehr 2.0 beträgt. Nvidia setzt (sollte es denn so sein) auf mathematische Korrektheit.
Das heißt also, Smoothness auf Null ergibt auch Null Antialiasing-Wirkung? Kann ich kaum glauben. Dann könnte man sich doch das Rendern in höherer Auflösung gleich ganz Sparen. :rolleyes:

Edit:

Das ist aber teilweise schon ziemlicher Schrott. Was hat nV denn da geritten?


Man benötigt schon recht viele Samples für gute Filter. Und das dauert dann auch schon deutlich länger als 10 bis 50 Takte, um z.B. 64 Samples pro ausgegebenem Pixel beim Lanczos2 oder gar 144 Samples pro Pixel eines Lanczos3-Filters beim 4k zu 1080p Downsampling zu verrechnen. Erstmal müssen die ganzen Samples von irgendwo kommen. Wenn man zudem nicht die numerisch vereinfachte Variante eines separierbaren Filters nehmen will (Skalierung in x- und y-Richtung sind unabhängig voneinander und auch getrennt durchführbar, ergibt bei Lanczos aber z.B. Artefakte, Tent-Filter haben keine Probleme damit, die sind immer separierbar [mit ein Grund, warum die so beliebt sind, die sind billig und trotzdem nicht zu schlecht]), ist das auch numerisch durchaus nicht ganz unaufwendig, da man im worst-case wirklich den Abstand des Samples zum Pixelzentrum ausrechnen muß (das ist jeweils eine inverse squareroot pro Sample, also schon mal mindestens 4 Takte ALU pro Sample bei GCN und das ist ja längst noch nicht Alles, weil man ja auch noch pro Sample das Filtergewicht in Abhängigkeit von diesem Abstand berechnen und schlußendlich die Samples damit verrechnen muß, da kann man am Ende locker auf mehr als 1000 Takte pro Pixel kommen), zumindest wenn man auch alle "krummen" Downsampling-Auflösungen erlauben will und nicht nur eine feste 1:2 lineare Skalierung (oder sehr wenige feste).
Oder natürlich, man spart irgendwo und macht Kompromisse. Eine Abwägung, welche numerischen Ungenauigkeiten man sich erlauben kann, ohne zu viel Qualität zu verlieren wird dann schon wichtig.

Wir kommen irgendwie vom Thema ab.

@Tesseract: Lies Dir den Anfang nochmal durch (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=10450341#post10450341), der Punkt war genau, was ich vorhin gerade geschrieben hatte, eine möglichst spezifische Testprozedur zum Vergleich von AMDs und nVs Downsampling-Lösungen. Meine Sichtweise habe ich ausführlich dargestellt und begründet und ich bin recht sicher, daß diese auch korrekt ist. AF kann allgemein gesehen keine Frequenzen im Bildraum erzeugen, die höher sind als man bei senkrechtem Blick auf eine Fläche (ohne AF) auch hinbekommt. Man muß also die Situation nicht unnötig verkomplizieren und damit den DS-Vergleich weniger aussagekräftig machen.

Unterabtastung ist generell kein korrektes Verfahren und ergibt dann Moirees bzw. Flimmern in Bewegung. Die Frage ist, wie gut bekommt man eine graue Fläche ohne Moirees (wenn die Felder <1 Pixel im fertigen Bild sind) und wie klein können Felder werden, ohne daß es ein einfarbiges Grau wird (eventuell zu früh und damit zu weichgezeichnet?) oder anfängt zu flimmern (Unterfilterung, hohe Frequenzen ungenügend unterdrückt?). Bei AF ist dies eine Frage des AF-Filter-Algos. Bei AF+Downsampling haben beide Filter-Algos Einfluß. Bei senkrechten Blick auf eine Fläche spielt AF offensichtlich keine Rolle mehr (es wird ja rein bi-/trilinear gefiltert, per LoD-Bias kann man hier die Flimmerneigung sehr gut einstellen) und man kann den DS-Filter isoliert vom AF-Filter bewerten.
==================================

Das würde ich mit einem klaren Ja beantworten. Man benötigt einen vernünftigen Rekonstruktionsfilter. Gauß ist wie schon gesagt relativ schlecht. Er unterdrückt Flimmern typischerweise mit unnötig starkem Blur. Außerdem wird nV den vermutlich ziemlich früh abschneiden oder nicht alle Samples im Footprint nehmen (damit die Anzahl der Samples nicht explodiert, die nehmen ja offenbar nur [maximal?] 13), was allgemein der Unterdrückung hoher Frequenzen nicht förderlich ist. Man kombiniert also suboptimale Schärfe mit wahrscheinlich suboptimaler Flimmerunterdrückung. Da gibt es sicher bessere Kompromisse.
Nach dem, was ich gesehen habe, liefert es bei geraden Verhältnissen bessere Ergebnisse. Für die krummen Verhältnisse benötigt man tatsächlich einen guten Filter (der eben auch etwas mehr Aufwand kostet). Wenn das entsprechend thematisiert wird, kann das sicher nicht schaden.

edit:
Gerade mal ein wenig drüber nachgedacht, wie nV auf ihren "13 tap" Gauss Filter kommt und wie man das mit den Beobachtungen bei verschiedenen Smoothness-Einstellungen und DS-Auflösungen überein bekommt.
Das intern in höherer Auflösung berechnete Bild wird zuerst mit diesem Gauß-Filter geblurrt. Der Footprint des Filters sieht dabei so aus:
http://abload.de/img/nv_ds_gauss-patterncecs3.png

Das Blurring erfolgt dabei vermutlich "in place", es wird also eine geblurrte Kopie des Framebuffers erzeugt. Der Gaußfilter wird somit nicht direkt als Rekonstruktionsfilter genutzt. Der Vorteil ist, daß dies numerisch sehr einfach geht. Es werden nur 4 verschiedenen Filtergewichte (abhängig von der Smoothness) als Parameter an den Shader gegeben (für die schwarz, rot, grün, blau markierten Samples) und die Werte direkt damit multipliziert und dann addiert. Es stellt also lediglich die Abfolge von 13 Multiply-Adds (pro Komponente) dar. Das geht recht schnell.
Für das danach folgende Downsampling wird dann offenbar nearest Neighbor (Pointsampling) benutzt. Das ist der allereinfachste und mithin auch so ziemlich der schlechteste Rekonstruktionsfilter (falls man es überhaupt Filter nennen will). Anders kann man aber kaum erklären, daß ganze Pixelreihen verschwinden können. Vorteil ist hier wieder die einfache numerische Umsetzung. Der Nachteil natürlich, daß teilweise Sampelwerte genommen werden, die deutlich von der eigentlichen Pixelposition entfernt liegen. Dies führt zu zusätzlichem Flimmern in Bewegung, weil praktisch von Pixel zu Pixel schlicht einen Offset der Sampleposition gibt. Das vorhergehende Gauß-Blurring schafft hier keine wirkliche Abhilfe ohne exzessiv Schärfe zu verlieren (das würde nur ein vernünftiger Rekonstruktionsfilter tun, der den vermutlichen Farbwert an der echten Pixelposition berechnet). Nur bei 4x Downsampling wird offenbar bilinear gesampelt (ein Tent-Filter der hier praktisch zum Box-Filter degeneriert, da alle 4 Samples pro Pixel gleich weit vom Pixelzentrum entfernt liegen), was schon besser als Pointsampling ist (aber natürlich noch nicht perfekt). Der Grund dürfte darin liegen, daß ein bilinearer Filter (oder Tent oder im Deutschen Kegelfilter) zwar schon ein Rekonstruktionsfilter ist, dieser aber insbesondere bei geringen Faktoren ein merkliches Blurring verursachen könnte, welches vor allem in regelmäßigen Mustern variiert, z.B. bei 1,5x1,5 Downsampling nur jede zweite Pixelreihe auftritt (hier könnte/müßte man einen kleinen Offset von 0,25 Pixeln zwischen den Pixel- und Sampleraster einführen, um das möglichst gleichmäßig zu gestalten).
Zur Performanceoptimierung dürfte nV das Blurring praktisch nur an den per nearest neighbor ermittelten Positionen machen, also den Gaußfilter nur an den Positionen drüberjagen, die auch gesampelt werden. Das läuft dann in einen einzigen Resolve-Pass ab, also ohne eine physische Kopie des geblurrten Framebuffers hoher Auflösung zu machen. Für die Qualität ist das aber unerheblich.
Die machen das vermutlich etwas anders als in Deinem Link und schneiden bei Radius 2 ab. Dadurch werden die Pixel in den Ecken nicht gesampelt. Zähle mal die von mir eingemalten Kreise im 5x5 Pixelraster! Das sind 13 ;).
Der kommt durch das Aliasing des Samplegrids (also der höheren internen Auflösung) mit dem Pixelgrid (der letztendlich ausgegebenen Auflösung) zu Stande. Bei 2,25 Downsampling sitzt nur jeder zweite ausgegebene Pixel in jeder Richtung genau auf einem Sample (Pixel der internen höheren Auflösung), jeder zweite genau zwischen zweien. Es gibt also 4 Kombination in einem Schachbrettmuster: exakt auf Sample, in x-Richtung drauf aber in y-Richtung um 0,5 Pixel verschoben, in x-Richtung um 0,5 Pixel verschoben aber in y-Richtung drauf oder in beiden Richtungen um 0,5 Pixel verschoben. Genau dieses kann man dann bei einigen Testbildern bewundern.
Um das gleichmäßiger zu gestalten, könnte man versuchen, das Pixel- leicht gegen das Samplegrid zu verschieben (also bei 1,5 x 1,5 Supersampling um 0,25 Pixel in x- und y-Richtung). Damit erreicht man einen konstanten Abstand der Sample- zu den Pixelpositionen (immer 0,25 Pixel neben dem Zentrum in beiden Richtungen). Dann sind die Modulationen vielleicht kleiner. Keine Ahnung, warum nV das nicht macht bzw. was die da genau machen.

Edit:
Also hier mal zur Veranschaulichung. Links ist es so, wie nV das vermutlich macht mit den vier unterschiedlichen Klassen an Pixeln (schwarz: exakt auf Sample; grün: in x-Richtung drauf aber in y-Richtung um 0,5 Pixel verschoben, blau: in x-Richtung um 0,5 Pixel verschoben aber in y-Richtung drauf; rot: in beiden Richtungen um 0,5 Pixel verschoben). Rechts wäre die meiner Meinung nach etwas bessere Lösung. Damit ist jeder Pixel immer gleich weit von den Samplepositionen weg (0,25 Pixel in x und y-Richtung), was gleichmäßiger aussehen könnte, zumindest mit einen "richtigen" Rekonstruktionsfilter. Bilinear würde es fast schon tun, aber man müßte eigentlich die Größe des Kernels anpassen [dann wird es ein Tent-Filter], damit alle Pixel immer gleichmäßig beitragen. Durch die besondere Anordnung der Samplepositionen im linken Fall ist dieser gleichmäßige Beitrag sogar schon beim Einsatz eines einfachen bilinearen Filters der Fall. Es dürfte aber im Zweifelsfall Flimmern, es wird zu wenig gefiltert. Im linken Layout variiert bei Einsatz eines bilinearen Filters das Gesamtgewicht eines Samples zu den verschiedenen Pixeln um bis zu Faktor 4 (es gibt die Gewichte 0.25, 0.5 oder 1), je nach Lage, im rechten Fall nur etwa um Faktor 2,25 (es gibt die Abstufungen 0.25, 0.375, 0.5625, wobei die allermeisten Samples mit 0,375 oder 0,5625 gewichtet werden, also deutlich geringere Variationen, Durchschnittsgewicht ist in allen Fällen immer 0,444). Bilinear nutzt eben einen zu kleinen Kernel.

http://abload.de/img/ogssaa_2.25_pixel_patrez6j.png
Ich glaube, ich habe bis auf ein oder zwei Ausnahmen mehr Erfahrung mit der praktischen Implementation des Resamplings von Daten als Andere hier im Thread. :rolleyes:

Ich kann hier nur noch mal ganz pauschal anmerken, daß der Ausgangspunkt für die Diskussion der Wunsch aufkrawalls war, mit einem "DS-Tester" die Downsamplingqualität zwischen verschiedenen Anbietern (also nV und AMD) zu vergleichen. Und Downsampling ist schlicht die Reskalierung eines 2D-Bildes zu einer anderen Auflösung. Will man das vergleichen, so sollten die verschiedenen Anbieter möglichst das gleiche Bild für das Downsampling angeboten bekommen. Dies ist bei AF-gefilterten Szenen nicht immer der Fall (sonst wären ja die ganzen Diskussionen um die AF-Filter für die Katz). Dies sollte man also vermeiden. Man kann genauso (oder sogar "schlimmere") flimmerkritische Situationen auf vollkommen ohne AF erzeugen (die bi-/trilinearen Filter arbeiten [beinahe?] identisch [vor ein paar Jahren gab es afair 1 Bit Unterschied in der Auflösung der Filtergewichte, das war meßbar, aber praktisch nie sichtbar; es spielt sowieso nur bei den 4xFP16- oder 4xFP32-Framebufferformat eine Rolle, bei RGBA8888 arbeiten die afaik bitidentisch, aber keine Ahnung, wie es bei den neueren GPUs ist]). Dies ist also vorzuziehen, wenn man das DS isoliert im Vergleich zwischen nV und AMD bewerten will.
Im Optimalfall unterdrückt Downsampling Flimmern. Wenn Flimmern dazukommt, ist der Downsampling-Filter suboptimal.
Dann hat das vermutlich jemand so implementiert, das es (auf Kosten der Qualität) rechentechnisch möglichst einfach wird oder er hat schlicht nicht drauf geachtet, daß Downsampling Nyquist-konform filtern sollte. Technisch ist AF-Filterung und der Downsampling-Filter sehr nah verwandt. AF benutzt einen 1D-Filter (bzw. die Faltung eines 1D-Filters mit dem 2D-bilinearen Filter [bilinear ist ein Spezialfall des Tent-Filters]), DS einen 2D-Filter, beide verrechnen mehrere Samples höherer Auflösung zu dem Farbwert für einen Pixel.
Entscheidend ist, daß die Größe des Filterkernels nicht irgendeine feste Größe in der höheren internen Auflösung besitzt, sondern daß er eine bestimmte Größe in der Ausgabeauflösung besitzt. Dann flimmert da auch nichts. Bei AF klappt es ja auch zum allergrößten Teil, obwohl dort eigentlich relativ simple Filter eingesetzt werden (bilinear/Tent quer zur Line of Anisotropie, Box entlang der LoA [bzw. Faltung von 1D-Box mit 2D-Tent]).

Mal ganz allgemein gesprochen, hängt (wie schon erwähnt) die Flimmerneigung nicht nur von der Art des Filters ab, sondern ganz entscheidend von der gewählten Größe des Kernels. Das ist ja mitnichten fest miteinander verbunden. Jeder Filter beschreibt gewissermaßen eine Kurve in einer durch Flimmerneigung und Bildruhe definierten Ebene (ist natürlich kein vollständiges Bild, einige Filter können zur Ausbildung spezifischer Artefakte führen, aber das ist hier erstmal egal):

http://abload.de/img/filter_compromisesysau.png

Die Wahl des Filters bestimmt erst mal nur die Kurve, auf der man sich bewegt. Wo man sich auf der Kurve befindet, wird durch die Kernelgröße festgelegt (das wären die schwarzen Punkte). Ist die falsch (zu klein) gewählt, kann auch ein an sich sehr guter Filter (z.B. der durch die grüne Kurve symbolisierte) stark flimmern. Gleichzeitig kann man mit jedem Filter durch Vergrößerung des Kernels mehr Unschärfe generieren. Der Gaußfilter tut dies übrigens exzessiv, das wäre also eher die rote Kurve ;).
Eine gute Lösung wäre z.B., direkt einen bikubischen Filter mit passender (eventuell auch vom Nutzer an seine persönlichen Vorlieben anpaßbarer) Kernelgröße als Rekonstruktionsfilter zum Downsampling zu benutzen, ohne den Gaussian Blur.
Bilinear bzw. Tent ist zwar längst nicht optimal (man opfert man etwas zu viel Schärfe, bis auch wirklich die Flimmerneigung getilgt ist), aber oft annehmbar. Bei hohen DS-Faktoren ist für die Rechenzeitersparnis allerdings auch eine Kombination von bilinear mit einem "guten" Filter ohne große Verluste möglich.
Ja, wenn das gut implementiert ist (passende Kernelgrößen), bringen die entsprechenden Filter einen fast optimalen Kompromiß zwischen Bildschärfe und Flimmerneigung. Man kann tatsächlich relativ niedrige Flimmerneigung mit hoher Schärfe kombinieren.
Bei Mitchell-Netravali ([bi]kubisch) muß man übrigens etwas aufpassen, das ist nicht nur ein Filter. Den kann man über zwei Parameter zwischen Blur-Filter und schärfeerhaltendem Filter variieren (oder auch unsinnige Parameterkombinationen wählen, die artefakten wie die Hölle). Was MadVR standardmäßig nutzt, keine Ahnung. Die Version in GIMP ist relativ nahe an einem Lanczos2-Filter, die Version in Paint.NET blurrt dagegen recht stark. Oft wird irgendwas dazwischen empfohlen. Allerdings besitzt nur die GIMP-Version (wie auch bilinear, Box und die separierbaren Lanczos-Filter) eine interessante Eigenschaft: Wendet man die für ein 1:1 Resampling an, erhält man wieder exakt das Ausgangsbild (wenn man die nominelle Filterbreite von einem Pixel benutzt, also keine zusätzliche Unschärfe einführt [der Footprint der Filter ist außer bei Box größer als 1 Pixel]). Dies ist bei den (meisten) anderen Filtern nicht der Fall.
Nicht nur wahrscheinlich bilinear, sondern definitiv bilinear. Der Gaußfilter wirkt bei 4.00x DSR erst ab 11%. Wirklich sichtbar aber erst ab 20%.



NN erhöht das Flimmern sogar. Davon ab ist NN + smoothness 17% ungefähr mit bilinear vergleichbar.





NVs DSR ist billig (wenig Takte in den ALUs) aber dafür weder ideal in punkto Schärfe noch in Punkto Flimmeranfälligkeit)

Es gab sogar hier im Forum Videos, bei denen die Downsamplingfilter auf dem Desktop (dort sieht man wegen der feinen definierten Linien und harten Kontrastübergängen vieles) vorgeführt haben. Mit den von NV genutzten Filtern hat es massiv geflimmert. Mit bicubischem Filter nicht.
Ich finde die Videos nur gerade nicht.

Ich denke aber es war auch oc_burner oder Geldmann3

[blaidd]

Für gerade Faktoren wird ein bilinearer Filter genutzt. Für ungerade Gauß + Pointsampling. Über GeDoSaTo stehen Bilinear, Lanczos und Bikubische Filter bereit.
Der Qualitätsunterschied - vor allem hinsichtlich Flimmern und Schärfe ist schon signifikant.

Allerdings kosten ordentliche Filter laut Gipsel und Co. fast 2 Größenordnungen mehr an Rechenzeit.

Die Filterung dürfte im Endeffekt aber nur einen geringen Performance-Einschnitt ausmachen, selbst wenn da ein ordenlicher Lanzcos-Filter zum Einsatz käme. Ob da jetzt kolportierte 3 statt 1,5 Millisekunden draufgehen, spielt doch nur eine geringe Rolle, wenn man gleichzeitig die Auflösung drastisch erhöht - was im fiktiven Beispiel locker 30 bis 50 Millisekunden ausmachen könnte. Ich versteh daher diesen ganzen Filter-Geiz nicht ganz...

Selbst mit 16:9 gäbe es bei 75Hz kein VSR mit dem Monitor.

Das geht schon. Das hat AMD ein bisschen dämlich kommuniziert - Du kannst prinzipiell mit jedem Full-HD- oder WQHD-Display VSR nutzen, aber wenn es beispielsweise 75 oder 144 Hz unterstützt, bekommst du mit Downsampling nur die VSR-Auflösungen mit 60 Hz angeboten.

Generell sollte VSR noch ein bisschen aufgemöbelt werden, so finde ich die Lösung nur mäßig ansprechend. 2160p oder 1440p auf 1080p ist ganz schick, 2400p oder 1600p auf 1200 geht auch ganz gut, die 1800er-Auflösung ist leider nicht so gut zu gebrauchen. DSR ist von den Auflösungen her weiter, da sind aber auch nur eine handvoll gut zu gebrauchen, der Rest sieht einfach crap aus...

Downsampling mit GeDoSaTo sieht deutlich schicker aus und ist außerdem deutlich flexibler (rein vom DS her, nicht von der Kompatiblität). Was so schwierig daran ist, einfach eine ähnliche Lösung im Grafikkarten-Treiber anzubieten, ist mir auch nicht ganz klar - vielleicht wäre das für den durchschnittlichen Nutzer zu kompliziert oder man würde in Benchmarks gegenüber der Konkurrenz zu stark einbrechen, wenn man selbst schickere Filter nutzen würde, nicht aber der Wettbewerber. Leider ist ein minimales Performance-Plus offenbar oft wichtiger als ein deutlich besseres Bild, selbst wenn man ersters kaum bemerken würde, letzteres dagegen schon.

Einen längeren Balken kann aber eben auch jeder sofort nachvollziehen, Bildqualität vor allem in Bewegung kann man kaum vernünftig darstellen, nicht mal per Video - das bekommt man nur schwierig gecaptured und dazu kommt dann noch die Kompression... Und ohne entweder Bildmaterial oder Messwerte als Grundlage braucht man gar nicht versuchen, irgendwas zu erklären, glaubt einem ja doch keiner ;)

[robbitop]

Die Filterung dürfte im Endeffekt aber nur einen geringen Performance-Einschnitt ausmachen, selbst wenn da ein ordenlicher Lanzcos-Filter zum Einsatz käme. Ob da jetzt kolportierte 3 statt 1,5 Millisekunden draufgehen, spielt doch nur eine geringe Rolle, wenn man gleichzeitig die Auflösung drastisch erhöht - was im fiktiven Beispiel locker 30 bis 50 Millisekunden ausmachen könnte. Ich versteh daher diesen ganzen Filter-Geiz nicht ganz...

Ich sehe das ähnlich wie du. :)
Deshalb nutze ich, so oft es geht GeDoSaTo.

Da der Anteil der Rechenzeit pro Bild für das Downsampling gering ist, ist auch der Einfluss einer Erhöhung der Rechenzeit immernoch vergleichsweise gering.

Zu blöd, dass es keinen DX10/11 Support gibt. Die ReShade Leute wollen wohl auch kein Downsampling implementieren. Meh.

[Novum]

Nope.
Entschuldige ich meine Nearest Neighbor, nicht Pointsampling.
Nearest Neighbor würde bedeuten, dass genau ein Sample genommen pro Pixel. Das ist offensichtlich nicht der Fall.

ungerade gauß + nearest neigbour.
Das ist einfach ein Gauß-Filter wenn ich dich richtig verstehe. Das ist weder billig noch schlecht, höchstens leicht unscharf.

Ordentliches Image-Resampling für ungerade Faktoren braucht Polyphase-Kernel (jeder Pixel hat andere Gewichte) und Gamma-Korrektur. Das steht im ganzen Internet nirgends. Irgendwie ist das Black Magic die niemand verständlich erklären will, obwohl Photoshop usw. das schon seit Jahrzehnten so machen. Ich hab den Gedosato-Code mal kurz angeschaut und das sieht auf Anhieb auch falsch aus.

NVIDIA Texture Tools macht es aber korrekt, deshalb traue ich denen das eigentlich durchaus zu, das auch auf der GPU gescheit zu machen.

[Tesseract]

Nearest Neighbor würde bedeuten, dass genau ein Sample genommen pro Pixel. Das ist offensichtlich nicht der Fall.

ist wohl so implemeniert, dass im targetbuffer auf jeden pixel ein 13-tap-gauss-kern angewendet wird der die 13 werte aus dem sourcebuffer per nearest neighbor liest.

[aufkrawall]

Witzig: Durch schlechte Rekonstruktion bei unpassenden Faktoren oder zu niedriger Smoothness wird sichtbarer, was sich auch schon in nativer Auflösung im Filtertester ground2 andeutet:
NV HQ (also das echte von G80 und Maxwell 2) flimmert weniger als die ALU-Referenz von Coda. :D

[Blackhand]

Tja, Downsampling erhöht halt oftmals alle Details, auch die Artefakte X-D

[Blackhand]

Ich habe mal alle DSR-Faktoren überprüft.
Seit r352 ist es ja nicht mehr so, dass 25% für alle Faktoren ausreichen.
Ziel ist, dass es mit dem gewählten Smoothness-Wert möglichst wenig flimmert und der Wert dabei nicht höher ist als nötig.
Getestet mit Ground2 Textur im Filtertester.

Die Ergebnisse:
1,2x: 100% (Restflimmern) <- unnütz
1,5x: 100% fast flimmerfrei, aber sehr unscharf <- weitestgehend unnütz
1,78x: relativ starkes Flimmern, trotz 100% <- unnütz
2x: flimmerfrei mit 30%
2,25x: flimmerfrei mit 25%
3x: Restflimmern, trotz 100% <- unnütz
4x: flimmerfrei, Smoothness optional und je nach Vorliebe

Also eigentlich sind nur 2x, 2,25x und 4x gut. Mit denen sieht es seit r352 mit der richtigen Smoothness aber auch recht oder ziemlich scharf aus, ohne dabei schrottig zu sein.

Das kann ich leider weder für Kepler, noch fürs ALU-Rendering bestätigen. Evtl. macht hier die QHD-Auflösung und/oder Pixeldichte den Unterschied mit der du testest. Auf meinem 24" FHD-Display verhält sich das anders.

Ich versuche hier auch das Flimmern zwischen nativer und DS-Auflösung zu vergleichen, in nativer Auflösung ist es hier schließlich keineswegs flimmerfrei(weder ALU noch TMU(Qualitiy + tril. Opt. off). Die Maxfreq Textur lässt hier btw. viel deutlicher Unterschiede hervortreten zwischen TMU und ALU.

Leider ist das aber schwer machbar, zu der Thematik zitier ich mich grad nochmal selbst.

Ich hatte schon angefangen mit einem Lineal Flimmerspotpositionen zu bestimmen. Problem dabei ist, dass bei höheren Auflösungen die Fensterbreite abnimmt und so die Textur etwas anders im Bild liegt. Ich bin mir nicht sicher, ob man da den schwarzen oberen Rand als vergleichbaren Bezugspunkt verwenden kann. Hat der Tester irgendwie einen Vollbildmodus?

Ich hätte da für solche Zwecke folgendes Featurerequest beim Filtertester: Vollbildmodus, wobei die Settings als transparentes und vektorisiertes Overlaydock implementiert werden könnten. Dazu noch normierte und verschiebbare x- und y-Messachsen um auflösungsunabhängig bestimmte Flimmerspotpositionen bestimmen zu können.

So könnte man schon eher einen Konsens finden mit welchen DS-Settings wo flimmern entsteht/verstärkt wird und wo es vermindert/eliminiert wird.

Ist ground2@nativ QHD bei dir denn flimmerfrei?

[aufkrawall]

Nein, ein Restflimmern gibt es natürlich immer.
Das hab ich aber mitberücksichtigt. 2x 30% flimmern mehr als 2,25x 25%, aber trotzdem nicht unbedingt mehr als nativ (allerdings anders, nämlich breitflächiger).
Ebenso könnte man sagen, dass 4x mehr als nativ flimmert, aber die Texturen sind auch viel detaillierter. Deshalb müssen native 1440p auch nicht unbedingt flimmerfreier wirken als native 1080p.

[aufkrawall]

NV schraubt wohl heimlich immer weiter an DSR rum.
Es bleibt dabei, dass nur 2x und 2,25x von den Faktoren <4x gute Qualität liefern, aber man braucht jetzt (schon früher als mit 355.98, genauen Treiber weiß ich nicht mehr) 35% Smoothness (getestet mit BF4 Lancang Dam Asphalt-Textur).
Es ist so nicht gestochen scharf, aber auch nicht matschig. Ich hab nicht unbedingt das Bedürfnis, da ohne Post-AA noch Lumasharpen drüberlegen zu wollen.
So ist das durchaus brauchbar.

Mit einem der letzten Treiber wurden offenbar auch Maus-Probleme gefixt. Ich muss im HotS-Menü das Spiel nach dem Auswählen einer DSR-Auflösung nicht mehr per Alt + F4 einmalig abwürgen und auch die Mausgeschwindigkeit verändert sich nun nicht mehr gegenüber der nativen Auflösung (oder nur minimal).

Edit: Ach so: Es funktioniert im Fenster-Modus übrigens nun anders als im Vollbild-Modus. Im Fenstermodus hat der Smoothness-Regler keinen Effekt. Es ist immer etwas unscharf, dafür sind alle Faktoren ohne flimmern nutzbar. Warum das so ist? Weiß wohl nur Nvidia...
Jedenfalls kann man so Filtertester-Tests vergessen.

[Flusher]

Btw - hat man irgendwas mal vom nächsten Omega Treiber gehört? Da ist es seit dem Launch der FuryX glaub ich ziemlich still geworden.

[samm]

Ich vermute mal, einen Omega genannten gibt es z.B. Ende Jahr wieder.

[Blaire]

Edit: Ach so: Es funktioniert im Fenster-Modus übrigens nun anders als im Vollbild-Modus. Im Fenstermodus hat der Smoothness-Regler keinen Effekt. Es ist immer etwas unscharf, dafür sind alle Faktoren ohne flimmern nutzbar. Warum das so ist? Weiß wohl nur Nvidia...
Jedenfalls kann man so Filtertester-Tests vergessen.

Ist ein Treiberbug. Statt über den Treiber , probiers mal über die Windows-Anzeigeinstellungen direkt , dann funktioniert der Smoothness-Slider auch auf dem Desktop wie gehabt. :) Alles weitere wird sich dann sicher bald per Treiber lösen lassen.

[horn 12]

Neuer "Spezial" OMEGA Treiber 2.0 Release im November
Hoffe das diesmal auch die Fury Serie Richtig gepusht wird!

http://wccftech.com/second-special-edition-drivers-amd-november-catalyst/

[dargo]

Oha... meine größte Hoffnung liegt an Freesync im Fenstermodus. :naughty:

[AintCoolName]

Oje das riecht nach Ärger. Der Artikel behauptet der Treiber kommt im November,ich wette der kommt später und alle Welt behauptet AMD hätte Versprochen der kommt im November.

[aufkrawall]

Was dieser "Autor" so für einen Müll zusammen schreibt...

[Isen]

Die Kommentare und Meinung die dadurch gebildet werden sind noch schlimmer. Regelrechte Boyz-fabriken solche Artikel.

[horn 12]

Omega 2 wird wohl gemeinsam zur Fury X2 kommen, oder zumindest in ca. fast selbem Zeitraum!

[Menace]

The driver also included updates for Tress FX 3.0, HSA 1.0, CUDA 2.0

Ha, von wegen proprietär. :biggrin:

Ist das die 2. Version (die richtige), die damals für Februar angekündigt war? :confused:

[Unicous]

Wahrscheinlich haben sie eine Rechtschreibprüfungssoftware von Nvidia. Da wird OpenCl automatisch durch CUDA ersetzt.:wink:

[deekey777]

Ha, von wegen proprietär. :biggrin:

Ist das die 2. Version (die richtige), die damals für Februar angekündigt war? :confused:
Wollte mir auch da einen Spaß erlauben.

Mein Problem ist:
Wie man DAAMIT kennt, wird der Omega-Treiber abseits der gewöhnlichen Treiber veröffentlicht. Werden irgendwelche Fixes veröffentlicht, so werden sie nicht die Neuerungen des Omega-Treibers beinhalten.

[Menace]

Ich habe das nicht mehr wirklich in Erinnerung, aber war nicht mal vorgesehen die Catalyst-Software komplett umzukrempeln (letztes Jahr), es aber nur zu ein paar Neuerungen und Bug-Fixes gereicht hat (die aber sehr gut waren)? Oder waren das nur Gerüchte ohne jegliche AMD-Aussagen-Bezug?

[DeadMeat]

Ich habe das nicht mehr wirklich in Erinnerung, aber war nicht mal vorgesehen die Catalyst-Software komplett umzukrempeln (letztes Jahr), es aber nur zu ein paar Neuerungen und Bug-Fixes gereicht hat (die aber sehr gut waren)? Oder waren das nur Gerüchte ohne jegliche AMD-Aussagen-Bezug?

Ich dachte das "All-New" bezog sich nur auf die Windows 10 Treiber und auch nur der Treiber Teil und nicht das Control Center.

[aufkrawall]

Ob wegen VSR überhaupt noch etwas kommt?
Vielleicht sind DX11 Overhead-Verbesserungen wahrscheinlicher, AMD hatte da ja vor einiger Zeit eine Stelle für ausgeschrieben.

[dargo]

Ob wegen VSR überhaupt noch etwas kommt?
Vielleicht sind DX11 Overhead-Verbesserungen wahrscheinlicher, AMD hatte da ja vor einiger Zeit eine Stelle für ausgeschrieben.
VSR ist imo völlig überbewertetes Thema, es gibt genug Auswahl bei 1440p und 2160p Bildschirmen. Da gibt es wichtigere Baustellen:

* Freesync im Fenstermodus
* Prerenderlimit für DX11 und DX12
* Weitere DX11 Overhead-Reduzierung
* Funktionierende Bildschirmskalierung in einer 3D-Anwendung (nicht nur Desktop)

[aufkrawall]

Ganz deiner Meinung.

[Lurtz]

* Freesync im Fenstermodus
Ich dachte das wäre technisch unmöglich?

[dargo]

Wie kommst du darauf?

[blaidd]

Ich bin mal gespannt, was da kommt (falls das Gerücht denn überhaupt stimmt).

Bei VSR erhoffe ich mir ein paar Verbesserungen (auch wenn ich es persönlich nur selten nutze), da hab ich ein Vorschläge abgegeben (z.B. mehr Auflösungen, wählbare Filterung). Genau wie zu Freesync, da arbeitet AMD meines Wissens bereits an Framedoubling.

Ein paar andere Dinge wären auch noch nett, beispielsweise das schon angesprochene Prerender-Limit, aber auch eine Anhebung des einstellbaren Framelimits über (unsinnige) 95 Fps, für den Fall das Vsync mal Stress macht oder zuviel Input-Lag erzeugt.

Das mit dem Overhead bzw. nicht vernünftiger Auslastung der GPU ist so eine Sache... wer weiß, wie viel da architekturbedingt überhaupt machbar ist - nett (und eigentlich nötig, um Performance-Lücken in einigen Spielen zu schließen) wäre es auf jeden Fall. Ich hab aber mittlerweile das Gefühl, dass da ohne Low-Level-API oder zumindest starken Auslegung der Engine auf AMD-GPUs einfach nicht viel drin ist. Die Fijis könnten aber sicherlich hier und dort einen zusätzlichen metaphorischen Treiber-Tritt vertragen.

Außerdem wäre ein weiterer Fokus auf VR meines Erachtens im Bereich des möglichen, da wird schließlich momentan eh dran herumgedoktort.

[dargo]

Das mit dem Overhead bzw. nicht vernünftiger Auslastung der GPU ist so eine Sache... wer weiß, wie viel da architekturbedingt überhaupt machbar ist - nett (und eigentlich nötig, um Performance-Lücken in einigen Spielen zu schließen) wäre es auf jeden Fall. Ich hab aber mittlerweile das Gefühl, dass da ohne Low-Level-API oder zumindest starken Auslegung der Engine auf AMD-GPUs einfach nicht viel drin ist.
Es ging mir um den Treiberoverhead im CPU-Limit, nicht GPU-Limit.

[Lurtz]

Wie kommst du darauf?
Weil Windows das Sagen auf dem Desktop hat, nicht der Treiber. Habe ich mir mal so erklären lassen als es um das "erzwungene" VSync im Borderless Fullscreen ging.

[dargo]

Dann hat man dir Quatsch erzählt.
http://www.hardwareluxx.de/index.php/news/hardware/grafikkarten/35480-nvidias-g-sync-erhaelt-neue-funktionen-und-neue-monitore-vorgestellt.html

[aufkrawall]

Das stimmt schon, in Aero ist Vsync immer an. Das wird der Treiber nur irgendwie zu Gsync umgemodelt haben.

[dargo]

Vsync ist aber kein Hindernis für VRR. Ich sehe da also kein Problem.

[aufkrawall]

Hab mal VSR auf Hawaii 3200x1800@WQHD in BF4 getestet: Sieht überraschend gut aus, recht scharf und flimmerfrei. Hätte ich jetzt gar nicht so gedacht, not bad.
Hat aber wegen des geringen Faktors halt kaum einen AA-Effekt und mit 75Hz per CRU gehts gar nicht mehr. AMD, warum...

[DrFreaK666]

Ich kann auch keine 96Hz wählen wenn DSR aktiv ist

[aufkrawall]

Etwas genauer bitte?
Das wär dann ein Bug und keine generelle Einschränkung. DSR geht mit 144Hz 5k@WQHD.

[DrFreaK666]

Etwas genauer bitte?
Das wär dann ein Bug und keine generelle Einschränkung. DSR geht mit 144Hz 5k@WQHD.

Wenn ich DSR aktiviere, dann habe ich nur 60Hz zur Auswahl. Liegt vielleicht daran, dass es ein 60Hz-Monitor ist (auf 96 übertaktet)

[aufkrawall]

Dann solltest du CRU nehmen. Damit kannst du übertakten und weiterhin DSR nutzen.

[Mr. Lolman]

Hab mal VSR auf Hawaii 3200x1800@WQHD in BF4 getestet: Sieht überraschend gut aus, recht scharf und flimmerfrei. Hätte ich jetzt gar nicht so gedacht, not bad.

Kombiniers mal testweise mit MLAA.

[DrFreaK666]

Dann solltest du CRU nehmen. Damit kannst du übertakten und weiterhin DSR nutzen.

CRU?

[Hübie]

Custom Resolution Utility. :)

[DrFreaK666]

Ok. Werde ich mal anschauen
Danke

[dildo4u]

Es gibt grad ein Free Weekend für Rocket League aufs Steam,aber irgendwie funzt DSR bei mir hier nicht komisch das Game nutzt UE 3.0.Bei 1080p hab ich dort über 150fps da ist noch Luft. ;D

[Raff]

Hast du mal testweise die Desktopauflösung auf die Wunsch-DSR-Auflösung gestellt und es dann versucht?

MfG,
Raff

[dildo4u]

Nope geht auch nich echt komisch.

[Raff]

Seltsam, denn bei mir geht's. DSR-Auflösung auf dem Desktop einstellen und dann das Spiel starten: Auflösung ist im Spiel verfügbar und wird nach Klick auf "Übernehmen" angewendet.

MfG,
Raff

[iuno]

Kann ich so bestaetigen aus meiner Zeit mit FHD Monitor.
Fuer RL habe ich immer die Aufloesung am Desktop auf die "VSR-Aufloesung" hochstellen muessen, dann das Spiel starten, dann war die Aufloesung auch ingame im Menue vorhanden.
Oder direkt in die ini eintragen, sollte auch gehen.

[aufkrawall]

Ich poste es auch mal hier:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=11173656&postcount=68
Die Unsitte von Windows 10, mit Downsampling automatisch die Skalierung umzuschalten, kann man per Registry-Tweak abschalten.
Die ist dafür verantwortlich, dass die Icons durcheinander geraten und die Oberfläche von geöffneten Programmen wie Browsern kaputt geht.

[Lurtz]

Mit standardmäßig eingeschalteter Skalierung ändert Win10 in Spielen unter nativer Auflösung auch automatisch die Skalierung.
Würde man um das zu fixen dann die Skalierung auf die Desktopskalierung in der Registry stellen (bspw. 150%)? :confused:

[aufkrawall]

Gute Frage, probier es doch aus. :)