-----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----- _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
