On Thu, Jan 29, 2004 at 01:07:30PM +0000, Keith Whitwell wrote:
In driCalculateTextureFirstLastLevel, there's this bit of code:
if (tObj->MinFilter == GL_NEAREST || tObj->MinFilter == GL_LINEAR) { /* GL_NEAREST and GL_LINEAR only care about GL_TEXTURE_BASE_LEVEL. */
firstLevel = lastLevel = tObj->BaseLevel;
}
else {
firstLevel = tObj->BaseLevel + (GLint)(tObj->MinLod + 0.5);
firstLevel = MAX2(firstLevel, tObj->BaseLevel);
lastLevel = tObj->BaseLevel + (GLint)(tObj->MaxLod + 0.5);
lastLevel = MAX2(lastLevel, t->tObj->BaseLevel);
lastLevel = MIN2(lastLevel, t->tObj->BaseLevel + baseImage->MaxLog2);
lastLevel = MIN2(lastLevel, t->tObj->MaxLevel);
lastLevel = MAX2(firstLevel, lastLevel);
}
I'm wondering if this has been thought through. For the test to work, this code fragement will have to be re-evaluated whenever tObj->MinFilter changes, or at least whenever it changes to/from NEAREST or LINEAR.
I don't think the drivers do this at the moment. Correct?
mga does the "right" thing ie. when MinFilter changes we call
driSwapOutTextureObject() which causes mgaSetTexImages() to be called and thus driCalculateTextureFirstLastLevel().
The above code is a bit heavy handed, but it works. I wrote it years ago.
If we're transitioning from a mipmapped filter to a non-mipmapped filter we shouldn't have to touch the texture images. Going the other way may require uploading new images.
Also, if the h/w supports lod clamping, this code is overkill.
-Brian
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
