[Mesa-dev] _mesa_texstore_argb8888 with GL_RGBA -> GL_RGB
Tristan Schmelcher
tschmelcher at google.com
Mon Apr 25 16:36:35 PDT 2011
On 25 April 2011 16:22, Ian Romanick <idr at 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-----
>
More information about the mesa-dev
mailing list