Bug 54763 - glCopyPixels dirties the context and all rendering is slower after that
Summary: glCopyPixels dirties the context and all rendering is slower after that
Status: RESOLVED WONTFIX
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: 8.0
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-11 09:24 UTC by Daniel van Vugt
Modified: 2018-02-28 03:31 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel van Vugt 2012-09-11 09:24:50 UTC
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
Comment 1 Daniel van Vugt 2012-09-11 10:10:48 UTC
I am using Intel Sandy Bridge HD 2000 by the way. I believe that means i965.
Comment 2 Michel Dänzer 2012-09-11 13:32:24 UTC
(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);
Comment 3 Daniel van Vugt 2012-09-12 01:48:54 UTC
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;
   }
}
Comment 4 Marek Olšák 2012-09-12 02:33:00 UTC
Don't worry about NewState. It's cleared after every draw operation.
Comment 5 Chris Forbes 2012-09-12 04:52:06 UTC
Would it be reasonable to put a performance note in
ARB_debug_output/KHR_debug when mesa falls into this slow state?
Comment 6 Michel Dänzer 2012-09-12 09:29:28 UTC
(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?
Comment 7 Daniel van Vugt 2012-09-12 09:31:58 UTC
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
Comment 8 Daniel van Vugt 2018-02-28 03:31:48 UTC
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.