Ubuntu

fglrx uses 100% CPU when screen turns off (spinning in glXWaitVideoSyncSGI or glXSwapBuffers)

Reported by Jean-Baptiste Lallement on 2012-03-31
658
This bug affects 131 people
Affects Status Importance Assigned to Milestone
Compiz
High
Unassigned
0.9.8
High
Unassigned
Compiz Core
High
Unassigned
The Ubuntu Power Consumption Project
Undecided
Unassigned
fglrx
Confirmed
Medium
compiz (Ubuntu)
High
Canonical Desktop Experience Team
fglrx-installer (Ubuntu)
Critical
Unassigned
fglrx-installer-updates (Ubuntu)
Critical
Unassigned
gnome-shell (Ubuntu)
Undecided
Unassigned

Bug Description

WORKAROUND (1):
1. Open Catalyst Control Center.
2. Go to 3D > More Settings.
3. Set "Wait for vertical refresh" to "On, unless application specifies".
And if that doesn't work, then also do:
4. Run "ccsm"
5. In Workarounds, enable "Force full screen redraw (buffer swap) on repaint".

WORKAROUND (2):
1. Run ccsm (from package compizconfig-settings-manager)
2. In OpenGL > Sync To VBlank = OFF

TEST CASE:
1. Monitor compiz CPU usage (from /proc/<pid of compiz>/stat or top in batch mode)
2. In "brightness and lock" settings set "Turn screen off when inactive" to 1 minute
3. Wait until screen turns off
4. Move mouse or press a key to turn screen back on
5. Check the CPU usage from the monitor

ACTUAL RESULT:
When screen turns off compiz goes to 100%
When the screen turns back on, cpu usage drops immediately to a normal value
The graph attached shows %CPU of compiz with a sample per second. The graph has been captured on a system with a Radeon HD5770 and fglrx if that matter

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: compiz 1:0.9.7.2-0ubuntu4
ProcVersionSignature: Ubuntu 3.2.0-21.34-generic 3.2.13
Uname: Linux 3.2.0-21-generic x86_64
NonfreeKernelModules: fglrx
.tmp.unity.support.test.0:

ApportVersion: 2.0-0ubuntu1
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
CompositorRunning: compiz
Date: Sat Mar 31 10:17:48 2012
DistUpgraded: 2012-02-01 00:15:24,616 DEBUG enabling apt cron job
DistroCodename: precise
DistroVariant: ubuntu
MachineType: Gigabyte Technology Co., Ltd. GA-890GPA-UD3H
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-21-generic root=UUID=cf89ba34-108b-404d-9804-32d54a1df2ea ro quiet splash vt.handoff=7
SourcePackage: compiz
UpgradeStatus: Upgraded to precise on 2012-01-31 (59 days ago)
dmi.bios.date: 07/23/2010
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: FD
dmi.board.name: GA-890GPA-UD3H
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrFD:bd07/23/2010:svnGigabyteTechnologyCo.,Ltd.:pnGA-890GPA-UD3H:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-890GPA-UD3H:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: GA-890GPA-UD3H
dmi.sys.vendor: Gigabyte Technology Co., Ltd.
version.compiz: compiz 1:0.9.7.2-0ubuntu4
version.fglrx-installer: fglrx-installer N/A
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.32-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.2-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.2-0ubuntu3
version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu8
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.0-0ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.17.0-1ubuntu4
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2

Jean-Baptiste Lallement (jibel) wrote :
Changed in compiz (Ubuntu):
importance: Undecided → High
assignee: nobody → Canonical Desktop Experience Team (canonical-dx-team)
description: updated
Daniel van Vugt (vanvugt) wrote :

I can't reproduce this with intel graphics in 12.04.

jibel, could you please try ssh'ing into the machine when this happens and getting a few stack snapshots of the busy compiz process using gdb?

This bug might be related to the buggy implementation of wait-for-vsync in the fglrx driver. So please also try this as a workaround:

1. Open Catalyst Control Center.
2. Go to 3D > More Settings.
3. Set "Wait for vertical refresh" to "On, unless application specifies".

And if that doesn't work, then also do:

4. Run "ccsm"
5. In Workarounds, enable "Force full screen redraw (buffer swap) on repaint".

Changed in compiz (Ubuntu):
status: New → Incomplete
summary: - compiz uses 100% CPU when screen turns off
+ [fglrx] compiz uses 100% CPU when screen turns off
Changed in compiz-core:
status: New → Incomplete

