Add option to use glXSwapBuffers on every frame, not just full-screen redraws.

[Daniel van Vugt]

Adding the option to use glXSwapBuffers on every frame should eliminate all tearing once and for all. It also allows us to remove glFinish from each frame, providing much higher rendering performance without the trade-off of reintroducing tearing.

[Daniel van Vugt (vanvugt)]

Here's my initial prototype. You get the idea, but it breaks lots of plugins. smspillaz says a reasonable amount of other changes would be required to avoid breaking the plugins :P

[Daniel van Vugt (vanvugt)]

Correction: It doesn't break "lots" of plugins. Only Unity and window resizing AFAIK.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sam Spilsbury (smspillaz)]

On Sun, 26 Feb 2012, Daniel van Vugt wrote:

> ** Changed in: compiz-core
> Assignee: (unassigned) => Daniel van Vugt (vanvugt)
>
> ** Description changed:
>
> Adding the option to use glXSwapBuffers on every frame should eliminate
> - all tearing once and for all.
> + all tearing once and for all. It also allows us to remove glFinish from
> + each frame, providing much higher rendering performance without the
> + trade-off of reintroducing tearing.
>

Daniel, if you are working on this, could you have a look into backporting
the paint-to-fbo stuff here
http://bazaar.launchpad.net/~linaro-graphics-wg/compiz-core/linaro-gles2-update/view/head:/plugins/opengl/src/screen.cpp#L1519

There's very little performance penalty here since there is only one
pipeline flush and it has the added benefit of reducing complexity in merging
the linaro branch in a few weeks.

> --
> You received this bug notification because you are a member of Compiz
> Maintainers, which is the registrant for Compiz Core.
> https://bugs.launchpad.net/bugs/901097
>
> Title:
> Add option to use glXSwapBuffers on every frame, not just full-screen
> redraws.
>
> Status in Compiz Core:
> Triaged
> Status in “compiz” package in Ubuntu:
> Confirmed
>
> Bug description:
> Adding the option to use glXSwapBuffers on every frame should
> eliminate all tearing once and for all. It also allows us to remove
> glFinish from each frame, providing much higher rendering performance
> without the trade-off of reintroducing tearing.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz-core/+bug/901097/+subscriptions
>

[Daniel van Vugt (vanvugt)]

Sam, I reviewed the options again last Friday. What I found was:

1. The GLES branch looks promising and merges cleanly but:
(a) It's too late to consider a new core rendering algorithm for precise; and
(b) The diff is still over 11k lines. Yet another reason why it won't land in 0.9.7.

2. Forcing full screen redraws (not really a code change, just a config change) now performs better than regional redraws in most cases. Full screen redraws provide higher framerates and equal or _lower_ CPU usage than regional redraws. The only exception was on a very slow system which got its framerate doubled, so the CPU increased somewhat in a good way. The other problem with full screen redraws is that there seems to be high lag when used on multiple monitors. I think someone has logged a bug for that already...
  I personally would not mind forcing full screen redraws right now as it will fix more peoples bugs than it would cause. But I won't do so because we are in freeze and it would still be risky to change core config so late.

3. Interestingly in the GLES code I saw some hints that they encountered the same kind of rendering bugs as I did with my prototype in comment #1. This suggests they are indeed plugin bugs.

I think at this late stage in the precise cycle, then only sane solution to bug 930192 is not to fix this bug yet, but use one of the quick solutions documented there --> bug 930192.

[Sam Spilsbury (smspillaz)]

On Tue, 20 Mar 2012, Daniel van Vugt wrote:

> Sam, I reviewed the options again last Friday. What I found was:
>
> 1. The GLES branch looks promising and merges cleanly but:
> (a) It's too late to consider a new core rendering algorithm for precise; and
> (b) The diff is still over 11k lines. Yet another reason why it won't land in 0.9.7.
>

I think what I was getting at is that we should look to backporting the
paint-fbo stuff that's in the current linaro branch. That is only about
400 lines, most of which is framebuffer management stuff.

