Memory not freed when free_after_load is True about pi3d HOT 5 OPEN

@jean-emmanuel I will have a look at this in an hour or two.. it does look odd, perhaps the highly optimised C and Fortran code in numpy skips some registration process, or the copying of the bytes is optimised into a transfer of ownership in some way?

from pi3d.

Running the same test on a system with an integrated graphic card (and shared video memory) gave different results (same pi3d/numpy version):

• the numpy array is allocated only once in python unless filled with a random value, I guess numpy detects the data is the same and reuses it. Somehow numpy behaves differently here... EDIT: creating the array with numpy.full instead of numpy.zero fixes it.
• the memory is released as expected: half of it with free_after_load, the other half when textures are unloaded

from pi3d.

Yes it's very odd. Showing the memory with free doesn't seem to take into account GC released space in this circumstance. If I do something like

        if len(textures) > 50:
            textures.pop(0)

when it's building the list then the memory stops being consumed although new Texture objects are being created. Similarly if the else block sets textures to [] and memory to 0 then the process is repeated ad infinitum but the amount of memory consumed stays the the max. If I put the Texture.file_string = None into the Texture.free_after_load() method (where it should be, as you point out. Just in time for the next release of pi3d!) then the memory usage shown by free is higher but the first time textures is deleted it does drop. However subsequent resets don't reduce the memory usage. The memory usage does depend on what the numpy array is filled with (zero, ones, full, random) which is bizarre.

I might do some more experiments and get info from gc

from pi3d.

Hmm, from what I understand memory management in opengl is hardware/driver dependent and nvidia driver may well keep memory allocated in ram as well as in vram (for swapping I guess). It may not be an issue with other hardwares (it isn't with that aforementioned intel integrated graphic card).

from pi3d.

Running the script with a system ram consumption limit made it a lot slower but eventually all the textures got into the vram while ram usage stood under the limit (which was 4x lower than the total allocated vram), this could well corroborate the nvidia-swap theory.

from pi3d.