[Mesa-dev] [PATCH] softpipe: Take all lods into account when texture sampling.

[Roland Scheidegger]

On 06/20/2012 05:43 AM, Olivier Galibert wrote:
> On Tue, Jun 19, 2012 at 02:46:35PM -0700, Jose Fonseca wrote:
>> Could you give more background on why is this necessary?
>>
>> This will make software renderering slower, so I'd really like to avoid it on llvmpipe if at all possible.
>
> Well, given the existence of textureLod and textureGrad every texture
> sample can easily hit a different mipmap or even, by switching between
> minification and magnification, a different filter entirely.  Even a
> simple texture() is hit, if your polygon is horizontal enough.
>
> And this goes double for vertex shaders, where texture fetches there
> have less reason to be close in texture space.
>
> textureSize and textureFetch, with their explicit lod, have of course
> the same problem. only worse.

If I see that right, this only really affects sampling with either 
(per-pixel) lodbias, explicit lod or explicit gradients. For "normal" 
texture sampling results shouldn't change since rho/lambda (which 
determines lod) is per-quad.

In this case I think we'd want to split the fetch functions in llvmpipe 
if any of that is present, since this is going to require per-pixel 
lookups of mip level offsets at least. Also, min/mag filter selection 
needs to be handled different in this case too (doing this with 
per-pixel branch code isn't really an option) - maybe keep the branch to 
choose between min/mag filter if all pixels use the same filter, and use 
some hacked-up linear path instead if not which forces weights for the 
pixels using nearest to the appropriate value. Sounds like a lot of 
effort though.

In any case for softpipe performance isn't as critical, though I'm 
curious if it makes a large performance difference for "ordinary" 
texture sampling (in which case things could be split as well, though I 
guess for softpipe code simplicity wins over faster code).

Otherwise this looks like the right thing to do in principle to me, 
though I'd like to hear Brian's opinion on that too.

Roland