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

Bug #969860 reported by Jean-Baptiste Lallement
666
This bug affects 134 people
Affects Status Importance Assigned to Milestone
Compiz
Invalid
High
Unassigned
0.9.8
Invalid
High
Unassigned
Compiz Core
Invalid
High
Unassigned
The Ubuntu Power Consumption Project
Fix Released
Undecided
Unassigned
fglrx
Confirmed
Medium
compiz (Ubuntu)
Invalid
High
Canonical Desktop Experience Team
fglrx-installer (Ubuntu)
Fix Released
Critical
Unassigned
fglrx-installer-updates (Ubuntu)
Fix Released
Critical
Unassigned
gnome-shell (Ubuntu)
Invalid
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

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :
Changed in compiz (Ubuntu):
importance: Undecided → High
assignee: nobody → Canonical Desktop Experience Team (canonical-dx-team)
description: updated
Revision history for this message
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
Revision history for this message
Jean-Baptiste Lallement (jibel) wrote : Re: [fglrx] compiz uses 100% CPU when screen turns off

- 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.

Revision history for this message
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.

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

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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Filipe Manco (fmanco) wrote :

The stack output is attached as requested.

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: [fglrx] compiz uses 100% CPU when screen turns off (spinning in glXWaitVideoSyncSGI or glXSwapBuffers)

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
Revision history for this message
Avery (docaltmed) wrote :

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

Revision history for this message
Lem (lem-jjr) wrote :

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

Revision history for this message
Mikolaj (mikolaj-babiak) wrote :

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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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).

Revision history for this message
Jose Padilla (sargepl) wrote :

The workaround seems to work. Thank you.

Revision history for this message
Gert Kok (yawarakaimono) wrote :

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

Revision history for this message
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.

Revision history for this message
Aurélien Leblond (blablack) wrote :

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

Revision history for this message
Кузнецов Андрей (andrew-kuznecov) wrote :

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

Revision history for this message
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
Revision history for this message
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).

Revision history for this message
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
Revision history for this message
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.

Revision history for this message
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)

Revision history for this message
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.

Revision history for this message
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

Revision history for this message
SlugiusRex (slugiusrex) wrote :

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

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

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

Revision history for this message
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

Revision history for this message
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
Revision history for this message
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?

Revision history for this message
Forage (forage) wrote :

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

Revision history for this message
Forage (forage) wrote :

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

Revision history for this message
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

Revision history for this message
Filipe Manco (fmanco) wrote :
Revision history for this message
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)
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
Changed in compiz:
milestone: 0.9.8.4 → 0.9.9.0
assignee: Daniel van Vugt (vanvugt) → nobody
31 comments hidden view all 111 comments
Revision history for this message
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.

Revision history for this message
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
Revision history for this message
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.

Revision history for this message
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
Revision history for this message
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...

Revision history for this message
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.

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

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

Revision history for this message
George (george-labuschagne-gmail) wrote : Re: [Bug 969860] Re: fglrx uses 100% CPU when screen turns off (spinning in glXWaitVideoSyncSGI or glXSwapBuffers)

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

Revision history for this message
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
Revision history for this message
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!

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

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.

Revision history for this message
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.

Revision history for this message
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
Revision history for this message
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
Revision history for this message
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

Revision history for this message
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.

Revision history for this message
MVNregress (pukakk) wrote :

I agree with Kellen Hawley.

Gnome Remix couldn't solve this problem.

Revision history for this message
MVNregress (pukakk) wrote :

Oops.. Sorry, I mean.. disagree.

I experience High CPU usage in Gnome Remix, too

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
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>

Revision history for this message
Vitaly Tskhovrebov (viialy) wrote :

Bug affects me as well.

Changed in compiz (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
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
Revision history for this message
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.

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

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...

Revision history for this message
S. Christian Collins (s-chriscollins) wrote :

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 :(

Revision history for this message
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

Revision history for this message
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?

Revision history for this message
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?

Revision history for this message
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)
tags: added: battery-power-consumption quantal
Revision history for this message
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

Revision history for this message
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"

Revision history for this message
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
Revision history for this message
Peleg (freepeleg) wrote :

I am using Dell latitude e7440, Ubuntu trusty, having the same problem. Every time I lock my screen using <Win-key>-L, after a few seconds my vent goes crazy and the temperature rises to 80+ Celsius.

I could not run the `dstack` file properly. The output of `sh ./dstack compiz > compizstack.txt` was
====
Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
/home/peleg/2417: No such file or directory.
Thread ID 1 not known.
/tmp/dstackscript4955:4: Error in sourced command file:
No stack.
====

The output of `sudo sh ./dstack compiz > compizstack.txt` was
====
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
185 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory.
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
====

My system info:

* Ubuntu 14.04.3 LTS (trusty)
* Architecture: 64 bit
* Kernel version: 3.16.0-40-generic
* Dell E7440
* Bios version: A14

Revision history for this message
V-Mark (vertesmark) wrote :

I faced with exactly the same problem with different hardware:

Data:
- Fresh install of Ubuntu 15.10 (plus some other non-desktop or gnome related packages)
- All energy consumption related settings are default (I have not changed them till now).
- Laptop: ACER Aspire V3-371-51
- CPU: Intel Core i5-5257U
- GPU: Intel Iris grapics 6100
- Display: 1920x1080 internal laptop display, no other display ever plugged in.
- 8G RAM
- 120G SSD

I do not have Catalyst Center (my GPU is Intel), but
The solution helped:

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

This made my 100% processor usage to 70%
and from workaround 1:

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

solved my problem totally.

All these chips (and problems) are more similar than we think!

Revision history for this message
V-Mark (vertesmark) wrote :

... unfortunately I realized that my problem begins NOT with screensaver activation, but screen LOCK activation.
During test I switched off the LOCK, this is why my problem seemed to be solved.

I found another bug report which describes my problem: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1322751

Revision history for this message
Khurshid Alam (khurshid-alam) wrote :

This bug has returned for me on Xenial for Intel 965 GMA and many other older intel video drivers.

Revision history for this message
Forage (forage) wrote :

@Khurshid: In which case it's a different bug which should be reported as a new one separately. This one is about AMD/ATI cards/drivers, not Intel.

Displaying first 40 and last 40 comments. View all 111 comments or add a comment.
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.