Memory leak - Something I'm missing ?

[ChicoGameDev]

Hi everybody,

I try for a few days now to warp my head around an issue of memory leak. I'm unable to find the issue myself so I hope someone will notice something I'm not able to see.

It's a map generation code... Large maps 5600x5600 pixels. Before you ask, yes I tried to manage it in chunks but that was actually worse than what you will see.


Right at the start you should get the memory usage at : ~325 Mo

And after flooding a bit with the space bar (3 rapid hits, little pause, 3 rapid hits again, and so on) it should go up to 1.5 Go or even 2 Go.

So it is going very fast. Maybe it's really simple but I don't get it, I release my canvas and everything. It's clear that the canvas is in cause but how ? Why ?

Note : I had big trouble with attachment so I put 1 zip with the love file and 2 screenshots. Bug on the website ?

DemoPackage.zip

(192.15 KiB) Downloaded 142 times

Thanks for advance to anyone taking a look at this issue.

[pgimeno]

Removing the draw calls while keeping the canvas gets rid of the problem. Drawing a rectangle right after the tile makes it a lot slower, but also gets rid of the problem. Therefore, I suspect this has to do with autobatching. Unfortunately, it can't be turned off (but it would have a huge performance penalty in your case if it was disabled, because you don't use spritebatches).

I suggest you try to create a spritebatch and draw that, instead of drawing to the canvas directly. Maybe you don't even need the canvas that way.

[ChicoGameDev]

Hi pgimeno,

Thanks for your answer.

So am I understanding this right ? Are you confirming that there is an issue with LÖVE's Canvases ?

I do not know a lot about SpriteBatch I will take a look. I really thought that canvases was the way to go in this case.

Do you think I could report this as a bug ?

Thanks

[pgimeno]

Hi pgimeno,

Thanks for your answer.

So am I understanding this right ? Are you confirming that there is an issue with LÖVE's Canvases ?

No, it doesn't look like it has to do with canvases at all. It seems to have to do with autobatching in love.graphics.draw. Removing the canvas from the equation does not alter the result.

I do not know a lot about SpriteBatch I will take a look. I really thought that canvases was the way to go in this case.

Do you think I could report this as a bug ?

Thanks

I'd say so.

Edit: Canvases may still be the way to go, I don't know. But to solve your immediate problem, using a spritebatch in order to render everything with a single draw call seems necessary.

[slime]

Certain aspects of autobatching (and GPUs in general) operate on a per-frame basis. Since your code draws almost 500,000 things within love.keypressed, and your repro steps cause love.keypressed to be called multiple times within a frame, the batching code will need to allocate enough memory to fit 1.5 million quads or more when you press space 3 times in a frame. LÖVE doesn't currently ever downsize its autobatching buffers.

Using a spritebatch may cause the graphics driver to do the same thing internally when its contents are modified/added to -> drawn -> modified/added to -> drawn etc. multiple times within a single frame (eg in your example where love.keypressed is called several times in a frame), so using love.keypressed for that isn't recommended.

[ChicoGameDev]

So if I understand everything right,

I'm doing it right but there will be absolutely no issue if my maps are generated only once in the load event ?

Actually the problem is still happening when you press space only once and wait and press again and wait and so on, so even without the multiple calls per frame the memory is still building up and never go down.

I'm a bit lost in all of that is my idea simply too big ?

Thanks, sorry I need more details to understand

[grump]

I'm doing it right

In my opinion, allocating ~120 MB of texture memory to draw a simple low-res, low-color, pixellated tile map that should only take a couple hundred KB at most is not right and seems like an awfully inefficient way to do things. It simplifies the map rendering, but it also defeats the purpose of having tile maps, which is to conserve memory by reusing tile graphics.

The approach is also prone to failure on older hardware. 5600x5600 is already over the limit on old hardware. Once you go over 8192x8192, which is only 4x8 1080p screens, you'll have a good percentage of people who can't run the game anymore.

By using Meshes or SpriteBatches, you'll save memory, probably have better performance due to lower memory bandwidth requirements and caching effects, and you can have chunked maps that are basically unlimited in size, even on weak hardware.

[ChicoGameDev]

Using a spritebatch may cause the graphics driver to do the same thing internally when its contents are modified/added to -> drawn -> modified/added to -> drawn etc. multiple times within a single frame (eg in your example where love.keypressed is called several times in a frame), so using love.keypressed for that isn't recommended.

Thanks for intel on that subject but my map is completely static. So the spritebatch is indeed the way to go for me. My memory usage stays on 300 mb max so it's ok for me no more stack to the 2Go x) Thanks for your help Slime and Pgimeno.

In my opinion, allocating ~120 MB of texture memory to draw a simple low-res, low-color, pixellated tile map that should only take a couple hundred KB at most is not right and seems like an awfully inefficient way to do things. It simplifies the map rendering, but it also defeats the purpose of having tile maps, which is to conserve memory by reusing tile graphics.

The approach is also prone to failure on older hardware. 5600x5600 is already over the limit on old hardware. Once you go over 8192x8192, which is only 4x8 1080p screens, you'll have a good percentage of people who can't run the game anymore.

By using Meshes or SpriteBatches, you'll save memory, probably have better performance due to lower memory bandwidth requirements and caching effects, and you can have chunked maps that are basically unlimited in size, even on weak hardware.

You are right!

In many other scenarios I'll cut my map in chunks but I actually want the player to be able to zoom completely out to see the whole map at once.

And yes Spritebatch is the answer I will use them now.

Thanks everybody you're awesome !


Cheers

[pgimeno]

Using a spritebatch may cause the graphics driver to do the same thing internally when its contents are modified/added to -> drawn -> modified/added to -> drawn etc. multiple times within a single frame [...]

How is "a single frame" defined when the drawing goes to a canvas? Is it still dependent on love.graphics.present() even if it's not to the screen?