yuzu icon indicating copy to clipboard operation
yuzu copied to clipboard

Splatoon 2 Memory Leaks Whenever a Loading Screen Shows Up and Ultimately Crashes

Open Lt-knb opened this issue 3 years ago • 6 comments

Ryzen 7 2700

RAM 16 GB Gtx 1070 Windows 10 1909 Nvidia driver game ready 471.11 Yuzu Early Access 1891

This is a TCR regression.

Splatoon 2 is currently not playable from start to finish in a single session on OpenGl due to the following:

Whenever an area change occurs (a loading screen is triggered) yuzu adds about 0.2/0.6 GB of RAM and 0.2/0.4 GB of VRAM, ultimately resulting in yuzu crashing. This also does not fill up entire RAM/VRAM due to yuzu crashing before reaching memory limits, for some reason.

Logs reflect the behavior, adding a ridiculous amount of NVDRV: STUBBED (CALLED) stacked together as soon as the area change starts, then gathers several “Mip cannot be aliased” and “Cleared event wait on, event_id: 0” at the end of the area change. This causes the log to be mostly comprised of these endless warning piles.

This makes the game playable for about 7 or 8 Octo Canyon levels (I did not test Octo Expansion) depending on where you go exactly and in what order (but varies depending on how complete your shader cache is. Mine is currently at the first quarter from completion, so about 2600), then you can expect a crash anytime.

The OpenGl renderers all exhibit this behavior, while it's fixed in Vulkan by enabling the Garbage Collector (logs are identical though).

I did several tests with graphic settings enabled/disabled with the only differences being reintroducing the pitch black shadows when I disabled Asynchronous GPU (so I recommend leaving it always on) and Asynchronous Shader Compilation causing yuzu to crash way earlier with a different type of warning at the end of the logs (so always leave it disabled).

Enabling the Reaper Garbage Collector on OpenGl makes no difference at all.

Also tested Unsafe CPU. Disabling Multicore gets rid of the “event_id: 0” warnings but nothing else changes.

I don't know if AMD and Intel GPUs are affected.

Quick steps to easily reproduce under 6 min:

Go to Octo Canyon and start repeatedly jumping to other sectors with the map until it crashes. 25 times should be enough but may also depend on RAM and VRAM capacity.

Normal more natural steps:

Just speedrun 8 or more Octo Canyon levels. It will crash eventually…

Log (still the old one):

yuzu_log.txt

Also the following happened in a test in which building new shaders was involved (log is 100 mb):

yuzu_log.zip

Lt-knb avatar Jul 11 '21 21:07 Lt-knb