[Mesa-dev] _mesa_texstore_argb8888 with GL_RGBA -> GL_RGB

[Tristan Schmelcher]

Interestingly I have just found out that this issue only happens after
the machine has done a suspend/resume. On a fresh boot prior to the
suspend/resume the performance is good. So I guess somehow the driver
is "forgetting" that it can take a faster path that doesn't go through
_mesa_texstore. Which means that it could easily be fixed in a later
version. But now that I have worked around the problem I probably
won't have time to delve any further.

In case anyone is interested, the affected machine is the Lenovo T410.

On 27 April 2011 07:39, Roland Scheidegger <sroland at vmware.com> wrote:
> 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
>