| Summary: | glCopyPixels dirties the context and all rendering is slower after that | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Daniel van Vugt <daniel.van.vugt> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | eero.t.tamminen |
| Version: | 8.0 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| See Also: | https://launchpad.net/bugs/1037411 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
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.
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