[Mesa-dev] _mesa_texstore_argb8888 with GL_RGBA -> GL_RGB

[Tristan Schmelcher]

On 26 April 2011 08:20, Roland Scheidegger <sroland at vmware.com> wrote:
> 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.

I guess that's sort of what I expected. I'll just have to use GL_RGBA
after all then. :/

Separately, if I coded and perf-tested a PACK_COLOR_8888 path for
this, is that something that people would be interested in taking into
MESA?

>
> Roland
>