[i945GM] (Needs UXA) compiz slowmotion after Jaunty upgrade

The system is a Dell Latitude D820 with Intel graphics onboard (lshw in attachment)

Thank you for your bug report. Did you enable slow animations by accident? So I can see if slow animations is bound to a key, could you please run "gconftool-2 -R /apps/compiz > compiz-gconf" and attach the file "compiz-gconf" to this bug report.

Thanks

I'll run the command when I get back home tonight.
But I guess I may have been premature assigning this on compiz. Yesterday evening I installed KDE4.2 to test if Kwin was also affected and it shows the exact same issue. So the cause must be found elsewhere (Xorg, kernel, ...), but I have no idea where as no errors or warnings are being logged.

Compiz config

I'm going to try to change the package as it affects all intensive X operations, even without compiz like playing a video etc.

Xorg seems a plausible culprit

Would you mind attaching your /var/log/Xorg.0.log please? It could be a driver issue

Does it speed up if you install compizconfig-settings-manager, and under System->Preferences-> Compiz config settings manager -> general options -> Display settings-> Sync to VBlank is turned off?

Peter

Just checked it and this setting is already off. Though it turns out to be all intensive X operations not only compiz, so it has to be kernel/driver/Xorg related

Confirming, as someone else with your chipset just reported the same issue.

it still happens in Alpha6. for my situation, the cpu usage is normal, just the compiz desktop effect is very slow.

Same here. I also get artefacts on the screen and video playback fullscreen is choppy (without compiz).

Just installed the beta and my compiz effects are slow too..
Changing file permissions on /dev/dri/card0 (suggested here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/303011) improved FPS a bit...

