Announcement

Collapse
No announcement yet.

Compiz with FGLRX causes leaks

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    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.

    Comment


    • #3
      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 80?C 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; 16 January 2010, 12:00 PM.

      Comment


      • #4
        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.

        Comment


        • #5
          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 ?

          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; 16 January 2010, 01:17 PM.
          Test signature

          Comment


          • #6
            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.)

            Comment


            • #7
              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; 16 January 2010, 04:02 PM.
              Test signature

              Comment


              • #8
                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; 17 January 2010, 04:34 PM.

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    :-) 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...

                    Comment

                    Working...
                    X