12
\$\begingroup\$

My (2D) game's memory footprint seems to increase any time I load a texture, e.g. when I start my game it uses 30 mb private RAM, after transversing a ~367mb background file, so it's all in RAM at some point, it increases to 54 mb private RAM.

The same thing happens after going the same distance but going back and forth between two points repeatedly.

However, my readouts are showing that the program is correctly calling glDeleteTextures about a second after textures go off screen; and valgrind isn't finding any leaks.

How do I know if I should be worried about this, or if it's just a quirk of how the OS pages memory?

\$\endgroup\$
4
  • 1
    \$\begingroup\$ How did you determine the RAM usage of your application? Are you using a profiler (which one?) or do you just trust the task manager of your operating system (which one)? \$\endgroup\$
    – Philipp
    Feb 10, 2017 at 15:33
  • 1
    \$\begingroup\$ Task manager on kUbuntu, the profiler on my debugger tells me it's waiting for data then never displays anything. \$\endgroup\$ Feb 10, 2017 at 15:46
  • 1
    \$\begingroup\$ By the way: When you check memory consumption on Linux, remember to not just look at the memory consumed by the game process. One time I worked on a multiplatform game were we wondered why the Windows version consumes so much more ram than the Linux version, until we noticed that the Linux version of our graphics API apparently allocated memory for all the textures in the X11 process. \$\endgroup\$
    – Philipp
    Feb 10, 2017 at 15:54
  • 2
    \$\begingroup\$ You should have no expectation that glDeleteTextures will actually free memory: gamedev.stackexchange.com/questions/136883/… \$\endgroup\$ Feb 10, 2017 at 16:27

1 Answer 1

21
\$\begingroup\$

Virtual memory is allocated from the OS in large chunks, when even a byte is left still in use in that large chunk it cannot be released back to the OS.

Allocation libraries in user-space also keep a certain amount for re-use to avoid repeatedly demanding and releasing memory from/to the OS which is extremely slow.

E.g. you allocate a texture, the OpenGL driver reserves a table of 32 texture slots, you keep allocating textures, the driver then needs to allocate a larger table of 1024 texture slots this new table is now taking space in the large chunk of RAM, you free all the textures, the driver isn't shrinking nor re-allocating that table in the expectation that your game/application will need to use as many textures later so that large chunk of RAM cannot be released back to the OS.

This is perfectly normal and wanted. The unused RAM will be re-used eventually by your app.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Worth noting that if usage continues to increase during play, but leak detectors still don't find anything, you may be suffering from excessive memory fragmentation. The approaches to solving such a problem described at stackoverflow.com/questions/150753/… would also be useful for game development. \$\endgroup\$
    – Jules
    Feb 11, 2017 at 1:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .