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
I am using Intel Sandy Bridge HD 2000 by the way. I believe that means i965.
(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);
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; } }
Don't worry about NewState. It's cleared after every draw operation.
Would it be reasonable to put a performance note in ARB_debug_output/KHR_debug when mesa falls into this slow state?
(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?
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
I'm no longer involved in this work so can't verify the bug any more.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.