Sluggish rendering since xorg 7.2 update

conn@dimension:~/bugreport$ cat mtrr-old.log
reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
reg01: base=0x3f800000 (1016MB), size= 8MB: uncachable, count=1
reg02: base=0xe0000000 (3584MB), size= 256MB: write-combining, count=1

The mtrr hasn't changed since the upgrade, in case someone suggested it. Also, I have since installed nvidia-glx on my first system (which is a Dell Dimension 1100, sorry) which exhibits the same slowness issue.

Another note: on my second system, I tried the newest xf860-video-intel from git, and it doesn't help with 2D performance at all.

same here with an ati radeon 9000 mobility

Just wondering, if for my case, could it be because the ati drivers are still compiled for xorg 7.1.1 when I am running xorg 7.2? I tried running the debian ati drivers (did not fix the problem) since it showed a newer version, but it is also compiled for 7.1.1 and not 7.2.

Thomas,

No, I don't think it's the problem. On my second system, I compiled xf86-video-intel from git using xorg 7.2 sources; here's my log:

(II) Module i810: vendor="X.Org Foundation"
 compiled for 7.2.0, module version = 1.7.4
 Module class: X.Org Video Driver
 ABI class: X.Org Video Driver, version 1.1

Performance is exactly the same.

This problem has been plaguing me ever since 7.2 hit the repos. I'm running feisty on a ThinkPad T43p with ATI FireGL V3200 using the open-source ati driver and aiglx. Beryl and Compiz are unusable.

Conn's description of the problem using Firefox and gnome-terminal apply to my machine also. I'll add that gnome-system-monitor will peg the CPU at 100% when displaying the resource graphs.

Following suggestions in this thread:

 http://www.ubuntuforums.org/showthread.php?t=372693

I first ran sudo dpkg-reconfigure xserver-xorg to create a more "generic" xorg.conf (still using ati, but no aiglx). This gave me a small but noticeable improvement.

I next restored my original xorg.conf, but disabled EXA acceleration. This has provided the most notable improvement, but still not quite as good as pre-7.2. Compiz will run without choppiness, but is somewhat flakey when rotating the cube or alt-tabbing.

My current xorg.conf is attached.

confirmed that exa slowed it down for me too, sad since XAA has stopped being developed and only EXA from now on (it is superior, not sure what is clutzing it up)

In my case, EXA or XAA had more or less exactly the same dragging performance on 3D. My card:
00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 340M] (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 99
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=68
        I/O behind bridge: 00009000-00009fff
        Memory behind bridge: d4300000-d43fffff
        Prefetchable memory behind bridge: dc000000-dfffffff
        Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-

It should be noted that this card was very well supported up untill the Xorg upgrade.

Happens here too. I'm using nvidia drivers.

Can confirm it happens with the ati (radeon) driver too, independant of using XAA or EXA.
VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)

Same problem fro intel i915 chip using i810 driver.
Beryl with aiglx was perfect before xorg 7.2 update. Now it's damn slow, even sluggish when you scroll a window.

I still can't reproduce all the symptoms myself but confiming since others can. For instance on my work desktop (Core2duo, Nvidia 7950, binary driver) everything just works (installed it 30min ago), but on my home desktop (XP3000+, Radeon8500, free driver) I can see the window minimize -action being slower.

..and it seems that the intel folks have been hit the most. You'll get a new driver soon (1.6.5->1.7.4), so maybe that helps.

I have this problem with both the nvidia and nv driver so I don't think this is driver related, but rather a problem with the xserver. The nv driver uses XAA while nvidia has its own NAA so I don't think the acceleration architecture is at fault either.

Not only is minimizing a window, or fading the screen for gksu slow but the mouse also lags when doing it and gnome-system-monitor shows a peak in CPU usage. I wonder why other distributions with xorg 7.2 don't have this problem? Perhaps you could try readding all fedora patches to see if it helps?

Timo,

Since the new updates (xserver-xorg-video-nv 1.2.2.1-0ubuntu1, xserver-xorg-video-i810 1.7.4-0ubuntu1), both of my systems still exhibit slow 2D rendering (using the nvidia, nv and i810 drivers). I tried re-building xserver-xorg using the only most innocuous patches (see attached "series" from debian/patches/) - performance was just as bad, so perhaps they aren't the source of this problem.

Are there any LiveCDs (from other distros) using xorg 7.2 that I can test on my systems?

Timo,

Upon further investigation I think I may have found the real culprit - metacity.

As I had kdebase installed on my system, I decided to try "kwin --replace" within GNOME, and performance is back to normal! Maybe the problem is specific to metacity and not xorg at all (a reasonable hypothesis, as when I checked the feisty-changes list, metacity and xorg-server were updated within very soon of each other).

