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

[Corbin Simpson]

On Wed, Aug 11, 2010 at 4:44 AM, Luca Barbieri <luca at luca-barbieri.com> wrote:
> Currently Gallium doesn't know about GL_TEXTURE_RECTANGLE textures, except
> for the normalized coordinates bit in the sampler state.
> Also, internal code always use normalized coordinates.
>
> This works fine on new hardware, but on older hardware like nv30, coordinate
> normalization is coupled to the resource layout, and rectangular textures cannot
> be used with normalized coordinates in any way.
>
> This makes it impossible to write an efficient nv30 driver (and, in practice, it's also
> impossible to write a correct one without significant work).
>
> The proposed solution is as follows:
> 1. Add a new PIPE_RESOURCE_FLAG_UNNORMALIZED_COORDS_HINT resource flag,
>   which tells Gallium that the resource is going to be used with unnormalized
>   coordinates. This allows to distinguish GL_TEXTURE_RECTANGLE from
>   GL_TEXTURE_2D in the case of POT texture.
>   This is supposed in theory to be only an hint, but in practice drivers
>   might not even work with the other normalization.
> 2. Make all internal drawing done by Mesa and Gallium support use of both
>   unnormalized and normalized coordinates (e.g. blitter module)
> 3. Set the flag for GL_TEXTURE_RECTANGLE textures
>
> A previous revision was already sent a while ago to this list, when it was not
> opposed, but also didn't get a definitive signoff from Brian or Keith.
>
> Luca Barbieri (3):
>  gallium: add PIPE_RESOURCE_FLAG_UNNORMALIZED_COORDS_HINT
>  gallium: use unnormalized coords internally for NPOT textures
>  st/mesa: set PIPE_RESOURCE_FLAG_UNNORMALIZED_COORDS_HINT for
>    GL_TEXTURE_RECTANGLE
>
>  src/gallium/auxiliary/util/u_blit.c            |   38 ++++++++++++++----
>  src/gallium/auxiliary/util/u_blitter.c         |   48 +++++++++++++++--------
>  src/gallium/include/pipe/p_defines.h           |    6 +++
>  src/mesa/state_tracker/st_atom_pixeltransfer.c |    2 +-
>  src/mesa/state_tracker/st_cb_bitmap.c          |    4 +-
>  src/mesa/state_tracker/st_cb_drawpixels.c      |    2 +-
>  src/mesa/state_tracker/st_cb_texture.c         |   18 +++++++-
>  src/mesa/state_tracker/st_gen_mipmap.c         |    8 +++-
>  src/mesa/state_tracker/st_texture.c            |    5 +-
>  src/mesa/state_tracker/st_texture.h            |    3 +-
>  10 files changed, 96 insertions(+), 38 deletions(-)

I'm completely okay with this iteration of this patchset, since it
requires no Gallium API changes and seems very straightforward. I do
have a question, though, since I'm so unfamiliar with nvfx. In r300g
there is a fragment program rewrite to normalize texcoords
unconditionally for r300 and conditionally for r500. This is also how
we fake our NPOT support. Is this kind of rewriting truly impossible
for nvfx, or just time-consuming?

This entire series has my Reviewed-by: Corbin Simpson
<MostAwesomeDude at gmail.com>.

~ C.

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

Corbin Simpson
<MostAwesomeDude at gmail.com>