[Mesa-dev] _mesa_texstore_argb8888 with GL_RGBA -> GL_RGB

[Roland Scheidegger]

Am 26.04.2011 01:15, schrieb Tristan Schmelcher:
> Hello,
> 
> I have an OpenGL app where I'm writing video frames to textures. The
> video frames are semantically opaque but the alpha in the source
> pixels is set to 0xff, so I have been using glTexImage2D with
> format=GL_RGBA and internalFormat=GL_RGB to indicate that the input
> has a valid alpha channel but that the OpenGL implementation could
> discard it if it wanted to (e.g., if the hardware had native support
> for GL_RGB which was faster than its GL_RGBA support, or something).
> 
> This has worked well for me on most systems, but today I found that it
> results in poor glTexSubImage2D() performance on an Intel IGDNG_M GPU
> (i965-based) with MESA 7.7.1 (using Ubuntu Lucid). Because
> internalFormat is GL_RGB instead of GL_RGBA, _mesa_texstore_argb8888
> takes a slow path by using _mesa_swizzle_ubyte_image instead of
> memcpy_texture.
> 
> Wouldn't it make sense for _mesa_texstore_argb8888 to use
> memcpy_texture in this case?
> 
> Or maybe it is right to not do that since there is no way for it to
> know that the alpha component in the input is already set to 0xff ...
> but in that case shouldn't it at least take the third path--the one
> that uses PACK_COLOR_8888(0xff, ...) ?

memcpy is pretty much out of the question - it is quite possible other
implementations would do this, but it's tricky. Most hw probably has
some bit which it can set so sampling from such a texture would always
return 1.0 for alpha regardless the actual values, but this is a generic
function shared by all drivers hence it can't assume that. And even if
it could, this can well break something else if you use the texture for
something not directly related to sampling.
Some PACK_COLOR_8888 path should work, it's probably not taken because
there are about 3 million different cases (based on src/dst/internal
format etc.) which you could code separately and this one just isn't one
of it for which this is done. Besides, I'm not sure how much faster this
is compared to _mesa_swizzle_ubyte_image (the big perf hit you take is
usually with the fully general path with the temp image). In any case it
would still be slower than memcpy.

Roland