On Wed, 2 Nov 2011 11:12:07 +0800, Yuanhan Liu <[email protected]> wrote: > On Tue, Nov 01, 2011 at 05:57:36PM +0800, Yuanhan Liu wrote: > > According to bspec, MIPCnt(was set to intelObj->_MaxLevel) was used for > > min/mag filter mode determination. For a normal case with no mipmap like > > this: > > > > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); > > glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); > > > > hardware would always choose mag filter(GL_LINEAR) here since MIPCnt was > > set to 0 zero, then would make LOD be zero. Then according the formula: > > MagMode = (LOD - Base <= 0) > > Here are some more comments about this: LOD is a pre-computed value. if > preClamp is enabled, then LOD would be: > LOD = min(min(MIPCnt, MAX_LOD), LOD); > > So, if MIPCnt was set to 0, and preClamp was enabled, then the _final_ > LOD would be 0, and hardware choose mag filter. > > Thoughts?
It took me a long time to understand what you were trying to fix here. The story I've worked out is: "We can't optimize out uploading the other mipmap levels for non-mipmapped filtering modes if the min filter is not the same as the mag filter. This is because the min/mag decision is based on the computed LOD of the sample, and if we clamp the LOD to BaseLevel by not including the other levels, it will always choose the mag filter even if minification should have occurred. See page FINISHME: citation of PRM." Particularly what was unclear was that the patch was just skipping an optimization, to get behavior back in line with what the user did through the API: Specify multiple levels in their texture.
pgp1pu3ekw1cc.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
