https://bugs.freedesktop.org/show_bug.cgi?id=41263
Summary: [r600g] glCopyTexImage2D selects a texture format that involves fallback to software Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: simon.farnsworth@onelan.co.uk
In my compositor, on AMD G-T56N (Fusion, Evergreen) I create a texture using GLX_EXT_texture_from_pixmap, where the source application is using Xv textured video on evergreen to write to its backing pixmap (found with XCompositeNamePixmap).
To have a stable copy of this output for compositing from, I immediately copy the texture to a separate texture whose backing store is owned by the compositor, using code like the following:
glBindFramebuffer( GL_FRAMEBUFFER, framebuffer );
glFramebufferTexture2D( GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, source_texture, 0 );
glBindTexture( GL_TEXTURE_2D, dest_texture ); glCopyTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, 0, 0, width, height, 0 ); glBindFramebuffer( GL_FRAMEBUFFER, 0 );
Where framebuffer is an FBO that I've created earlier with glGenFramebuffers( 1, &framebuffer ), source_texture is the texture bound to the video pixmap, and dest_texture is my private texture for the compositor to use.
The glCopyTexImage2D call is incredibly slow - it's falling back to a CPU-side copy. Tracing in with GDB shows me that, in st_copy_texsubimage (st_cb_texture.c:1463), src_format is PIPE_FORMAT_B8G8R8A8_UNORM and dest_format is PIPE_FORMAT_R8G8B8A8_UNORM (st_cb_texture.c:1523).
As a result, Gallium can neither do a straight copy of the data, nor can it find a suitable format_writemask to do the swizzle, so it falls back to software.
Either Gallium and r600g needs to learn how to do swizzled copies to make this work, or whichever parts of the chain (highest level in Mesa is copyteximage() at teximage.c:2744) choose the swizzled format need to learn to Not Do That.