All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* Extreme memory usage when running USDX with Intel driver
@ 2010-05-03 23:19 Tobias Doerffel
  2010-05-04  1:24 ` Eric Anholt
  0 siblings, 1 reply; 4+ messages in thread
From: Tobias Doerffel @ 2010-05-03 23:19 UTC (permalink / raw
  To: intel-gfx


[-- Attachment #1.1: Type: Text/Plain, Size: 2163 bytes --]

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.

Best regards,

Toby

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Extreme memory usage when running USDX with Intel driver
  2010-05-03 23:19 Extreme memory usage when running USDX with Intel driver Tobias Doerffel
@ 2010-05-04  1:24 ` Eric Anholt
  2010-05-04 16:19   ` Eric Anholt
  2010-05-04 22:27   ` Tobias Doerffel
  0 siblings, 2 replies; 4+ messages in thread
From: Eric Anholt @ 2010-05-04  1:24 UTC (permalink / raw
  To: Tobias Doerffel, intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 3302 bytes --]

On Tue, 4 May 2010 01:19:01 +0200, Tobias Doerffel <tobias.doerffel@gmail.com> 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).


[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Extreme memory usage when running USDX with Intel driver
  2010-05-04  1:24 ` Eric Anholt
@ 2010-05-04 16:19   ` Eric Anholt
  2010-05-04 22:27   ` Tobias Doerffel
  1 sibling, 0 replies; 4+ messages in thread
From: Eric Anholt @ 2010-05-04 16:19 UTC (permalink / raw
  To: Tobias Doerffel, intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 3399 bytes --]

On Mon, 03 May 2010 18:24:56 -0700, Eric Anholt <eric@anholt.net> wrote:
> On Tue, 4 May 2010 01:19:01 +0200, Tobias Doerffel <tobias.doerffel@gmail.com> 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.

It's also an environment variable.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Extreme memory usage when running USDX with Intel driver
  2010-05-04  1:24 ` Eric Anholt
  2010-05-04 16:19   ` Eric Anholt
@ 2010-05-04 22:27   ` Tobias Doerffel
  1 sibling, 0 replies; 4+ messages in thread
From: Tobias Doerffel @ 2010-05-04 22:27 UTC (permalink / raw
  To: Eric Anholt; +Cc: intel-gfx


[-- Attachment #1.1: Type: Text/Plain, Size: 718 bytes --]

Hi,

Am Dienstag, 4. Mai 2010, um 03:24:56 schrieb Eric Anholt:
> 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.
This indeed makes all issues disappear completely. As as workaround I'll patch 
the software to set this environment variable at startup. Nevertheless the 
issue should be debugged and fixed.

Best regards

Toby

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-05-04 22:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-03 23:19 Extreme memory usage when running USDX with Intel driver Tobias Doerffel
2010-05-04  1:24 ` Eric Anholt
2010-05-04 16:19   ` Eric Anholt
2010-05-04 22:27   ` Tobias Doerffel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.