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?
>
>
>> 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
