Deal with the overloading of _mesa_texstore_rgba, which is actually
used to store all sorts of formats.
Software mesa fails the glean pixelFormats test, but it appears to be
failing even with the swizzle code disabled??
try to use a 8888 texture format which will result in only a memcopy in mesa's texstore functions whenever possible for r200 and r300. r200 can use hw formats argb8888, rgba8888 and abgr8888 (or the opposite on big endian), r300 can use argb8888, bgra8888, rgba8888 and abgr8888 regardless of endian, as it supports free component swizzling.
reenable code in _mesa_texstore_rgba8888 to avoid the generic copy path if only swizzling is required as it works just fine (tested with glean pixelFormats test and a hacked up r200 driver which always uses that format).
fix mixed texgen/non-texgen with texgen modes requiring plane parameters (GL_OBJECT_LINEAR, GL_EYE_LINEAR). This is a chip limitation, try to hack it up regardless or use a tcl fallback in some cases. Might still produce wrong results if fixed up, but so far this corrects celestia ring shadows (in multitexture mode), doom3 (arb renderer), quake4 (arb renderer and some less visible bugs in r200 renderer), and even the remaining texgenmix broken case (this is pure luck though, it is easy to construct artifical cases where it will break).
1) Add a new flag in the sarea (coopting the unused texAge value) to
identify context switches between members of a share group -
ie. multiple contexts in a single application, possibly on different
threads. In this case the contexts share a bufmgr instance and there
is no need to evict textures - so don't.
2) Use a new flag 'need_flush' to ensure hardware rendering is flushed
prior to starting a software fallback.
Add a new internal program parameter value STATE_TEXRECT_SCALE which
provides 1/width and 1/height of the active texture, useful for
implementing ARB_texture_rectangle support on hardware which only
supports ARB_npot-style texturing.
Fix _mesa_swizzle_ubyte_image() to deal with RGBA->RGB->RGBA
conversions, ensuring that the final A value is 0xff in those cases
where we use a RGBA hardware texture format to store RGB textures.
Fix a couple of cases where hardwired texture conversions were
ignoring this restriction.
always use argb8888 instead of rgba8888, this is far more likely to hit a faster memcopy path in mesa (at least on little endian systems, possibly on big endian too)
Always mark tex state atom as dirty when the texture image is dirty, this ensures texture cache gets flushed in case the new texture has the same offset as the old one (fixes glean pixelFormat test at least on r200).