Nvidia Intellisample?

[mapel110]

http://www.digit-life.com/articles2/behind-intellisample/index.html
kann jemand mal mit kurzen worten zusammenfassen, was da in dem artikel steht ? irgendwie durchschau ich das ganze nicht so.

[Demirug]

Eigentlich ganz einfach. Der Treiber macht nun nur das was NVIDIA schon jahrelang (seit es AF und/oder tri Filter gibt) den Entwicklern erzählt das sie es tun sollen. Der maximale AF-Level wird nicht mehr generel auf einen Wert für alles festgelegt sondern pro Texture.

Jetzt stellt sich natürlich die Frage welcher AF-Level für welche Texture benutzt werden soll. Um da eine Entscheidung zu treffen analysiert NVIDIA den Inhalt der Texture. Diese Analyse überprüft die Schärfe der Texture. Eine Detailmap hat zum Beispiel in der Regel viele schnelle Farbübergänge bei einer Lightmap dagegen sind kaum solche extremen übergänge von einem Pixel zu nächsten vorhanden. Aufgrund dieser Analyse und den Einstellungen im Panel wird dann für jede Texture der max AF-Level festgelegt. Eine Detailmap wird dabei meistens den aus dem maximalen Wert aus dem Panel bekommen und eine Lightmap einen sehr kleinen (wenn die Optimierung aktiv ist). Da bei einer Lightmap AF sowieso nicht viel bringt ist das auch eigentlich in Ordnung.

Letzten Endes macht hier NVIDIA eine Optimierung welche die faule Designer/Grafiker nicht machen wollten.

PS: Diese Textureanalyse wird übrigens in dem Intellisample Dokument von NVIDIA auch angekündigt.

PPS: Ja es ist irgendwie ein Treibercheat. Aber ein echt guter.

[aths]

Ja, der Treiber analysiert offenbar jede Textur und ermittelt den Kontrast-Umfang. Er unterscheidet in 3 Stufen zwischen schwachkontrastige und hochkontrastige Texturen. Die letzteren bekommen je nach Verzerrungsfaktor auch das volle AF-Level. Die anderen müssen sich, je nach Einordnung, mit einem niedrigeren maximalen AF-Level begnügen.

Die Analyse zeigt schnell: Im "Performance"-Modus wird, sobald die Textur nicht mehr hochkontrastig ist, praktisch gar kein AF gemacht. Ausnahme: Wenn 8x AF eingestellt ist, bekommen mittelkontrastige Texturen "noch" 2x.

Der "Balanced" Mode hingegen ist nicht so dreist, er schaltet nur bis 2x runter, so dass die Anisotropie in jedem Fall erhalten bleibt. Mittelkontrastige Texturen werden bei eingeschaltetem 8x AF noch bis zu 4x AF gefiltert. Das erscheint mir eine gute Mischung aus Bildqualität und Geschwindigkeit zu geben. Man sollte nicht vergessen, dass AF zugeschaltet wird, um Qualität zu bekommen.

Die Optimierung gilt Unwinder für alle Stages. Ich finde das weniger toll. Allerdings kann man in Q3 eigentlich keine Unterschiede ausmachen, insofern ist es schon clever.

Es soll noch eine weitere Optimierung geben. Der Treibe soll bei bestimmten Polygonen, die Kriterien sind unklar, für Stage 1 bis 3 AF komplett weglassen, und nur noch Stage 0 filtern. Diese Optimierung ist allerdings nur aktiv, wenn AF "von außen" erzwungen wird.

Wenn man das so betrachtet, hat NV eine Menge für die AF-Performance (zulasten der Qualität, natürlich) getan.

[Demirug]

Originally posted by aths
Die Optimierung gilt Unwinder für alle Stages. Ich finde das weniger toll. Allerdings kann man in Q3 eigentlich keine Unterschiede ausmachen, insofern ist es schon clever.

