Re: compiz w/ i965 video and horrible cpu usage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> John Priddy writes:

j> I recently just rebuilt a laptop with FC9 from FC8.  When I start compiz
j> I get a massive cpu of about 50 and 75%.  The culprit always is the Xorg
j> process.  Even simple scrolling text (ie. dmesg output) takes about 10
j> seconds to come back, whereas metacity is instant.  When compiz is
j> enabled, i also get digusting stats from glxgears as well, but only when
j> I am doing things like moving windows, etc.  On the other hand, glxgears
j> is solid with about 100fps when not using compiz.  I have tried
j> disabling various plugins via ccsm to the point of where it looks pretty
j> much identical to metacity, but the perf problem still persists.
j> Previously I didn't notice any issues with FC8 on the same laptop.  I
j> would be suprised if the hardware is the issue, its a dual core 2.2 w/
j> 4G ram.  I have even tried some 3rd party compiz repositories that are a
j> little bit more bleeding edge with the versions and i still have the
j> same issue.  

[...]

j> [jpriddy@boatanchor ~]$ dmesg | grep agp
j> Linux agpgart interface v0.103
j> agpgart: Detected an Intel 965GM Chipset.
j> agpgart: Detected 7676K stolen memory.
j> agpgart: AGP aperture is 256M @ 0xe0000000


        What does "cat /proc/mtrr" say?

        I had the same problem after I upgraded from F8 to F9 on my
Dell desktop (965Q chipset).  The problem appears to be related to
having >2GB memory and maybe having bad BIOS settings:

https://bugs.launchpad.net/linux/+bug/210780
https://bugs.freedesktop.org/show_bug.cgi?id=15360

I ended up using a workaround similar to the one described at the end
of that second web page, which involved redoing the MTRR settings:

original:
reg00: base=0x00000000 (   0MB), size=65536MB: write-back, count=1
reg01: base=0xbf800000 (3064MB), size=   8MB: uncachable, count=1
reg02: base=0xbf700000 (3063MB), size=   1MB: uncachable, count=1
reg03: base=0xc0000000 (3072MB), size= 1024MB: uncachable, count=1

new:
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0xbf800000 (3064MB), size=   8MB: uncachable, count=1
reg02: base=0xbf700000 (3063MB), size=   1MB: uncachable, count=1
reg03: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg04: base=0xc0000000 (3072MB), size= 256MB: write-combining, count=1
reg05: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg06: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg07: base=0x100000000 (4096MB), size=4096MB: write-back, count=1


The key is to set the framebuffer memory (reg03: 0xc0000000 in my
case) to be "write-combining" but this could not be done with the
original MTRR settings because reg00 overlapped reg03.

        The workaround breaks up the regions to avoid overlap.  I
split up reg00 into three (reg00, reg03, reg07) and I split up reg03
into another three (reg04, reg05, and reg06), with the framebuffer
(reg04) set to "write-combining".

        Unfortunately, I do not know why this only started failing in
F9.
-- 
Gregorio Gervasio, Jr.

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux