On 25.02.2010 19:00, Brian Paul wrote: > 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. > > We'd also need a BUFFER target then, they also have scaled coordinates. The problem is I think that this drivers gallium a little towards catering towards specific APIs (OpenGL).
OpenCL for instance does have a per sampler normalization bit iirc, but it seems there's no hardware that reflects this property. Then again, TGSI does have a RECT target already, so we might as well add corresponding PIPE targets. I want to remind again that the normalization bit only becomes problematic once samplers and textures can be independently combined, and that it seems older hardware can't nicely do this anyway, except if they take it upon them to recompile their shaders (although I hear some need to do that already ...) I admit I'm actually being a bit selfish here, trying to get the interface more adapted to nv50, but, if other hardware doesn't have conflicting views, why not ? Maybe I should accept nv50 is getting old. What about future hardware ? Well, we don't know how Fermi works in this respect yet, and I don't think $MANUFACTURER will tell us .. Christoph > -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 > ------------------------------------------------------------------------------ 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
