Roland Scheidegger wrote: > 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.
We should also be thinking about texture array targets. With a 2D texture array, the S and T coords would be normalized, but not R. I think we either need new texture targets for RECT, 1D_ARRAY, 2D_ARRAY, etc. or per-dimension normalization flags. I'm thinking the former may be better (simpler) since textures are created as a particular type and not changed afterward. We also know the texture type/target when we execute TEX shader instructions. If it's part of sampler state it gives the impression that it's variable state, but it really isn't. -Brian ------------------------------------------------------------------------------ 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
