[Mesa-dev] _mesa_texstore_argb8888 with GL_RGBA -> GL_RGB

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/25/2011 04:15 PM, Tristan Schmelcher wrote:

> 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).

I can't imagine that ever happening for 8-bit per component color.  RGB
with 8-bits per component is 3 bytes, so drivers will always promote
this to RGBx (a single byte of unused padding).  This is basically what
you already have.

> 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, ...) ?

A lot has changed in that code since Mesa 7.7.1.  Are you able to
reproduce this performance issue on a more recent version?  Mesa 7.10.2,
perhaps?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk22AiAACgkQX1gOwKyEAw/zCwCfed0CqgK5WgcoX7UM9pViBu7F
rpEAniVTdJRyyljkitg/KlqYkoIk//qa
=rkFT
-----END PGP SIGNATURE-----