is it necessary to "free" texture data / love.graphics.Image ?

[trabitboy]

Hi!
In the context of a paint app,
I tend to create a lot of new textures / images,
each time I save the GPU canvas:

Code: Select all

--TODO REMOVE try disable display as workaround on android 
function saveCanvasToFrame(idx)

	disableDisplay=true

	love.graphics.setCanvas()
	fromGpu=cvs:newImageData()
	frames[idx].data=fromGpu
	frames[idx].pic=love.graphics.newImage(fromGpu)
	--pic is not referenced anymore but is it enough for it to be freed?
	
	disableDisplay=false
end

it's not clear to me if you need to call any kind of deallocation function for the texture data on the GPU to be released?

[raidho36]

It will be freed automatically once Lua garbage-collects discarded items. You can manually release the associated memory, but it's not strictly necessary. Keep in mind that ImageData resides in RAM and Texture resides in VRAM.

[pgimeno]

I've found that in a similar situation, if I didn't force garbage collection, the memory grew and grew out of control until the memory was completely filled. My hypothesis is that, since Lua does not know the size of the underlying object, it doesn't care that there are many big ones waiting to be garbage-collected, so if their number doesn't reach a high enough threshold, GC doesn't happen. Since in the Lua side the memory used by UserData is very small, many objects can accumulate until GC is triggered.

Manually running GC every 5 seconds worked for me. https://notabug.org/pgimeno/Thrust-II-r ... e.lua#L557

[slime]

If that situation happens in code like the above where the lifetime of the texture is obvious, Object:release (new in LÖVE 11.0) is probably a better solution – it'll perform better, at least.

[raidho36]

Since in the Lua side the memory used by UserData is very small, many objects can accumulate until GC is triggered.

This implies that Lua would trigger GC sooner if it knew about object sizes, but that's not the case. Plain Lua objects that take up a lot of memory don't trigger GC any quicker than normal. GC only cares about reference counting.

[trabitboy]

thanks a lot,
I will add a call to release() explicitly when an Image ( or other gpu resource ) gets out of scope.

maybe we should add a mention on the wiki about this ?

[raidho36]

Wiki does tell about this. Maybe you missed it because you were focused on whatever you were looking for.

[trabitboy]

:release() exists on the wiki page of love.graphics.Image , but the particular context of objects having allocated gpu memory, and the preventive use of release() in this context, is not explained.

[zorg]

:release() exists on the wiki page of love.graphics.Image , but the particular context of objects having allocated gpu memory, and the preventive use of release() in this context, is not explained.

https://love2d.org/wiki/Object:release
It's defined for all Object types, even though it isn't explained what will happen to specific memory areas whether in the gpu or in main RAM; It does say that the lua reference will be cleaned up and if that was the only one it had, the object itself will be completely deleted, so one could infer that to mean freeing up all areas of memory.

[m0nkeybl1tz]

This thread saved my life! I'm drawing to and sampling from a canvas every frame, and I was having my framerate drop in half every few seconds. Calling Object:release() on my ImageData stopped it from spiking, as well as saved me 5 FPS overall.