Emulator Issues #7554
closedHigh memory consumption when using OpenGL
0%
Description
Game Name?
Metroid Prime 2 (Trilogy edition)
Game ID?
R3MP01
What's the problem? Describe what went wrong in few words.
While playing with OpenGL selected as graphics backend memory consumption slowly increases, eventually (after a few hours) leading to
- ingame slowdowns
- warnings from windows about little memory being available
- sometimes dolphin crashes when exiting emulation or quitting dolphin
What did you expect to happen instead?
Memory consumption staying almost constant after some time, as is the case when using Direct3D
What steps will reproduce the problem?
- Select OpenGL as graphics backend
- Play for some time. Walk around the world, visiting different rooms, ... I am at the moment playing in the Torvus world, both light and dark.
Dolphin 3.5 and 3.5-367 are old versions of Dolphin that have
known issues and bugs, so don't report issues about them and test the
latest Dolphin version first.
Which versions of Dolphin did you test on?
4.0-2474 (latest as of 08/08/2014)
Does using an older version of Dolphin solve your issue? If yes, which
versions of Dolphin used to work?
I noticed this also with some older 4.0 builds.
I don't remember having this issue with 3.0 / 3.5 builds, but possibly I used the Direct3D backend.
What are your PC specifications? (including, but not limited to: Operating
System, CPU and GPU)
OS: Windows 8.1 x64
CPU: AMD FX 8350 @ 8x4 GHz
Memory: 8 GB DDR3
GPU: Sapphire Radeon 6870, 1GB memory, Catalyst 14.4 drivers
Is there any other relevant information? (e.g. logs, screenshots,
configuration files)
http://imgur.com/NutUiN1,wWzrrdq#0
http://imgur.com/NutUiN1,wWzrrdq#1
Memory usage when idle and after running dolphin for some time.
Difference in memory usage is about 5.5 GB
About 1 GB are for Firefox and Steam, the rest is dolphin although it claims to use only 2.7 GB. When quitting dolphin (entirely, stopping the emulation is not enough) Much more memory is freed than what it states to use. During tests with no other programs running memory consumption dropped from ~7 GB to ~1.5 GB when quitting dolphin.
Possibly this is related to issue 6942, but I haven't observed issues with graphics memory.
Updated by JMC4789 over 10 years ago
I have a feeling this is more related to issue 6101 which is partially my fault.
Updated by kodiacktech about 10 years ago
I have been able to reproduce this in Pokémon Puzzle League. Puzzle League actually increases virtual memory use at an alarmingly fast rate, however! If you have Puzzle League available, you can test this by simply opening the game and attempting to move around on the game selection menu/map. The first time around it caused Windows to whine about low memory, and the second time around it actually crashed Chrome/Pidgin and black screened my system. I haven't seen this sort of instability since I wrote a C++ program that does nothing but leak memory until there's no system memory left to leak. :P
Updated by kodiacktech about 10 years ago
Also, Dolphin's commit size after being on the Puzzle League map for maybe five seconds:
http://i.imgur.com/IwllrX9.png
The game has to be closed quickly after Dolphin's screen goes black, otherwise stuff starts exploding. :)
Updated by degasus about 10 years ago
What is needed to free this memory again? Is it enough to invalidate the texture cache (change the hash accurency), does destroying the ogl context work (close the emulation, but not dolphin), or do you really have to terminate the process?
Updated by kodiacktech about 10 years ago
It looks like I'm able to free up the address space by either nuking the emulation or changing the texturca
Updated by crazysheep17 about 10 years ago
Ok, strike what i said. Changing texture accuracy was supposed to have been fixed.
Updated by kodiacktech about 10 years ago
Disregard that last comment. I was doing some testing, accidentally kept Puzzle League running for about twenty seconds, and it consumed dozens of gigabytes of memory, crashing things and forcing a logout. Accidentally submitted the comment when I reopened Chrome. >_>
Anyways, some fun information about this peculiar bug:
•At least in the case of Puzzle League, Dolphin will only leak address space when the screen "goes black".
•Changing the texture cache accuracy DOES free up the consumed virtual memory, dropping Dolphin to a rather cozy ~500 MB
•Invalidating the texture cache also restores the expected image in the emulator, albeit only for a very brief time
•Simply stopping emulation by hitting escape also releases the consumed address space, dropping the emulator to a completely normal ~100-150 MB
Updated by kodiacktech about 10 years ago
I was talking to degasus in #dolphin-dev about this, and after further testing it appears that this will only happen when EFB copies are enabled. Disabling them in Puzzle League will produce a black screen, although Dolphin's commit size will remain static.
Additionally, this occurs at a significantly faster rate the higher the IR is set to. This is probably why it's such a major issue on my system: I'm pushing 6xIR!
Direct3D also appears to exhibit this issue, although its symptoms are a bit different. I was unable to ever see the increasing memory usage or commit size in Task Manager, although GPU-Z reported that the dynamic VRAM usage hit OVER SEVEN GIGABYTES on the Puzzle League title screen. Upon going to the map, it dropped to "only" a couple of gigabytes, but Windows whined about memory usage shortly after, a bunch of programs crashed, and then Dolphin finally crashed. Again, that memory usage was not visible in Task Manager.
Updated by ZephyrSurfer almost 10 years ago
The title is wrong then if this also affects D3D. Right?
Updated by JMC4789 almost 10 years ago
We have a few issues with this, and need to condense them to a global issue.
Updated by ZephyrSurfer almost 10 years ago
Is this at all related with the texture cache increasing rapidly issue that Asmodean mentioned/reported on the forums? I can't link right now though...
Updated by degasus almost 10 years ago
iirc this is because of our hash missmatches because of tlut changes. So we'll hold much too many textures within the cache, which just waste VRAM. OGL will use huge memory, D3D will crash :/
Updated by ZephyrSurfer almost 10 years ago
So what happens with the hashless branch in this case? Can that be tested then so? It should work as expected I guess?
Updated by SeeebM over 9 years ago
I have the same problem with dolphin 4.0-6131 (windows) and Resident Evil 4 Pal.
Dolphin uses about 2 GB of RAM when I start the game and the memory consumption slowly increases until crash.
I have a big User/ShaderCache/ogl-G4BP08-shaders.cache file (about 330 MB).
If I delete this file and then restart the game, dolphin uses about 450 MB of RAM but the memory consumption still increases while playing.