All of lore.kernel.org
 help / color / mirror / Atom feed
* [Bug 41263] New: [r600g] glCopyTexImage2D selects a texture format that involves fallback to software
@ 2011-09-27 15:27 bugzilla-daemon
  2011-09-27 15:31 ` [Bug 41263] " bugzilla-daemon
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: bugzilla-daemon @ 2011-09-27 15:27 UTC (permalink / raw)
  To: dri-devel

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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-09-28 23:24 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-27 15:27 [Bug 41263] New: [r600g] glCopyTexImage2D selects a texture format that involves fallback to software bugzilla-daemon
2011-09-27 15:31 ` [Bug 41263] " bugzilla-daemon
2011-09-28 17:07 ` bugzilla-daemon
2011-09-28 17:28 ` bugzilla-daemon
2011-09-28 23:24 ` bugzilla-daemon

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.