New pooled memory types

[jhorv]

This PR adds 2 new types for using pooled memory:

• MemoryOwner<T> is a generic class for easy access to pooled memory.
• SpanOwner<T> is generic value type (readonly ref struct) that serves the same purpose in more constrained scopes, without requiring an additional allocation to manage it.

Both are intended for future optimization and to eventually replace the existing ByteMemoryPool and ByteMemoryPool.ByteMemoryPoolBuffer types in Ryujinx.Common.Memory, which have the following limitations:

• They only support byte buffers
• The IMemoryOwner<byte> implementation (the nested ByteMemoryPoolBuffer class) is private and returned as the interface. Usage as the concrete type would be faster.
• They don't have a value-type version, meaning their use requires allocating a ByteMemoryPoolBuffer instance.

This PR also uses the SpanOwner type to target a memory profiler hotspot, replacing a new array allocation with pooled memory in Ryujinx.Graphics.Vulkan.MultiFenceHolder. The table below shows the measured # of new FenceHolder[] allocations per second of gameplay (actual gameplay, past the title/intro/loading etc.).

Before this PR (a.k.a., # of Allocations Eliminated by this PR)

Game	Test Duration	Allocations	Allocations / second
Metroid Prime Remastered	1 min 2.725 sec	395,500	6,305
TotK	1 min 1.19 sec	769,100	12,569

[github-actions]

Download the artifacts for this pull request:

• ryujinx-Release-1.1.0+a5fca84-linux_arm64
• ryujinx-Release-1.1.0+a5fca84-linux_x64
• ryujinx-Release-1.1.0+a5fca84-macos_universal
• ryujinx-Release-1.1.0+a5fca84-win_x64

Old GUI (GTK3)

• gtk-ryujinx-Release-1.1.0+a5fca84-linux_arm64
• gtk-ryujinx-Release-1.1.0+a5fca84-linux_x64
• gtk-ryujinx-Release-1.1.0+a5fca84-win_x64

GUI-less (SDL2)

• sdl2-ryujinx-headless-Release-1.1.0+a5fca84-linux_arm64
• sdl2-ryujinx-headless-Release-1.1.0+a5fca84-linux_x64
• sdl2-ryujinx-headless-Release-1.1.0+a5fca84-macos_universal
• sdl2-ryujinx-headless-Release-1.1.0+a5fca84-win_x64

Only for Developers

• ryujinx-Debug-1.1.0+a5fca84-linux_arm64
• sdl2-ryujinx-headless-Debug-1.1.0+a5fca84-linux_arm64
• gtk-ryujinx-Debug-1.1.0+a5fca84-linux_arm64
• ryujinx-Debug-1.1.0+a5fca84-linux_x64
• sdl2-ryujinx-headless-Debug-1.1.0+a5fca84-linux_x64
• gtk-ryujinx-Debug-1.1.0+a5fca84-linux_x64
• ryujinx-Debug-1.1.0+a5fca84-macos_universal
• sdl2-ryujinx-headless-Debug-1.1.0+a5fca84-macos_universal
• ryujinx-Debug-1.1.0+a5fca84-win_x64
• sdl2-ryujinx-headless-Debug-1.1.0+a5fca84-win_x64
• gtk-ryujinx-Debug-1.1.0+a5fca84-win_x64

[gdkchan]

There are other custom pool implementations that we currently have, like https://github.com/Ryujinx/Ryujinx/blob/master/src/Ryujinx.Graphics.Vic/Image/BufferPool.cs
Do you think this would be eventually able to replace those?
One think to note is that, at least for this linked buffer pool, the size of the buffers are rather large (a few MB in memory iirc).

[jhorv]

There are other custom pool implementations that we currently have, like https://github.com/Ryujinx/Ryujinx/blob/master/src/Ryujinx.Graphics.Vic/Image/BufferPool.cs Do you think this would be eventually able to replace those?

They could be replaced, but I think it'd be wise to study them for possible behavior/perf differences. If any of them wrap ArrayPool, those could be drop-in replaced by these new ones without much concern. But any that have a custom algorithm (like BufferPool you mention) may have significantly different perf characteristics that we should probably measure before replacing.

[gdkchan]

There are other custom pool implementations that we currently have, like https://github.com/Ryujinx/Ryujinx/blob/master/src/Ryujinx.Graphics.Vic/Image/BufferPool.cs Do you think this would be eventually able to replace those?

They could be replaced, but I think it'd be wise to study them for possible behavior/perf differences. If any of them wrap ArrayPool, those could be drop-in replaced by these new ones without much concern. But any that have a custom algorithm (like BufferPool you mention) may have significantly different perf characteristics that we should probably measure before replacing.

I think ArrayPool originally had a pretty low size cap before, low enough that if I tried to rent those buffers using this approach it would not be actually pooled and would just allocate a new array every time. I think around .NET 7 they increased it, so probably should not be a problem anymore. But yea, if its replaced in the future, it will need to be tested carefully. That specific use case is somewhat special since VIC usually allocates a few buffer for the video frames when the decoding starts, and keeps using them until decoding ends. So the lifetime of those buffers is pretty well defined in those cases.

[gdkchan]

lgtm, thanks.

[riperiperi]

Looks good, sorry for the late review!