[Mesa-dev] [PATCH] lp_build_lod_selector: Disable brilinear folding on explicit lod.

Jose Fonseca jfonseca at vmware.com
Wed Jun 27 03:17:05 PDT 2012



----- Original Message -----
> ----- Original Message -----
> > On Mon, Jun 25, 2012 at 03:16:35PM -0700, Jose Fonseca wrote:
> > > Indeed lp_build_brilinear_lod is not faster than
> > > lp_build_ifloor_fract, but brilinear is faster, not because log
> > > is
> > > a
> > > faster approximation, but because it increases the odds that
> > > fract
> > > part is zero, which means that we can sample from a single mip
> > > level, instead of lerping between two mip levels.
> > > 
> > > I think you have a good point here -- lp_build_brilinear_lod is a
> > > log2 approximation which is wrong here and that's a great catch,
> > > --
> > > but I have a point too: lp_build_ifloor_fract will slow down
> > > texture
> > > sampling.
> > >
> > > Just like log2 and brilinear log2, we need a variant of
> > > ifloor_fract, that increases the probability of fract part being
> > > zero, essentially by applying a stair case transformation like:
> > 
> > You can do that by multiplying by 'k', subtracting 0.5*k and
> > clamping
> > to [0,1[.
> 
> Actually, looking at the code, this is precisely what
> lp_build_brilinear_lod should be doing (albeit a bit more
> efficiently).  It does not do a log2, as you implied earlier. log +
> brilinear is done by lp_build_brilinear_rho and not
> lp_build_brilinear_lod.
> 
> Olivier, please look at the failure again, and confirm exactly what's
> the problem: does lp_build_brilinear_lod have a bug, does the
> assumption that clamping is not necessary not old, or is the piglit
> test too strict for bri-linear?

I took a look at the results, and it seems to me that bri linear code is fine -- the test is merely too strict, and doesnot forgive the gravitation towards integer lod that brilinear implements.


Jose


More information about the mesa-dev mailing list