actually, I tried to compile the newest intel driver(2.6.99)(from the intel linux official website) on the Jaunty Beta. it didn't work at all. Then I tried to compile the 2.5.99 version. But that didn't work either. I was trying to compile the 2.4.XX. But it seemed that I needed to downgrade something(i can't remember now..) to achieve that. I gave up...
Also I changed to other desktop environment and window manager, it's still kind of slow.
Gnome metacity works good. cuz it doesn't really have a lot of effect.
LXDE ＋ openbox works great.
XFCE works great.
KDE + Kwin ----- extremly slow.

I turned back to Ubuntu8.10

While I can't be sure that it's the same root cause, I am also seeing a regression from 8.10 to 9.04 in the performance of compiz effects. In my case it seems to be particularly closely tied to system activity - the busier the system is the worse the effects get (which stands to reason, but the effect is very pronounced. flipping workspaces is enough to slow the effects down).

It's the same problem probably. I had been testing for a long while and tried to solve the same issue for several weeks.

Just chiming in that I'm also effected on a Mac mini with Intel GMA950 (more verbose info in duplicate Bug #353245).

I can confirm Chris Jones's observation regarding system activity. In addition to switching workspaces bogging down the system and getting sluggish I've found that moving a gnome-terminal window rapidly around the screen causes the rest of the screen to freeze. Other gnome-terminal windows that were updating (htop, irssi, anything with terminal scroll) froze their scroll and stopped updating for the duration of time I was moving another window around the screen.

I am able to get "normal" levels of speed by switching from EXA to UXA for rendering acceleration, however, this does not appear to be sufficiently stable/bugfree for us to consider for Jaunty

Could this be a dup of bug #349314?

Thanks, Loïc!

People experiencing the symptoms described in this bug: please try the test kernel in bug 349314 and see if it helps.

from the compiz gconf configuration:

    sync_to_vblank = true

disable that and try again. The default is false.

I enabled UXA/DRI2 and it's working very well for several days now. It's faster then even before this bug.

Yes, we know it's faster, but could you still try what was suggested because EXA is and will remain the default for jaunty.

Timo: I can reproduce slowness on 965 from a fresh user and a beta live CD, so it shouldn't be the sync-to-vblank setting.

Loic: tested apw's kernel on my 965 laptop, no obvious improvements (but also no further regressions)

Forget to report this... If you enable UXA in xorg.conf the performance of desktop effects is quite good. The downside is that compiz.real consumes a lot of memory. It starts normal but after a couple of hours the memory usage is several hundred megabytes. I turned my laptop on this morning and at noon compiz.real used 500Mb, logging in and out or restarting X brings memory usage back to normal... temporarily

My laptop has 2GB RAM so I don't really mind, but intel and compiz are still a bit buggy... :)

FWIW, my intel G45 also runs like a snail in EXA (much much worse than intrepid, even to the point where I get _really_ annoyed by the slowness doing normal 2D programming etc). However, UXA runs like clockwork for me (I guess I'm very lucky that UXA is stable on my chipset, also I have 8GB ram so leaks is not such a big problem for me).

I think the EXA perf regression should be taken very seriously. Otherwise Jaunty might get really bad reviews in Phoronix and elsewhere (they already did an article about the gfx perf problems when we first merged the new intel driver + mesa so I get they're going to follow up on it).

Hmm, the problem described here is hard to differentiate from other performance issues. It seems to just be describing a "performance is slow" issue, which could be due to any number of reasons.

I'd like to know if there is any way we can distinguish this bug separately from bug 349992, (which itself is not specific enough to fix, but is at least has flagged it to a particular upstream change). If we can't distinguish this bug from that, I'd recommend we just close this bug and focus efforts towards solving 349992.

I have also started a troubleshooting guide for Intel performance issues, cataloging what I know on the subject: https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance

I don't know the reason, but UXA causes frequent crashes and the normal driver isn't just giving a performace regression, effects are slow-motion and not workable...

@Timo Aaltonen wrote on 2009-04-03: (permalink)

sync_to_vblank is off already.

Latest Jaunty updates have fixed performance problems for me.. Memory usage is also back to normal, a bit higher but maybe that's normal...

On Tue, Apr 07, 2009 at 08:24:43PM -0000, Chris Quach wrote:
> Latest Jaunty updates have fixed performance problems for me.. Memory
> usage is also back to normal, a bit higher but maybe that's normal...

If the latest updates fixed things for you, you may have been experiencing
bug 349314, which was fixed in linux 2.6.28-11.40.

--
 - mdz

Chris Quach, you mentioned you switched to UXA in an earlier comment. Are you seeing performance better even with EXA?

Can any one else confirm Chris' findings?

I've composed a page detailing various issues that have caused performance regressions for some on Intel graphics: https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance

Probably incomplete still, but for anyone with remaining issues might give a few ideas of things to check.

I switched to uxa mode. But it's terribly slow still.

I downloaded the daily live desktop from April 8th today, and to my great delight EXA performance was much much better on my G45 machine (not as good as UXA but certain acceptable for everyday use). I will try to investigate why the installed and upgraded jaunty version on my HDD isn't as speedy.

On Wed, Apr 08, 2009 at 11:05:21AM -0000, martin wrote:
> I downloaded the daily live desktop from April 8th today, and to my
> great delight EXA performance was much much better on my G45 machine
> (not as good as UXA but certain acceptable for everyday use). I will try
> to investigate why the installed and upgraded jaunty version on my HDD
> isn't as speedy.

Great to hear, thanks for letting us know.

Probably this was the newer kernel uploaded yesterday, you could try
booting the earlier and newer kernels each to do a comparison.

Bryce

Closing this bug since several people report it fixed.

@Guy, if you still have the problem, feel free to reopen with any additional details you find.

@Everyone else, file new bugs. "Performance regression" is a generic symptom and you could be having it yet suffer from a completely unrelated underlying cause.

On Thu, Apr 09, 2009 at 12:39:39AM -0000, Bryce Harrington wrote:
> Closing this bug since several people report it fixed.
>
> @Guy, if you still have the problem, feel free to reopen with any
> additional details you find.
>
> @Everyone else, file new bugs. "Performance regression" is a generic
> symptom and you could be having it yet suffer from a completely
> unrelated underlying cause.
>
>
> ** Changed in: xserver-xorg-video-intel (Ubuntu)
> Status: Confirmed => Fix Released

I think the people for whom this was fixed are now "unfixed" due to kernel
.41 (see bug).

Or is there some other intel performance fix you're aware of having gone in
recently?

--
 - mdz

On Thu, Apr 09, 2009 at 09:42:08AM +0100, Matt Zimmerman wrote:
> On Thu, Apr 09, 2009 at 12:39:39AM -0000, Bryce Harrington wrote:
> > Closing this bug since several people report it fixed.
> >
> > @Guy, if you still have the problem, feel free to reopen with any
> > additional details you find.
> >
> > @Everyone else, file new bugs. "Performance regression" is a generic
> > symptom and you could be having it yet suffer from a completely
> > unrelated underlying cause.
> >
> >
> > ** Changed in: xserver-xorg-video-intel (Ubuntu)
> > Status: Confirmed => Fix Released
>
> I think the people for whom this was fixed are now "unfixed" due to kernel
> .41 (see bug).

Which bug #?

> Or is there some other intel performance fix you're aware of having gone in
> recently?

More likely I'm just out of the loop on what the kernel team has done.

On Thu, Apr 09, 2009 at 01:55:47AM -0700, Bryce Harrington wrote:
> On Thu, Apr 09, 2009 at 09:42:08AM +0100, Matt Zimmerman wrote:
> > On Thu, Apr 09, 2009 at 12:39:39AM -0000, Bryce Harrington wrote:
> > > Closing this bug since several people report it fixed.
> > >
> > > @Guy, if you still have the problem, feel free to reopen with any
> > > additional details you find.
> > >
> > > @Everyone else, file new bugs. "Performance regression" is a generic
> > > symptom and you could be having it yet suffer from a completely
> > > unrelated underlying cause.
> > >
> > >
> > > ** Changed in: xserver-xorg-video-intel (Ubuntu)
> > > Status: Confirmed => Fix Released
> >
> > I think the people for whom this was fixed are now "unfixed" due to kernel
> > .41 (see bug).
>
> Which bug #?

Sorry, copy/paste error. Bug 349314.

--
 - mdz

Thanks; do we know for certain that this symptom (compiz slow motion) is due to that kernel change? Can we just dupe this one to that?

On Thu, Apr 09, 2009 at 09:30:38AM -0000, Bryce Harrington wrote:
> Thanks; do we know for certain that this symptom (compiz slow motion) is
> due to that kernel change? Can we just dupe this one to that?

Several people who reported similar symptoms to those in this bug reported
that fixing 349314 made their symptoms better. However, the kernel team has
rolled back that change, so even if it does fix the problem, the relevant
bug(s) should remain open.

The original reporter of this bug should probably test kernel .40 and see if
it fixes their problem. If so, we can dupe this bug.

--
 - mdz

One thing to keep in mind here (at least in my case) is that on the live CD I put a different kind of load on the graphics card. On my installed version I do certain things differently, like for example the first thing I do at boot is to restore my never ending Firefox session which has got like 20 windows with around 10 TABs in each window (I'm speculating here but maybe that will fill up the graphics card memory or GART aperture or whatever these things are called). There is also other things that are different for example, I use a special theme (Dust) on the installed version. Again, this is complete speculation but what if one theme used a special kind of gradient or other graphics primitive that taxed the graphics card heavily (of course the default human theme also has gradients and glossyness etc but you get the idea, the scenarios might be hitting different executation paths in the driver). As far as I understand it's very possible that certain operations on the card are dead slow while others are fast.

Also about the kernel fix, I was under the impression that we were dealing with three separate intel perf regressions at once. These are A) tiling being disable due to some MCHBAR thing, B) tiling being disabled due to some A17 sizzling thing and then C) the thing I was having and possibly also the original bug reporter for this bug. Note that I never once so any error about tiling not working correctly, not in xorg.log and not in dmesg so basically I think the tiling issues is limited to older intel chipsets like 945 and whatnot (I have G45). Even just given the possilibity that we're dealing with different vaguely formulated perf bugs, probably means we should do some more measurements on this. Unfortunately, I'll be traveling for the next week so I can't help with G45 testing.

I think the best way to proceed is to try to isolate some kind of repeatable benchmark so that we can then run this scenario on both intrepid EXA and jaunty EXA and then say it's this and that much slower or faster. It might also be necessary to create/find a test workflow that uses lots of big bitmaps / textures (as in multiple fullscreen apps in compiz). I was thinking about Phoronix Test Suite as one alternative but while they have a lot of gaming benchmark I don't think they have anything that is similar to fullscreen operations in compiz (like maximize/minimize a window or rotate the cube etc). In the last few weeks while trying to figure this out, I used the gtkperf benchmark from phoronix suite which indeed has one pixmap test but I fear the pixmaps where too small to really give you obvious clear results. If you want to try this anyway install the phoronix-test-suite package and then run "phoronix-test-suite install gtkperf" followed by "phoronix-test-suite run gtkperf".

I was mostly confused by the numbers. Another option for a benchmark idea is to activate the compiz "benchmarking" plugin (install compizconfig-settings-manager package from universe, activate the plugin and then maximize say 10 firefox webpages and spin the cube with the compiz FPS benchmark plugin active).

I just downloaded the daily live(Kubuntu), 9th April, cuz Martin said it works better on his machine. the animation is still really slow. so, the graphic performance is not merely happen in using compiz. it's also really slow in Kwin. for my GM945, I still have this annoying problem.

Intel gm945
ubuntu 9.04 RC
the default EXA mode is still really slow.
switching to UXA mode speed up the compiz to a normal speed.(in beta version this didn't work.)

Switched to UXA per Chris Jones's comment above; performance is now back to normal on my Mac mini with Intel GMA950.

Upgrading to the newest kernel can solve this issue.
Uxa gets way fast again.
Jaunty deb package , kernel 2.6.30rc2
Here's the tutorial.
http://www.myubuntu.ca/?p=256

Is this known to be separate issue from bug 349314? Perhaps folks here could try the test kernels in that bug and see if they resolve the problem.

Please note that this bug is related to i945 systems; if you have i965, this is not your bug.

I tried the kernel from bug 349314, it's not helping, as well as 2.6.28-12 kernel from jaunty-proposed. On the other hand, turning UXA acceleration on indeed accelerates things, but it's unstable (X freezes time after time).

$ lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
$ uname -a
Linux corner 2.6.28-11-generic #43~lp349314apw5 SMP Tue Apr 21 17:26:20 UTC 2009 i686 GNU/Linux

@Ilya: bug 349314 isn't for this chipset, so that's why it doesn't help.

The good news is that bug 314928 has a different test version of the kernel which fixes the MTRR allocation problems - maybe try that one and report back on that discussion: try "cat /proc/mtrr" on the kernel you have now,

If you are using "fixmtrr.sh" you'll need to stop using it temporarily to make this comparison. If you're NOT using fixmtrr.sh (and you don't know what I mean) then I'm pretty sure the kernel from 314928 will fix your problem.

Thank you for your advice, Zack, but this kernel doesn't solve the performance problem as well. (It does, however, change the MTRR allocation as intended.)

Repository kernel:
$ uname -a
Linux corner 2.6.28-12-generic #43-Ubuntu SMP Fri May 1 19:27:06 UTC 2009 i686 GNU/Linux
$ cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable

Kernel from bug 314928:
$ uname -a
Linux corner 2.6.28-13-generic #44~lp314928apw1 SMP Wed May 6 08:32:32 UTC 2009 i686 GNU/Linux
$ cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable
reg02: base=0x0e0000000 ( 3584MB), size= 256MB, count=1: write-combining

[kernel 2.6.30 now in karmic]

This bug was fixed in the package xserver-xorg-video-intel - 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu1

---------------
xserver-xorg-video-intel (2:2.7.99.1+git20090602.ec2fde7c-0ubuntu1) karmic; urgency=low

  * Update to git 20090602 (master branch) up to commit ec2fde7c
    - xvmc is disabled since DRI1 no longer supported
    - LP: #96991 - 3D stuff breaks with Compiz: Redirected Direct Rendering
      is needed in DRI
    - LP: #120834 - X freezes with I830WaitLpRing error when running OpenGL apps
    - LP: #337608 - X crashes in fbBlt() when using Sun Java Plugin 6 + firefox3.0
    - LP: #339555 - compiz slowmotion after Jaunty upgrade
    - LP: #363900 - X.org freezes with intel driver, no apparent trigger
    - LP: #331719 - VT switching doesn't work on Intel 915GM
    - LP: #339091 - X freezes a few minutes after resuming
    - LP: #348436 - Kubuntu: X server crash when screensaver is started (4500MHD)
    - LP: #279727 - Kubuntu: Display Corruption w/ Intel 4700MHD
    - LP: #357851 - Kubuntu: Distorted display after switching virtual desktops w/ exa
    - LP: #158415 - Front buffer dynamic resize not supported
    - LP: #324998 - x server restarts itself w/ compiz on Intel 945GM
    - LP: #355593 - after upgrade to 9.04, rotating desktop cube ran slow
    - LP: #357290 - 1 fps in 3d apps like neverball with EXA
    - LP: #360774 - Graphical Corruption with EXA on X4500
    - LP: #364126 - screensaver prefs dialog in 9.04 RC livecd leaves dirt
    - LP: #375712 - Native resolution for dell "2005fpw" monitor not listed
    - LP: #375264 - Choppy flash video and poor performance with compiz
    - LP: #349568 - Jaunty / Compiz slow and tearing on GMA 4500MHD
    - LP: #356056 - window tearing during movement on 965 (no compiz)
    - LP: #330460 - xorg shows black image/hangs with jpg in firefox
    - LP: #347587 - X asserts on pI830->batch_ptr != 0 on resume from suspend
  * Merge with Debian experimental. Remaining Ubuntu changes:
    - Add lpia architecture
    - Re-enable the patch system, add quilt to build-deps.
    - 110_quirk_hp_mini.patch: quirk (sent upstream)
    - 117_quirk_thinkpad_x30.patch: quirk (sent upstream)
  * Drop 116_8xx_disable_dri.patch. There have been fixes for 3d on 8xx
    chipsets upstream, so drop the DRI disablement so the fixes can be
    re-tested.
  * Drop 103_quirk_intel_mb890.patch. Better quirk available upstream.
    (LP: #305269)

 -- Bryce Harrington <email address hidden> Tue, 02 Jun 2009 10:47:32 -0700