> 2. Forcing full screen redraws (not really a code change, just a config change) now performs better than regional redraws in most cases. Full screen redraws provide higher framerates and equal or _lower_ CPU usage than regional redraws. The only exception was on a very slow system which got its framerate doubled, so the CPU increased somewhat in a good way. The other problem with full screen redraws is that there seems to be high lag when used on multiple monitors. I think someone has logged a bug for that already...
> I personally would not mind forcing full screen redraws right now as it will fix more peoples bugs than it would cause. But I won't do so because we are in freeze and it would still be risky to change core config so late.
>

Forcing fullscreen redraws means that the damage-intersection detection
code will be turned off and we also can't use plugins like showrepaint in debugging. We
can use full screen redraws by default this cycle but it is not a long
term solution.

> 3. Interestingly in the GLES code I saw some hints that they encountered
> the same kind of rendering bugs as I did with my prototype in comment
> #1. This suggests they are indeed plugin bugs.
>
> I think at this late stage in the precise cycle, then only sane solution
> to bug 930192 is not to fix this bug yet, but use one of the quick
> solutions documented there --> bug 930192.
>
> --
> 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/901097
>
> Title:
> Add option to use glXSwapBuffers on every frame, not just full-screen
> redraws.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz-core/+bug/901097/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help : https://help.launchpad.net/ListHelp
>

[Daniel van Vugt (vanvugt)]

Even 400 lines is way too much change for precise. And I haven't done any performance testing on it yet.

At the moment forcing full screen redraws provides the highest framerates and lowest CPU (compiz+Xorg). It also means regional damage debugging with showrepaint is irrelevant. And it's even lower CPU than the prototype in comment #1.

Keep in mind that the opengl plugin goes through the motions of drawing ALL windows regardless of the rendering mode. So the more complex the regions (even if they're small), the more CPU it uses.

I would like to benchmark the GLES rendering when I have time. But it's irrelevant this close to release.

[Daniel van Vugt (vanvugt)]

But don't panic too much. Before new rendering modes are added, I planned on adding a simple config option to the opengl plugin so we can switch between the existing (and future) rendering modes. So we don't need to settle on a single solution. Just decide which is default :)

[Lasse Kärkkäinen (tronic+mb48)]

Care must be taken with removing glFinish as doing so may cause additional latency. Ideally the drawing should occur as late as possible, right before the buffer swap (1-5 ms latency at compositing stage) but it may be difficult to guarantee that the deadline isn't missed (causing frameskips). Drawing right after the previous swap is much easier and still acceptable (one frame latency). If no glFinish is done, the display driver may buffer multiple completed frames, leading to high latency.

[Daniel van Vugt (vanvugt)]

The fix has landed in lp:~compiz-linaro-team/compiz/gles2. So now we just have to wait till that branch lands in lp:compiz for 0.9.8.0.

[Daniel van Vugt (vanvugt)]

I now think my original patch in comment #1 was correct. The bugs with Unity should be fixed by:
    lp:~vanvugt/unity/regionalDamage
and the bugs with resizing should be fixed by:
    http://bazaar.launchpad.net/~compiz-linaro-team/compiz/gles2/revision/3256

[Daniel van Vugt (vanvugt)]

Fix committed into lp:compiz at revision 3320. And won't be backported to compiz-core (0.9.7) because this is a massive architectural change.

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.9.8.0-0ubuntu1

---------------
compiz (1:0.9.8.0-0ubuntu1) quantal-proposed; urgency=low

  * debian/control, debian/rules:
    - enable gles on armel and armhf
    - use dh-translations rather than custom code

  [ Sam Spilsbury ]
  * Enable OpenGL ES building
    - Refresh debian/patches/workaround_broken_drivers.patch
    - Remove non-ported plugins from compiz-plugins
    - Add FindOpenGLES2.cmake to compiz-dev

  [ Timo Jyrinki ]
  * New upstream release.
    - Code to make compiz work on GLES. This includes several changes
      to the compiz API. (LP: #201342) (LP: #901097) (LP: #1004251)
      (LP: #1037710)
    - Draft first 0.9.8.0 NEWS and bump VERSION
  * debian/patches/compiz-package-gles2.patch:
    - Remove, obsoleted by the upstream GLES work
  * Disable plugins that don't work on pure GLES on armhf/armel:
    - bench, firepaint, mblur, showmouse, splash, showrepaint, td, widget
 -- Sebastien Bacher <email address hidden> Fri, 31 Aug 2012 22:59:50 +0200