Project

General

Profile

Actions

Emulator Issues #7554

closed

High memory consumption when using OpenGL

Added by sascha.riemer over 9 years ago. Updated about 6 years ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

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?

  1. Select OpenGL as graphics backend
  2. 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.

Actions #1

Updated by JMC4789 over 9 years ago

I have a feeling this is more related to issue 6101 which is partially my fault.

Actions #2

Updated by kodiacktech over 9 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

Actions #3

Updated by kodiacktech over 9 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. :)

Actions #4

Updated by degasus over 9 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?

Actions #5

Updated by kodiacktech over 9 years ago

It looks like I'm able to free up the address space by either nuking the emulation or changing the texturca

Actions #6

Updated by crazysheep17 over 9 years ago

Ok, strike what i said. Changing texture accuracy was supposed to have been fixed.

Actions #7

Updated by kodiacktech over 9 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

Actions #8

Updated by kodiacktech over 9 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.

Actions #9

Updated by ZephyrSurfer over 9 years ago

The title is wrong then if this also affects D3D. Right?

Actions #10

Updated by JMC4789 over 9 years ago

We have a few issues with this, and need to condense them to a global issue.

Actions #11

Updated by ZephyrSurfer over 9 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...

Actions #12

Updated by degasus over 9 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 :/

Actions #13

Updated by ZephyrSurfer over 9 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?

Actions #14

Updated by SeeebM almost 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.

Actions #15

Updated by Helios about 6 years ago

  • Status changed from New to Invalid

Cannot reproduce. Closing

Actions

Also available in: Atom PDF