Launchpad has imported 8 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=54763.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2012-09-11T09:24:50+00:00 Daniel van Vugt wrote: I call glCopyPixels a couple of times briefly on startup and then never again. The problem is that doing this makes all subsequent rendering much slower. If I never call glCopyPixels on startup then rendering remains fast thereafter. It seems glCopyPixels is modifying the context in a way that permanently cripples later operations. The only possible cause I can see so far is: src/mesa/main/drawpix.c: _mesa_CopyPixels: /* We're not using the current vertex program, and the driver may install * it's own. Note: this may dirty some state. */ _mesa_set_vp_override(ctx, GL_TRUE); This seems to set a flag in the ctx which is never cleared. Using Mesa 8.0.2 in Ubuntu 12.04 Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/16 ------------------------------------------------------------------------ On 2012-09-11T10:10:48+00:00 Daniel van Vugt wrote: I am using Intel Sandy Bridge HD 2000 by the way. I believe that means i965. Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/18 ------------------------------------------------------------------------ On 2012-09-11T13:32:24+00:00 Michel-daenzer wrote: (In reply to comment #2) > I call glCopyPixels a couple of times briefly on startup and then never again. > The problem is that doing this makes all subsequent rendering much slower. If > I > never call glCopyPixels on startup then rendering remains fast thereafter. What are the read and draw buffers for glCopyPixels? If either of them is GL_FRONT*, that will cause a DRI2 fake front buffer to be allocated and thereafter kept up to date wrt the real front buffer. > This seems to set a flag in the ctx which is never cleared. It is cleared: end: _mesa_set_vp_override(ctx, GL_FALSE); Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/19 ------------------------------------------------------------------------ On 2012-09-12T01:48:54+00:00 Daniel van Vugt wrote: Yes, the read buffer is GL_FRONT in this case. So I guess the slow-down is by design in Mesa. I'm going to work around it in compiz anyway. glCopyPixels should never be touched at all really. P.S. _mesa_set_vp_override(ctx, GL_FALSE) does not clear NewState. Which is what I was concerned about: void _mesa_set_vp_override(struct gl_context *ctx, GLboolean flag) { if (ctx->VertexProgram._Overriden != flag) { ctx->VertexProgram._Overriden = flag; /* Set one of the bits which will trigger fragment program * regeneration: */ ctx->NewState |= _NEW_PROGRAM; } } Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/20 ------------------------------------------------------------------------ On 2012-09-12T02:33:00+00:00 Marek Olšák wrote: Don't worry about NewState. It's cleared after every draw operation. Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/21 ------------------------------------------------------------------------ On 2012-09-12T04:52:06+00:00 Chris Forbes wrote: Would it be reasonable to put a performance note in ARB_debug_output/KHR_debug when mesa falls into this slow state? Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/22 ------------------------------------------------------------------------ On 2012-09-12T09:29:28+00:00 Michel-daenzer wrote: (In reply to comment #3) > Yes, the read buffer is GL_FRONT in this case. So I guess the slow-down is by > design in Mesa. Rather the X server / DRI2 protocol. It *might* be possible to make xserver not enforce the fake front buffer for the Composite Overlay Window, not sure. > I'm going to work around it in compiz anyway. glCopyPixels > should never be touched at all really. Out of curiosity, what are you using it for? Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/23 ------------------------------------------------------------------------ On 2012-09-12T09:31:58+00:00 Daniel van Vugt wrote: It is a fallback used for maintaining a persistent backbuffer if FBOs are not available. However it's not an important one because all drivers provide FBOs now. http://bazaar.launchpad.net/~compiz- team/compiz/0.9.8/view/head:/plugins/opengl/src/screen.cpp#L1726 Reply at: https://bugs.launchpad.net/compiz/+bug/1037411/comments/24 ** Changed in: mesa Status: Unknown => Confirmed ** Changed in: mesa Importance: Unknown => Medium -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1037411 Title: [regression][DRI] SubBuffer rendering is much slower in compiz 0.9.8.0 than it was in 0.9.7 Status in Compiz: Fix Committed Status in Mesa: Confirmed Status in “compiz” package in Ubuntu: Triaged Status in “mesa” package in Ubuntu: Triaged Status in “compiz” source package in Precise: Invalid Status in “mesa” source package in Precise: Invalid Status in “compiz” source package in Quantal: Triaged Status in “mesa” source package in Quantal: Triaged Bug description: (This is no longer the primary performance regression bug for compiz 0.9.8.0. Look at bug 1024304 instead) TEST CASE: 1. CCSM > OpenGL > framebuffer_object = OFF vertex_buffer_object = OFF always_swap_buffers = OFF 2. Run graphics benchmarks. Expected: Similar results to compiz 0.9.7 Observed: Much lower results than compiz 0.9.7 ORIGINAL DESCRIPTION: Comparing graphics performance in a two-monitor configuration, I find the gles2 branch is 25-40% slower than trunk. This would not normally be surprising, however the slowdown REMAINS even when I turn off the new rendering features in the gles2 branch: framebuffer_object, vertex_buffer_object, always_swap_buffers So both branches should be using the same code path. But gles2 is still dramatically slower than trunk using two monitors. The good news is that this bug only affects benchmark results and seemingly a little lag. The physical frame rate achieved with two monitors still seems to be higher using the gles2 branch, meaning it drops from 60Hz to 30Hz much less often than trunk does. NOTE 1: This regression was allowed in compiz 0.9.8.0 because it is generally only visible in benchmark results. Meanwhile, physical compiz rendering performance (as reported by the compiz Benchmark plugin) is higher in compiz 0.9.8.0 than previous versions, in most cases. NOTE 2: If you're just worried about fullscreen game performance, then you don't need to wait for this bug to be resolved. You can get optimal graphics performance with unredirect mode. But see bug 980663 first. To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1037411/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
