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