Much slower OpenGL frame rates with unityshell loaded, than plain compiz

What's the video card model involved?
I believe this might be a duplicate of bug #982710

Quadro FX 380, which is based on the GeForce 9400, so it's not the bug that affects performance on the older cards.

Could you please do the following in order to collect data about the affected system, specifically while using said monitor:
- run 'sudo apport-collect 988079' in a terminal
- Attach to the bug report the contents of /var/log/Xorg.0.log
- Attach a text file with the output from lspci -vvnn

We block the normal operation of apport. Can you describe exactly what you want from it?

I think /var/log/Xorg.o.log and the output of lspci -vvnn would be a good start. Also, I think using nvidia-settings creates an /etc/X11/xorg.conf file; if you have that, it would be interesting to have to.

Hi Thomas,

The .40 nvidia driver was a security fix to close a direct memory access flaw. Unfortunately by disabling that interface it caused a few regressions for certain hardware and/or certain applications, such as (I strongly suspect) this problem you're seeing. An updated driver was released by NVIDIA about a week ago; we're still in process of getting it available in all past ubuntu versions but I think it is now available in Precise's via jockey driver updates. Since it reportedly addresses a lot of the regressions that turned up I would suggest putting that on your test machine to see if that will resolve some or all of the issues you've seen. If so, then no need for any further information beyond that. Let me know if you need any special assistance getting that update made available for your systems.

If there are still issues with that updated driver, then we will need further information so we can escalate the issue with NVIDIA. In general they want to have the nvidia-bugreport.sh script executed to generate the bug data they need. As of precise, the xorg apport hook now collects this information in new bug reports, so filing bug reports with us using 'apport xorg' is our recommended way of filing bugs. Note that you can run this command even on systems where the automatic apport reports have been disabled.

In fact, because we have quite a few basic diagnostics built into the apport hook, we tend to not look at bug reports which were not filed using that tool (i.e. our queues and reports only include bugs filed using apport). So, if policy prohibits running apport in general, I'd still like to arrange a robust way for you to escalate bugs to us as priorities so please contact me directly (<email address hidden>) and we can sort out a good solution.

Needs tested with the 295.49. Available in x-updates PPA:
https://launchpad.net/~ubuntu-x-swat/+archive/x-updates

(Btw, it is recommended not to reference glxgears when reporting performance issues. Instead we recommend running a 3d game with fps enabled and report the fps numbers from that, as it is a more realistic measure of performance. glxgear numbers can go up or down significantly without any correlation with actual graphics performance.)

The problem appears to be caused by the window manager or compositor. On request from NVIDIA, I disabled the window manager on the affected machine and ran a raw X server:

sudo service lightdm stop
sudo Xorg &
xlogo &

and then ran glxgears full-screen:

glxgears -geometry 2400x1900+10+10

This worked well.

glxgears is only being used as a simple test application. The Chrome web browser's GPU accelerated rendering path is broken in the same situations that glxgears fails to work well.

I've upgraded NVIDIA's drivers to 295.53 but they have the same behavior as the 295.40 drivers when running within Unity.

It looks to me like the compositor in Precise doesn't respect the GLX swap interval requested by OpenGL applications, and this is causing the Chrome browser to run open-loop, spamming the GPU with commands.

On request from NVIDIA, here is the output of nvidia-bug-report.sh on the machine while glxgears was running badly, with the 295.53 drivers.

Installed GNOME. GNOME Classic without effects runs Chrome properly. Details:

GNOME: fails to run WebGL Aquarium
GNOME Classic: runs WebGL Aquarium at 20 FPS full-screen
GNOME Classic (No effects): runs WebGL Aquarium at 30 FPS full-screen (this appears to be the maximum this card supports at this resolution)

The problem is almost certainly compiz. It was known in past Ubuntu releases that compiz didn't respect the GLX swap interval, but it looks like the issue has been exacerbated with recent releases of GNOME / Unity.

Now that this has been narrowed down, and the requested check of 295.49 has been done (actually, with 295.53), can we move the status away from Incomplete?

Moving this to compiz now that kbr has identified the locus of the problem.

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

Daniel, could you have a look at this bug report and see if it has all the details we need if that's something we could SRU a fix for in precise?

@Kenneth: thanks for the testing, I've some questions though, when you say "GNOME", is that a gnome-shell session? "GNOME classic" runs compiz right (where the "no effects" one doesn't)?

So to summarize:
- it doesn't work under unity (and GNOME = gnome-shell?)
- it works under GNOME classic with compiz with a slower framerate
- it works full speed when no compositor is used

that would suggest the issue there is with unity itself rather than compiz? did you try under unity-2d?

Sebastian: I don't think it's unity. Kenneth is pretty sure it's a failure to implement the GLX swap interval, which is definitely compiz' responsibility. If Unity is using GL more aggressively than Gnome classic, then it stands to reason that the problem would be moderately worse on unity.

Sebastien: yes, GNOME=gnome-shell. The three desktops I listed above are the names of the login menu options.

unity-2d is currently broken in our modified Precise distribution so I haven't been able to test with it.

The problem is not isolated to Unity. The new gnome-shell desktop with all of the effects turned on doesn't run Chrome properly either. The first thing that should be investigated, in conjunction with NVIDIA, is Compiz' interaction with OpenGL applications and support for the GLX swap interval.

Hi Thomas, Kenneth,