Wo ist das Problem. Solange der Treiber den Kontrast richtig erkennt ist es doch in Ordnung. Wenn auf Stage 0 eine Texture mit hohem Kontrast gesetzt wird gibt es ja volles AF.

Es soll noch eine weitere Optimierung geben. Der Treibe soll bei bestimmten Polygonen, die Kriterien sind unklar, für Stage 1 bis 3 AF komplett weglassen, und nur noch Stage 0 filtern. Diese Optimierung ist allerdings nur aktiv, wenn AF "von außen" erzwungen wird.

Das ist nun aber mist. Wenn die primäre Texture dann mal nicht auf Stage 0 liegt gibt es IQ Verlust ohne ende. Da gefällt mir die andere Variante besser.

[aths]

Originally posted by Demirug
Wo ist das Problem. Solange der Treiber den Kontrast richtig erkennt ist es doch in Ordnung. Wenn auf Stage 0 eine Texture mit hohem Kontrast gesetzt wird gibt es ja volles AF.Hoher Kontrast "braucht" mehr AF, ja. Aber sieh es mal so: Niedriger Kontrast, der dann auch noch verwaschen bleibt, ist auch nicht so geil. Da sieht man dann erst recht nichts.

Lösungs-Idee: Die Engine appliziert je nach Inhalt selbst ein maximales AF-Level. Also Lightmaps z.b. bekommen halt maximal 2x AF, aber schwachkontrastige Base Maps je nach Wunsch auch 4x oder 8x.

Originally posted by Demirug
Das ist nun aber mist. Wenn die primäre Texture dann mal nicht auf Stage 0 liegt gibt es IQ Verlust ohne ende. Da gefällt mir die andere Variante besser. Da sollte die Base Texture aber liegen :naughty:

[Demirug]

Originally posted by aths
Hoher Kontrast "braucht" mehr AF, ja. Aber sieh es mal so: Niedriger Kontrast, der dann auch noch verwaschen bleibt, ist auch nicht so geil. Da sieht man dann erst recht nichts.

Wo nichts ist kann man auch mit AF nichts herausholen. Wenn eine Textur eine hohe lokale Farbähnlichkeit (pro Kanal) aufweist dann kannst du soviel Texel aus einem Bereich nehmen wie du willst es ändert nicht wirklich was am Endergebniss.

Lösungs-Idee: Die Engine appliziert je nach Inhalt selbst ein maximales AF-Level. Also Lightmaps z.b. bekommen halt maximal 2x AF, aber schwachkontrastige Base Maps je nach Wunsch auch 4x oder 8x.

:rofl: Sorry

Das NVIDIA diese erkennung jetzt eingebaut hat ist die Reaktion darauf das die Designer/Grafiker diese Empfehlung schon seit jahren einfach ignorieren bzw die Programmierer gar keine Option dafür einbauen.

In jedem Performanceguide von NVIDIA steht immer. AF ist teuer also bitte immer selektiv nur soviel wie notwendig.

Da sollte die Base Texture aber liegen :naughty:

Das ist eine überholte Vorstellung. Gerade wenn man Shaderhochsprachen und Effektframeworks benutzt gibt man die Verantwortung für solche Deatails wie welche Texture kommt bei welchem Pass auf welchen Stage kommt, an die Tools ab.

Auf Stage bezogenes Filtern ist deswegen keine gute Lösung.

[aths]

Ok, mal von hinten aufgerollt.
Originally posted by Demirug
Das ist eine überholte Vorstellung. Gerade wenn man Shaderhochsprachen und Effektframeworks benutzt gibt man die Verantwortung für solche Deatails wie welche Texture kommt bei welchem Pass auf welchen Stage kommt, an die Tools ab.

