[Mesa-dev] _mesa_texstore_argb8888 with GL_RGBA -> GL_RGB

[Roland Scheidegger]

Am 26.04.2011 19:35, schrieb 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?

I think it would be ok though I can't speak for others. As long as the
code is simple enough. I believe the idea was to only special-case the
most common cases to keep the code sane, but supplying RGB data in RGBA
form seems like a valid case to me.

Roland