Please try these two workarounds, separately, in CCSM:

1. Enable both:
Workarounds > "Force full screen redraws (buffer swap) on repaint"
OpenGL > "Sync To VBlank" (it should be enabled already)

or

2. Disable both:
Workarounds > "Force full screen redraws (buffer swap) on repaint"
OpenGL > "Sync To VBlank"

Hi Daniel,

Here are the results:

> 1. Enable both:
> Workarounds > "Force full screen redraws (buffer swap) on repaint"
> OpenGL > "Sync To VBlank" (it should be enabled already)

Result: WebGL Aquarium runs (i.e., desktop doesn't lock up), but at ~2 FPS

> 2. Disable both:
> Workarounds > "Force full screen redraws (buffer swap) on repaint"
> OpenGL > "Sync To VBlank"

Result: if the window is covering most of the screen when launching the app, the WebGL aquarium or any other WebGL app doesn't start the first time. Looks to me like the browser's rendering loop is running out of control, consuming all CPU and preventing the HTTP resources from being downloaded correctly.

The desktop doesn't become completely unresponsive; it's still possible to close the browser window.

After reloading the aquarium once, it loads; Chrome's GPU process (which is running the OpenGL code) is running at 100% CPU, and the aquarium redraws once every ten seconds or so.

Kenneth, All,

I have been profiling and debugging compiz with the nvidia driver today and have found some unexpected performance bottlenecks that we previously didn't know about:

1. NVIDIA driver 295.* changed; they have now changed the default setting of "Sync To VBlank" in the driver from enabled to disabled. Being disabled means apps (like glxgears or Chrome) will throw damage events at the server completely unthrottled. And compiz has to handle a lot more than it used to (when Sync To VBlank defaulted to on).
So two fixes are required for this:
  (a) Enable "Sync To VBlank" in nvidia-settings. And remember to log out/in again.
  (b) Compiz needs to be more efficient in damage event handling. I'm looking into this but see also #4 below.

2. NVIDIA driver 295.* changed again, and apparently dropped all MESA GLX extensions. Compiz usually defaults to using GLX_MESA_copy_sub_buffer to redraw small regions of the screen efficiently. If it can't use that then it will fall back to glCopyPixels which is slow. But those are not the only two rendering options compiz has...
Solution: Enable CCSM > Workarounds > "Force full screen redraws (buffer swap) on repaint". This will force compiz to use glXSwapBuffers, for better hardware acceleration.

3. `CCSM > Workarounds > "Force full screen redraws (buffer swap) on repaint' was not working before, but it will now. It wasn't working because of #1, which is required for compiz to enable GLX_SGI_swap_control for more efficient pipelining of frame rendering. If you enable #1, then this workaround will now provide the boost that it didn't yesterday.

4. (bug 1005569) A simple stupid bottleneck has been found in compiz event handling which was amplified by #1. This has been fixed and the fix will be in the next update for compiz (timeline still uncertain).

With the Unity WM, I enabled Sync to VBlank in nvidia-settings, logged out and back in, and made sure the setting stuck.

I then opened CCSM, made sure "Sync To VBlank" was set in the OpenGL section and that "Force full screen redraws" was set in the Workarounds section, and logged out and back in again.

I then launched Chrome and ran the WebGL aquarium nearly full-screen; still 1-2 FPS.

Is there some way to make sure these settings actually took effect?

Daniel, this isn't only a performance bug; it's a correctness bug. One consequence of this is, for example, outright rendering errors in chrome. (IOW, we need this in an SRU for precise).

Kenneth,

smspillaz@interpol:~$ glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
297 frames in 5.0 seconds = 59.317 FPS

At least on nvidia here, it seems like you can check if the operation took effect by quickly running glxgears.

Thomas,

In terms of rendering errors, there are all kinds of rendering errors that could possibly occurr - the most likely is probably tearing in the application due to VSync being turned off in the driver by default. I don't think other rendering errors would really be related to /this/ particular bug, a new bug should be filed for that if its not just tearing.

Sam,

I re-verified that "Sync to VBlank" was set in nvidia-settings and the OpenGL panel of CCSM, and that "Force full screen redraws" was set in the Workarounds panel of CCSM.

glxgears claims to be synced to the vertical refresh, and doesn't claim to be running faster than 60 FPS. However, when maximizing glxgears, it claims to be getting better than 15 FPS, but visually, it's getting a much worse frame rate -- there is very bad temporal aliasing.

296 frames in 5.0 seconds = 59.008 FPS
110 frames in 5.0 seconds = 21.856 FPS
85 frames in 5.1 seconds = 16.796 FPS
87 frames in 5.1 seconds = 17.004 FPS
89 frames in 5.0 seconds = 17.682 FPS

When logged in to gnome-shell ("GNOME Classic (No effects)" at the login menu), glxgears runs smoothly when maximized:

302 frames in 5.0 seconds = 60.229 FPS
299 frames in 5.0 seconds = 59.605 FPS
300 frames in 5.0 seconds = 59.805 FPS

Finally, when run under gnome-shell with compiz ("GNOME" at the login menu), glxgears claims to get about the same FPS as under Unity, but the animation seen on-screen is smoother than under Unity. It's nowhere near as smooth as with compiz disabled however.

232 frames in 5.0 seconds = 46.336 FPS
89 frames in 5.1 seconds = 17.614 FPS
89 frames in 5.0 seconds = 17.744 FPS
90 frames in 5.0 seconds = 17.931 FPS

The default window manager settings for both Unity and GNOME were used, so I don't think any additional effects are being enabled when run under Unity vs. under GNOME.

Kenneth,

I know the problems with glxgears often look like temporal aliasing. However that's unlikely the cause unless glxgears itself reports a frame rate lower than the vertical refresh rate. Temporal aliasing could occur at any frame rate, I know, but that would lead to a slight lack of smoothness. Not an obvious and consistently low frame rate like I believe this bug is about.

FYI, in cases where an application reports higher frame rates than you know you're getting from compiz, it is best to consult the "bench" (Benchmark) plugin from package: compiz-plugins-extra. The bench plugin reports the actual frame rate being achieved (from the composite and opengl plugins). Just remember to change bench's key binding in CCSM because the default Super+F12 apparently does not work.

As I mentioned in comment #19, a bottleneck in compiz' event handling has been found. That may be related and is described in bug 1007299.

I will be doing more testing and debugging with the NVIDIA driver this week. So hope to have more suggestions soon.

Kenneth, could you please:

1. Attach output from "glxinfo".

2. Check with xrandr to see what refresh rate it is telling compiz to use (in the absence of sync-to-vblank):
    xrandr | grep '\*'
If xrandr (hence the driver) is reporting the wrong refresh rate for your monitor then you can fix it using either of the workarounds listed in:
    Bug 92599: Incorrect (low/stuttering) refresh rate with NVIDIA driver
    Bug 1009338: composite refresh rate falls back to 50Hz, which is wrong in most cases

3. Install "glmark2" and tell us if it looks significantly smoother than glxgears?

Regarding WebGL Aquarium performance with NVIDIA:
The above history says you had ~20 FPS in Gnome Classic (basic compiz), but only ~2 FPS in Unity (?). That would suggest WebGL in Chrome is mostly being impacted by bug 987304 and/or bug 1005074.

glxinfo output attached.

xrandr was reporting a 50 Hz refresh rate. I disabled "Detect Refresh Rate" in CCSM -> Composite, forced the refresh rate to 60 Hz, logged out, logged back in, confirmed the settings stuck, and re-tested glxgears and glmark2. No significant difference.

I installed glmark2 and ran the first few scenes under gnome-shell ("GNOME Classic (No effects)" from the login menu), gnome-shell with compiz ("GNOME Classic" from the login menu), and Unity ("Ubuntu" from the login menu), with -s 2550x1450 for all, which mostly fills the machine's screen. The detailed results are attached above. The first time I ran it with gnome-shell+compiz I didn't have the "Force full screen redraws" workaround enabled in CCSM; thus the two attachments.

In all situations, Sync to VBlank was turned on both in nvidia-settings and CCSM.

Without compiz glmark2 achieves a smooth framerate.

With compiz and gnome-shell glmark2 claims to be reaching between about 170 and 240 FPS depending on whether "Force full-screen redraws" is turned on in CCSM. However, it is *not* achieving this frame rate. The on-screen animation is visibly dropping frames. This clearly indicates that compiz is part of the problem.

With Unity glmark2 gets about 1 frame per second, confirmed from visual inspection. This clearly indicates that Unity is a major part of the problem.

Some colleagues have indicated that Unity is working well in similar workstations with recent NVIDIA graphics cards. I suspect that the problems occur when the GPU is fully saturated, which is much less likely to happen with newer cards. Unfortunately, we have thousands of Quadro FX 380 and 580 cards in deployment, and they have been working reasonably well up until now under Ubuntu 10.04.

It may well be that bug 987304 and bug 1005074 describe part of the problem reported here, but compiz is also unquestionably imposing overhead that is affecting the performance of OpenGL applications; the Unity shell is not the only problem.

Thanks. Those results seem to confirm the problem only happens to compiz when unityshell is loaded. So that is bug 987304 and/or bug 1005074.

A fix for the former was released yesterday in unity 5.12-0ubuntu1.1. Please update and try that. The latter is not yet resolved.

I think comment #30 shows the primary problem we should focus on here. If you agree then I will merge bug 1005074 into this one.

While I agree that Unity is the largest problem, I do not agree that it is the only problem. Compiz is definitely imposing overhead, and causing incorrect reporting of OpenGL applications' performance. With gnome-shell+compiz, glmark2 thinks it is running at >170 FPS, but it is definitely dropping frames. If it were actually running at 170 FPS then it wouldn't be exhibiting the jerky animation it does on screen. Perhaps compiz is competing for the GPU's fill rate with other OpenGL applications on the system, but if this were true, then the app shouldn't be able to provide frames to compiz at a rate faster than the screen refresh rate. The fact that compiz doesn't appear to be imposing the GLX swap interval on OpenGL applications is causing Chrome's GPU accelerated rendering path to not function correctly. Chrome relies on the swap interval to throttle its rendering.

According to synaptic, unity 5.12-0ubuntu1.1 is already installed, and I just rebooted to make sure; however, my installation clearly doesn't have the fix you describe. Could you please point to a .deb I can install manually? Google's modified Precise distro doesn't allow PPAs to be added.

Kenneth, the one of the most important things for ensuring a bug is eventually resolvable is to have a clear definition and that multiple bugs are not being discussed in the same place. I think the issue with Unity, which seems to be the largest issue, should be discussed here. And the other issues, while certainly valid, should be handled as separate bugs.

Regarding, imposition of "GLX swap interval" on OpenGL applications:
As far as I know, that is the responsibility of the driver. The driver virtualizes vblank events for applications when they're running in a composited environment. Whether applications get throttled is entirely determined by:
  (a) The application's support for waiting for vblank; and
  (b) The driver configuration (most ignore sync to vblank for faster rendering by default).
If "Sync To Vblank" is not enabled in the driver and/or not implemented in the application, or if the application does not throttle itself by other means, then we cannot throttle the application. That has nothing to do with compiz. However we can control how much unthrottled app rendering impacts compiz performance, and its ability to redraw the real screen. That is discussed in bug 1007299.

> If it were actually running at 170 FPS then it wouldn't be exhibiting the jerky animation it does on screen. Perhaps compiz is competing for the GPU's fill rate with other OpenGL applications on the system, but if this were true, then the app shouldn't be able to provide frames to compiz at a rate faster than the screen refresh rate.

On this point, I can assure that there isn't any such competition for fill rate because we don't do full-screen redraws every frame and even if we were doing fullscreen redraws every frame that would impact application performance substantially. As Daniel already pointed out, respecting the swap interval is the responsibility of both the driver and the application. One thing to note here is that compiz uses glXSwapIntervalEXT only on full-screen redraws and falls back to GLX_SGI_video_sync on partial redraws. "Force fullscreen redraws" causes it to use the former path all the time.

Now what could be causing the visible "dropping frames" in GLMark2 is higher than normal CPU usage when trying to deal with the damage events coming from the directly rendered application. Daniel's looked into that already and come up with some ideas for it, but needs some more time to ensure it works perfectly. This is bug 1007299 . What's also worth looking into I believe is the server-side CPU usage as well.

It seems to me that Unity and / or Nux is doing something that causes GLmark to take a slow path in the driver, or a software path. As such, I think its a good idea to engage NVIDIA on this subject. Can you attach an nvidia bug report while running Unity and GLMark2?

I don't see any evidence that NVIDIA is a fault here. We risk wasting theirs and our time if we engage them prematurely.

There is some simple testing I have yet to do in the Unity code to better identify the location of the problem. Anyone can do that; not just me.

Once a feasible solution is identified, we can further test it by creating a PPA. I know Google can't use PPAs but they can simply be pointed to a URL and download potential fixes for verification.

Not "the fix" but definitely removes a performance bottleneck that doesn't need to exist: https://code.launchpad.net/~smspillaz/unity/unity.less-paint-insanity/+merge/109079

@Kenneth: when you say "gnome-shell and compiz", do you really mean gnome-shell or do you mean gnome-classic (i.e gnome-panel), they are different session, gnome-shell is not using compiz (and not sure it can work with it since some of their feature are integrated in their windows manager)

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

I've now tested my experimental XDamageReport changes and found they provide no improvement here. But that's with NVIDIA, and they never did provide much improvement with the NVIDIA driver. Likewise, skipping damage events in unity itself provides no benefit.

I did make a startling observation though... If you've never opened the Dash then you will get 10-20% higher frame rates than if you have ever opened the Dash since logging in. That's huge. But it only accounts for about half the slowdown I observe with unityshell loaded.

The issue with opening the Dash permanently affecting graphics performance for the session could be related to bug 982434.

> @Kenneth: when you say "gnome-shell and compiz", do you really mean
> gnome-shell or do you mean gnome-classic (i.e gnome-panel), they are
> different session, gnome-shell is not using compiz (and not sure it
> can work with it since some of their feature are integrated in their
> windows manager)

I meant the "GNOME Classic" desktop environment selection at the login screen. I assumed that was using Compiz. Please correct me if I'm wrong.

> I meant the "GNOME Classic" desktop environment selection at the login screen. I assumed that was using Compiz. Please correct me if I'm wrong.

it's using compiz no worry, it's just using gnome-panel not gnome-shell (which has a different environment and window manager than compiz), it was just to make sure we are not overlooking any other factor there...

OK, this is going to be a long one.
During these days I've taken some time to perform some benchmarks in my system (Dell D830 with Nvidia Quadro NVS 140M).
The system is an up-to-date 12.04, running NVIDIA driver version 295.49. Vsync was enabled in the drivers; compiz refresh rate was forced to 60Hz to prevent wrong refresh rate detection.

I benchmarked gnome-classic with metacity, gnome-classic with compiz, gnome-shell, Unity 3D, and Unity 2D against GlMark, Unigine, and 3DMark 2001. The reason of the last benchmark is that I'm having e a lot of trobles running LIMBO at a decent framerate under Unity, while I have no problem under gnome-classic with metacity.
So before filing a new bug I thought about profiling it through a similar WINE program.

Also, for the compiz benchmarks, I tried with and without the "Force full screen redraws" workaround.

Please find the spreadsheet attached.

OVERALL RESULTS:
1) gnome-classic without effects is always the best performer
2) "Force full screen redraws" does bad: it gives -50% performances in some cases
3) Unity 3D is a worse performer than standalone compiz (below 5% however)
4) Opening the dash in Unity 3D has a certain impact on performances (below 10% however)
5) Gnome shell performs slightly better than Unity 3D
6) Unity 2D performance is sub-par

OTHER CONSIDERATIONS:
1) At least in my system, I've always felt that any composited environment has a big impact in performances. I can see it even in 2D applications: take firefox, where scrolling certain pages (eg: ossblog.it) is very sluggish. Now this is confirmed by numeric results. The question is: do you think it's normal, or it is just an NVIDIA driver issue?
2) I have also measured the memory usage in the several cases. There actually is a slight correlation between memory usage and performance.
3) The 3DMark 2001 25% drop from metacity to Unity 3D confirms the problem I am having with LIMBO. However, I feel that the drop is even higher, "at sensation". Do you think I need to file a new bug?

Re: comment #39

Sam, sorry to say lp:~smspillaz/unity/unity.less-paint-insanity does not seem to improve performance at all. But the change still looks worthwhile because it's a nice simplification and seems to work well.

I was slightly wrong. I think the above branch provides ~4% speedup, not to mention the nice simplification.

Will you provide a ppa for testing like in previous release?

Ivan,

Yes, when a fix is ready I will try to get it to precise ASAP.

For Nvidia users the ONLY way to get a responsible experience in 3D apps games is to enable

composite -> "unredirect fullscreen windows"

it fixes ALL performance issues - regardless of the ' Sync To Vblank' setting ... It's the same speed as kde (with /without desktop effects), xfce, lxde, etc

If you are getting a slow speed (and have Nvidia)

Out the box as well as the speed of fps being 1/2 of what it should I was getting weird graphic (lagging) issues

https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1012401

Enabling "unredirect fullscreen windows" in compiz settings fixes everything - the speed, the issues, it is the ONLY way I have seen unity3D to be usable....

However one word of warning - enabling that option can make Unity3D not start when you re-login...

https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/980663

At present I would advise all Nvidia users to avoid Unity3D / Compiz if you ever want to play a 3d game... Unity/Compiz needs to be fixed for Nvidia user asap (I really fear the bugs will give Linux a bad name for gaming..)

Kde,lxde,xfce,cinammon - none of these DE's have these issues btw... Kde has 'suspend desktop effects on fullscreen apps' and gnome 3 seems to automatically do the same...

That's right. "Unredirect fullscreen windows" should fix performance for full screen graphics, BUT BEWARE:

1. Enabling that option will generally make it impossible for any other window to pop up in front. For example, if you run a browser full screen, then you can never get any popup/context menus.

2. The option is not reliable in my experience. It doesn't detect all full screen windows as full screen. That needs investigation.

I haven't noticed the issues you mention, however I will double check tonight.

So the 'solution' at present is - Use another desktop environment if
you want to play a game....

I have found that unredirecting fullscreen windows does help in many of cases, and I've used it before with games and "old" compiz classic (the one in Lucid). But I have also found the option rather unreliable in practice. I've resolved most issues by using a separate Openbox session dedicated to fullscreen gaming. Not a very desirable solution, but it works wonders for the performance .. (Why Openbox instead of Unity2D ? Because even Unity2D with disabled compositing in metacity causes performance issues with some games for me - Limbo in fullscreen from Humble Bundle V comes to mind.). Nvidia-blob & Ubuntu 12.04.

glxgears :

- Gnome-shell / Unity 3D : 10 FPS
- Gnome classic no effects : 15000 FPS

Games runs fine on gnome-classic (Limbo, Heroes of Newerth), laggy like hell on shell/unity (seems legit).

Nvidia GTS 250. Tested officiel nvidia-current, from special ppa for nvidia, with official driver from website.
Nothing changes.

Very very very annoying !

Any way to downgrade driver and use and older one to test it ?

Forgot to mention:

Unable to play HTML5 videos and flash vids are very slow and blue (inverted?) on Youtube.

My Laptop with Intel HD3000 works better :-/

Blue flash vids is a flash player bug. To solve: right click on youtube video, go to settings, untick hardware acceleration and restart the browser.

Antoine, please be careful not to confuse:
  Gnome Classic
  Gnome Classic (no effects)

If you are comparing performance with "Gnome Classic (no effects)" then you are commenting on the wrong bug.

This bug is only about the difference in performance between the Ubuntu (Unity) session and Gnome Classic (with effects = compiz).

An update: we tried upgrading the graphics card in the affected workstation from a Quadro FX 380 to a Quadro 600. This worked around the performance problems. With the new card, glmark2 runs smoothly within Unity, and Chrome runs well; it claims 60 FPS with the WebGL Aquarium demo running nearly full-screen, though it does appear to drop frames occasionally.

The Quadro FX 380 is admittedly a fairly old card, and I don't think it's worth investing a lot of time making things work flawlessly on it. However, I do believe the performance issues are indicative of problems with Unity+Compiz on older or slower graphics cards in general, and they should continue to be investigated.

Kenneth,

I'm going ahead with the fix anyway. It solves a large number of performance problems and is under review right now. As always, we are keen to ensure graphics performance is good on low-end hardware too.

See also: bug 1007299 which will make a difference when fixed. However the proposed fix for this bug in unity seems to provide the most significant improvement.

Fix committed into lp:unity at revision 2470

This bug was fixed in the package unity - 6.0.0-0ubuntu1

---------------
unity (6.0.0-0ubuntu1) quantal-proposed; urgency=low

  [ Didier Roche ]
  * debian/rules, debian/control, debian/unity-autopilot.install:
    - install new unity-autopilot package, containing autopilot bindings and
      test for Unity
    - add some python build-dep for executing setup.py
    - use dh_python2 and add some python:Depends dep for automatic python
      version detection
  * debian/control:
    - remove gnome-desktop dependency: not needed upstream anymore
    - unity Breaks older lenses due to path change
    - remove libgdu in build-dep
  * debian/libunity-core-6.0-5.install, debian/libunity-core-6.0-dev.install,
    debian/control:
    - version bump in libunity-core, change soname

  [ Matthieu Baerts (matttbe) ]
  * Update apport hook for python3 ; thanks to Edward Donovan (LP: #1013171)

  [ Łukasz 'sil2100' Zemczak ]
  * New upstream release.
    - compiz crashed with SIGSEGV in get_current_slide() from
      unity::BGHash::OnSlideshowTransition() (LP: #889625)
    - Unity is visible on top of fullscreen apps (LP: #734908)
    - App icon on the Unity Launcher lost track of running instance
      (LP: #772063)
    - unity crashed with NameError in reset_unity_compiz_profile(): global
      name 'GError' is not defined (LP: #778470)
    - compiz crashed with SIGSEGV in CompWindow::id() from getPaintMask()
      [compizminimizedwindowhandler.h] from unity::UnityWindow::glPaint()
      (LP: #851982)
    - HUD - Formatting of text in the auto-complete is wrong (LP: #939436)
    - [regression] Launcher is silent to screen reader users (LP: #949448)
    - still some accent issues with unity/nux (LP: #950740)
    - [regression] [precise] 3D apps run much slower under Unity (LP: #987304)
    - No launcher icon or Alt+Tab entry for Gimp windows (LP: #995916)
    - Locked smuxi launcher icon does not indicate smuxi running status
      (LP: #999820)
    - When number of workspaces is set to 1, the Spread no longer works
      (LP: #996604)
    - Much slower OpenGL frame rates with unityshell loaded, than plain compiz
      (LP: #988079)
    - Port to libudisks2 (LP: #1012000)
    - Desktop, Launcher and menu bar still visible when screen locked
      (LP: #886605)
    - Searching in the HUD freezes unity (LP: #1016239)
    - Dragged icons rendered under dash (LP: #1021541)
    - Regression in Launcher keyboard navigation (with Alt+F1) (LP: #1021549)
    - Unity dash is is much slower/laggy after revision 2469. (LP: #1021665)
    - Dash and Launcher - As soon as a user starts dragging a file from the
      Dash, there is a 'flicker' before the Launcher icons that are valid drop
      receptacles re-saturate (LP: #863230)
    - Dash - when a file is dragged from the Dash (Dash home, file lens, or
      music lens) and dropped on a Launcher icon, the Dash should
      automatically close (LP: #865168)
    - Refreshing active blur makes the dash painfully slow (LP: #874230)
    - Open dash, press Alt+f1 - dash remains open (LP: #919209)
    - application reopens itself when last instance is closed from
      windows/application switcher (LP: #926406)
    - HUD D...

What is the state of releasing the fix for Precise, please?

tbushnell: AFAIK, since Unity 6.0 is slated for release for Quantal, this bugfix will probably not make it into Precise, unless someone decides to backport Unity 6.0. You can, however, attempt to compile Unity 6.0 for yourself: http://askubuntu.com/questions/28470/how-do-i-build-unity-from-source

Source: https://answers.launchpad.net/unity/+question/203290

Thomas: We plan to backport the changes to Unity 5.x for precise in the coming weeks, after no further related issues are found by Unity 6.0 users.

This means the change will definitely hit precise by 12.04.2, possibly in time for 12.04.1. However I'll publish a PPA for precise testing before then.

Thanks Daniel, that's very helpful. We would love to test it once you have
the backported patches ready. Is it planned to backport all the bugfixes
mentioned in the changelog, or only some of them? (If only some, is there a
list available of which are targeted?)

On Mon, Jul 16, 2012 at 6:48 PM, Daniel van Vugt <
<email address hidden>> wrote:

> Thomas: We plan to backport the changes to Unity 5.x for precise in the
> coming weeks, after no further related issues are found by Unity 6.0
> users.
>
> This means the change will definitely hit precise by 12.04.2, possibly
> in time for 12.04.1. However I'll publish a PPA for precise testing
> before then.
>
> --
> You received this bug notification because you are a member of Goobuntu
> Team, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/988079
>
> Title:
> Much slower OpenGL frame rates with unityshell loaded, than plain
> compiz
>
> Status in Unity:
> Fix Released
> Status in unity 5.0 series:
> Triaged
> Status in “unity” package in Ubuntu:
> Fix Released
> Status in “unity” source package in Precise:
> Confirmed
>
> Bug description:
> The main problem is that OpenGL apps run slower with unityshell
> compared to plain compiz (Gnome Classic).
>
> In extreme cases, running glmark2 under Unity only achieves 0-3 FPS.
> Yet on the same machine reports frame rates of several hundred FPS in
> Gnome Classic. See comments #28-#30.
>
> In other cases, game performance is OK but still visibly worse under
> Unity. ioquake3 drops in frame rate by around 20% in Unity compared to
> plain Compiz in Gnome Classic (see duplicate bug 1005074).
>
> ORIGINAL DESCRIPTION:
> On my Z600, with a fresh Precise installation, after installing the
> NVIDIA driver 295.40 (same version as in gPrecise), glxgears runs extremely
> slowly full-screen. When running on Precise, Chrome's GPU accelerated
> rendering path produces correct results, albeit extremely slowly.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/unity/+bug/988079/+subscriptions
>

Thomas, there will always be more bug fixes backported. That's up to the Ubuntu distro team.

With respect to this particular bug, the branch that resolves it actually resolves 7 unique bugs (to the best of my knowledge), which are listed here:
    https://code.launchpad.net/~vanvugt/unity/regionalDamage

Really golad the issue has been taken so seriously.

I have not been using Unity because of the games related issues.

I look forward to testing when the updates are released.

btw - todays news makes it more important than even now.

Steam have confirmed Linux support......

http://blogs.valvesoftware.com/linux/steamd-penguins/

Thanks for the hard work at getting this bug fixed. I am wondering something though. If and when it gets ported to precise, will I have to enable the "Unsupported updates" (precise-backports) or will it get released in recommended updates?
Just wondering because you use the word backport.

P.D, Unity 6 will be backportet to Ubuntu 12.04 without precise-backports when all issues are fixed.

So we have to wait until Unity 5.16.0 "SRU-2" before the fix in place for Ubuntu 12.04 ? (i hope its before steam in launched for Linux..)

One other bug which I most likely related still exists for unity at present (I have just with the latest unity updates today)

https://bugs.launchpad.net/compiz/+bug/1012401

This is really really easy to re-create - just download the heaven 3 unigine engine benchmark

http://unigine.com/products/heaven/download/

- Run it in Unity3D - you will see an area in the middle of the screen which doesn't update correctly (also performance sucks)
- Run it in another non compiz DE and the issues are fixed.

Is this bug also going to be fixed for in the 5.16 SRU-2 updates ? I fear this will also effect the Oil Rush game (uses the same engine)

Again at present it is only happening in unity, other desktops are fine.

Fix committed into lp:unity/5.0 at revision 2394

Just wanted to add a comment for people following this bug, that for me using Ubuntu 12.10 (august 11th) , it seems fixed. I checked this using an OpenGL (SDL controlled) window I had troubles with in 12.04, it no longer has the slow down in the current 12.10 alpha. It also fixes that application not switching to fullscreen properly.

I cannot vouch for precise performance numbers compared to a non compiz environment, but at least from my experience, visually the slowdown is definitely gone, applying to both a windowed and fullscreen OpenGL application.

Thomas, All,

The fix for this bug has now landed in the Unity 5 tree to be released in 5.16. I am told it will be available for testing soon in one of the PPAs owned by unity-team. Most likely it will appear in:
    https://launchpad.net/~unity-team/+archive/sru
or
    https://launchpad.net/~unity-team/+archive/release

I've installed Unity from the SRU PPA and it improved performence greatly but it's still far from what it should be.

glmark2 and glxgears run without problems. glmark2 reports in every result more than 2 thousand fps while glxgears as expected about 60 fps.

Unfortunately in the Heaven 3.0 benchmark the performance is terrible compared to Gnome Shell and E17 Ecomorph.

Heaven Benchmark v3.0 Basic
                               Unity SRU PPA Gnome Shell E17 Ecomorph
FPS:
                                   5.3 11.9 13.6
Scores:
                                   134 301 341
Min FPS:
                                   3.0 3.9 8.5
Max FPS:
                                   10.1 27.2 29.7
Hardware

Binary:
Linux 64bit GCC 4.4.5 Release Mar 7 2012
Operating system:
Linux 3.5.0-10-generic x86_64
CPU model:
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
CPU flags:
1332MHz MMX+ 3DNow!+ SSE SSE2 SSE3 HTT
GPU model:
GeForce 9600 GT PCI Express 304.37 512Mb

I'm also having problems with sound (Open Sound System v4.2-2006) while running this Unigine benchmark (stuttering) and they only occur in Unity. The same goes for games run through Wine but even native Trine 2.

I'm sorry that I don't provide results for Gnome Classic with Compiz but it's because when I select it in LightDM the thing that shows up is Gnome panels and Unity Dock. I think it's not the way it supposed to be.

I test this on my laptop, unity[-3d] is finally usable at last.
(DualCore 2.1GHz, Intel MHD4500, 2Gb RAM).

Previously unity was very sluggish, even for actions like moving windows.
Disabling the unity plugin in ccsm did show potential, but we need that plugin for the desktop itself.

With the update, unity-3d seems to run at the same speed as compiz without unity.

Thanks very much to the person who found the issue and fixed it!

All,

We know that benchmark and game performance in Compiz/Unity is less than in Gnome or Metacity. And we will hopefully look at improving that soon. However that is not what this bug is about.

Unless you're comparing Unity graphics performance to plain Compiz, please report your performance concerns in new bugs by running:
    ubuntu-bug compiz

I solved my problem with Gnome Classic and unwanted Unity dock showing in this session. I just disabled Unity Plugin in CompizConfig.

I've tested Unity from the SRU PPA (5.14.0+bzr2400ubuntu0+704) against Gnome Classic with Compiz (1:0.9.7.8-0ubuntu1.4).

Sync To VBlank - disabled
Unredirect fullscreen windows - enabled

I tested the following benchmarks Unigine Sanctuary 2.3 (fullscreen 1920 x 1080), Unigine Tropics 1.3 (fullscreen 1920 x 1080), Unigine Heaven 3.0 (fullscreen 1280 x 1024) and the results were the same for Unity and Gnome Classic (Compiz).

However when running Heaven benchmark in fullscreen 1920 x 1080 Unity was slower than pure Compiz.

Unity Gnome Classic (Compiz)
8.1 13.2
203 333
3.9 8.3
17.4 29.1

This was true for every time I run Heaven 3.0 in this screen resolution. Unity in this case is always slower than pure Compiz.

Hello Thomas, or anyone else affected,

Accepted unity into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/unity/5.16.0-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Tested with ioquake3 in window mode 1280x800.
As far as I can tell this specific performance regression is gone for me.

1260 frames 25.7 seconds 49.0 fps 3.0/20.4/43.0/7.6 ms → 5.8.0-0ubuntu2 50Hz
1260 frames 25.9 seconds 48.7 fps 3.0/20.5/40.0/7.3 ms → 5.8.0-0ubuntu2 60Hz

1260 frames 25.2 seconds 50.1 fps 9.0/20.0/37.0/1.1 ms → 5.16.0-0ubuntu1 50Hz
1260 frames 21.0 seconds 60.0 fps 12.0/16.7/33.0/1.1 ms → 5.16.0-0ubuntu1 60Hz

compiz:
  Installiert: 1:0.9.7.8-0ubuntu1.4
  Kandidat: 1:0.9.7.8-0ubuntu1.4
  Versionstabelle:
 *** 1:0.9.7.8-0ubuntu1.4 0
        500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1:0.9.7.8-0ubuntu1vvpreproposed2 0
        500 http://ppa.launchpad.net/vanvugt/compiz-preproposed/ubuntu/ precise/main amd64 Packages
     1:0.9.7.6-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
unity:
  Installiert: 5.16.0-0ubuntu1
  Kandidat: 5.16.0-0ubuntu1
  Versionstabelle:
 *** 5.16.0-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     5.14.0-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
     5.10.0-0ubuntu6 0
        500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
nux-tools:
  Installiert: 2.14.1-0ubuntu1
  Kandidat: 2.14.1-0ubuntu1
  Versionstabelle:
 *** 2.14.1-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     2.14.0-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
     2.10.0-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

With 5.16.0-0ubuntu1 there is a visual regression may be related to this bug fix. Windowed GL-Applications like SuperTux 2 or glxgears stay always on top, even over the dash. The window decoration is hidden, but the window content stays above all other windows and the dash. When the window is draged, only the decoration moves - the content is displayed at the original position until the movement ends (mouse button released).

For me with 5.16 everything seems normal with glxgears drawing. Not always on top, and dragging updates contents. Running with Radeon graphics with the open driver.

All,

Please log new bugs using this command:
    ubuntu-bug unity
so that we can track each problem more easily as a separate bug.

This bug was fixed in the package unity - 5.16.0-0ubuntu1

---------------
unity (5.16.0-0ubuntu1) precise-proposed; urgency=low

  [ Łukasz 'sil2100' Zemczak ]
  * debian/control:
    - Update libgeis-dev and libgrail-dev dependencies in debian/control
  * New upstream release.
    - launcher is not refreshed after user session switch (LP: #1016430)
    - Dragging windows around is slow/sluggish/laggy when multiple monitors
      are enabled (LP: #874619)
    - Dragging icons to reorder -away from launcher causes the dragged icon
      image edges to fade away(cut off) (LP: #1026247)
    - Arrow for indicating lenses points empty space on alt+F2 (LP: #998752)
    - Tooltips backgrounds are not refreshed (no active blur) (LP: #967112)
    - [regression] Unity panel transparency (active blur) not updating properly
      (LP: #865006)
    - [Regression] Hideous low-res icon when using the HUD with autohide
      enabled. (LP: #1035951)
    - Launcher dragged icon is not redrawn when the mouse pointer is not moved
      (LP: #1032700)
    - Black background around after dash is restored (LP: #992516)
    - Refreshing active blur makes the dash painfully slow (LP: #874230)
    - [SRU regression] alt-grave not switching to next window unless 'grave'
      pressed twice (LP: #1035668)
    - [SRU Regression] Unity 5.14 + Nux 2.14: Launcher tooltips are
      incomplete/missing (LP: #1034164)
    - [nvidia] unity crashed in
      nux::GraphicsEngine::QRP_GLSL_1Tex (glDrawArrays) (LP: #1031554)
    - compiz crashed with SIGSEGV in
      unity::ui::EdgeBarrierController::Impl::OnPointerBarrierEvent()
      (LP: #1020075)
    - Much slower OpenGL frame rates with unityshell loaded, than plain compiz
      (LP: #988079)
    - Compiz won't start if "unredirect fullscreen windows" is enabled
      (LP: #980663)
    - [regression] Unity launcher on-screen corruption on resume from suspend
      with nVidia proprietary driver (LP: #915265)
    - Desktop, Launcher and menu bar still visible when screen locked
      (LP: #886605)
    - Unity is visible on top of fullscreen apps (LP: #734908)
    - [nvidia] compiz crashed with SIGSEGV in
      nux::BasePainter::PaintBackground (LP: #982626)
    - Update dependency on the renamed libgeis

  [ Didier Roche ]
  * debian/control:
    - build-dep on latest nux as libgeis-dev and libutouch-geis-dev are
      conflicting (LP: #1047385)
 -- Lukasz 'sil2100' Zemczak <email address hidden> Tue, 11 Sep 2012 10:53:17 +0200

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.