Auf Stage bezogenes Filtern ist deswegen keine gute Lösung. Für Pixelshader sehe ich vor allem drei große Anwendungsgebiete: Schnelles Multitexturing, Bump Mapping, und prozedurales Texturing. Schon beim Bump Mapping sollte der Designer sich Gedanken um das AF-Level machen, sonst hat man z.B. bei Wasserflächen ruckzuck Pixelflimmern drin. Bei prozeduralen Texturen ist ja ohnehin nicht von vornherein klar, welche Frequenzen entstehen werden. Der Designer muss den gegebenen Effekt kennen, und sagen, welches AF-Level die Texturen bekommen sollen sobald der Spieler im Menü die Textur-Qualität einstellt.

Bei Stage 0 anzunehmen, es handele sich um die Base Map, geht natürlich nur beim Multitexturing. Ansonsten sollte man den faulen Designern mal in den Hintern treten und sie schlicht zwingen, sich einen Kopp zu machen welche Texturen welches AF-Level brauchen, um Flimmereien zu vermeiden.

("Trilineares" Pixelshading wäre an der Stelle auch mal anzudenken. Der Effekt wird zwei mal gerendert wo unterschiedlich aufgelöste Texturen zum Einsatz kommen, das Ergebnis wird dann linear geblendet. Im nächsten Schritt müsste man "anisotropes" Pixelshading machen, wo der Effekt insgesamt mindestens 4x gerendert wird. Würde SIMD-Logik eingesetzt, sollte das auch mit vertretbarem Aufwand machen lassen.)
Originally posted by Demirug
In jedem Performanceguide von NVIDIA steht immer. AF ist teuer also bitte immer selektiv nur soviel wie notwendig.Leider leider gibt es kaum Spiele, wo man AF überhaupt einstellen kann, und wenn, dann nur "on" oder "off". Wobei mir ehrlich gesagt das Verständis fehlt, wieso sich kaum einer darum kümmert. Das Feature ansich wird von sehr vielen Karten beherrscht. Man bräuchte lediglich 3 "Profile": Kein AF möglich, 2x AF möglich, 8x/16x AF möglich.

(Es gab Zeiten, da waren Polygone mit Flat Shading schon toll, doch die Zeiten sollten langsam mal vorbei sein...)
Originally posted by Demirug
Wo nichts ist kann man auch mit AF nichts herausholen. Wenn eine Textur eine hohe lokale Farbähnlichkeit (pro Kanal) aufweist dann kannst du soviel Texel aus einem Bereich nehmen wie du willst es ändert nicht wirklich was am Endergebniss.

Das NVIDIA diese erkennung jetzt eingebaut hat ist die Reaktion darauf das die Designer/Grafiker diese Empfehlung schon seit jahren einfach ignorieren bzw die Programmierer gar keine Option dafür einbauen. Diese Erkennung ist mir zu primitiv. Der Treiber analysiert die gesamte Textur. Es kann durchaus sein, dass der größte Teil geradezu einfarbig ist (dann brauchts natürlich gar kein AF) aber einige Stellen Struktur haben. Sobald der Kontrast-Umfang insgesamt zu klein ist, geht der Treiber einfach davon aus, dass die ganze Textur weniger (oder gar kein) AF braucht.

Der Treiber analysiert Texturen nicht, wenn sie komprimiert sind. Das ist dumm. Es wäre vielleicht sogar sinnvoller, wenn pro Textur-Kachel entschieden würde. Hier gibts natürlich das Problem, dass es Kachel-Artefakte geben könnte, das wäre aber zu lösen, in dem die Kontrastumfang-Erkennung vorsichtig genug arbeitete. (Jedenfalls finde ich es schade, dass komprimierte Texturen aus der Optimierung generell rausfallen.)

