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 <srol...@vmware.com> wrote: > 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
