----- 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
