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 compiz packagers, which is subscribed to compiz 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 To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1037411/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~compiz Post to : [email protected] Unsubscribe : https://launchpad.net/~compiz More help : https://help.launchpad.net/ListHelp
