Christoph Bumiller wrote on 2010-02-25 19:39: > 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. > Why do you say that? NV50 is a DX10-level card -- it deserves better treatment. Your request is valid and we should go and ask gallium gatekeepers to get this change pushed.
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