Was Lightmapping und AF angeht: Ohne den dummen AF-Bug gibts bei BF immerhin 2x AF bei gleicher Pixelfüllrate (sofern 2 TMUs pro Pipe.) Sobald auch nur 2x AF aktiv ist, hat man bei BF auf NV25 und NV28 den Leistungsverlust. Bevor man der Leistung wegen das AF-Level senkt, sollte man erst mal die vorhandenen TMUs fürs AF ausnutzen können. Vermutlich ist die Lightmap so ziemlich das einzige, was bei Multitexturing heutzutage nur bilinear gefiltert wird. Imo sollten Lightmaps auch anisotrop gefiltert werden, einfach, weil "gute", also detaillierte Lichteffekte schön sind, und man durch den AF das Fehlen von MIP-Texturen etwas ausgleichen kann.

Angenommen man hat eine schwachkonstrastige, aber fein strukturierte Textur. Die wird mit Optimierung matschig. Schwacher Kontrast heißt nicht automatisch, dass jedes Texel von Texeln mit hoher Farbähnlichkeit umgeben ist. Wenn ich mich jetzt nicht irre, ist der erste Treshold bei 48. Auf einer Skala von 0..255 ist das nicht unbedingt wenig, finde ich. Zum Glück ist diese Optimierung abschaltbar, und mit der "Balanced"-Optimierung kann man in den meisten Fällen afaik durchaus leben.

[mapel110]

hm, warum geht das prüfen der einzelnen texturen schneller als AF anzuwenden ?

[Demirug]

Originally posted by aths
Ok, mal von hinten aufgerollt.
Für Pixelshader sehe ich vor allem drei große Anwendungsgebiete: Schnelles Multitexturing, Bump Mapping, und prozedurales Texturing. Schon beim Bump Mapping sollte der Designer sich Gedanken um das AF-Level machen, sonst hat man z.B. bei Wasserflächen ruckzuck Pixelflimmern drin. Bei prozeduralen Texturen ist ja ohnehin nicht von vornherein klar, welche Frequenzen entstehen werden. Der Designer muss den gegebenen Effekt kennen, und sagen, welches AF-Level die Texturen bekommen sollen sobald der Spieler im Menü die Textur-Qualität einstellt.

Bei Prozeduralen Texturen gibt es keine AF-Filter. Diese werden ja nur berechnet ;) Aber ansonsten stimme ich dir im Prinzip zu.

Bei Stage 0 anzunehmen, es handele sich um die Base Map, geht natürlich nur beim Multitexturing. Ansonsten sollte man den faulen Designern mal in den Hintern treten und sie schlicht zwingen, sich einen Kopp zu machen welche Texturen welches AF-Level brauchen, um Flimmereien zu vermeiden.

Ack

("Trilineares" Pixelshading wäre an der Stelle auch mal anzudenken. Der Effekt wird zwei mal gerendert wo unterschiedlich aufgelöste Texturen zum Einsatz kommen, das Ergebnis wird dann linear geblendet. Im nächsten Schritt müsste man "anisotropes" Pixelshading machen, wo der Effekt insgesamt mindestens 4x gerendert wird. Würde SIMD-Logik eingesetzt, sollte das auch mit vertretbarem Aufwand machen lassen.)

mit genügend PS-ALUs kein Problem das wird aber noch etwas dauern.

Leider leider gibt es kaum Spiele, wo man AF überhaupt einstellen kann, und wenn, dann nur "on" oder "off". Wobei mir ehrlich gesagt das Verständis fehlt, wieso sich kaum einer darum kümmert. Das Feature ansich wird von sehr vielen Karten beherrscht. Man bräuchte lediglich 3 "Profile": Kein AF möglich, 2x AF möglich, 8x/16x AF möglich.

Beschwer dich nicht bei mir ich kann in andere Spiele auch keine AF-Einstellungen einbauen. ;)

(Es gab Zeiten, da waren Polygone mit Flat Shading schon toll, doch die Zeiten sollten langsam mal vorbei sein...)
Diese Erkennung ist mir zu primitiv. Der Treiber analysiert die gesamte Textur. Es kann durchaus sein, dass der größte Teil geradezu einfarbig ist (dann brauchts natürlich gar kein AF) aber einige Stellen Struktur haben. Sobald der Kontrast-Umfang insgesamt zu klein ist, geht der Treiber einfach davon aus, dass die ganze Textur weniger (oder gar kein) AF braucht.

