Am 26.04.2011 19:35, schrieb Tristan Schmelcher: > 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?
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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
