No subject

Tue Aug 17 12:12:55 PDT 2010

reference driver->st flags, separated from the flag above.
I think this is the approach allows the code to be the simplest, and
cleanly separates this aspect from everything else.
Also, drivers for modern hardware can just do nothing and thus express
no preference.

The downside of all this is that the texture usage semantics are quite
convoluted, whereas using 4 bind flags, they are simpler.

However, they are more predictable, while otherwise everything would
depend on the acceptance or not of specific combinations of bind flags.

Also, nv30 is slightly worse off (because we can't differentiate
between POT TEXTURE_2D and internal textures), but this doesn't really

Again, this is only compile tested, since the goal right now is to find
the most acceptable high level design.

Luca Barbieri (3):
  gallium: add resource normalization flags (v4)
  gallium: use unnormalized coords internally if the driver asks for
    them (v6)

 src/gallium/auxiliary/util/u_blit.c            |   55 ++++++++++++++++++------
 src/gallium/auxiliary/util/u_blitter.c         |   48 +++++++++++++-------
 src/gallium/include/pipe/p_defines.h           |   54 +++++++++++++++++++++++
 src/mesa/state_tracker/st_atom_pixeltransfer.c |    2 +-
 src/mesa/state_tracker/st_cb_bitmap.c          |   25 +++++++----
 src/mesa/state_tracker/st_cb_drawpixels.c      |   34 ++------------
 src/mesa/state_tracker/st_cb_texture.c         |   17 ++++++-
 src/mesa/state_tracker/st_context.h            |    2 +-
 src/mesa/state_tracker/st_gen_mipmap.c         |    3 +-
 src/mesa/state_tracker/st_texture.c            |    5 +-
 src/mesa/state_tracker/st_texture.h            |    3 +-
 11 files changed, 170 insertions(+), 78 deletions(-)

More information about the mesa-dev mailing list