summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/nv30/nv30_fragtex.c
diff options
context:
space:
mode:
authorKeith Whitwell <[email protected]>2009-08-20 15:46:51 +0100
committerKeith Whitwell <[email protected]>2009-08-20 17:59:39 +0100
commit79a7ddb57a04cde5a4a0c27eb4a9b6889d12622a (patch)
treef461c01485e4be15d934ab50e7a7cd8cba002c30 /src/gallium/drivers/nv30/nv30_fragtex.c
parent4f409da3456070946eda2d8ff5153b3b4306bb46 (diff)
softpipe: fix glitch in texel lookups on fastpaths
Fixes two issues - firstly for mipmap levels with one or more dimensions smaller than tilesize, the code was sampling off the edge of the texture (but still within the tile). Secondly, in the linear_mipmap_linear case, both the default code and new fastpath were incorrect. This change fixes the fastpath and adds a comment to the default path, which still needs to be fixed. Basically the issue is that the coordinates in the smaller texture level are/were being computed by just dividing thecoordinates from the larger texture level by two, as in: x0[j] /= 2; y0[j] /= 2; x1[j] /= 2; y1[j] /= 2; The issues with this are signficant. Initially x1 is most often equal to x0+1, but after this, it will likely be equal to x0, so we will not actually be performing the linear blend within the smaller mipmap. The fastpath code avoided this (recalculated x1), but was still using the weighting factors from the larger mipmap level (xw, yw), which were incorrect. Change the fastpath code to do two full, independent linear samples of the two mipmap levels before blending. The default code needs to do the same thing.
Diffstat (limited to 'src/gallium/drivers/nv30/nv30_fragtex.c')
0 files changed, 0 insertions, 0 deletions