Benchmark results (with FBO enabled) in compiz 0.9.8.0 are lower than compiz 0.9.7

Bug #1024304 reported by Daniel van Vugt
120
This bug affects 23 people
Affects Status Importance Assigned to Milestone
Compiz
Fix Released
Medium
Sam Spilsbury
compiz (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

I've noticed a 9-10% drop in performance between compiz 0.9.7 and compiz 0.9.8 where FBO rendering is enabled. If I edit the opengl plugin to explicitly disable the FBO code and buffer swapping then it is fast again (since I have the fix for bug 1037411).

NOTE 1:
This regression was allowed in compiz 0.9.8.0 because it is generally only visible in benchmark results. Meanwhile, physical compiz rendering performance (as reported by the compiz Benchmark plugin) is higher in compiz 0.9.8.0 than previous versions, in most cases.

NOTE 2:
If you're just worried about fullscreen game performance, then you don't need to wait for this bug to be resolved. You can get optimal graphics performance with unredirect mode. But see bug 980663 first.

WORKAROUND 1:
Revert back to the rendering method used by compiz 0.9.7. Not recommended as it will increase stuttering of animations and make desktop usage less smooth...
CCSM > OpenGL >
  framebuffer_object = OFF
  vertex_buffer_object = OFF
  always_swap_buffers = OFF

WARNING: Workaround 1 will make your desktop and animations less smooth. It will increase the peak frame rate at the expense of the minimum and average frame rate.

WORKAROUND 2:
If you only care about fullscreen graphics performance then:
1. Make sure you have compiz 0.9.8.2 or later. Otherwise this is unsafe.
2. CCSM > Composite > unredirect_fullscreen_windows = ON

WARNING: Workaround 2 is not enabled by default because it can and does cause serious problems with system stability. Mainly with the nouveau and intel graphics drivers.

Related branches

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

It appears this is two separate issues:

1. glmark and glxgears report 80-96% lower frame rates. This is fixed if I disable FBO support. Unfortunately that doesn't fix #2...

2. Desktop feels much more sluggish with gles2 than trunk.

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: [GLES] gles2 benchmark results are significantly lower than trunk

I'm splitting this bug in two.

This bug is now about just benchmark results, which are caused by GL::fbo.

The issue with the desktop stuttering and feeling slower is now bug 1026498.

summary: - [GLES] gles2 rendering performance is significantly worse than trunk
+ [GLES] gles2 benchmark results are significantly lower than trunk
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I've now added configuration options to the opengl plugin so you can control the rendering mode. That includes a new option to allow glXSwapBuffers even when FBO support is not available.

If turns out that the slowdown is buffer swapping of any sort. Not just FBOs.

However since buffer swapping provides visually smoother graphics (physically higher framerates, despite lower benchmark results), and since there are now config options for your to toggle to use the older rendering method (higher benchmark results), this bug is no longer an issue.

Changed in compiz:
importance: High → Medium
status: In Progress → Won't Fix
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

This issue actually isn't the FBO logic, it seems. A better description is bug 1037411, so let this be a duplicate of that.

Changed in compiz:
status: Won't Fix → Triaged
summary: - [GLES] gles2 benchmark results are significantly lower than trunk
+ [GLES] Benchmark results (with FBO enabled) in compiz 0.9.8.0 are much
+ lower than compiz 0.9.7
description: updated
Changed in compiz:
assignee: Daniel van Vugt (vanvugt) → nobody
milestone: 0.9.8.0 → 0.9.8.4
description: updated
tags: added: performance
description: updated
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: [GLES] Benchmark results (with FBO enabled) in compiz 0.9.8.0 are much lower than compiz 0.9.7

I am not advocating disabling FBO rendering because it does seem to be the fastest way to achieve buffer swapping on every frame. However...

1. Our FBO code could probably be made faster by fixing bug 1040478. That probably won't be enough to resolve this bug though.

2. We might be able to implement unredirection for the foreground window in future. Not just fullscreen windows as we can now.

3. If you desperately want to go back to the old rendering method that compiz 0.9.7 uses then see workaround #1 in the description above.

description: updated
Changed in compiz:
assignee: nobody → Daniel van Vugt (vanvugt)
summary: - [GLES] Benchmark results (with FBO enabled) in compiz 0.9.8.0 are much
- lower than compiz 0.9.7
+ [GLES] Benchmark results (with FBO+VBO) in compiz 0.9.8.0 are much lower
+ than compiz 0.9.7
Changed in compiz:
assignee: Daniel van Vugt (vanvugt) → Sam Spilsbury (smspillaz)
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: [GLES] Benchmark results (with FBO+VBO) in compiz 0.9.8.0 are much lower than compiz 0.9.7

Scrap that. Something changed on my system and suddenly all compiz branches and versions are super-fast.

Whatever it was that caused this regression, I cannot reproduce it any more.

Changed in compiz:
assignee: Sam Spilsbury (smspillaz) → nobody
status: Triaged → Incomplete
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Actually, there is a small difference/improvement still, if I disable FBO+VBO+swap. But it's very small for my machine.

Changed in compiz:
status: Incomplete → Confirmed
description: updated
description: updated
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: [GLES] Benchmark results (with FBO enabled) in compiz 0.9.8.0 are lower than compiz 0.9.7

Sorry for the confusion. I think I've clarified the comment now and I think it agrees with the regression other people see.

summary: - [GLES] Benchmark results (with FBO+VBO) in compiz 0.9.8.0 are much lower
- than compiz 0.9.7
+ [GLES] Benchmark results (with FBO enabled) in compiz 0.9.8.0 are much
+ lower than compiz 0.9.7
summary: - [GLES] Benchmark results (with FBO enabled) in compiz 0.9.8.0 are much
- lower than compiz 0.9.7
+ [GLES] Benchmark results (with FBO enabled) in compiz 0.9.8.0 are lower
+ than compiz 0.9.7
description: updated
summary: - [GLES] Benchmark results (with FBO enabled) in compiz 0.9.8.0 are lower
- than compiz 0.9.7
+ Benchmark results (with FBO enabled) in compiz 0.9.8.0 are lower than
+ compiz 0.9.7
description: updated
description: updated
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Removed references to bugs that existed in compiz 0.9.7. Obviously they're not relevant here.

description: updated
Revision history for this message
chucrute301 (chucrut1nh0) wrote :

This bug is Bug #1050650 ?? (read the last reply)

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

chucrute301,

I would have said no because we think bug 1049214 is the biggest problem for NVIDIA. But your findings in bug 1050650 suggest this bug so I'll make it a duplicate of this for now.

Changed in compiz:
milestone: 0.9.8.4 → 0.9.9.0
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Items of work which will improve rendering performance to mitigate the switch to using framebuffer objects as back-storage with glXSwapBuffers:
Bug #1051284 in Compiz: "[gdebugger] many redundant calls to glBufferData"
Bug #1051285 in Compiz: "[performance] should be using interleaved buffers"
Bug #1051287 in Compiz: "[gDEBugger] glXBindFramebufferEXT called 4 times per frame with blit buffers branch"
Bug #1051290 in Compiz: "[gdebugger] many redundant state changes"
Bug #1051291 in Compiz: "[gdebugger] glUniform is called too much"
Bug #1051292 in Compiz: "[gDEBugger] glGetUniformLocation called too much"
Bug #1051299 in Compiz: "[performance] Use vertex array objects where available"
Bug #1051300 in Compiz: "Use UBOs where possible"
Bug #1051302 in Compiz: "[gDEBugger] glFramebufferRenderbufferEXT called twice per bind"
Bug #1049214 in Compiz: "[nvidia] XSync usage is a massive bottlenecking factor"

description: updated
description: updated
description: updated
description: updated
description: updated
Revision history for this message
Achim (ach1m) wrote :

Hey Daniel,

I am a bit curious are the intel driver problems with »unredirect_fullscreen_windows« specific to some chip generations?
On my IvyBridge system everything seems to run quite well with unredirect fullscreen windows enabled.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Achim,

This is not the right place to discuss X crashes. However the crashes are worse on precise than quantal AFAIK, and might be different between Sandy bridge and Ivy bridge...
bug 1056039, bug 1053789

Revision history for this message
chucrute301 (chucrut1nh0) wrote :

Not pressure, but these bugs will be really fixed in 0.9.9.0??

Bug #1051284 in Compiz: "[gdebugger] many redundant calls to glBufferData"
Bug #1051285 in Compiz: "[performance] should be using interleaved buffers"
Bug #1051287 in Compiz: "[gDEBugger] glXBindFramebufferEXT called 4 times per frame with blit buffers branch"
Bug #1051290 in Compiz: "[gdebugger] many redundant state changes"
Bug #1051291 in Compiz: "[gdebugger] glUniform is called too much"
Bug #1051292 in Compiz: "[gDEBugger] glGetUniformLocation called too much"
Bug #1051299 in Compiz: "[performance] Use vertex array objects where available"
Bug #1051300 in Compiz: "Use UBOs where possible"
Bug #1051302 in Compiz: "[gDEBugger] glFramebufferRenderbufferEXT called twice per bind"
Bug #1049214 in Compiz: "[nvidia] XSync usage is a massive bottlenecking factor"

Revision history for this message
Sam Spilsbury (smspillaz) wrote :

Hi chucrute301

They were /targeted/ for 0.9.9.0. They're still on the radar in the long run based on some analysis we've done, but obivously we need to allocate priorities to other things where it makes sense too.

Revision history for this message
CSRedRat (csredrat) wrote :

Have bad performance on comparing with 12.04 on virtual machine under Microsoft Hyper-V Server 2008 R2 SP1. Graphics is too slow, but other things is perfect.

Changed in compiz:
status: Confirmed → Triaged
Revision history for this message
Simon Strandman (nejsimon) wrote :

Hello

On my system the option "vertex buffer object" causes some serious lag issues in unity. Unity becomes smooth if I disable it but it's almost unusable when it's enabled (I don't need to change the other mentioned options).

Disabling all three options makes compiz use more CPU and causes some visual artifact (parts of windows remain when I move them for ex).

I'm using fglrx (9.000-0ubuntu3) on Ubuntu 12.10. The "radeon"-driver doesn't seem to have any problems with this option.

Simon

Revision history for this message
Sam Spilsbury (smspillaz) wrote :

Hey all,

At least in the nvidia driver, the recently released support for GLX_EXT_buffer_age means that we no longer have to preserve the contents of the backbuffer in an fbo in order to use glXSwapBuffers. As such, we can sidestep that and get a performance improvement.

I've linked the branch with the ongoing work for that, or you can test it in this ppa here : ppa:smspillaz/compiz-experimental

Changed in compiz:
assignee: nobody → Sam Spilsbury (smspillaz)
Revision history for this message
Sam Spilsbury (smspillaz) wrote :

(Note: you must be using 313.09)

Changed in compiz:
milestone: 0.9.9.0 → 0.9.9.2
Changed in compiz:
milestone: 0.9.9.2 → 0.9.10.0
status: Triaged → In Progress
Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :
MC Return (mc-return)
Changed in compiz:
milestone: 0.9.10.0 → 0.9.11.0
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:compiz at revision None, scheduled for release in compiz, milestone 0.9.11.0

Changed in compiz:
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (44.6 KiB)

This bug was fixed in the package compiz - 1:0.9.11+14.04.20140214-0ubuntu1

---------------
compiz (1:0.9.11+14.04.20140214-0ubuntu1) trusty; urgency=low

  [ Timo Jyrinki ]
  * Bump version to 0.9.11

  [ Marco Trevisan (Treviño) ]
  * debian/00_remove_decor_in_unity_session.py: add migration script
    to avoid to load the decor plugin on compiz startup when using unity.
  * debian/compiz-gnome.gconf-defaults: disable decor plugin on unity session

  [ Sebastien Bacher ]
  * debian/compiz-gnome.links: lists keybinding in unity-control-center
  * typo fix in the previous commit. (LP: #1271710)

  [ Iven Hsu ]
  * Opacify: Only dim the windows above the active window.(LP:
    #1189374). (LP: #1189374)
  * KWD: Fix compile errors with KDE 4.11. The KWin developers made
    kdecorationbridge.h private. See:
    http://lists.freedesktop.org/archives/compiz/2013-March/003479.html
    (LP: #1193792). (LP: #1193792)

  [ Nikolay Martynov ]
  * When static switcher is enabled and has an option to show
    application icon turned on the icons are expected to be ~1/3 of a
    thumbnail (48px). Instead they are displayed in 512px size and
    completely cover everything. This change addresses this issue. See
    LP #1173914. (LP: #1173914, #1186426)

  [ BryanFRitt ]
  * Fixed the non-working Annotate 'Clear' Button. Moved this option's
    CCSM position upwards to keep the button shortcuts together. (LP:
    #1202907). (LP: #1202907)

  [ CI bot ]
  * Flush trunk to Ubuntu

  [ William Hua ]
  * Replace <Primary> with <Control> in CCSM. Fixes
    https://bugs.launchpad.net/compiz/+bug/1069121. (LP: #1069121)
  * Tweak support of key bindings of the form
    '<Modifier>Modifier_KeySym'. We tweak a bit the behaviour of key
    bindings such as '<Control>Shift_L' and '<Alt>Alt_R'. 1. We ignore
    the order of key pressing and releasing, so tapping
    '<Shift>Control_L' is the same as '<Control>Shift_L'. 2. We properly
    handle the double modifiers case, for example '<Control>Control_R'.
    3. We also parse key bindings with '<Primary>' being equivalent to
    '<Control>'.
  * Fix GSettings tests with extra slash.
  * Add an interface for plugins to provide non-option key actions that
    can be triggered.

  [ Eleni Maria Stea ]
  * It fixes the bug #1245886. In DecorScreen::handleEvent compiz
    shouldn't try to handle any events if there's no active window yet.
    (LP: #1245886)
  * Compiz static analysis shows that some compiz classes have virtual
    methods but not virtual destructors. Added the virtual destructors
    to get rid of warnings and potential memory leaks.
  * fixed cmake syntax errors.
  * CMake considered compiz a C++ project and couldn't find some
    dependencies like pthreads. Defined compiz as a C, CXX project to
    fix the issue.

  [ Povilas Kanapickas ]
  * Opacify: Properly initialize window drawing for new windows in
    Opacify plugin. (LP: #787814, part 2). (LP: #787814)
  * Opacify: Fix damage generation in the Opacify plugin. When setting
    opacity to some value, non-opacified windows need to be damaged
    regardless of opacity, whereas opacified windows need to be damaged
    only if opacity changes. Remove u...

Changed in compiz (Ubuntu):
status: New → Fix Released
Stephen M. Webb (bregma)
Changed in compiz:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.