[Mesa-dev] gallium & texture rectangles

[Luca Barbieri]

> I appreciate all the work you've put into looking at alternatives, but
> at this stage I'm going to be firm - if PIPE_TEXTURE_RECT can be made to
> work, that's the direction we should be taking.  I haven't seen anything
> so far that suggests it isn't a feasible approach.
Yes, it seems feasible, it's just a matter of choosing between tradeoffs.
Right now I think it's more important to actually make any choice
rather than making a specific choice.

Effectively, implementing this is a matter of changing the resource flag to be a
target, and change all existing code that checks for PIPE_TEXTURE_2D to check
for PIPE_TEXTURE_RECT as well.

> What about this for a starting poing:
>   - PIPE_TEXTURE_RECT texture target, following GL semantics
OK.

>   - PIPE_CAP_TEXTURE_2D_NPOT  (nv30 should not advertise this)
We already have this right now, it's called PIPE_CAP_NPOT_TEXTURES.

> Is there anything more you actually require right now?
State trackers must support both normalizations and have some criteria
to choose between them.

I see these options:
1. Have a cap to decide whether to use PIPE_TEXTURE_RECT for internal
textures, and use unnormalized if and only if the target is
PIPE_TEXTURE_RECT
2. Have a cap to decide whether to use PIPE_TEXTURE_RECT for internal
textures, and use the two preference flags to choose the normalization
3. Have state trackers always use PIPE_TEXTURE_2D, and use the two
preference flags to choose the normalization
4. Have state trackers always use PIPE_TEXTURE_RECT, and use the two
preference flags to choose the normalization
5. Have state trackers use yet another new target, e.g.
"PIPE_SURFACE", that would be intended for "2D operations", and use
the two preference flags to choose the normalization

Instead of two preference flags, only one can be used, but this loses
the ability for the driver to express no preference, and only saves a
single line of code.

My latest patchset uses option 3.

What is your preference in this?