NV3X Leistungs AF Analyse

[Demirug]

http://demirug.bei.t-online.de/IMAGE/AFA8XQvsL.png

Was wir hier sehen ist eine Sampleanalyse für die ersten beiden Mip-Maps bei 8xAF Qualität gegen Leistung. Die Farbe gibt an wie viele Texel in die Berechung der entgültigen Pixelfarbe einfliessen. Je grüner desto mehr.

Oben haben wir die Mipmap Stufe 1 und unten die Stufe 0.

Links Qualität und rechts Leistung.

Zu Qualität braucht man nicht viel zu sagen. Hier haben wir das bekannte Bild mit dem breiten Überlabungsbreich der beiden Mipmap stufen.

Beim Leistungmodus ist ja wie schon bekannt der Überlabungsbreich nur noch sehr klein. Auf den Sampleanalyse sehen wir nun aber noch zwei zusätzliche Dinge. Die maximale Texelausnutzung wir früher ereicht und zudem scheinen im Durchschnitt auch mehr Texel aus einer Stufe pro Pixel genutzt werden. Das muss ich aber noch nachrechnen lassen.

Der zweite Trick (welcher dann die Speed bringen müsste) besteht darin das man sobald man in den Bereich kommt in dem die Mip-Map einen geringeren Einfluss auf das Endresulttat bekommt einfach nicht mehr aus dieser samplet.

Zusammengefast:

- Es werden nur noch Texel gesamplet die einen Mindesteinfluss auf das Endresulttat haben. Bei Quality wird alles gesampelt was einen Einfluss hat.

- Es werden tendenziel mehr Texel für dem gleichen Pixel aus einer höhren Mip-Map Stufe verwendet als bei Quality.

- Bei den Mip-Map Übergänge werden besonders viele Texel (im vergleich zum rest) zum Einsatz gebracht.

- In Summe werden für die meisten Pixel weniger texel benutzt als bei Quality.

Wenn ich Zeit habe werde ich das ganze noch mit Zahlen untermauern. Dafür muss ich das Programm aber noch erweitern.

[Ailuros]

Frage: werden bei solchen Applikationen meistens nur die base Texturen (ergo "0") getestet, oder nicht?

Wenn ja (und da ich sowieso in der Mehrheit von Spielen auf der NV25 mit Unwinders Aniso D3D Optimierung spiele und fast nie einen Unterschied sehen kann), wieso haben IHV's bis jetzt noch nicht versucht die Algorithmen auch in diese Richtung zu optimieren? (nein ich meine jetzt nicht die bi-/trilinear Faelle, sondern dass nur mehr als die base Textur gefiltert wenn absolut noetig).

Weiterhin waere es moeglich (wenn die obrige Applikation es schon nicht kann) eine derartige Applikation so zu coden, dass man alle Texturstages analysieren kann? Ich meine so in etwa eine Auswahl wo man von texture stage zu texture stage wechseln kann, so in etwa:

check texture stage 0
check texture stage 1
check texture stage 2
check texture stage 3 usw.

Last but not least, hat schon jemand versucht ob Unwinders D3D Aniso Texturing stage Trick auch auf NV3x laeuft? Selbst wenn der Patch nicht moeglich ist fuer NV3x, wuerde theoretisch wenn es moeglich ist der Leistungs-einbruch mit Aniso bei einer NV3x aeusserst klein sein?

[Demirug]

Original geschrieben von Ailuros
Frage: werden bei solchen Applikationen meistens nur die base Texturen (ergo "0") getestet, oder nicht?

In der Regel ja. Ich kann zwar alle Stages prüfen aber ich traue dem ganze noch nicht so ganz.

Wenn ja (und da ich sowieso in der Mehrheit von Spielen auf der NV25 mit Unwinders Aniso D3D Optimierung spiele und fast nie einen Unterschied sehen kann), wieso haben IHV's bis jetzt noch nicht versucht die Algorithmen auch in diese Richtung zu optimieren? (nein ich meine jetzt nicht die bi-/trilinear Faelle, sondern dass nur mehr als die base Textur gefiltert wenn absolut noetig).

nv arbeitet ja an sowas. Dort versucht man in Abhängigkeit des Texturekontrast den Filter zu bestimmen. Von der Idee das ganze in abhängkeit der Texturestages zu machen bin ich kein Freund. Das ist aber eher ein persönliches Problem. Unsere Engine hat einen Effektgenerator welcher automatisch die Texturen auf die Stages verteilt. Deshalb können wir nie sicher sein wo den nun die wichtige Texture zum liegen kommt.

Weiterhin waere es moeglich (wenn die obrige Applikation es schon nicht kann) eine derartige Applikation so zu coden, dass man alle Texturstages analysieren kann? Ich meine so in etwa eine Auswahl wo man von texture stage zu texture stage wechseln kann, so in etwa:

check texture stage 0
check texture stage 1
check texture stage 2
check texture stage 3 usw.

Ja ist bei den NV3X aber nutzloss weil dort alle Stages standardmässig gleiche behandelt werden.

Last but not least, hat schon jemand versucht ob Unwinders D3D Aniso Texturing stage Trick auch auf NV3x laeuft? Selbst wenn der Patch nicht moeglich ist fuer NV3x, wuerde theoretisch wenn es moeglich ist der Leistungs-einbruch mit Aniso bei einer NV3x aeusserst klein sein?

