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

[Corbin Simpson]

On Wed, Aug 11, 2010 at 1:07 PM, Luca Barbieri <luca at luca-barbieri.com> wrote:
>> 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.

Power users of CL, just like GL, will be aware that having NPOT data
sets impacts performance, and will keep their data sets POT as often
as possible. We shouldn't be worried about speed hax for users when
it's up to the users to make this particular call.

PIPE_TEXTURE_RECTANGLE seems, in my mind, to be the best compromise.
Shader compilers with keys for texture types (r300g) can simplify
their logic slightly, and chipsets with strong notions of RECT
resources (nvfx) can avoid extra hoop-jumping. The only question is
whether RECT behaves like NPOT:

~ Are rects *always* non-normalized?
~ Can rects have mipmaps?
~ Can rects have full border repeat and mirror?

If the answer is "yes, no, no", just like actual GL rects, then I support this.

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude at gmail.com>