Anyone with KDE installed, try it out! Just make sure you go into kcontrol and in Desktop, Window Behavior, Moving, disable "Animate minimize and restore", then try kwin. Minimize and maximize some apps and hopefully you'll notice that it's instantaneous like before. Tested & verified on both my systems with nvidia, nv and i810 drivers.

In light of this, I'm reassigning/adding to metacity.

With the latest updates, things are snappy again. Quite snappy indeed. But the only problem is that I'm suddenly loosing input focus on gnome-terminal and xterm windows.

Just as suddenly it comes back, at a random time...

I don't think this has anything to do with metacity.

Well, it just looks like I can execute commands, but the characters don't appear, and the window "looks", but isn't, frozen.

Maximized apps also get random weird factors.

It's actually worse than that. Windows randomly stop being updated, focus is lost (also on run command dialog), etc...

Cyclops,

It's still feasible that xorg is to blame, but it sounds like metacity could be stealing focus from your apps, or it could be an EXA rendering bug. Try changing back to XAA to see if it helps, and try kwin (or another WM besides metacity) to see if this behaviour continues with a different window manager.

Hmm,

I downgraded metacity, metacity and metacity-common to 2.16.3-0ubuntu2 from Edgy, but it's still slow. Perhaps there's certain rendering paths that are slow in xorg that metacity happens to use; all I know is that performance is excellent with kwin. Maybe I'll try some x11perf tests on my system and compare them against a Herd 4 LiveCD to see any differences.

Hi,

I ran a complete set of x11perf on first system (Celeron 2.8Ghz w/NVIDIA GeForce FX 5200 using nv driver), using the herd 4 livecd, and the version installed on my drive (herd 5 with updates, including the new xorg 7.2 drivers). I used the same xorg.conf, disabled screensavers and monitor poweroff, and had no other processes running for these tests. I'm attaching the results, and system logs tarred together.

As you can see from the output, some operations with xorg 7.2 are up to 5x slower than xorg 7.1.1; in particular see 1x1 fills, "X protocol NoOperation", and nearly all window operations.

I can perform these benchmarks on my laptop (Intel 82855GM) if you wish, but I'm pretty sure we'll see a similar pattern (especially regarding window operations), as I'm seeing the same sluggishness on both systems using xorg 7.2.

Thank you for your work on that. Could you open a bug upstream?

Hi Sebastien,

I've opened a bug there, but I focused more on performance profiling. I'll expand on it and explain the problem in detail (I had just linked to launchpad).

Here it is: https://bugs.freedesktop.org/show_bug.cgi?id=10173

