Bug 444328 (i810compizslow)

Summary: [965GM/945GM] compiz and 3d in general slow with i810/intel driver
Product: [Fedora] Fedora Reporter: Geert Jansen <gjansen>
Component: xorg-x11-drv-intelAssignee: Adam Jackson <ajax>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 11CC: 01plik, aaron, ahsaleem, ajax, albertczyk, amlau, ascii79, bche, bnocera, bojan, bugzilla, cbredesen, daniel, deerfieldtech, djaara, drago01, drussell, herrold, humpf, jrb, konstanty, linux.ninja1, ljonsson, llange, lukasim, markg85, matt.britt, mcepl, mikem, mishu, moneta.mace, noa, pdemauro, piskozub, rafapp, rembspam, rh-bugzilla, tjb, tristanmoody, uckelman, uosiumen, vedran, xgl-maint, zkabelac
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-05 17:29:35 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 466319, 474496    
Bug Blocks: 469690    
Attachments:
Description Flags
xorg.conf
none
Xorg.0.log none

Description Geert Jansen 2008-04-27 04:09:54 EDT
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.
Comment 1 Geert Jansen 2008-04-27 04:11:38 EDT
Created attachment 303899 [details]
xorg.conf
Comment 2 Geert Jansen 2008-04-27 04:12:28 EDT
Created attachment 303901 [details]
Xorg.0.log
Comment 3 Geert Jansen 2008-05-11 02:29:25 EDT
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.
Comment 4 Bug Zapper 2008-05-14 06:15:02 EDT
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
Comment 5 Konstanty 2008-05-14 21:39:44 EDT
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.

Comment 6 Sean 2008-05-15 16:20:01 EDT
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
Comment 7 Sean 2008-05-15 16:27:29 EDT
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!
Comment 8 Konstanty 2008-05-15 23:37:46 EDT
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).
Comment 9 petrosyan 2008-05-18 09:34:46 EDT
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.
Comment 10 Matěj Cepl 2008-05-19 05:56:06 EDT
*** Bug 446370 has been marked as a duplicate of this bug. ***
Comment 11 Juan Pablo Giménez 2008-05-20 07:01:29 EDT
Option "AccelMethod" "XAA"

