On 26 April 2011 08:20, Roland Scheidegger <srol...@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 > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