- Setting "Wait for vertical refresh" to "On, unless application specifies" doesn't work.
- But setting enable "Force full screen redraw (buffer swap) on repaint" in CCSM does work.

strace shows that compiz loops on
ioctl(12, 0xc00c645c, 0x7fff3791e1f0) = 0

where 12 is /dev/ati/card0

Daniel, I'd be happy to provide stack snapshots with gdb if you'd tell me how. Thanks for your help.

Daniel van Vugt (vanvugt) wrote :

jibel, here's a tool that will output the stack info. You can run it as:
    sh ./dstack compiz > compizstack.txt

And then please attach compizstack.txt to this bug.

Daniel van Vugt (vanvugt) wrote :

Actually, while compiz is spinning at 100% CPU please run this command several times:
    sh ./dstack compiz >> compizstack.txt

Filipe Manco (fmanco) wrote :

I'm affected by this bug too.

Enabling "Force full screen redraw (buffer swap) on repaint" doesn't work for me.
This workaround just delays the problem, i.e. the compiz takes more time (about 30 minutes) to use 100% of cpu.

Daniel van Vugt (vanvugt) wrote :

All - Please provide the stack info as requested in comments #4 and #5. You will need to ssh into your machine while the screen is off to do so.

drumour (drumour) wrote :

I appear to have this happening on two near identical 12.04 beta 2 ati systems. Have attached stack info as requested above

Aurélien Leblond (blablack) wrote :