speed up things... but looks like a workaround, not the real fix... 
Comment 12 Noa Resare 2008-05-20 07:21:33 EDT
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.
Comment 13 vvs 2008-05-21 04:21:10 EDT
Looks like https://bugzilla.redhat.com/show_bug.cgi?id=445681 is related
Comment 14 Juan Pablo Giménez 2008-05-21 15:57:01 EDT
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...
Comment 15 Noa Resare 2008-06-04 03:24:56 EDT
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.
Comment 16 Noa Resare 2008-06-04 04:04:31 EDT
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.
Comment 17 drago01 2008-06-10 15:28:51 EDT
Does setting "MigrationHeuristics" to "greedy" improve things?
Comment 18 Adam D. Ligas 2008-07-09 05:27:56 EDT
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
Comment 19 bughead 2008-07-09 06:27:32 EDT
(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.
Comment 20 petrosyan 2008-08-13 10:36:44 EDT
*** Bug 457669 has been marked as a duplicate of this bug. ***
Comment 21 Enrico Scholz 2008-08-14 15:02:51 EDT
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 :(
Comment 22 Enrico Scholz 2008-08-14 15:56:38 EDT
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
Comment 23 Geert Jansen 2008-09-21 10:06:50 EDT
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.
Comment 24 Simon Karpen 2008-10-31 18:16:33 EDT
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)
Comment 25 Geert Jansen 2008-11-11 08:08:10 EST
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.
Comment 26 Dave Russell 2008-11-26 09:33:42 EST
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)
Comment 27 Sean 2008-11-26 20:59:54 EST
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.
Comment 28 Arif Saleem 2008-11-27 06:00:52 EST
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
Comment 29 Pedro Lamarão 2008-11-27 19:45:11 EST
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.
Comment 30 Pedro Lamarão 2008-11-27 20:28:20 EST
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
Comment 31 Fake name 2008-11-28 14:54:23 EST
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)
Comment 32 Matěj Cepl 2008-12-04 17:43:02 EST
*** Bug 474496 has been marked as a duplicate of this bug. ***
Comment 33 Matěj Cepl 2008-12-04 17:48:16 EST
*** Bug 469818 has been marked as a duplicate of this bug. ***
Comment 34 Šimon Lukašík 2009-01-20 15:53:06 EST
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.
Comment 35 Samo Dadela 2009-02-19 08:16:10 EST
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?
Comment 36 Alberto 2009-03-04 10:55:28 EST
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.
Comment 37 Alberto 2009-03-09 06:16:43 EDT
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
Comment 38 Steve Hill 2009-06-11 05:57:02 EDT
Looks like this is fixed under Fedora 11
Comment 39 Mike McLean 2009-06-11 17:05:40 EDT
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.
Comment 40 Samo Dadela 2009-06-12 07:11:34 EDT
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.
Comment 41 Mike McLean 2009-06-12 12:03:48 EDT
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...
Comment 42 Sean 2009-06-12 13:00:52 EDT
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!
Comment 43 drago01 2009-06-12 13:38:24 EDT
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).
Comment 44 Matt Britt 2009-06-22 00:04:10 EDT
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
Comment 45 Mark 2009-06-26 12:38:52 EDT
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.
Comment 46 Matěj Cepl 2009-06-27 05:43:01 EDT
(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?
Comment 47 Mark 2009-06-27 13:06:25 EDT
(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 ^_-
Comment 48 Mark 2009-06-28 10:32:14 EDT
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.
Comment 49 Joel Uckelman 2009-08-04 18:09:57 EDT
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.
Comment 50 Vedran Miletić 2009-09-06 03:49:48 EDT
*** Bug 469100 has been marked as a duplicate of this bug. ***
Comment 51 Vedran Miletić 2009-09-06 03:51:04 EDT
Is rawhide any better?
Comment 52 Vedran Miletić 2009-09-06 03:55:06 EDT
*** Bug 465145 has been marked as a duplicate of this bug. ***
Comment 53 Vedran Miletić 2009-09-06 03:57:09 EDT
*** Bug 469818 has been marked as a duplicate of this bug. ***
Comment 54 Vedran Miletić 2009-09-06 03:57:26 EDT
*** Bug 469584 has been marked as a duplicate of this bug. ***
Comment 55 Vedran Miletić 2009-09-21 10:20:49 EDT
*** Bug 470152 has been marked as a duplicate of this bug. ***
Comment 56 Vedran Miletić 2009-09-21 10:24:47 EDT
*** Bug 453742 has been marked as a duplicate of this bug. ***
Comment 57 Mark 2009-09-21 10:33:04 EDT
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.
Comment 58 Vedran Miletić 2009-09-21 10:42:32 EDT
*** Bug 473179 has been marked as a duplicate of this bug. ***
Comment 59 rembspam 2009-10-07 10:33:07 EDT
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.
Comment 60 Vedran Miletić 2009-11-01 07:31:26 EST
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?
Comment 61 Matěj Cepl 2009-11-05 13:19:18 EST
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.]
Comment 62 Vedran Miletić 2009-11-05 17:29:35 EST
This is no longer an issue on Fedora 12 (at least on my 965GM).

If someone can reproduce it, please reopen it.
Comment 63 Mark 2009-11-05 19:37:20 EST
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.
Comment 64 Chris Bredesen 2009-11-16 11:08:01 EST
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!
Comment 65 Bojan Smojver 2009-11-16 18:09:12 EST
(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?
Comment 66 Chris Bredesen 2009-11-17 11:58:52 EST
(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.
Comment 67 Bojan Smojver 2009-11-17 16:34:00 EST
(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 68 Mark 2009-11-17 16:51:33 EST
@ 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.
Comment 69 Bojan Smojver 2009-11-17 17:16:30 EST
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.