A couple of things/differences I noted whilst reading through your logs:
- The Xorg.0.log from Herd5 mentions it can't initialize the GLX extensions, since it is using the Nvidia libglx.so
Might this be the cause?
- In the Xorg.0.log from Herd5 AIGLX is disabled (since it can't load the GLX module)
- The Xorg.0.log from Herd5 mentions it loads a vm86 module (libvm86.so), which isn't loaded in the Herd4 log.

It might be good to try to keep the config the same, so the comparison is fair (though the stock config might be different).

disturbedsaint,

Thanks, let me address your points:
1. That's right, nvidia-glx is installed on my system and so the nv driver can't initialize GLX.
2. Ditto, see above.
3. This may be a symptom of the above too, so I don't know.

In light of this, I'm running the benchmarks again, this time using the herd 5 livecd instead, and have copied xorg.conf from herd 4. I checked the resulting logs and libvm86.so is still being loaded; it's because of the new xorg build, I believe. I ran a quick test, "x11perf -umove" - here's the results (herd 4 livecd vs herd 5 livecd):

514000.0 186000.0 ( 0.36) Moved unmapped window (4 kids)
503000.0 185000.0 ( 0.37) Moved unmapped window (16 kids)
496000.0 184000.0 ( 0.37) Moved unmapped window (25 kids)
485000.0 184000.0 ( 0.38) Moved unmapped window (50 kids)
472000.0 182000.0 ( 0.39) Moved unmapped window (75 kids)
465000.0 181000.0 ( 0.39) Moved unmapped window (100 kids)
452000.0 175000.0 ( 0.39) Moved unmapped window (200 kids)

As you can see, these results reflect my initial benchmarks on my installed herd 5 system. I'm running the full set right now to be sure, and if anything significantly changes I'll post them here.

Hi,

After some troubleshooting I have identified the precise source of this sluggishness. When I downgraded xserver-xorg-core sluggishness persisted, so I experimented with downgrading other packages selectively, and found the problem to be with libx11-6 (1.1.1-1ubuntu1). After downgrading to version 1.0.3-4ubuntu1 from the Herd4 alternative cd, performance is back to normal.

FYI I installed fedora 7 test2 in parallel with feisty. It has the same versions of metacity and xserver but it doesn't show this problem. But libX11 is still at version 1.0.3 in fedora while feisty has 1.1.1. Perhaps xcb is the problem?

nxsty,

I would say xcb definitely is to blame. I booted up Herd 4, ran "sudo apt-get update", "sudo apt-get install libx11-6", and libxcb-xlib0 and libxcb1 were installed as new packages. Upon restarting gdm, I could see the sluggishness present.

Until the bug is fixed, any tips on how to properly go back to the old version? Good work pinpointing where the problem was.

Hi Thomas,

What you can try is to downgrade libx11-6 and libx11-data to version 1.0.3 from the Herd 4 alternative cd (I'm not sure where to get obsolete packages from Feisty). I've grabbed them from my cd and uploaded here in case you want to try:

http://www.zshare.net/download/oldx11-6-tar-bz2.html

sudo dpkg -i oldx11-6/libx11*

The packages should downgrade fine, but when you next try to use apt-get it will complain about breakage, and offer to upgrade these packages again. I suggest you try it nevertheless; downgrade the packages, restart X and test your system's minimizing speed, then upgrade afterwards with apt-get. At least you'll be confirming the bug, and then something better can be done by the developers.

I am having the same problem.
I'll try the downgrade tonight and post the result.

Thanks for the good work on that guys.

I had this problem, but downgrading as suggested really got things going.

Just did the downgrading and things work much better. So, apparently those packages really are the problem.
Next step is to figure out what's happening !

Thanks again for looking into that.

Finding old packages in Launchpad is really annoying:

http://librarian.launchpad.net/5509177/libx11-6_1.0.3-4ubuntu1_i386.deb
http://librarian.launchpad.net/5509176/libx11-data_1.0.3-4ubuntu1_all.deb

Downgrade helped metacity quite a bit, back to normal speeds, although compiz and beryl both seem a bit sluggish still, anyone else notice this (mainly when scrolling web pages, uses 100% cpu and is very slow)? Still using the same xorg.conf as i posted before. Thanks again guys.

nevermind, http://bugs.beryl-project.org/ticket/1 is the bug, seems be related to exa acceleration

Slow performance when EXA is enabled is not what this bug is about, see bug #88696 instead.

Though I'd like to know if downgrading libx11 helps to improve performance with EXA..

yes, I realize that, i was just commenting on my comment, sorry for the confusion. And to answer your question timo, yes, it does.

Using Fiesty with an ati RV350 NP, 'ati' driver, and XAA.

Switching to EXA did not make any difference
sudo dpkg-reconfigure xserver-xorg did not make any difference

Downgrading libx11* worked

A workaround might be to compile libX11 with "--without-xcb". At least then we'll be sure if it's really xcb that's the problem and not any other change in libX11 1.1.

nxsty,

I've tried to modify the deb source and rebuild without xcb, but it failed building and I couldn't test. Feel free to try yourself, but one thing to note: you need to use "--with-xcb=no", the line you typed above has no effect (I already tried).

Martey,

It was an understatement to say that "finding old packages in Launchpad is really annoying". How do you do it?

I want to downgrade also libx11-dev to stop aptitude complaining.

Conn:

Actually both work, you can see a status message when configure completes that tells if xcb is disabled. It builds but debconf wants to package the xcb files intead of xlib and fails as they're missing. It might work to use some files from libx11-1.0.3/debian/ and just change the version but I'll leave that to someone who better understand how debbuild works. :)

Bruce: I use Søren Hansen's tricks: http://www.warma.dk/blog/article/68/

Timo,

This bug is still present on my systems, have you gotten any closer to isolating the problem? Have you tried building libx11-6 without xcb support? I tried, but couldn't build the debs due to the script expecting the xcb files to be present.

Another note regarding the sluggishness: the slowdown is not just visual (i.e. metacity's animations).

Steps to reproduce:
1. Open a firefox window, maximized.
2. Click on the minimize button of firefox's window, and immediately move the mouse in a circular or zig-zag motion.

It appears that minimizing and maximizing applications affect even the mouse, causing interruption/jerkiness in movement.

Also, I noticed when using tsclient to make a vnc or rdp connection to another connection, if I switch from fullscreen to windowed, there is often a very large delay when switching modes (~2 secs to render the window), whereas using the downgraded packages, there's no delay at all.

Confirming that downgrading to libX11-6 and libX11-data to version 1.0.3-4ubuntu1 solve this issue.

Had issue - Fixed with downgrade.

Same here; feels much! better after downgrade (VIA onboard grafics, VIA driver, very 2D).

I mainly notice the sluggishness in OpenGL-apps (compiz etc). Downgrading libx11 from 1.1.1 to 1.0.3 - like suggested above - did not improve the situation for me. The machine is question is a laptop with i915-based graphics.

Mirco,

Your issue is not related to this bug, please see here: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88918

I suggest you experiment with the INTEL_BATCH variable, e.g. "INTEL_BATCH=1 glxgears", and compare it with normal glxgears performance. Please don't reply in this bug, though, as it's a separate issue.

Ok, I managed to build libx11 without xcb:

http://users.tkk.fi/~tjaalton/dpkg/

at least on my laptop (savage) the performance is much improved.

Timo,

By coincidence Michel Danzer and I were experimenting with packages he built sans xcb, see the upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=10173

What we discovered is that it's definitely caused by xcb, and it's a client-side issue - respawning metacity after changing the packages will trigger the slowness/speedup, without an X server restart.

Timo,

I tried your libx11-packages-without-xcb (thanks to Mithrandir for pointing me to them) and I too can see a clear improvement.

(this is on a P3@666MHz and a Riva TNT2 Pro using nvidia-glx-legacy driver)

I tried Timo's libx11 packages without xcb and I can confirm improvement as well.

Hello, I´m new to linux and when I try to use the libx11-6 package I get this error:

Error: Dependency is not satisfiable: libc6

And when I tried: sudo dpkg -i oldxll-6/libxll*

in the terminal I got this error:

dpkg: error processing oldxll-6/libxll* (--install):
cannot access archive: No such file or directory
Errors were encountered while processing:
oldxll-6/libxll*

I was able to use GDebi Package installer to install the libxll-data_1.0.3-4ubuntu1_all.deb but not the libxll-6_1.0.3-4ubuntu1_i386.deb it gives me the dependency error.

Hopefully this is a simple problem that can be attributed to inexperience. If anyone has any insight I would appreciate it!

Thanks,

-David-

Are you running Edgy? This bug only appears on Feisty, and the package
only installs on Feisty.

I just witnessed an odd behaviour. When I unplug the power-cable from my i915-based laptop and the CPU-throttling kicks in (going from 2 GHz to about 800 MHz). Once that happened all the sluggish drawing performace of OpenGL- and cairo-based programs gets smooth as silk again. I'm running a up-to-date Feisty without downgraded libx11. I've currently no idea what's going on and causing this behaviour, but this might be a hint for more xorg/kernel savvy people here to solve the issue.

I noticed that high CPU usage improves the drawing performance of OpenGL programs.

I am running Edgy Eft as far as I know but I'm having the same scrolling issues.

-David-

David,

This bug is only on Feisty, and has nothing to do with scrolling. It's slowness when minimizing/maximizing windows, and switching between windows.

Tnx TIM for your link. Works much better now. I was begining to wonder what I had done to make GNOME so sluggish

seems to be fixed with the latest upgrades! Thank you

indeed, fixed it by this upload

 libx11 (2:1.1.1-1ubuntu2) feisty; urgency=low
 .
   * Don't build with libxcb, since it causes performance regressions on
     some X clients. (LP: #88815)

I'll keep the xcb component open, though.

Good work Timo, the sluggishness is now gone on all my systems. What are the implications of building without xcb, are we losing functionality somewhere? Nevertheless, this issue is reported upstream so there's a good chance it will be fixed in the xcb component too.

Currently there are no other component which depends on xcb, and no-one has reported of any regressions so we should be safe for Feisty.

I just updated to the new libx11-6 package and rebooted, but my performance is still horrible when I am using EXA (i use the "radeon" driver with an ATI Radeon 9600 XT). Could this be a driver bug?

EXA
Lots of ppl get sluginesh with EXA.
Heres a bug report sbout it. Suggest U ask there:
https://bugs.launchpad.net/xorg-server/+bug/88696

The x11perf results are a known issue, but not obviously significant. (How many apps do you have that use the X NoOperation request?) Despite our belief that the "slow" requests have almost no impact on real applications, we are working on improvements in this area.

However, I believe the bug you actually experienced with metacity is identical to https://bugs.freedesktop.org/show_bug.cgi?id=10644, which Josh Triplett and I believe is fixed in libX11 git.

Can you confirm that current libX11 from upstream git fixes metacity's performance for you?

Assuming it does, could the libX11 maintainer for Ubuntu please stop building libX11 without XCB?

For people with intel graphics cards xgl could be the problem. I ad problems with realy bad graphis performance using a 915 intel card but then i followed the advise in this post:

http://ubuntuforums.org/showpost.php?p=3416144&postcount=15

I just uninstalled the xserver-xgl package and then everything worked just fine. According to the post above this is not a bug, just a performance issue...

I just recently installed Ubuntu 8.4 (8.04?) with Gnome and noticed the problem. After seeing someone’s suggestion with KDE, I tried this:
I went to the System menu, selected Preferences - Appearance, clicked the Visual Effects tab and selected “None”. It got rid of the sluggishness for me.