On 25 April 2011 16:22, Ian Romanick <i...@freedesktop.org> wrote: > -----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.
Yeah, I am definitely going to change my code to use GL_RGBA to fix things ... I'm just puzzled about why the perf is so bad on this system when using GL_RGB. My app has been used on a lot of other systems (with many different OpenGL implementations) and this is the first time I've seen this problem. > >> 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? I didn't test 7.10.2 but I looked at the source code for it and _mesa_texstore_argb8888 hasn't changed in any significant way, AFAICT. > -----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
