[Jaunty][UXA] Compiz is unusably slow

I can confirm that on my lenovo X61 tablet, which is also driven by an intel i965 ("Mesa DRI Intel(R) 965GM GEM 20090114"). Intrepid was _a_lot_ faster and snappier with compiz running. I mostly see this when texture-fetches are being preformed (e.g. when triggering the expo-plugin, cube-rotation or scale-plugin). According to my /var/log/Xorg.0.log my system is using EXA and not UXA. For UXA to work I would need to use/enabled DRI2, which needs a more current linux-kernel (>= 2.6.29) afaik.

I switched to "AccelMethod" "UXA" now. Using UXA acceleration on my lenovo X61 tablet is _much_ faster than EXA. The only issue I see is with some windows (using compiz) having the wrong alpha-channel (multiplied alpha), which is mentioned in https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/324854.

Yes, the EXA is slow in intrepid, but in my case UXA is even slower, it is so slow, that it makes me thinking, that this is something more than just a performance issu, but something with the process with screen refreshing

I know that it is not a good idea to confirm my own bugs, but I've found a compete duplicate, so it seems to be reproducible.

I'm the guy from the duplicate and I agree this is the same bug. Please note that "slow" really means that the _whole_ screen gets updated less than every two seconds. There is also not much CPU used by compiz. The only thing which still works as usual is the mouse cursor. (Which is also painted by compiz, right?)

I can confirm this bug on an Asus Eee PC 4G Surf (00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 04)). The refresh rate with UXA enabled is about 1 frame every 5 seconds, although CPU usage is normal. With EXA, desktop effects are on the verge of being unusable, because the refresh rate is low. Long web pages scroll very slowly, for example - the graphics can't keep up. Compiz worked very well with UXA before the update.

If you disable vsync in compiz it works with UXA again so it's apparently a problem with GLX_SGI_video_sync in the intel driver when using UXA.

True, setting /apps/compiz/general/screen0/options/sync_to_vblank to False solves the problem for me.

Same here. Disabling sync_to_vblank does the trick.

Thanks for the bugreport.

There was indeed a bug in the patch that swichtes the default settings. It should now be back to "sync_to_vblank=false" by default.

Thank you! Problem solved.

When does that fix will be available in repositories ?

I just updated my Jaunty this morning, and still having problems with Compiz :
Maximize/restore effect on a window seems to do nothing for 1 sec before the window will really restore.

I noticed that it was the main effect with this problem, switching cube for example is not slower than it was in Intrepid.

Is it really the same bug ?

Shouldn't a "proper" fix for this bug address the "Sync to VBlank" problem rather than change the default setting (which in my opinion is a good default setting)?

On Fri, May 8, 2009 at 7:56 PM, pablomme <email address hidden> wrote:
> Shouldn't a "proper" fix for this bug address the "Sync to VBlank"
> problem rather than change the default setting (which in my opinion is a
> good default setting)?
>

I am now using the xorg-edgers PPA with a 2.6.30-rc4 kernel (to
improve my performance on a big screen and avoid the hangs I
experienced with the stock Ubuntu UXA) and it runs like a charm even
with vsync enabled. - Just to let you know it is fixed with upstream.

I see. Perhaps we should add xorg-*-intel to the list of packages associated with this bug to acknowledge the problem, with triages and wontfixes for different Ubuntu releases as appropriate.

Well, I'm now running 2.6.30-rc7 + (from xorg-edgers) intel 2.7.99 + mesa 7.5 + latest libdrm on 965G (GMA X3100) and having compiz vblank enabled still makes things crawl. So I don't think the upstream has solved it. If you happen to read this and can reproduce, this bug could be retargeted to eg. xserver-xorg-video-intel. It's quite intolerable if people bump into this problem accidentally (running metacity --replace is not in everyone's common knowledge).

On Mon, May 25, 2009 at 8:51 AM, Timo Jyrinki <email address hidden> wrote:
> Well, I'm now running 2.6.30-rc7 + (from xorg-edgers) intel 2.7.99 +
> mesa 7.5 + latest libdrm on 965G (GMA X3100) and having compiz vblank
> enabled still makes things crawl. So I don't think the upstream has
> solved it.

There was a patch committed to the intel driver trunk regarding vsync
and ScreenPixmap today. Maybe that one helps you?

See http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=c3bf8b980134a2761701e4bc18235695a1cb07a4

I can confirm that having vsync on or off doesn't make a difference for me on a 945GME. I have not tried the patch yet.

Installed xserver-xorg-video-intel git 0602 from xorg-edgers, no change. It includes that commit. I still had to disable syncing to vblank from compiz settings to not to have ca. 0.5fps screen update rate.

(as a sidenote, that -intel required 'Driver "Intel"' in xorg.conf for some reason, otherwise started vesa. just a note.)

I still have this problem. Should I unmark it as "fixed"?

Still happens to me too on both Jaunty's linux 2.6.28 and xserver-xorg-video-intel, and on custom-compiled linux 2.6.29 with xorg-edgers' driver. It is possible that linux 2.6.30+ is what fixes the problem, though, as per previous comments.

I'm running 2.6.30-02063004, and if I enable sync to vblank, it slows to a crawl (~0.5Hz updates).

Is that with xorg-edgers? If not, it may be the combination of 2.6.30 with the newer drivers that fixes the issue. If that is not the case either, we should remove the "fixed" status.

I am running the newest drivers and kernel. I'm running on a Lenovo laptop. Oddly enough, when I had an external monitor connected, and was only outputting to that, sync to vblank worked correctly. Now that I'm using the built-in laptop LCD, it sync to vblank causes the ~0.5Hz update issue. I'm not sure what the problem is. Maybe I need to do some dpkg-reconfigure'ing somewhere...?

Had the exact same problem in Mandriva 2009.1. Turn on sync to vblank in ccsm works as well.

It works fine now. I had "Always Sync to Vblank" selected in DriConf, and that apparently didn't get along with the "Sync To Vblank" in Compiz. Once I changed the settings in DriConf and restarted, sync to vblank in compiz worked perfectly. As to why I didn't have this problem with my external monitor, but I did with the built-in LCD, I'm not sure.

Thanks, this bug got me for months, everything works now!

Yep, people are still experiencing this on upgrades. It's some combination of compiz/DRI/something settings that causes the need to disable sync to vblank.