I am having the same problem with an HP Envy 17 (Mobility Radeon HD 5800 Series) with FGLRX (I can't reproduce it with the open source driver).

I attached the stack output.

Matt Fischer (mfisch) wrote :

I can always tell when my screen is blanked because my CPU fan is roaring. I on an HP elitebook with Radeon HD 6470M graphics and am running the fglrx driver.

I found that it takes about a minute for the CPU to start spiking after the screen blanks. From running top, compiz goes from 0 (for about the first 20 seconds) to 30 to 100.

I ran your script in a loop every 5 seconds, there are approx 26 runs in that file The last stack in there may show it starting to wake-up as I bumped the mouse during the last trace.

If I can gather more info, please let me know.

Filipe Manco (fmanco) wrote :

The stack output is attached as requested.

Thanks all. Your stack outputs confirm everyone has the same problem.

summary: - [fglrx] compiz uses 100% CPU when screen turns off
+ [fglrx] compiz uses 100% CPU when screen turns off (spinning in
+ glXWaitVideoSyncSGI or glXSwapBuffers)
Changed in compiz-core:
importance: Undecided → High
status: Incomplete → Triaged
Changed in compiz (Ubuntu):
status: Incomplete → Triaged
description: updated
Changed in compiz-core:
assignee: nobody → Daniel van Vugt (vanvugt)
Changed in compiz-core:
milestone: none → 0.9.7.8
Changed in ubuntu-power-consumption:
status: New → Confirmed
Avery (docaltmed) wrote :

This bug also effects me. I'm on Ubuntu 11.10 with Radeon 6600M.

Lem (lem-jjr) wrote :

Same bug here, HP dm1-3010au (AMD E-350), Ubuntu 12.04, Catalyst from Ubuntu repository.

Mikolaj (mikolaj-babiak) wrote :

Same bug (AMD A8-3510MX). Workaround from first post worked for me.

Evren Yurtesen (eyurtese-g) wrote :

Same problem HP dm1z-4100 (amd e-450)
Setting "Force full screen redraw (buffer swap) on repaint" seems to improve performance overall, compiz normally uses 60-80% cpu when moving a window (crazy right?) and when set "Force full screen redraw (buffer swap) on repaint" it uses only ~30%.

Also the cpu usage is near zero % when the screen is off with the "Force full screen redraw (buffer swap) on repaint" option.

Jose Padilla (sargepl) wrote :

This bug alse affects me (Ubuntu 12.04 with last catalyst driver from Ubuntu Packages on a Zotac AD02, AMD Fusion E-350). I'm testing the first workaround.

Jose Padilla (sargepl) wrote :

The option "Force full screen redraw (buffer swap) on repaint" also reduces the CPU usage with a NVIDIA Go 7700 (last driver version from Ubuntu Package) on an Asus G1 laptop (Ubuntu 12.04).

Jose Padilla (sargepl) wrote :

The workaround seems to work. Thank you.

Gert Kok (gert-n) wrote :

Workaround (Catalyst: 'wait...' + CCSM: 'force...' ) is OK
ATI Radeon HD 5670
dual screen mode

Sascha Jazbec (jazbec) wrote :

deactivating all vsyncing, both in ccsm + in amd catalyst makes compiz snappier and less cpu intense for me ( hd 4650 mobility ).

The windows are tearing slightly when moving, but that is not a serious topic when it comes to the overall desktop expierence. Unity already makes the cpu more hot, so every fix to lower that pressure is a welcome, at least to me.
I also lowered the mouse polling intervall from 40 to 20 in ccsm and checked the "fix fglrx" under "workarounds" in ccsm.

Unity MT-Grab Handles I have turned off. These make only sense if we are on a touchscreen.

I also uninstalled the liboverlayscrollbar packages - first because I dislike Ubuntus strange new scrollbars and second I found that without them the scrolling is more fluid.

and last :

If all the tweaking and tinkering with compiz/ unity3d is too much for you but you still want to use unity : run the "2d" session. This has all the Dash and HUD stuff, but all compiz and cpu hogging is solved instantly because it is not used, making your pc run very much quicker.

Aurélien Leblond (blablack) wrote :

Workaround (Catalyst: 'wait...' + CCSM: 'force...' ) doesn't work for me.
ATI Radeon HD 5700

Workaround doesn't work for me.
ATI Radeon HD 6870

Daniel van Vugt (vanvugt) wrote :

If the workaround doesn't work for you, please follow the instructions in comments #4 and #5.

Changed in compiz:
assignee: nobody → Daniel van Vugt (vanvugt)
importance: Undecided → High
status: New → Triaged
odror (ozdror) wrote :

I have the same issue with catalyst version 12.4 (from the web site) and HD 6850. The workaround did not work for me at all. I have the same issue in Unity 3d and gnome 3. No issues with KDE (with compiz).

Daniel van Vugt (vanvugt) wrote :

I thought this was a compiz-only issue. Does anyone else have the bug with Gnome Shell?

Changed in compiz:
milestone: none → 0.9.8.0
no longer affects: compiz-core/0.9.8
Changed in compiz-core:
milestone: 0.9.8.0 → 0.9.7.10
no longer affects: compiz-core/0.9.7
Chris Merrett (chrisfu) wrote :

Well, for the time being I've switched from Unity to Unity 2D (metacity) and I'm no longer having the issue at all. Whenever I've seen the problem compiz has been the only process hitting 100% when the screen is off. When the machine is left in this state for some time I sometimes end up finding that the machine has hard-locked.

I've noticed that on occasion compiz hits 60-80% with the screen on too when not much is happening.

Catalyst 12.4 (fglrx-updates) and AMD Radeon HD 5830.

Forage (forage) wrote :

I can confirm that this issue occurs with gnome-shell as well. It has been bugging me for a while now since it already started to occur in Ubuntu 11.10, again with gnome-shell.

OS: Ubuntu 12.04 (x64)
Video card: ATI HD6950
Drivers: proprietary AMD CCC 12.4 (fglrx 8.961)

capiporra (jcaceres77) wrote :

Thi is my stack with ubuntu 12.04+unity3d+Catalist 12.04 (I get the same problem with opensource drivers)

Compiz raise to 100% in idle state.

capiporra (jcaceres77) wrote :

more info missed in #29 (sorry)

Device: Dell Inspiron 5010
GPU: ATI Mobility Radeon HD 5650
Process: compiz 1:0.9.7.8-0ubuntu1

With same config that out the box , no tweaks, mods or whatever modification

SlugiusRex (slugiusrex) wrote :

The symptoms here seems kinda similar to Bug #969359. Was the fix to this related to the gnome-settings-daemon?

Daniel van Vugt (vanvugt) wrote :

SlugiusRex, no this bug is not related to gnome-settings-daemon. Only the fglrx driver and compiz.

Pēteris Caune (cuu508) wrote :

Same problem with gnome-shell, attaching stack traces.

Ubuntu 12.04
Radeon 6870
Version of fglrx-updates is 2:8.960-0ubuntu1

Daniel van Vugt (vanvugt) wrote :

Marked as affecting gnome-shell, as reported by multiple people. Also affects fglrx, obviously.

summary: - [fglrx] compiz uses 100% CPU when screen turns off (spinning in
+ fglrx uses 100% CPU when screen turns off (spinning in
glXWaitVideoSyncSGI or glXSwapBuffers)
Changed in gnome-shell (Ubuntu):
status: New → Confirmed
Changed in fglrx-installer (Ubuntu):
status: New → Confirmed
Changed in fglrx-installer-updates (Ubuntu):
status: New → Confirmed
Forage (forage) wrote :

The set "Wait for vertical refresh" to "On, unless application specifies" workaround does not fix the issue when running gnome-shell. Compiz is not being used when using gnome-shell. Therefore I expect there will be no point in installing ccsm to try the alternative workaround. Is this assumption correct?

If yes, would there be anything else worth trying?

Forage (forage) wrote :

Also, updating the driver to AMD CCC 12.6 beta (fglrx 8.980) does not solve the issue either.

Forage (forage) wrote :

I reported the issue "upstream" at http://ati.cchtml.com/show_bug.cgi?id=535

capiporra (jcaceres77) wrote :

In Ubuntu 11.10 with catalyst 11.8 or fglrx this bug isn't present. At least I can't replicate it

Daniel van Vugt (vanvugt) wrote :

I figured this was driver behaviour unique to fglrx so it's not surprising it happens on Windows too. However we might yet be able to work around it in Compiz.

Omer Akram (om26er) on 2012-08-12
no longer affects: compiz-core
description: updated
Changed in compiz:
milestone: 0.9.8.0 → 0.9.8.1
Changed in compiz:
milestone: 0.9.8.2 → 0.9.8.4
26 comments hidden view all 106 comments
Ari (ari-lp) wrote :

Just a small heads-up:

Activating "Force full screen redraw (buffer swap) on repaint" caused a significant increase in CPU load with regular usage on my system. That's why I had to go back to deactivating the automatic screen switch entirely.

In the course of doing so I discovered another bug in that the automatic screen lock does not work as long as the display isn't turned off. Has anyone else experienced something similar here?

Changed in compiz:
milestone: 0.9.8.4 → 0.9.9.0
assignee: Daniel van Vugt (vanvugt) → nobody
capiporra (jcaceres77) wrote :

Is this bug solved in Ubuntu 12.10 ?? I cant't test beta2 by myself right now, sorry.

@DanielVanVugt, if you need some test, logs or alternative workarounds, I can help (if you want, of course)

odror (ozdror) wrote :

no it was not with beta 1.

Jelu (ghotomcity) wrote :

still affects me on 12.10 Gnome Remix

Alex Tudorache (alextudorache) wrote :

I had the same problem for a while now, until recently I found a solution which I'm going to share with you. I know it's not the ideal approach, but I hope it will be useful for you guys until someone fixes the issue.

Investigating I found that installing Caffeine in my Ubuntu 12.04.1 and checking the "Disable Screensaver" option fixed the problem for me. I also checked the option "Start Caffeine on login" at the Caffeine Preference's window, although the "Disable Screensaver" is not a persistent option and each time I log in I have to check this option again.

With this software installed and enabled, my CPU is now always low and the computer is quiet... the only drawback is that the screen never goes blank and I have to turn off the monitor attached to my laptop manually, but for me it's not really a problem and I much prefer this to finding my laptop hot when I come back after leaving it for 15 minutes.

This is the Caffeine file which I have installed:
https://launchpad.net/~caffeine-developers/+archive/ppa/+files/caffeine_2.4.1%2B464~precise1_all.deb

It's also available for other Ubuntu versions as well:
https://launchpad.net/~caffeine-developers/+archive/ppa/+packages

Forage (forage) wrote :

As of Ubuntu 12.10 GNOME remix in combination with AMD CCC 12.11 beta (fglrx 9.010) the issue has disappeared! Note that I did a complete fresh install (not perserving the home folder either) and I have yet to test it with tear free and vsync on, but so far so good.

Kellen Hawley (hawleykc) wrote :

I had the same problem using a Ubuntu 12.10/Gnome 3.6/Radeon HD 6650M/fglrx-updates set up. None of the workarounds worked for gnome-shell (although they worked when using Unity).

My workaround was to uninstall gnome-screensaver and replace it with xscreensaver.

Changed in compiz-core:
status: New → Triaged
importance: Undecided → High
milestone: none → 0.9.7.10
Changed in compiz:
status: Triaged → Fix Released
Changed in compiz-core:
status: Triaged → Fix Released
Changed in ubuntu-power-consumption:
status: Confirmed → Fix Released
Changed in compiz (Ubuntu):
status: Triaged → Fix Released
Changed in fglrx-installer (Ubuntu):
status: Confirmed → Fix Released
Changed in fglrx-installer-updates (Ubuntu):
status: Confirmed → Fix Released
Changed in gnome-shell (Ubuntu):
status: Confirmed → Fix Released
Changed in compiz:
status: Fix Released → Triaged
Changed in compiz-core:
status: Fix Released → Triaged
Changed in compiz (Ubuntu):
status: Fix Released → Triaged
Changed in fglrx-installer (Ubuntu):
status: Fix Released → Confirmed
Changed in fglrx-installer-updates (Ubuntu):
status: Fix Released → Confirmed
Changed in gnome-shell (Ubuntu):
status: Fix Released → Confirmed
Jordon Bedwell (envygeeks) wrote :

While we're at it, can anyone update us on the status of this bug in Precise? When I tested it on Quantal it was working exactly as intended with no side-affects like this so I'm wondering if there are plans to fix this soon? Since it seems like it didn't make it into the point.

MVNregress (pukakk) wrote :

What version is the fixed one?

I have updated my comiz to 0.9.8.4-bzr3407, but the problem still exists.

What can I do?

Changed in compiz-core:
milestone: 0.9.7.10 → 0.9.7.12
Jordon Bedwell (envygeeks) wrote :

Why is this constantly being pushed? And being pushed at all, this is a pretty critical issue that breaks quite a few laptops, I don't even understand why you would ignore an issue like this and push it instead of making it a top priority issue...

Daniel van Vugt (vanvugt) wrote :

I agree it's critical and I would love to have time to work on it. Hopefully this week.

Please stop complaining about status changes. So many people complain about status changes that I mostly don't bother changing bug status's even when I should, just so no one will complain.

Daniel van Vugt (vanvugt) wrote :

P.S. Compiz is open source. Canonical is not to blame for things not getting fixed, but everyone is.

I have to agree with Jordan.

This fried one of my laptops and actually made me move to kubuntu.

Sent from my BlackBerry® wireless device

-----Original Message-----
From: Jordon Bedwell <email address hidden>
Sender: <email address hidden>
Date: Mon, 19 Nov 2012 07:49:53
To: <email address hidden>
Reply-To: Bug 969860 <email address hidden>
Subject: [Bug 969860] Re: fglrx uses 100% CPU when screen turns off (spinning
 in glXWaitVideoSyncSGI or glXSwapBuffers)

Why is this constantly being pushed? And being pushed at all, this is a
pretty critical issue that breaks quite a few laptops, I don't even
understand why you would ignore an issue like this and push it instead
of making it a top priority issue...

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/969860

Title:
  fglrx uses 100% CPU when screen turns off (spinning in
  glXWaitVideoSyncSGI or glXSwapBuffers)

To manage notifications about this bug go to:
https://bugs.launchpad.net/compiz/+bug/969860/+subscriptions

Daniel van Vugt (vanvugt) wrote :

OK, I've spent hours testing various options. The bug is much harder to reproduce in Ubuntu 12.10 because the default rendering method in Compiz 0.9.8 is the same as the workaround (1) listed at the top of the bug. To reproduce the bug I had to force the rendering method that Compiz 0.9.7 uses:
    CCSM > OpenGL >
        Framebuffer object = OFF
        Vertex buffer object = OFF
        Always use buffer swapping = OFF

Then I could reproduce the bug. And this time I noticed that glXWaitVideoSyncSGI is not returning. The spin is happening below glXWaitVideoSyncSGI, but above uki_firegl_WaitVBlank (which returns constantly). And because glXWaitVideoSyncSGI is never returning it means we have little hope of even working around the bug in compiz. It's happening 100% inside the fglrx driver, out of reach of compiz.

Interestingly even with the native compiz 0.9.8 rendering method I could reproduce a similar spin in the glxgears process (not compiz). So again, the problem applies to any OpenGL application.

If neither of the workarounds listed at the top of the bug work for you, then please consider uninstalling fglrx and using the default radeon driver instead. And if you haven't already, then upgrading to Ubuntu 12.10 might help, but you don't really need to because that's equivalent to the workaround at the top of the bug.

Finally, I have contacted AMD directly and asked them to review the bug because even their copy has not been touched since it was logged 5 months ago: http://ati.cchtml.com/show_bug.cgi?id=535

Changed in compiz:
status: Triaged → Invalid
Changed in compiz-core:
status: Triaged → Invalid
Changed in fglrx-installer (Ubuntu):
importance: Undecided → Critical
Changed in fglrx-installer-updates (Ubuntu):
importance: Undecided → Critical
Changed in compiz (Ubuntu):
status: Triaged → Invalid
Changed in gnome-shell (Ubuntu):
status: Confirmed → Invalid
Jordon Bedwell (envygeeks) wrote :

Crap, I had a strong suspicion this was the case because I too didn't experience this bug in 12.10 but 12.10 did not really appeal to my tastes (because of some personal reasons that aren't necessary to this bug.) I don't remember if I ever mentioned that in another bug or not.

Just as a side request if you could, can you please report the default settings for 12.10 for the settings you changed. I actually prefer to keep my desktop tearfree and knowing what those settings are by default in 12.10 will help me a long with plenty of others who want to keep tearfree. (I remember keeping tearfree enabled and not having the problem in 12.10 but the case might have changed since I tested it before Quantal was released and in beta1)

Thanks for taking the time to look into this deeper, and I'm sorry if I sounded angry earlier, I just really wanted updates on the matter and you surely did provide updates that show me peeps care!

With the fglrx driver on my laptop using Kubuntu, I have to turn off screen blanking, because every once in a while it causes my system to hang when the screen blanks. I am able to reset gracefully using ALT+PrintScrn+REISUB. I wonder if this is related to the same fglrx bug. I will try running my desktop without OpenGL compositing and see if that makes a difference.

Daniel van Vugt (vanvugt) wrote :

Jordan: I have already mentioned all the settings I've changed in comment #80.

However if you want an optimal tear-free experience then you should not change the compiz settings. The default compiz settings in 12.10 give the optimal tear-free experience, unless it's disabled in your driver settings in which case you should enable it there too.

Daniel van Vugt (vanvugt) wrote :

AMD tell me the fix is complete and will appear in Catalyst 12.12 (which I think means the December release?).

I'm still confused about the relationship between the Catalyst version number (year.month?) and the fglrx version number that comes from it. But AMD also tell me that it will be made more clear in the version string (from running: glxinfo | grep OpenGL) at least by 12.12.

Changed in compiz:
milestone: 0.9.9.0 → none
Changed in compiz-core:
milestone: 0.9.7.12 → none
Forage (forage) wrote :

And for those who can't wait: Ubuntu 12.10 GNOME remix still works like a charm. No compiz, no CPU issues, with tear-free enabled.

Changed in fglrx:
importance: Unknown → Medium
status: Unknown → Confirmed
Jordon Bedwell (envygeeks) wrote :

I forgot all about that until you had mentioned the 12.12 driver, for those of you who cannot wait you can get the 12.11 beta (which of course is the 12.12) and install it: http://support.amd.com/us/kbarticles/Pages/AMDCatalyst1211betadriver.aspx

Kellen Hawley (hawleykc) wrote :

I can confirm Forage's comment: Ubuntu 12.10 Gnome Remix does not have this problem.
I switched from Ubuntu 12.10 to the Gnome Remix and the problem seemed to solve itself. And I will note that I am running the exact same drivers/programs/extensions that I was when I was experiencing the problem.

MVNregress (pukakk) wrote :

I agree with Kellen Hawley.

Gnome Remix couldn't solve this problem.

MVNregress (pukakk) wrote :

Oops.. Sorry, I mean.. disagree.

I experience High CPU usage in Gnome Remix, too

Daniel van Vugt (vanvugt) wrote :

Gnome probably does not suffer from this bug if it doesn't have any vsync enabled by default. That's equivalent to "WORKAROUND (2)" listed at the top of the bug.

Forage (forage) wrote :

@Daniel: That does not explain why Gnome Shell users had the same issue earlier. For the record, I have vsync enabled in CCC and no high CPU issue to be seen.

Daniel van Vugt (vanvugt) wrote :

Regardless of what is affected and what is not... AMD have confirmed their driver is to blame and they have a fix.

If Gnome is not affected, that's awesome. But we don't need to worry about why.

Aurélien Leblond (blablack) wrote :

Quick questions - Once the driver is released by AMD:
- Will it be available in Ubuntu 12.10?
- Which version of the driver will be updated: fglrx or fglrx-updates?

Daniel van Vugt (vanvugt) wrote :

blablack: I'm not aware of AMD sharing their release schedule with us.

When it is available from AMD, you should keep an eye on:
https://launchpad.net/ubuntu/+source/fglrx-installer
https://launchpad.net/ubuntu/+source/fglrx-installer-updates

Our package maintainer might have more info:
Alberto Milone <email address hidden>

Vitaly Tskhovrebov (viialy) wrote :

Bug affects me as well.

Changed in compiz (Ubuntu):
status: Invalid → Confirmed
Jordon Bedwell (envygeeks) wrote :

This is an upstream bug, and it's been fixed in 13.1 so please either install 13.1 or wait until Ubuntu updates fglrx in the repository (even though they are practically the same -- minus a few differences -- if you build them.)

Changed in compiz (Ubuntu):
status: Confirmed → Invalid
Patrick Callahan (pxc) wrote :

I'm running Kubuntu 12.10 and this bug continues to affect me with 13.1, using .deb packages I built automatically from their 13.1 installer.

It looks like this is just as ‘fixed’ as their ‘Konsole resize causes X crash’ bug.

Patrick, does using Xrender as kwin's compositing backend work as a workaround? That's how I resolved my blank screen freezes using previous versions of the fglrx driver. I haven't been able to get a freeze using 13.1 + kwin OpenGL backend yet, but we'll see...

Patrick, is this the bug you are experiencing?: http://ati.cchtml.com/show_bug.cgi?id=553

This is what I'm currently experiencing using KDE + fglrx drivers, unless I use the xrender backend or disable compositing altogether. Unfortunately, using xrender causes issues with windowed OpenGL apps not updating their screen contents :(

Marcos Lans (markooss) wrote :

WORKAROUND (2):
1. Run ccsm (from package compizconfig-settings-manager)
2. In OpenGL > Sync To VBlank = OFF

worked for me in Ubuntu 12.04
Thanks

David (daved314) wrote :

Either the upstream bug was re-introduced or never really fixed because I'm running the amd-catalyst-13.8 beta2 version (fglrx 13.2000). As soon as the screen shuts off, the CPU usages spikes to 100%. Neither of the workarounds work for me. I've been forced to just turn off X at night.

I've noticed the problem as well if I run xbmc as a standalone. As soon as the screen is shut off, the xbmc.bin process jumps to 100% cpu. The same is true when trying with fvwm2 or xfce4 as well.

can we get upstream to re-open the bug?

Forage (forage) wrote :

No issues with amd-catalyst-13.8 beta2 (since 12.12 for that matter) in combination with GNOME Shell (3.8) on Ubuntu GNOME 13.04 for me.

@David: Are you using Unity or GNOME Shell and which version of Ubuntu are you running?

David (daved314) wrote :

I'm running Ubuntu 12.10 quantal with the amd-catalyst-13.8 beta2 drivers downloaded from the AMD website and compiled/installed on the system. I've not tried GNOME but I've seen this in the other xsession environments. The primary use of this box is running a standalone xbmc instance though. Whenever the screen is shut off (either by standard delay or xset dpms force off) the cpu usage shoots up to 100%. The card is a Radeon HD 7310

papukaija (papukaija) on 2013-10-12
tags: added: battery-power-consumption quantal
Ken Phillis Jr (kphillisjr) wrote :

Just to check, Can anyone confirm that this is still a problem with the Catalyst 13.11 Beta drivers?

http://support.amd.com/en-us/kb-articles/Pages/Latest-LINUX-Beta-Driver.aspx

David (daved314) wrote :

I've just upgraded to the Catalyst 13.11 Beta Drivers linked in #104 and my CPU utilization issue has gone away. When the monitor shuts off, the CPU usage goes down instead of to 100%

I'm going to say "fixed for me with latest 13.11 drivers"

Daniel van Vugt (vanvugt) wrote :

OK then. I haven't retested myself but trust both comment #105 and the upstream bug info. Therefore fix released somewhere around:

fglrx-installer (2:13.101-0ubuntu1) saucy; urgency=low
fglrx-installer-updates (2:13.101-0ubuntu1) saucy; urgency=low

Changed in fglrx-installer (Ubuntu):
status: Confirmed → Fix Released
Changed in fglrx-installer-updates (Ubuntu):
status: Confirmed → Fix Released
Displaying first 40 and last 40 comments. View all 106 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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