Created attachment 20702 [details] xorg.conf I've an Intel 965GM video card and I use the xf86-video-intel-2.4.2 driver. Now after login into Gnome and launch compiz-fusion-0.7.8, every windows that I minimize/maximize the X process increase about 3mb of ram (every time). I can get 1gb of ram of X process in a few of minutes. The only way to free memory is to restart Xorg. With Metacity I've no problem. I tried to install Gentoo unstable (~amd64), and the problem was present as now with Arch Linux, that utilize Xorg-1.5. On Arch Linux, with the xorg.conf generated with hwd -x, X takes 10mb every minimize/maximize. My arch is x86_64. With XAA same problem as EXA. Xrestop say nothing about the problem. With Metacity, the ram slowly go down. Some people, with Nvidia video cards, say the problem was resolved. I don't think the problem is Compiz, because the same version, but with different xorg-server (1.4), hasn't this problem. This is my first bug-report, I'm sorry if I did some mistakes. If other informations are needed, no problem.
Update: Now on Arch Linux, with xf86-video-intel 2.4.3-1, the leaks seems resolved, or with a temporary workaround.
Thanks for reporting. Since it works with newer driver, this can be closed.
(In reply to comment #2) > Thanks for reporting. Since it works with newer driver, this can be closed. > Sorry, but the problem is still present. Without xorg.conf, with autogenerated one, with X -configure, nothing changed. With Pixman 0.13.2 same thing. I can see this problem since September, when Xorg-server 1.5 came out on Gentoo unstable. In these links, they had/have my same problem. https://bugs.launchpad.net/ubuntu/+source/compiz-fusion-plugins-main/+bug/151168 https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/154210 https://bugs.gentoo.org/show_bug.cgi?id=237502 It seems that Nvidia driver had this bug, but fortunately, now it's fixed. I don't know if is a xf86-video-intel or a xorg-server-1.5 bug. I can reproduce without problem this bug, and if you tell me how to do to get info, or to debug, I will try to do it.
With Xorg-server-1.5.3 same problem
(In reply to comment #3) > (In reply to comment #2) > > Thanks for reporting. Since it works with newer driver, this can be closed. > > > > Sorry, but the problem is still present. The problem is present if you use xf86-video-intel-2.4.2, and gone with 2.4.3, right? If so, this indicates it has been fixed. Or are you able to try master branch or 2.5.1 release?
> > The problem is present if you use xf86-video-intel-2.4.2, and gone with 2.4.3, > right? If so, this indicates it has been fixed. > > Or are you able to try master branch or 2.5.1 release? > The problem is present in 2.4.3 driver too. I tried xf86-video-intel-2.5.1 and the problem is still present.
What's your mesa version? Have you tried more recent mesa, git master maybe?
(In reply to comment #7) > What's your mesa version? Have you tried more recent mesa, git master maybe? > Sorry for the late, I did some try. My version of mesa was 7.2, now I'm running the git version, with the xf86-video-intel, and libdrm git version too. The problem is still present. I tried the live version of Ubuntu 8.10, with xorg 7.4, and on the amd64 version, the problem is present, while in the x86 version, is very limited, if there is the leak. Maybe, this is a problem that only affects amd64 architectures.
We expect it to be fixed as of Mesa 7.5 and this change to libdrm: commit 3f3c5be6f908272199ccf53f108b1124bfe0a00e Author: Eric Anholt <eric@anholt.net> Date: Thu Jul 9 17:49:46 2009 -0700 intel: Free buffers in the BO cache that haven't been reused in a while. The goal of the BO cache is to keep buffers on hand for fast continuous use, as in every frame of a game or every batchbuffer of the X Server. Keeping older buffers on hand not only doesn't serve this purpose, it may hurt performance by resulting in disk cache getting kicked out, or even driving the system to swap. Bug #20766.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.