Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: Compiz with FGLRX causes leaks

  1. #1
    Join Date
    May 2009
    Posts
    42

    Default Compiz with FGLRX causes leaks

    Hi, Im using fglrx driver with compiz enabled and I did notice huge memory consumption of memory. Even scroling page in firefox eats megabytes of ram. I minimize and maximize window and 10 MB of ram is gone...

  2. #2
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,788

    Default

    The same happened with KDE at some point. It seems to be fixed now. Not sure exactly where it was fixed. I'm on Catalyst 9.12, kernel 2.6.32 and X.Org 7.4.

    You might want to install the "xrestop" tool. It's like "top" but shows X's used resources. If you can find the leak there, it means fglrx is innocent (for a change :P) since fglrx is kernel space.

  3. #3
    Join Date
    May 2009
    Posts
    42

    Default

    Well, Im on fresh karmic install, fglrx 9.12 hotfix driver, xrestop didnt show any change when I scroll in firefox, but in HTOP its like 10 MBps, after few hours my notebook is unusable... I try Lucid with radeon driver, no problem there, but since that driver has no powersavings capabilites, my notebook goes to 80C with in few minutes...

    edit: I try run glxgears and after I closed glxgears window, I get about 300 MB of RAM back...
    Last edited by icek; 01-16-2010 at 11:00 AM.

  4. #4
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,788

    Default

    There's not much you can do about it. Simply too many things that can play a part. You have to live with it. If it's an fglrx bug, no one is going to fix it. It seems only bugs the developers themselves see get fixed.

  5. #5
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,440

    Default

    Quote Originally Posted by RealNC View Post
    If it's an fglrx bug, no one is going to fix it.
    If it's an fglrx bug, and it doesn't show up in our testing, and if nobody files a useful bug report at ati.cchtml.com, nobody is going to fix it.

    The only recent ticket I found was #1453, which has essentially no system information other than driver version; maybe someone could update it so the developers are aware of what you are seeing and have enough info to repro the problem on a supported distro ?

    Quote Originally Posted by RealNC View Post
    It seems only bugs the developers themselves see get fixed.
    With respect, if the bug isn't reproducible in-house (shows up on developer system, or QA system, or we have enough info in a bug ticket to reproduce) then it's not really possible to do anything about it.

    This is why bug reports need to have enough info to let an arbitrary developer reproduce the problem on their system so that they *are* able to investigate and fix it.
    Last edited by bridgman; 01-16-2010 at 12:17 PM.

  6. #6
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,788

    Default

    Yeah, I know, like wrong colors and tearing in xvideo.

    With all due respect bridgman, fglrx development and bug fixing is below "worst". The devs would probably know about all the bugs if they were actually using the stuff they write the same way we use it (watch movies, do some work, maybe play a game.)

  7. #7
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,440

    Default

    No, not like wrong colours and tearing in Xv at all (assuming that by wrong colours you mean outputting with a 16:235 range for HDMI TVs rather than 0:255 range for computer displays). Both of those involve new functionality that needs to be added to the driver - sync-to-vblank and buffer-queue code to deal with Xv tearing, and switchable output range for the colours.

    If your reference to "wrong colours" is something different from the "washed out colours" caused by using a 16:235 output range please let us know.

    As I understand it the fglrx devs went with a 16:235 range in order to correctly drive HDMI-attached HDTVs (at the expense of under-driving computer displays), while the radeon devs expanded the range out to 0:255 in order to correctly drive computer displays (at the expense of over-driving HDTVs). Different design decisions, not a bug in either case. The ideal solution would be to add a facility to switch between 16:235 and 0:255 depending on the type of display being used.

    This is getting off topic though -- the original poster reported an issue which doesn't seem to be showing up on our development and test systems, or on your system for that matter. Filing a bug report, or updating the existing mostly empty one, would probably help in that case.
    Last edited by bridgman; 01-16-2010 at 03:02 PM.

  8. #8
    Join Date
    May 2009
    Posts
    42

    Default

    Ok, I have filed the bug report, number 1738. But I dont thing it is bug in ati driver... Can somebody try to run HTOP and see if memory consumption goes up?

    Edit : Launchpad bug
    Last edited by icek; 01-17-2010 at 03:34 PM.

  9. #9
    Join Date
    Feb 2010
    Posts
    3

    Default

    I'm using Mobility Radeon HD 4870 X2 and I can confirm, that memory goes up whenever I scroll anything (firefox, krusader, skype - you name it).

    However, the interesting thing, that running glxgears or glxinfo frees the consumed memory. So as a temporary workaround you can write a scipt to call glxinfo every 20 seconds and that should fix most of the problems.

  10. #10
    Join Date
    May 2009
    Posts
    42

    Default

    :-) funny, I did the same thing... but its really annoying if you play movie and glxgears window pops up... I believe that this is bug in Xserver, so I hope this bug will be fixed in Lucid...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •