RPCS3
Resistance 3: Possible memory leaks on VRAM
Quick summary
Switching from an old GTX 970 (only 4GB of VRAM) to an RTX 5090 (32 GB of VRAM) and just double checked #16548 for a possible growth of VRAM due to memory leaks.
In some sections of the game more than others (e.g. Main Street Defence section on Haven, OK chapter, Train Defence section on Mt. Pleasant, PA chapter etc.) the VRAM (allocated by rpcs3) constantly grows. This is particularly evident using an high Resolution Scale such as 300% (4K); the VRAM usage quickly reaches high values (e.g. 28GB) in few minutes.
Attached a screenshot taken on Main Street Defence section after about 1 minute of gameplay where VRAM reached almost 17GB (second stat reported on the MEM overlay while first stat (18GB) is the overall VRAM usage (so including OS etc.)).
This issue is present with Disable Vulkan Memory Allocator setting set to disabled (default) or enabled. Of course when enabled, memory is released more frequently (you see frequent memory drop) and you have the feeling all the memory is properly released when requested but the leaks are inevitably there if you check after some time.
Details
No response
Attach a log file
Attach capture files for visual issues
No response
System configuration
No response
Other details
No response
Rpcs3 being an emulator cannot budget VRAM like a traditional game. We just create new things as they are demanded and if they can't fit we evict old stuff. It's just aggressive caching. By default, the max caching size is calculated with 64GB VRAM in mind. If you wish to change this, open the config.yml and set your desired max caching limit to something like 4GB or 8GB. Note that GPUs combine multiple types of memory so you may exceed the set limit but it should at least try to stick to it as much as possible. if it still grows to 20+ GB let me know.
Just set 8192 for VRAM allocation limit (MB) and a crash for VRAM limit reached occurred (allocated reported VRAM was more than 9GB).
I was expecting less than 8GB was needed contemporary so I was expecting some old stuff (no more used) was released and VRAM allocated for new stuff keeping the VRAM on the limit of 8GB.
Maybe 8GB is not enough for RS 4K and I can set the limit to 16GB (I suppose that limit should be enough to start reusing the VRAM).
Marking as a bug. Memory management was tightened a few years ago so that even 512MB of VRAM was enough for AAA titles at 100% res scale.
Attached the log file (app crashed after less than 1 min for limit reached of 8GB) with the following settings in the GPU tab:
I also noted that with Multithreaded RSX disabled when the 8GB limit is reached the eviction is done and I see slowdown (e.g. when from 9.2GB the VRAM drops to 8.2GB) as in the attached video. The crash for the limit reached does not happen.
https://github.com/user-attachments/assets/de99ef33-e062-4385-8cff-ee0fa0943f9b
Looking at the first log without MTRSX I see the allocator tried to reclaim 4GB just before crashing. The crash doesn't enter into memory recovery either which means I might need to rebalance the thresholds a bit more. Second log looks like what I'd expect though it should have started spilling sooner to avoid excessive hitching.
Looking at the first log without MTRSX I see the allocator tried to reclaim 4GB just before crashing. The crash doesn't enter into memory recovery either which means I might need to rebalance the thresholds a bit more. Second log looks like what I'd expect though it should have started spilling sooner to avoid excessive hitching.
yes, in second case (MTRSX disabled) the behavior is ok although it basically creates continuous slowdown (the memory is always on the limit of the 8GB) making the gameplay impossible. But I do not understand why this is the only game I own where I see the VRAM growing up to the limit (e.g. KZ3 remains below 4GB)
Looking at the first log without MTRSX I see the allocator tried to reclaim 4GB just before crashing. The crash doesn't enter into memory recovery either which means I might need to rebalance the thresholds a bit more.
First log with the crash (for limit reached) is WITH MTRSX