Keith Whitwell wrote:
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.
Indeed - my point being that I don't think we do call it under (all of) those circumstances.
The importance of firstLevel/lastLevel is that they specify which mipmaps to upload, if they aren't correct, how can we have confidence that the right set of mipmaps are on the card?
At the moment, in most drivers, this function doesn't get called unless at least one texture level (t->base.dirty_images[0] != 0) is going to be uploaded - which isn't really what you want to happen every time you change some of that state.
I'm pretty sure that the i830 driver didn't have the test on tObj->MinFilter, fwiw, possibly due to conform or glean testing done near the end of its development.
Keith
------------------------------------------------------- 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
