Mehr FPS bei aktivierten Texturfiltern?

[energyzer]

Hallo!

Hab gerade mal Texturfilter in meine Engine implementiert. Das ist dabei heraus
gekommen:

D3DTEXF_NONE: 115 FPS
D3DTEXF_LINEAR: 150 FPS
D3DTEXF_ANISOTROPIC: 150 FPS

Jetzt wundert mich, warum die Performance mit aktivierten Filtern steigt. Die
Filter sollen doch die Bildqualität verbessern, oder nicht?

Wäre nett, wenn mich da jemand aufklären kann

[ChockoCookie]

Viell sind in deinem Treiber so viele "Mogel - Optimierungen" für das filtering eingebaut, das die Performance sogar besser wird ;). Kannst du denn einen Unterschied in der Bildqualität feststellen?

[TGGC]

Ein Erklärungsversuch: Also wenn vorher weit enfernte Texturen nicht "gemippmapped" wurde, dann musste immer der höchste Level im Texturspeicher sein. Wenn der voll wahr, dann wird über Bus ausgelagert, was realtiv langsam ist.

Bye, TGGC Deine Unterstützung wird gebraucht!

[energyzer]

Hm.. Es sind Terrain-Texturen. d.h. man sieht eigentlich immer sämtliche
Miplevel der Textur. Ein Qualitätsunterschied ist schon da. Bilenear und
Anisotrophisch sehen halt verwaschener aus, sind aber sonst pixelidentisch,
was mich auch wundert.

[Trienco]

TGGC schrieb:

Ein Erklärungsversuch: Also wenn vorher weit enfernte Texturen nicht "gemippmapped" wurde, dann musste immer der höchste Level im Texturspeicher sein.

sofern sich in den letzten monaten nicht vollkommen überraschend etwas geändert hat, dann muß eine texture IMMER als ganzes (mit allen mipleveln) im speicher liegen. der einzige grund, warum es mit mipmaps schneller geht ist mal wieder der cache. ohne mipmaps werden x pixel in der hohen auflösung übersprungen und der cache ist für die tonne, mit mipmap sollten die benötigten pixel schön brav nebeneinander liegen. kurz: mipmaps brauchen zwar grob geschätzt bis zu doppelt soviel speicher, können aber weit effizienter gelesen werden.

[rapso]

das problem hatten wir schon öfters hier im forum besprochen.

zum einen muss ich sagen, dass von einer textur, sobald ein texel gebraucht wird, die ganze textur in die graka geladen wird (alle mipmaps levels). ausnahmen sind da spezielle highend grakas und die XGI Volari bzw deren chips die wie eine cpu nur die nötigen pages einladen.
GeForce und Radeon karten laden also grundsätzlich alles erstmal ins VRam sobald ein teil benötigt wird.

so, das eigentliche problem das du hast, ist dass die graka bei pointfiltering unter direct3D auf der obersten ebene der texturen rumließt. Wenn du ein quad zeichnest was z.b. 16*16 pixel hat und du dabei eine 1024*1024 pixel textur verwendest, und lineares filtering an hast. wird von der textur die mipmap benutzt die 16*16 texel hat. diese passen zum glück komplett in den cache, der bei der ati ca 256kb und bei nvidia etwas kleiner sein soll. beim ersten lesen aus der textur ist wohl die komplette texturmipmap im cache, ab da geht es ab wie schmit's katze, resultat-> 256 pixel gezeichnet, ein zugriff für 256 texel ins ram(langsamm) und 256 zugriffe in den cache(schnell)
bei pointfiltering muss jedoch aus der 1024*1024 bei jedem pixel des quads eine ganze kachel (also vielleicht 16*16texel) in den cache geladen werden. dann wird ein texel verwendet und für den nächsten pixel wiederhollt sich der spass. resulatat-> 256 pixel gezeichnet, 256 zugriffe für insgesammt 65536 texel ins ram, 256 zugriffe in den cache.