AFAIK funktionert es nicht. Was es bringen würde ist schwer zu sagen weil man nicht weiss welche optimierungen bei dem einen oder anderen Spiel schon greifen.

[Ailuros]

nv arbeitet ja an sowas. Dort versucht man in Abhängigkeit des Texturekontrast den Filter zu bestimmen. Von der Idee das ganze in abhängkeit der Texturestages zu machen bin ich kein Freund. Das ist aber eher ein persönliches Problem. Unsere Engine hat einen Effektgenerator welcher automatisch die Texturen auf die Stages verteilt. Deshalb können wir nie sicher sein wo den nun die wichtige Texture zum liegen kommt.

Na in dem Fall waere es wohl nicht praktisch eine solche Methode anzuwenden. Theoretisch wenn Spiele von jetzt ab, aehnlich ausgelegt sind, dann macht es keinen Sinn. Im Gegenfall wo es sich nur um Ausnahmen handelt, schaltet halt man diese Optimierung einfach mit ein paar game presets ab.

Ja ist bei den NV3X aber nutzloss weil dort alle Stages standardmässig gleiche behandelt werden.

AFAIK funktionert es nicht. Was es bringen würde ist schwer zu sagen weil man nicht weiss welche optimierungen bei dem einen oder anderen Spiel schon greifen.

Kommen die beiden Abschnitte nicht zum Widerspruch? Ich kann verstehen dass bei einer Applikation die zur Analyse des Treibers-Verhaltes mit Anisotropy man so etwas schwer herausfinden koennte, da ich mir nur vorstellen kann dass Faelle wie oben im zweitem Quote, wohl nur mit game-presets behandelt werden, wo wohl der Treiber source code (oder wichtige Teile dieses) helfen wuerden (?), um hinter derartige Optimierungen zu kommen.

Falls derartige Optimierungen durch game presets auch wirklich existieren, bezweifle ich dass Kerle wie Unwinder dieses mal Bruchteile des source code zugeschickt bekommen.

Und bevor mich jemand falsch versteht ich bin persoenlich ganz und gar nicht gegen solche Optimierungen, so lange man keine Unterschiede sehen kann. Mich wuerde aber trotz allem eine Applikation interessieren die diese Faelle auch analysieren koennte; ich sehe nur keine Loesung dafuer unter all den oben erwaehnten Bedingungen.

Vielleicht dem Treiber vorgaukeln dass die Applikation UT2003.exe heisst? :ups:

[Demirug]

Original geschrieben von Ailuros
Na in dem Fall waere es wohl nicht praktisch eine solche Methode anzuwenden. Theoretisch wenn Spiele von jetzt ab, aehnlich ausgelegt sind, dann macht es keinen Sinn. Im Gegenfall wo es sich nur um Ausnahmen handelt, schaltet halt man diese Optimierung einfach mit ein paar game presets ab.

Ja wobei ja nach wie vor gilt das wenn die Applikation explizit AF anfordert kann sie auch für jeden Stage bestimmen ob nun bi oder tri und auch bis zum welchem maximalen AF Level gefiltert werden soll. Da wir das AF Management selber übernemen haben wir da kein Problem solange wir eben nicht doch überschreiben werden.

Kommen die beiden Abschnitte nicht zum Widerspruch? Ich kann verstehen dass bei einer Applikation die zur Analyse des Treibers-Verhaltes mit Anisotropy man so etwas schwer herausfinden koennte, da ich mir nur vorstellen kann dass Faelle wie oben im zweitem Quote, wohl nur mit game-presets behandelt werden, wo wohl der Treiber source code (oder wichtige Teile dieses) helfen wuerden (?), um hinter derartige Optimierungen zu kommen.

Nein kein Wiederspruch. Das default verhalten ist das Beschrieben aber für einzelne Anwednungen wäre auch etwas anderes denkbar.

Ja mit dem Sourcecode könnte man das alles wohl recht schnell finden.

Falls derartige Optimierungen durch game presets auch wirklich existieren, bezweifle ich dass Kerle wie Unwinder dieses mal Bruchteile des source code zugeschickt bekommen.

Und bevor mich jemand falsch versteht ich bin persoenlich ganz und gar nicht gegen solche Optimierungen, so lange man keine Unterschiede sehen kann. Mich wuerde aber trotz allem eine Applikation interessieren die diese Faelle auch analysieren koennte; ich sehe nur keine Loesung dafuer unter all den oben erwaehnten Bedingungen.

Vielleicht dem Treiber vorgaukeln dass die Applikation UT2003.exe heisst? :ups:

Der name aleine reicht nicht um den Treiber anspringen zu lassen.

[Demirug]

So hier noch ein bischen Statistik


Quality:

Map Pixel Texel T/P
0 443573 3758454 8,47
1 79310 983301 12,40
2 23800 353729 14,86
3 11208 164921 14,72
4 5604 82466 14,72
5 2807 36730 13,09
6 991 10131 10,22
7 64 307 4,80
8 0 0 0,00
9 0 0 0,00

Leistung:

Map Pixel Texel T/P
0 426157 3432422 8,05
1 35200 544710 15,48
2 12322 208382 16,91
3 6104 100085 16,40
4 3044 50584 16,61
5 1520 22070 14,52
6 529 6082 11,50
7 0 0 0,00
8 0 0 0,00
9 0 0 0,00


Pixel die aus mehr als einer Map kommen sind bei beiden entsprechend berücksichtigt.