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

[Brian Paul]

On 06/20/2012 06:39 AM, Roland Scheidegger wrote:
> 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.

Yeah, I think it's pretty clear that we need to support per-pixel LOD 
selection.  For softpipe, Olivier's big patch looks good.  For 
llvmpipe it's important to maintain performance for the common case 
where we compute LOD per quad but we'll also need new paths for 
per-pixel LOD.  Hopefully, the two paths can share some code.

-Brian