Description of problem: Enabling compiz on a Lenovo X61 thinkpad makes graphics performance extremely slow. Examples of this slowness: - scrolling a website with firefox lags behind for at least 0.5 seconds. - menu effects are slow and you can see them being built up The system reports an Intel 965GM chipset. Version-Release number of selected component (if applicable): compiz-0.7.2-3.fc9.x86_64 xorg-x11-drv-i810-2.2.1-22.fc9.x86_64 xorg-x11-server-Xorg-1.4.99.901-26.20080415.fc9.x86_64 How reproducible: Always Steps to Reproduce: 1. Install F9 preview release on Lenovo X61 thinkpad. 2. Enable compiz with System -> Preferences -> Look and Feel -> Desktop Effects -> Enable Desktop Effects 3. System graphics become very slow Actual results: Slow graphics Expected results: Graphics should be at least as fast as when compiz is not enabled. Additional info: Under F8 the performance of compiz was adequate.
Created attachment 303899 [details] xorg.conf
Created attachment 303901 [details] Xorg.0.log
A small update: I have tried compiz with the 2.2.1-24 driver. The speed is much better and things like menu effects are almost as fast as the non-compiz case. The speed of scrolling a large Firefox window up and down however is still quite slow-- too slow to be usable in my perception.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I am using the 'intel' driver with a similar chipset: Intel Corporation 82G965 Integrated Graphics Controller rev 2, Mem @ 0xffa00000/1048576, 0xd0000000/268435456, I/O @ 0x0000ec00/8 Things like scrolling in firefox (even worse when 'smooth scrolling' was turned on) and selection of icons in nautilus/the desktop is extremely slow. (Barely useable) Initially I thought the video memory was not being reserved correctly, but there is 266Mb (the default) being reserved for the on board graphics. 3D animations with compiz are relatively fast though. My packages are from Fedora 9 release: compiz-0.7.2-3.fc9.x86_64 xorg-x11-drv-i810-2.2.1-24.fc9.x86_64 xorg-x11-server-Xorg-1.4.99.901-29.20080415.fc9.x86_64 In Fedora 8 things were much more useable. As both i810/intel drivers are in the same package, I am not filing a new bug.
Hello! I'd like to verify this bug for the "intel" driver. I was running Fedora 8 + compiz-fusion on a T61 ThinkPad with the Santa Rosa chipset (GM965 graphics). Performance is fine until I enable Desktop Effects, and then it goes down the drain. Just to be sure, I created a new partition on my hard drive and installed Fedora 8 alongside the new F9. My home directory is on its own partition, so I have the same home directory (and therefore the same Gnome settings) for both F8 and F9. Here is my glxgears performance under F9, kernel 2.6.25.3-18.fc9.x86_64: [me@localhost ~]$ glxgears 98 frames in 5.5 seconds = 17.936 FPS 60 frames in 5.5 seconds = 10.926 FPS 60 frames in 5.5 seconds = 10.959 FPS 60 frames in 5.6 seconds = 10.740 FPS 60 frames in 5.8 seconds = 10.386 FPS XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 792 requests (36 known processed) with 0 events remaining. Here is my glxgears performance under F8, kernel 2.6.23.1-42.fc8: [me@localost ~]$ glxgears 5256 frames in 5.0 seconds = 1050.917 FPS 5340 frames in 5.0 seconds = 1067.914 FPS 5340 frames in 5.0 seconds = 1067.556 FPS 5340 frames in 5.0 seconds = 1067.778 FPS 5340 frames in 5.0 seconds = 1067.561 FPS 5340 frames in 5.0 seconds = 1066.627 FPS XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" after 65150 requests (64669 known processed) with 0 events remaining. That's an almost 99% reduction in performance. Not to mention, the other applications have issues...Firefox paints quite slowly, and gnome-terminal occasionally can't even keep up with my typing. Ouch ;) . What information can I supply that would be useful to help identify this problem? Thanks, -- Sean
Oops, there's a typo in my comment #6: The first paragraph reads "I was running Fedora 8 + compiz-fusion on a T61", but it should read "I am running Fedora 9 with desktop effects enabled on a T61...". Sorry!
Like Sean, I also have very limited performance in glxgears. I don't have F8 available to test, but with F9 I can show compiz and no compiz results: [With-out Compiz running] $ glxgears Failed to initialize TTM buffer manager. Falling back to classic. 676 frames in 5.0 seconds = 135.172 FPS 667 frames in 5.0 seconds = 132.757 FPS 630 frames in 5.0 seconds = 125.873 FPS 643 frames in 5.0 seconds = 128.386 FPS 671 frames in 5.0 seconds = 134.069 FPS 639 frames in 5.0 seconds = 127.680 FPS 630 frames in 5.0 seconds = 125.953 FPS 661 frames in 5.0 seconds = 132.151 FPS [With compiz running] $ glxgears 81 frames in 5.1 seconds = 15.781 FPS 99 frames in 5.2 seconds = 19.007 FPS 120 frames in 5.2 seconds = 23.159 FPS 47 frames in 5.0 seconds = 9.385 FPS 12 frames in 6.4 seconds = 1.870 FPS 88 frames in 5.7 seconds = 15.501 FPS 209 frames in 5.0 seconds = 41.799 FPS 441 frames in 5.9 seconds = 74.857 FPS 550 frames in 5.0 seconds = 109.886 FPS 596 frames in 5.0 seconds = 119.070 FPS 352 frames in 5.0 seconds = 69.866 FPS 485 frames in 5.0 seconds = 96.940 FPS 507 frames in 5.0 seconds = 101.377 FPS The higher frame-rates are possible after minimizing all other windows (and the really slow rates are those when the process of minimizing happens).
I also have ThinkPad X61 with intel video card and I have the same problem. However I think compiz has nothing to do with this. Even when I am running metacity (no compiz), glxgears is giving me about 150 FPS. It used to be over a 1000 FPS under Fedora 8. So this bug is probably related to intel video driver. I can also confirm that if I enable compiz Firefox scrolling becomes very slow.
*** Bug 446370 has been marked as a duplicate of this bug. ***
Option "AccelMethod" "XAA" speed up things... but looks like a workaround, not the real fix...
XAA makes for exmple graphics heavy java (swing) apps useable on F9 with G965. Thanks, jpg. I can report that the latest released upstream driver (2.3.1) doesn't fix this. The upstream bug report is over at http://bugs.freedesktop.org/show_bug.cgi?id=13389 and a fix is apparently in the works in a separate branch but I've seen no definitive success reports with that code as of yet.
Looks like https://bugzilla.redhat.com/show_bug.cgi?id=445681 is related
some of my lasts perfomance problems go away after I lower swappiness settings... sudo sysctl -w vm.swappiness=10 don't know if this is related... but works here...
I've now had time to look into this a bit more, and it turns out that the branch that gives me good performance is compiled as a part of the xorg-x11-drv-i810 under the name intel_batchbuffer. The intel driver is actually a small wrapper that selects either intel_batchbuffer or intel_master. Unfortunately the option parsing code in intel_stub.c seems broken, (setting the "intel-batchbuffer" option to "true" has no effect, except a message from the intel_master driver telling me that the option was unused) so I had to recompile intel_stub.c:getDriverName() to always return "intel_batchbuffer" to test it. Once I did the FPS value measured by glxgears went from ~100fps to ~1000fps and my desktop is as snappy as ever.
Snappy as ever was probably an overstatement. Trying around a bit more it seems like scrolling in firefox, working in my java IDE and overall desktop experience is kind of slow compared to F8.
Does setting "MigrationHeuristics" to "greedy" improve things?
FYI - The slow performance of the "Desktop Effects" option on my machine continues to occur with the recently released update package: xorg-x11-drv-i810-2.3.2-2.fc9.x86_64
(In reply to comment #18) > FYI - The slow performance of the "Desktop Effects" option on my machine > continues to occur with the recently released update package: > > xorg-x11-drv-i810-2.3.2-2.fc9.x86_64 I also can confirm that the problem is still persistent and should be fixed before xorg 1.5.
*** Bug 457669 has been marked as a duplicate of this bug. ***
intel-batchbuffer (activated by setting option in ServerLayout but not in Device Section), update to xorg-x11-drv-i810-2.4.0, enabling XAA instead of EXA, PageFlip + TripleBuffer does not change anything. I still get only 140-150fps with glxgears :(
seems to be a MTRR issue here; there was | reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 Reducing this to 512MiB | echo -e "disable=0" > /proc/mtrr | echo -e "base=0xc0000000 size=0x20000000 type=uncachable" > /proc/mtrr and X11 setting | reg06: base=0xe0000000 (3584MB), size= 256MB: write-combining, count=1 gives me now | 4062 frames in 5.0 seconds = 812.210 FPS
The comment above resolves the issue on my system too. My system has 4GB of RAM and it had two MTRRs that included the framebuffer area at 0xe0000000. One MTRR made the first 4GB of memory write-back, and a second MTRR a segment at 3GB uncacheable. I had to shrink both areas before I was able to add an MTRR to enable write combining of the 256MB frame buffer at 0xe0000000.
The MTRRs above cause my system to lock up, but a different set of MTRRs works. The MTRRs below are from http://overlap.org/2008/08/06/fix-your-mtrr-on-gentoo-with-thinkpad-x61-intel-x3100/ but work with F9 (all updates) on a Lenovo X61s (Intel GMA X3100). glxgears goes from about 140fps to 600fps, and more importantly things like firefox scrolling go from painful to fast and smooth. echo "disable=0" >| /proc/mtrr echo "disable=1" >| /proc/mtrr echo "disable=3" >| /proc/mtrr echo "disable=4" >| /proc/mtrr echo "disable=5" >| /proc/mtrr echo "disable=2" >| /proc/mtrr echo "base=0x00000000 size=0x80000000 type=write-back" >| /proc/mtrr echo "base=0x80000000 size=0x40000000 type=write-back" >| /proc/mtrr echo "base=0xC0000000 size=0x10000000 type=write-back" >| /proc/mtrr # Video Card: # 0x10000000 was the value for size trying for echo "base=0xE0000000 size=0x10000000 type=write-combining" >| /proc/mtrr # High memory area echo "base=0x100000000 size=0x40000000 type=write-back" >| /proc/mtrr (all pasted from the script up on overlap.org above - credit where credit's due)
The problem still exists in Fedora 10 Preview. With compiz enabled, and with the default MTRRs, glxgears performance is better and scrolling firefox is too, but stepping through windows with ALT-TAB is still very slow. Resolution is the same: shrink the system MTRRs so that the framebuffer can be made write-combining. In my view this is something the Intel driver should do.
Still exists in F10 released. Applying the above tweaks gives about 100 extra fps from glxgears, but still in the 300fps range. Lenovo x61 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
Bug possibly gone in F10... This is Sean again. I just installed Fedora 10 x86_64 from the installation DVD on the same machine for which I confirmed this bug in comment #6, above, and there now seems to be no problem :) :( ?? . The machine is a Lenovo T61 ThinkPad with the GM965 integrated graphics card and 4GB of memory. Here are the relevant lines from lspci: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) and my /proc/mtrr: reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 reg01: base=0x13c000000 (5056MB), size= 64MB: uncachable, count=1 reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg03: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 reg04: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 reg05: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 I installed the Gnome desktop from the DVD, went through the firstboot configuration, logged in, went to System > Preferences > Look and Feel > Desktop Effects and clicked "Enable Desktop Effects", "Windows Wobble when moved" and "Workspaces on a cube". I verified that compiz was working then opened a gnome-terminal and ran glxgears. My current glxgears output is back to the performance I was getting under F8 and 2.6.23.1-42.fc8: 5438 frames in 5.0 seconds = 1087.441 FPS 5558 frames in 5.0 seconds = 1111.480 FPS 5560 frames in 5.0 seconds = 1111.894 FPS 5564 frames in 5.0 seconds = 1112.609 FPS 5555 frames in 5.0 seconds = 1110.910 FPS Compiz is smooth, Firefox scrolls smoothly, ALT-TAB is working great, and all the other applications seem to be living happily ever after. This is great news for me (thank you F10 and upstream teams!), but it seems to contradict the other bug reports (such as Dave's comment #26). Please shoot me an email or post a comment here on the bug tracker if I can provide any helpful information.
Hi, I seem to be facing this bug after upgrading from F9 x86_64 to F10 x86_64 (final). Under F9, performance was good. Now, after the upgrade to F10 I have slow 3D performance. Both compiz effects and Quake3 are noticeably slower, though not completely unusable. The Laptop is an HP Compaq nx7400 (Intel Core 2 Duo 1.8GHz, Intel 945 integrated Graphics chipset, 2GB RAM. lspci says : 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) driver : xorg-x11-drv-i810-2.5.0-3.fc10.x86_64 xorg-x11-server-Xorg-1.5.3-5.fc10.x86_64 cat /proc/mtrr : reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0xf7f800000 (63480MB), size= 8MB: uncachable, count=1 reg02: base=0xfeda0000 (4077MB), size= 128KB: uncachable, count=1 reg03: base=0xe0000000 (3584MB), size= 256MB: write-combining, count=1 $ glxinfo | grep direct direct rendering: Yes # dmesg | grep drm [drm] Initialized drm 1.1.0 20060810 [drm] Initialized i915 1.6.0 20080730 on minor 0 $ glxgears 1587 frames in 5.0 seconds = 317.246 FPS 1640 frames in 5.0 seconds = 327.967 FPS 1641 frames in 5.0 seconds = 328.168 FPS IIRC, I used to get ~1000 FPS under F9, though I can't be completely sure. Hope this helps to resolve this issue, Regards Arif
I have also noticed "slowness" with compiz enabled; dragging windows around with the "wobble" effect produces a weird situation in which I release the mouse button and the window keeps going on. My setup: [pedro.lamarao@localhost ~]$ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) [pedro.lamarao@localhost ~]$ cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1 reg01: base=0x3f800000 (1016MB), size= 8MB: uncachable, count=1 reg02: base=0x3f700000 (1015MB), size= 1MB: uncachable, count=1 reg03: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1 [pedro.lamarao@localhost ~]$ glxinfo | grep direct direct rendering: Yes [pedro.lamarao@localhost ~]$ dmesg | grep drm [drm] Initialized drm 1.1.0 20060810 [drm] Initialized i915 1.6.0 20080730 on minor 0 [pedro.lamarao@localhost ~]$ glxgears 1845 frames in 5.0 seconds = 368.945 FPS 1885 frames in 5.0 seconds = 376.863 FPS 1867 frames in 5.0 seconds = 373.373 FPS I will test glxgears in Fedora 9 today.
On Fedora 9: [pedro.lamarao@localhost ~]$ glxgears 6138 frames in 5.0 seconds = 1227.559 FPS 6213 frames in 5.0 seconds = 1242.474 FPS 6080 frames in 5.0 seconds = 1215.911 FPS
Hello, I have exactly the same problem under F10 with my laptop (Maxdata 4510IW). I had also good performance under F9, but now all OpenGL applications... e.g quake3 ~15fps (F9 ~90 fps). Ok, my configuration: lspci | grep VGA: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) rpm -qa xorg-x11-drv-i810*: xorg-x11-drv-i810-2.5.0-3.fc10.i386 cat /proc/mtrr: reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x7f700000 (2039MB), size= 1MB: uncachable, count=1 reg02: base=0x7f800000 (2040MB), size= 8MB: uncachable, count=1 reg03: base=0xc0000000 (3072MB), size= 256MB: write-combining, count=2 glxinfo | grep direct: direct rendering: Yes dmesg | grep drm: [drm] Initialized drm 1.1.0 20060810 [drm] Initialized i915 1.6.0 20080730 on minor 0 glxgears: 1508 frames in 5.0 seconds = 301.552 FPS 1526 frames in 5.0 seconds = 305.187 FPS 1506 frames in 5.0 seconds = 301.081 FPS (F9 about 1000 FPS)
*** Bug 474496 has been marked as a duplicate of this bug. ***
*** Bug 469818 has been marked as a duplicate of this bug. ***
I have fedora 10 installed on Thinkpad R61 with same intel graphics. I've noticed behaviour described above. But... - Firstly everything is 0k, compiz enabled and glxgears gives me something about 1300 FPS - Then (after few minutes or hours) graphics slow down terribly (all scrollings, and moving windows, even mouse pointer), it's still usable but after few minutes it definitely freeze. - It's not only problem of compiz(glx), it affects metacity and even openbox as well!!! - Now I am using xfce with xfwm4 as wm, and freezes are gone.
My few cents: - compared the mtrr on latest Knoppix DVD (with excelent 3d performance) vs FC10 and they are exactly the same... (tried glxgears and compiz) - setting Option "Tiling" "False" speeds up glxgears and other simple 3D applications (speedup factor ~ 8x) but google earth performance (if it can be called that) is still poor (0.5 fps, I'd say) - this is not only a laptop problem (as someone may conclude from the meniton of laptops in this report) I guess this has something to do with tiling being disabled (X complains: tiling rejected by kernel) HW: Intel BLKD945GCNL Motherboard From what I've seen on the ubuntu thread this looks like a mesa problem... which would AFAIK require a kernel update... Is someone looking into this? Will this be fixed or should we just give up on using 3D on intel GMA 950?
Yes, it looks it has something to do with what Samo mentions. I have an HP computer with 915G chipset which worked really fine with Fedora 7 and beryl; after upgrade to F10, visual effects were way slower. I changed to KDE 4.2 instead of beryl, but I don't think it has any influence; it's rather that the xorg driver doesn't catch all hardware accel. features. I get the following in my Xorg.log: (**) intel(0): Framebuffer compression disabled (**) intel(0): Tiling enabled (==) intel(0): VideoRam: 262144 KB (II) intel(0): Attempting memory allocation with tiled buffers. (EE) intel(0): Failed to set tiling on front buffer: rejected by kernel (EE) intel(0): Failed to set tiling on back buffer: rejected by kernel (EE) intel(0): Failed to set tiling on third buffer: rejected by kernel (EE) intel(0): Failed to set tiling on depth buffer: rejected by kernel (II) intel(0): Tiled allocation successful. (II) intel(0): [drm] Registers = 0xcfd00000 (II) intel(0): [dri] visual configs initialized (II) intel(0): Page Flipping disabled (II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 In another similar machine with a NVIDIA 8600 card, identical configuration, performance is superb.
Hmmm... it looks like it's a kernel issue. I've found this in dmesg output: [drm:i915_gem_detect_bit_6_swizzle] *ERROR* Couldn't read from MCHBAR. Disabling tiling. http://www.mail-archive.com/kernel-testers@vger.kernel.org/msg01868.html
Looks like this is fixed under Fedora 11
I'm running F11 on a T60 and I still find parts of compiz to to slow, particularly alt-tab switching. Better perhaps than when I first experienced the bug, but the issues are still sufficient to keep be from using compiz.
Got a report from a friend that tried F11 live CD on GMA450 and he says Desktop Effect work. He also tried Google Earth and he got decent performance.
Trying to get a better handle on this. Summarizing: Reported problems: • slow scrolling a website with firefox lags behind for at least 0.5 seconds. • menu effects are slow and you can see them being built up • selection of icons in nautilus/the desktop is extremely slow. • dramatically reduced glxgears performance • stepping through windows with ALT-TAB is very slow • expose feature slow • strange window drag inertia? (comment#29) • freeze on suspend/resume (from dup bug 474496) • slow window fade in/out (from dup bug 469818) • gnome-terminal occasionally can't even keep up with my typing (comment#6) Possible workarounds: • Option "AccelMethod" "XAA" • lower swappiness settings... sudo sysctl -w vm.swappiness=10 • intel_batchbuffer (comment#15) • reduce MTRR (comment#22, #23, #24) • Option "Tiling" "False" (comment#35) On my system (Thinkpad T60, 945GM) with F11 I am not seeing most of the above problems. The ones I am still seeing are: • stepping through windows with ALT-TAB is very slow • expose feature slow With out effects, glxgears gives about 415 FPS With effects, glxgears is slowed only a little to about 380 FPS However, if I trigger the expose feature the fps drops to about 30 And during alt-tab switching it drops to about 10. I haven't tried the workarounds yet...
Hi Mike! I've got a similar system to yours (Thinkpad T61, GM965) with a fresh F11 x64_86 install. I've only been using it a few days, but so far I'm extremely pleased with desktop effects performance and haven't experienced any of the issues I had when we were all using F9 (as I reported in comment#6, etc). Under F10, I had over 1000 FPS with glxgears, but under F11, I have only 450 FPS (similar to your FPS). Interestingly, though, my desktop effects seem /smoother/ under F11 than F10. For example, when using the "ring" switcher, F10 would slow noticeably with five or six windows to switch. Under F11, I can smoothly ring-switch ten different windows without noticing a performance decrease. I was trying to determine whether my system had the same "expose feature is slow" symptom that you mention in comment#41 . I wasn't sure whether you meant the compiz "expo" plugin, or the compiz "scale" plugin (which looks like OS X "expose"). In either case, both of these plugins seem to work smoothly on my install with ten or a dozen open applications. Would it be useful to compare my apparently happy system with your apparently unhappy system to see if perhaps we could find a difference? Or would the difference in VGA controllers (945 vs 965) invalidate the comparison? Feel free to send me an email or reply here if you think I can provide anything useful!
For people that still have issues, please remove or move your /etc/X11/xorg.conf file away. It should be fine with the default autodetected configuration. If this does not help try disabling KMS (or enabling it if you have it disabled).
I've experienced a GL performance regression with an Intel 915GM (Thinkpad T43) going from FC9 -> FC11. I get about 300 fps with glxgears, and compiz effects are unusably slow (especially alt+tab and expose). Turning off KMS and going to EXA and XAA actually make the problem worse (glxgears performance drops in half). Removing my xorg.conf and using the server's autoconfiguration does nothing, nor does adding the explicit no tiling option to xorg.conf. Here's a copy of my mtrr configuration; I'm not sure whether it's correct or not: reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back reg01: base=0x07f700000 ( 2039MB), size= 1MB, count=1: uncachable reg02: base=0x07f800000 ( 2040MB), size= 8MB, count=1: uncachable reg03: base=0x0b0000000 ( 2816MB), size= 256MB, count=1: write-combining
I can confirm this issue on a default Fedora 11 installation. Actually present in fedora (for me) since fedora has desktop effects which was since Fedora 8? Note that this bug makes my firefox unusable slow if i turn on desktop effects. Also note that on ubuntu (same pc) it runs just as fast as without desktop effects and is never choppy.. so it is possible.
(In reply to comment #45) > Note that this bug makes my firefox unusable slow if i turn on desktop effects. > Also note that on ubuntu (same pc) it runs just as fast as without desktop > effects and is never choppy.. so it is possible. Ubuntu is behind us, so they have (very roughly speaking) the same stuff we had in Fedora 10. Would running with nomodeset help?
(In reply to comment #46) > (In reply to comment #45) > > Note that this bug makes my firefox unusable slow if i turn on desktop effects. > > Also note that on ubuntu (same pc) it runs just as fast as without desktop > > effects and is never choppy.. so it is possible. > > Ubuntu is behind us, so they have (very roughly speaking) the same stuff we had > in Fedora 10. Would running with nomodeset help? That is short sighted. Let me say it a little different. Ever since it's _broken_ in fedora it's working fine in ubuntu. So in distribution versions: Fedora 8 : broken Fedora 9 : broken Fedora 10 : broken Fedora 11 : broken (going to guess ubuntu versions a bit but it's always been working fine so doesn't mather much) Ubuntu 7.10 : worked just fine Ubuntu 8.04 : worked just fine Ubuntu 8.10 : worked just fine Ubuntu 9.04 : worked just fine I think that sums it up nicely. Now what do you mean by "ubuntu is behind us"... fedora has this issue for years and ubuntu never had this issue. you got the point i think ^_-
Today i installed ArchLinux (just wanted to try a completely different distribution) and i installed everything the way there wiki pages describe it. That includes: Gnome, Firefox and Compiz. There svn links: Firefox : http://repos.archlinux.org/viewvc.cgi/firefox/repos/extra-x86_64/ Compiz(-core) : http://repos.archlinux.org/viewvc.cgi/community/x11/compiz-core/?root=community Compiz-decorator-gtk : http://repos.archlinux.org/viewvc.cgi/community/x11/compiz-decorator-gtk/?root=community No svn link needed for gnome i think. Now look at those 3 links. there is only one patch in compiz-decorator-gtk to solve a crash. The rest of compiz and the decorator is the same as upstream. As for firefox. A few patches, oke, but none seem to fix a compositing issue like fedora has for years. So apparently just installing packages that are as close to upstream as possible (fedora clains to be that but they have a lot of patches!) is resulting in a working firefox. Or even better in my case. firefox and compiz are working perfectly here. and i'm on a old acer aspire 5630 notebook with a crappy intel gma graphics. So enough "proof" that it can just work fine. now all that has to be done is identify and destroy the bug that's causing this long standing issue.
I also have a Thinkpad T61, as in Comment #6, and noticed a pretty serious performance regression from F10 to F11 when using Compiz. What's happening for me is that I'll be doing something rather graphically intensive, say editing a large image in GIMP, and X will either slow to a craw, taking minutes to recover, or hang altogether. This did not happen for me with F10. I'm happy to provide whatever diagnostic information is needed to get this cleared up.
*** Bug 469100 has been marked as a duplicate of this bug. ***
Is rawhide any better?
*** Bug 465145 has been marked as a duplicate of this bug. ***
*** Bug 469584 has been marked as a duplicate of this bug. ***
*** Bug 470152 has been marked as a duplicate of this bug. ***
*** Bug 453742 has been marked as a duplicate of this bug. ***
The issue is between UXA and EXA. I had this same issue with ArchLinux when they updated the driver (intel) with UXA. then glxgears became a lot slower and the general compiz desktop was just a bit to slow to be fluid. Switching back to an older driver with EXA (or setting EXA in xorg.conf) solved this issue for me. Option "AccelMethod" "EXA" So, i guess this just fixed a long standing bug of 1 1/2 years old. Sadly this is likely not going to be in Fedora (or am i wrong?) because EXA == old and UXA is the new hype to use. UXA might work and run but it still has performance issues so i would recommend sticking at EXA untill those 2 are at the very least equal in speed.
*** Bug 473179 has been marked as a duplicate of this bug. ***
I can confirm this bug too on 2 IBM ThinksPads with the Intel 945 graphic mobile processor. With FC10 first release, no update, everything OK (speedy and snappy) with FC11 exactly the same problems as mentioned by most users: The first install with Fedora 10 (FC10) vs the first install with Fedora 11 (FC11) both scratch/without updates on 2 identical laptops (the IBM R60) show HUGE differences. FC11 effects/alt-tab switching is so slow that it becomes annoying. The refresh/redraw of a window that has been minimized to a maximized state shows corrupt images during redraw (but are corrected at the end in "slow motion"). slow scrolling a website with firefox lags behind for at least 0.5 seconds. • menu effects are slow and you can see them being built up • selection of icons in nautilus/the desktop is extremely slow. • dramatically reduced glxgears performance • stepping through windows with ALT-TAB is very slow • expose feature slow • strange window drag inertia? (comment#29) • freeze on suspend/resume (from dup bug 474496) • slow window fade in/out (from dup bug 469818) However NONE of the workarounds mentioned seem to work. • Option "AccelMethod" "XAA" • lower swappiness settings... sudo sysctl -w vm.swappiness=10 • intel_batchbuffer (comment#15) • reduce MTRR (comment#22, #23, #24) • Option "Tiling" "False" (comment#35) The problem is most visible with Firefox and Thunderbird programs and with Alt-Tab swithing to all windows that are active.
In my case (HP 6710s with GM965 (X3100)), this has much improved in Fedora 12 Beta and post-Beta Rawhide. I can't say when it was fixed, since I never tried Fedora 12 on this machine before. Only thing that is not 100% smooth a bit is Compiz desktop rotation with external monitor or projector (beamer) plugged in, but I can't quite remember if this was ever totally smooth. Everything else is nice and snappy, and I get 900-950 glxgears. Anyone else can confirm (or deny) that situation has improved recently?
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
This is no longer an issue on Fedora 12 (at least on my 965GM). If someone can reproduce it, please reopen it.
Hi, I had the same issues as described in this bug report ever since fedora had (or made an attempt to have) desktop effects. That "urge" of fedora lead me to leave fedora ll together; first for Ubuntu and some time after that i went to ArchLinux which is my linux "home" now. Now this beta build of fedora (i tried both the kde and gnome versions and are actually typing this message in the kde live cd). It used to be impossible (for me) to run KDE. It was sow, sluggish and not very responsive... to make matters worse turning on hardware acceleration was a lot __slower__ then running it in software mode. That seems to be over now. KDE runs smooth with no issues related to visibility or sluggish stuff. It just runs smooth. For gnome it's nearly the same although i saw one issue. When the desktop effects where turned on and i resize a window the window decorations (yes, only those) where sometimes white! like it couldn't keep up rendering.. but other times it was just smooth and fast so there is an issue there. For the firefox sluggish scrolling. I didn't see that issue on the live cd with and without desktop effects. So, i guess that means this issue is finally fixed. It took a few years to get there though ^_^. To the devs that fixed this: Thanx a lot for fixing it.
A fully updated F12 beta (32-bit) has finally rid me of this issue. I'm on a Dell D620 and Compiz is now quite smooth. In other news, I can also drive my external display at full resolution concurrently with the laptop panel!
(In reply to comment #64) > I'm on a > Dell D620 and Compiz is now quite smooth. Out of curiosity, you can hibernate/thaw as many times as you like using this config, right?
(In reply to comment #65) > (In reply to comment #64) > > I'm on a > Dell D620 and Compiz is now quite smooth. > > Out of curiosity, you can hibernate/thaw as many times as you like using this > config, right? I don't use suspend to disk. Suspend to RAM works well but I don't intentionally aspire to max uptime.
(In reply to comment #66) > Suspend to RAM works well OK. I guess I must be the unlucky one. For me F-12 if a huge regression when it comes to running compiz and hibernate/thaw or suspend/resume.
@ comment #67 then post: - your smolt hardware profile - your xorg log files - your xorg.conf (if you have one) - full output of glxinfo and any other hardware/graphic related log that might have influence in this case. I can't help with it as i run Archlinux but perhaps some others here can help you.
I already filed a separate bug for this. I just wanted to find out how many people with similar hardware are seeing the same thing.