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