[Mesa-dev] [PATCH 2/2] intel: make sure hardware choose the right filter mode

Eric Anholt eric at anholt.net
Wed Nov 2 14:18:46 PDT 2011


On Wed, 2 Nov 2011 11:12:07 +0800, Yuanhan Liu <yuanhan.liu at linux.intel.com> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111102/77688210/attachment.pgp>


More information about the mesa-dev mailing list