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

[Jose Fonseca]

----- Original Message -----
> 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.  

I haven't read the relevant specs, but with such agreement I'm more than convinced.

> 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.

Yes, I think it should be possible to accomodate both cases with common code.

On x86_64 bits w/ SSE/AVX, a vector of pointers is innefficient -- it's better to use scalar 64bit pointer plus a vector of 32bit offsets. Therefore, for efficient per-pixel llvmpipe, we should allocate whole resource tree (all faces/levels/slices) with a single malloc.

draw module is used by many other drivers, so it probably can't make such assumption, but vertex shading seldom is a bottleneck anyway.

Jose