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?
This function was the result of a code refactor. All of the drivers had a bit of code like this in their SetTexImages function. I just pulled the code out of those individual functions are replaced it with a call to driCalculateTextureFirstLastLevel. So, the values of firstLevel and lastLevel may get out-of-date, but they are re-evaluated when they are actually needed. To keep them completely upto date (which I don't think is necessary, we'd have to call driCalculateTextureFirstLastLevel whenever:
1. The texture size changed. 2. MinLod or MaxLod changed. 3. The texture filter changed.
------------------------------------------------------- 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