deswegen der performance drop.

bei cpus wäre das noch drastischer aufgefallen

rapso->greets();

[energyzer]

Danke für die ausführliche Erklärung! Man will ja schließlich auch wissen, was
die eigene Engine so alles treibt

MfG,

EnERgYzEr

[TGGC]

Trienco schrieb:

TGGC schrieb:

Ein Erklärungsversuch: Also wenn vorher weit enfernte Texturen nicht "gemippmapped" wurde, dann musste immer der höchste Level im Texturspeicher sein.

sofern sich in den letzten monaten nicht vollkommen überraschend etwas geändert hat, dann muß eine texture IMMER als ganzes (mit allen mipleveln) im speicher liegen.

Daher nannte ich es auch "Erklärungs_versuch_". Aber letzendlich passiert ja genau das nur in anderem Speicher als ich vermutete.

Bye, TGGC Deine Unterstützung wird gebraucht!

[Trienco]

TGGC schrieb:

Aber letzendlich passiert ja genau das nur in anderem Speicher als ich vermutete.

ersetze "genau" durch "sehr grob, bei sehr abstrakter betrachtungsweise und einer großen portion guten willens", dann paßts ,)
hätte er z.b. wirklich akuten speichermangel und würde als "lösung" alles auf mipmaps umstellen, dann wäre das im zweifelsfall eher kontraproduktiv, je nachdem wieviel in seinem speziellen fall der cache noch rausreißen könnte.

[rapso]

Trienco schrieb:

mipmaps brauchen zwar "sehr grob, bei sehr abstrakter betrachtungsweise und einer großen portion guten willens" bis zu doppelt soviel speicher, können aber weit effizienter gelesen werden.

4/3

rapso->greets();

[TGGC]

Genau genommen < 4/3, das es immer einen minimalen Level gibt. 4/3 ist der Grenzwert, wenn man immer weiter halbieren würde.

Bye, TGGC Deine Unterstützung wird gebraucht!

[Trienco]

TGGC schrieb:

Genau genommen < 4/3, das es immer einen minimalen Level gibt. 4/3 ist der Grenzwert, wenn man immer weiter halbieren würde.

*rechne* 1 + 1/2 + 1/4 + 1/8 + 1/16= 1,9375

ok, 1d texturen sind vielleicht nicht übermäßig gebräuchlich, aber man soll ja nichts ausschließen ,-)

aber schon bei texturen, die nicht quadratisch sind würde man böse auf die nase fallen, wenn man nur 4/3 des speichers reserviert ,-)

[rapso]

Trienco schrieb:

TGGC schrieb:

Genau genommen < 4/3, das es immer einen minimalen Level gibt. 4/3 ist der Grenzwert, wenn man immer weiter halbieren würde.

*rechne* 1 + 1/2 + 1/4 + 1/8 + 1/16= 1,9375

ok, 1d texturen sind vielleicht nicht übermäßig gebräuchlich, aber man soll ja nichts ausschließen ,-)

aber schon bei texturen, die nicht quadratisch sind würde man böse auf die nase fallen, wenn man nur 4/3 des speichers reserviert ,-)

die auflösung wird solange halbiert bis du auf 1pixel kommst.

somit wäre es 1+ 1/4 + 1/16 + 1/64 + 1/256 ...
das ist eine Σ von 1 bis ∞ für n bei 1/(n^2) und somit 4/3

rapso->greets();

[Trienco]

rapso schrieb:

die auflösung wird solange halbiert bis du auf 1pixel kommst.

falsch, die auflösung wird entlang einer richtung nur solange halbiert, wie sie größer als 1 ist, was sich bei 1d texturen von anfang an und bei nicht quadratischen texturen früher oder später erledigt hat.

[TGGC]

Hey, rapso ist meiner Meinung. Da ist was faul!

Bye, TGGC Deine Unterstützung wird gebraucht!