Ist den sicher geklärt das die Komplette Texture am Stück analysiert wird. Wenn ich das ganze richtig gelesen haben würde immer der Kontrast der gesamten Texture verändert.

Der Treiber analysiert Texturen nicht, wenn sie komprimiert sind. Das ist dumm. Es wäre vielleicht sogar sinnvoller, wenn pro Textur-Kachel entschieden würde. Hier gibts natürlich das Problem, dass es Kachel-Artefakte geben könnte, das wäre aber zu lösen, in dem die Kontrastumfang-Erkennung vorsichtig genug arbeitete. (Jedenfalls finde ich es schade, dass komprimierte Texturen aus der Optimierung generell rausfallen.)

Ack. Möglicherweise kommt das noch wenn man die Idee bei NVIDIA weiter verfolgt.

Was Lightmapping und AF angeht: Ohne den dummen AF-Bug gibts bei BF immerhin 2x AF bei gleicher Pixelfüllrate (sofern 2 TMUs pro Pipe.) Sobald auch nur 2x AF aktiv ist, hat man bei BF auf NV25 und NV28 den Leistungsverlust. Bevor man der Leistung wegen das AF-Level senkt, sollte man erst mal die vorhandenen TMUs fürs AF ausnutzen können. Vermutlich ist die Lightmap so ziemlich das einzige, was bei Multitexturing heutzutage nur bilinear gefiltert wird. Imo sollten Lightmaps auch anisotrop gefiltert werden, einfach, weil "gute", also detaillierte Lichteffekte schön sind, und man durch den AF das Fehlen von MIP-Texturen etwas ausgleichen kann.

Angenommen man hat eine schwachkonstrastige, aber fein strukturierte Textur. Die wird mit Optimierung matschig. Schwacher Kontrast heißt nicht automatisch, dass jedes Texel von Texeln mit hoher Farbähnlichkeit umgeben ist. Wenn ich mich jetzt nicht irre, ist der erste Treshold bei 48. Auf einer Skala von 0..255 ist das nicht unbedingt wenig, finde ich. Zum Glück ist diese Optimierung abschaltbar, und mit der "Balanced"-Optimierung kann man in den meisten Fällen afaik durchaus leben.

Lightmaps profitieren recht wenig von AF. Was die Treshold berechung angeht so muss ich mir die nochmal genau anschauen. Bezüglich deiner "schwachkonstrastige, aber fein strukturierte Textur" wäre ich für ein optische Beispieldankbar weil ich mir da ehrlich gesagt gerade nicht vorstellen kannst was du meinst.

[Demirug]

Originally posted by mapel110
hm, warum geht das prüfen der einzelnen texturen schneller als AF anzuwenden ?

Weil die Analyse nur einmal beim Anlegen gemacht wird (also normalerweise ausserhalb des Renderloops). Die Einsparung aber pro Pixel entsteht.

[mapel110]

Originally posted by Demirug


Weil die Analyse nur einmal beim Anlegen gemacht wird (also normalerweise ausserhalb des Renderloops). Die Einsparung aber pro Pixel entsteht.

und bei theoretisch recht vielen (kleinen) texturen könnte doch der fall eintreten, dass es uneffektiver wird, oder ?!

[Demirug]

Originally posted by mapel110


und bei theoretisch recht vielen (kleinen) texturen könnte doch der fall eintreten, dass es uneffektiver wird, oder ?!

Nein. Die Texturen werden ja normalerweise nur einmal am Anfang angelegt (z.B. Levelstart). Die Analysze Leistung fällt also genau einmal an. Wenn es mehr Texturen sind dauert es eben ein bischen länger aber auf die FPS im Spiel hat dies ja keine Auswirkung mehr da dort nur auf die im Vorfeld berechneten Werte zurückgerifen wird.