On 25.02.2010 18:39, michal wrote: > Roland Scheidegger wrote on 2010-02-24 15:18: >> On 24.02.2010 12:48, Christoph Bumiller wrote: >> >>> This wasn't a problem before because textures and samplers were >>> linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch, >>> this coordinate normalization bit becomes a problem. >>> >>> NV50 hardware has that bit in the RESOURCE binding, and not the >>> SAMPLER binding, and you can imagine that this will lead to us having >>> to jump through a few annoying looking hoops to accomodate. >>> >>> As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have >>> sampler states that are decoupled from the texture, and which contain >>> a normalized coordinates bit, so it's worth considering not having it there >>> in gallium either. >>> >>> For OpenGL, unnormalized coordinates are only used for RECT textures, >>> and in this case it makes sense to make it a property of the texture. >>> >> I agree this is not sampler state, but I don't quite agree this should >> be texture state. >> This changes how texture coordinates get interpreted in the interpolator >> - in that sense it is similar to the cylindrical texture coord wrap >> which we moved away from sampler state recently. This one got moved to >> shader declaration. I wonder if the normalization bit should be treated >> the same. >> Though OTOH you're quite right that in OpenGL this really is texture >> property (it is a different texture target after all), and afaik d3d >> doesn't support non-normalized coords (?). Hmm... >> >> > Isn't it the case that for RECT targets we clear the bit, and for others > we always set it? > > In mesa st I see: > > if (texobj->Target != GL_TEXTURE_RECTANGLE_ARB) > sampler->normalized_coords = 1; > > By definition, RECT texture with normalised coordinates is just an NPOT. > If we removed this apparently redundant flag, would that make nouveau > developers life easier? But we don't have rect targets in gallium hence we need the flag. I think conceptually this makes sense since for texture layouts etc. drivers won't care one bit if this is 2d npot or rect texture. Though I guess introducing rect targets instead would be another option.
Roland > >> >>> And, finally, I've seen you reverted the changes for independent image >>> and sampler index in the texture opcodes. What's up with that ? >>> Is the code not nice enough, or has the idea been discarded and by problem >>> disappears ? >>> >>> > > Please consider this branch dead. It will be easier for me to introduce > new, optional sampler and fetch opcodes a'la GL 3.0. There's just too > much code to fix and test and we still want the older hardware not to > stand on its head to try and translate back to old model. > > Thanks. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
