Memory allocated for storyboards is never being released

[EVAST9919]

Type

Performance

Bug description

Whenever you are trying to start a map with storyboard - osu! will increase the memory consumption and will never decrease it. Restarting the map or exiting to the song-select screen and starting again will increase it further and further and will stay at that point until the game being closed.
Upon quick look I noticed that TextureStore in DrawableStoryboard is never being disposed, so that's potentially the cause, but that's just a speculation for now.
With this map the issue is easy to reproduce, however it's not a map-specific problem since it happens with basically every storyboard as far as I can tell.

Screenshots or videos

No response

Version

master

Logs

n/a

[frenzibyte]

It doesn't seem like TextureStore holds any resources that it can dispose of on disposal, since textures generally never get disposed, they continue to exist until all references to it are lost (which happens when all sprites no longer use the texture and the texture store containing it no longer has any references).

I do see the memory usage increasing however (consistently happens with https://osu.ppy.sh/beatmapsets/499488#osu/1077683), so there's definitely something bad going on. Never mind, memory usage getting higher is just because of the above statement. Since they're only disposed when they're finalised, that won't happen until GC collects them (which takes a period of time).

[peppy]

It's fine here. Releases fine.

Probably opengl renderer issues or something.

[frenzibyte]

As per above, please check this isn't a duplicate of #23252.

[EVAST9919]

With LegacyGL memory usage goes down after some time, yes, but with D3D it's stays the same even after leaving the game idling in the main menu for 15 mins.

[peppy]

@EVAST9919 can you try tapping the "clear all caches" button in settings and confirm it doesn't help?

[EVAST9919]

Yep, I tried - still doesn't help. Here's an example:

• Entered song-select - 500mb
• Starting gameplay with storyboard - 1400mb
• Went back to main menu - same
• Clear caches - 1200 mb (multiple times or after waiting for some time - still the same)
• Repeat multiple times to get more

As I said with LegacyGL memory consumption will be reduced by it's own after a bit, however clearing caches will do that instantly, so it should work as expected.
I can attach video showing the process however I'm not sure it can show anything useful.

[frenzibyte]

As I said with LegacyGL memory consumption will be reduced by it's own after a bit, however clearing caches will do that instantly, so it should work as expected.

That would be textures getting garbage collected I believe, so yes that's working correctly

For the issue you're seeing, that sounds like unmanaged GPU resources not being disposed correctly, but I couldn't reproduce on any backend with the storyboards I had. I'll double check again, but this may potentially somehow depend on platform (maybe platform-specific code in Veldrid?)

[Cootz]

I can reproduce this but it takes a lot of time

Basically you need to get ~1.6 GB of memory usage and then go to any beatmap and continuously restart it
Platform: Win 10
Render: OpenGL

Update:

memoryLeak.mp4

[peppy]

Basically you need to get ~1.6 GB of memory usage and then go to any beatmap and continuously restart it

What you're showing here is very likely not a leak. It's just the .NET runtime expanding its used memory due to fragmentation or high memory requirements.

[EVAST9919]

Found a small hint hopefully: I have only 4gb of vram, and after looking at it's usage it became obvious that it's not being freed in veldrid after textures disposal (for me at least). So huge ram usage - is actually overflowed vram.
But sorry if it was already obvious.

[peppy]

I'm not sure how relevant, but there was an issue opened over at veldrid regarding ballooning Direct X memory usage. veldrid/veldrid#508

[EVAST9919]

Probably should be moved to the framework as it has nothing to do with storyboards but textures in general.

[peppy]

Fine to keep it here for now (I'm tracking it).

[smoogipoo]

Will likely be fixed in the next release by ppy/veldrid#54