compiz team mailing list archive

[Bug Watch Updater <1037411@xxxxxxxxxxxxxxxxxx>]

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