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\$
  • 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 '17 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\$ – Patrick Jeeves Feb 10 '17 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 '17 at 15:54
  • 2
    \$\begingroup\$ You should have no expectation that glDeleteTextures will actually free memory: gamedev.stackexchange.com/questions/136883/… \$\endgroup\$ – Maximus Minimus Feb 10 '17 at 16:27
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.

| improve this answer | |
\$\endgroup\$
  • 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 '17 at 1:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.