LOD Stufe in GLSL selbst festlegen

[Asmodeus]

Wenn ich unter GLSL folgende Befehle verwende, wird die passende LOD Stufe der Textur ja automatisch ausgewählt:

vec4 Texture0Color = texture2D(Texture0,gl_TexCoord[0].xy);

gl_FragColor.rgb = Texture0Color.rgb;


Nun möchte ich das gleiche Ergebnis erreichen, wenn ich die LOD-Stufe selbst angebe. Dazu wollte ich folgenden Code verwenden:

float lod = length(dFdx(gl_TexCoord[0].xy) + dFdy(gl_TexCoord[0].xy));

vec4 Texture0Color = texture2DLod(Texture0,gl_TexCoord[0].xy,(-1.0 / lod));

gl_FragColor.rgb = Texture0Color.rgb;


Leider ergibt das nicht das gleiche Ergebnis, sondern das Bild flimmert sehr stark, so als würden eben nicht die richtigen LOD-Stufen der Textur ausgewählt werden. Woran kann das liegen, oder wo ist der Denkfehler in meiner Herangehensweise?

Gruss, Carsten.

[ScottManDeath]

AFAIK gibts für bi/tri/aniso filter noch ein unterschiedliches LOD bias.
Manchmal überschreiben auch die Treiber das LOD bias.

Guck am besten mal in der 2.0 spec Seite 175... nach. Ich habs nur überflogen, das müsste es dabei stehen.

[Asmodeus]

AFAIK gibts für bi/tri/aniso filter noch ein unterschiedliches LOD bias.
Manchmal überschreiben auch die Treiber das LOD bias.

Guck am besten mal in der 2.0 spec Seite 175... nach. Ich habs nur überflogen, das müsste es dabei stehen.

Ok, es gibt also noch 3 verschiedene Bias-Werte (bias-texobject,bias-texunit,bias-shader). Bias-shader ist ja nun der Wert denn ich in meinem Codebeispiel versucht habe im Shader zu setzen. Aber was ist nun mit den beiden anderen Bias-Werten, soll ich die auf den Standardwerten belassen, mit eigenen Werten überschreiben, und wenn ja, mit welchen? Und wie bekomme ich mit, ob der Treiber da dann nicht auch noch seine Finger im Spiel hat? Hmm, Fragen über Fragen.

Gruss, Carsten.

[Chris Lux]

Ok, es gibt also noch 3 verschiedene Bias-Werte (bias-texobject,bias-texunit,bias-shader). Bias-shader ist ja nun der Wert denn ich in meinem Codebeispiel versucht habe im Shader zu setzen. Aber was ist nun mit den beiden anderen Bias-Werten, soll ich die auf den Standardwerten belassen, mit eigenen Werten überschreiben, und wenn ja, mit welchen? Und wie bekomme ich mit, ob der Treiber da dann nicht auch noch seine Finger im Spiel hat? Hmm, Fragen über Fragen.


ich würde zum testen GL_NEAREST_MIPMAP_NEAREST als texture filter einstellen, sicherstellen, dass texobj und texunit bias auf 0.0 sind. und gefärbte mipmaps nutzen. achja und anisotropen filter deaktivieren. dann dir überlegen was du sehen müsstest und vergleichen... das kannst du natürlich auch mit den anderen beiden bias typen testen. ich bin mir nicht sicher ob du den bias im shader berechnen solltest oder es effizienter wäre den vorher für die texture (texobj) oder die verwendete unit (texenv) zu setzen.

hachja visuell debuggen fetzt ;)

[Asmodeus]

ich würde zum testen GL_NEAREST_MIPMAP_NEAREST als texture filter einstellen, sicherstellen, dass texobj und texunit bias auf 0.0 sind. und gefärbte mipmaps nutzen. achja und anisotropen filter deaktivieren. dann dir überlegen was du sehen müsstest und vergleichen... das kannst du natürlich auch mit den anderen beiden bias typen testen. ich bin mir nicht sicher ob du den bias im shader berechnen solltest oder es effizienter wäre den vorher für die texture (texobj) oder die verwendete unit (texenv) zu setzen.

hachja visuell debuggen fetzt ;)

Ja, dank dem visuellen Debuggen und einiger hilfreicher Informationen eines Papers bezüglich dieser Probleme funktioniert es jetzt. In dem Paper "Seamless Texture Atlases" wird interessanterweise auch die Frage endgütlig geklärt, dass Atlastexturen sehr wohl immer funktionieren können, auch im Zusammenspiel mit Mipmapping, bilinearer, trilinearer, anisotropher Filterung und sämtlichen Texturmodi. Natürlich muss dafür im Fragmentshader einiger Aufwand betrieben werden :wink: .

Gruss, Carsten.

[Xmas]

Ja, leider gibt NVidia für texld[b|d|l] als Richtwert 1/10 der Performance von texld an...

[Asmodeus]

Ja, leider gibt NVidia für texld[b|d|l] als Richtwert 1/10 der Performance von texld an...

Ups, das ist ja echt heftig, da hatte ich bei mir wohl mit etwa 1/3 noch "Glück". Wie lässt sich das erklären, wodurch wird dieser extreme Einbruch verursacht?

Gruss, Carsten.

[Chris Lux]

Ja, leider gibt NVidia für texld[b|d|l] als Richtwert 1/10 der Performance von texld an...
hmm, laut dieser präsentation (http://download.nvidia.com/developer/presentations/2004/6800_Leagues/6800_Leagues_SM3_Best_Practices.pdf) nur ein zehntel bei texldd (seite 29), die anderen werden mit full performance angegeben.

[Asmodeus]

hmm, laut dieser präsentation (http://download.nvidia.com/developer/presentations/2004/6800_Leagues/6800_Leagues_SM3_Best_Practices.pdf) nur ein zehntel bei texldd (seite 29), die anderen werden mit full performance angegeben.

Also unter GLSL macht er dann im Assembly-Code aus texture2DLod( ) wohl immer TXD.

Gruss, Carsten.

[Chris Lux]

Also unter GLSL macht er dann im Assembly-Code aus texture2DLod( ) wohl immer TXD.

Gruss, Carsten.
achso.

ist es eigentlich möglich damit selbst das filtering muster bestimmen? das soll heissen, dass man ja selbst die derivate bestimmen kann, die für den filter verwendet werden und so das AF muster verändert werden könnte?

[Xmas]

hmm, laut dieser präsentation (http://download.nvidia.com/developer/presentations/2004/6800_Leagues/6800_Leagues_SM3_Best_Practices.pdf) nur ein zehntel bei texldd (seite 29), die anderen werden mit full performance angegeben.
Hm, stimmt. Das wirft meine ganze Überlegung über den Haufen warum das so ist. Denn ich ging davon aus, weil man dann einen LOD pro Pixel statt pro Quad hat, wird viermal einzeln gesampelt, also vier statt einen Takt für Bilinear.

Jetzt frage ich mich, ob texldd 9 Takte Overhead hat (um es in texldl umzuwandeln), was noch brauchbar wäre, oder tatsächlich 10mal so lange braucht (auch bei Trilinear und AF), was inakzeptabel wäre. Wohl eher ersteres.


Allerdings, von Hand brauche ich von Gradient -> LOD keine 9 Takte...


Und langsamer als normales Samplen ist es natürlich, wenn der LOD stark schwankt, weil der Chache dann nicht mehr so effektiv ist.