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

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

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.

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

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.

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?

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.

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.

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

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

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.

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.

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.

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.

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.

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

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

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

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.

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

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