[Mesa-dev] [RFC] [PATCH 0/3] Make Gallium aware of GL_TEXTURE_RECTANGLE

Luca Barbieri luca at luca-barbieri.com
Wed Aug 11 13:07:41 PDT 2010

> Because all nvidia hardware seems to have the normalized bit as a property
> of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all ATI
> hardware has the normalized bit as part of the texture instruction (it's a
> shader state, so a driver looks for TGSI_TEXTURE_RECT), I believe it would
> really be best for everyone to have this RECT texture target type and
> removing normalized_coords from pipe_sampler_state. Luca, you've already
> done some work for this change. If you don't have time to finish
> PIPE_TEXTURE_RECT, I'll do that.

So no hardware at all supports specifying the normalization as part of
the sampler state?

One has to keep in mind OpenCL though, which has the following API:
cl_sampler clCreateSampler (cl_context context,
    cl_bool normalized_coords,
    cl_addressing_mode addressing_mode,
    cl_filter_mode filter_mode, cl_int *errcode_ret)

If you put the bit in the resource itself, then it becomes impossible
to change the normalization without copying the whole resource, which
would seem to be a major problem for implementing OpenCL.

A possible solution could be removing the bit from the sampler state
and adding the bit to both TEX instructions and sampler views.
This would seem to suit nv50, which has it in the hardware sampler
view, and r300-r700 which has it in the hardware shader instruction
(according to you).
I'm not sure if it is good enough for OpenCL (i.e. whether the OpenCL
state tracker can statically determine the sampler<->texture mapping),
but I suppose it is, since it matches the hardware and the proprietary
drivers manage to support OpenCL.

A flag would need to be passed on resource creation anyway though,
since nv30 needs to use different memory layouts.

Also in this option, adding the resource hint and moving the bit out
from the sampler state would be independent.

More information about the mesa-dev mailing list