On Tue, 4 May 2010 01:19:01 +0200, Tobias Doerffel <[email protected]> wrote: > Hi, > > I have serious problems with running UltraStar Deluxe (a free OpenGL-based > karaoke program) on an Intel graphic card (945GME). When starting the program, > the system starts to use more than 1,5 GB of RAM for (I guess) GEM stuff. I > can't blame the program as it's running fine with both swrast (on the same > computer and setup) and the nouveau driver on another computer and itself > consumes about 100 MB of RAM. > > I collected some data describing the system status after the program has been > started up (and switched to tty0 in order to get these values). > > With Mesa 7.9 /proc/dri/0/gem_object tells me > > 8996 objects > -1422700544 object bytes > 3 pinned > 19365888 pin bytes > 140005376 gtt bytes > 260308992 gtt total > > With Mesa 7.8.1 it looks like the following: > > 2655 objects > -1792622592 object bytes > 3 pinned > 19365888 pin bytes > 233402368 gtt bytes > 260308992 gtt total > > At the same time /proc/<PID>/smaps has about 2500 similiar entries looking > like > > 1007e000-1017e000 rw-s 20ac0e000 00:05 314 /dev/dri/card0 > Size: 1024 kB > Rss: 0 kB > Pss: 0 kB > Shared_Clean: 0 kB > Shared_Dirty: 0 kB > Private_Clean: 0 kB > Private_Dirty: 0 kB > Referenced: 0 kB > Swap: 0 kB > KernelPageSize: 4 kB > MMUPageSize: 4 kB > > > /proc/dri/0/gem_names contains > > name size handles refcount > name 1 size 4194304 > 1 4194304 2 5 > name 2 size 4194304 > 2 4194304 2 4 > name 3 size 16777216 > 3 16777216 1 4 > > > My setup is the latest kernel with latest commits from the drm-intel-next > branch. Same for xf86-video-intel and libdrm (both compiled from Git). > XServer > version is 1.8. Mesa as written above. What could I do further to track down > the problem? > > From what I saw in the source code, the program creates lots of textures for > individual glyphs of fonts. The extreme memory usage seems to start while the > several thousands of textures are being created. I'm just wondering that > everything works fine with other drivers.
Yeah, we've got a few reports of some apps that have spectacularly large memory usage, some to the point of OOMing. It hasn't been clear yet that these are leaks or just overallocation, as they've all been in relatively sizeable apps like Blender. Unfortunately, we don't have any details yet on what it is special that these apps do. Your note about glyphs is interesting, and may be useful. Right now we tile any texture that comes our way. If the app is generating many tiny textures for glyphs, the tiling may increase the pitch by up to a factor of 8. You could test if this was the problem by setting texture_tiling=false in driconf. If that's the case, we can just tune when we tile textures according to their size, and fix the problem. (Of course, if the app is doing that many small textures then it should really really be doing texture atlasing. But that wouldn't justify our behavior being that bad).
pgpXeoPZH2tnR.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
