New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High virtual memory usage on macOS #2416

Closed
roberthharvey opened this Issue Jan 8, 2017 · 37 comments

Comments

Projects
None yet
@roberthharvey
Copy link

roberthharvey commented Jan 8, 2017

issue 1 #2415

here is the ram problem (it keeps building... did not wait till it got to breaking point this time only to about 30GBs)

screen shot 2017-01-08 at 3 44 54 pm

screen shot 2017-01-08 at 3 20 03 pm

game: PKM Moon, build (tried last 4, same issue)

Hardware Overview:

Model Name: MacBook Pro
Model Identifier: MacBookPro11,4
Processor Name: Intel Core i7
Processor Speed: 2.2 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 6 MB
Memory: 16 GB
Boot ROM Version: MBP114.0172.B10
SMC Version (system): 2.29f24

@MerryMage MerryMage changed the title 2 of 2 bugs - 1) screen moves up on stretching & 2) VRAM usage over 68GBs... High VRAM usage on macOS Jan 8, 2017

@MerryMage MerryMage changed the title High VRAM usage on macOS High virtual memory usage on macOS Jan 8, 2017

@roberthharvey

This comment has been minimized.

@mailwl

This comment has been minimized.

Copy link
Contributor

mailwl commented Jan 8, 2017

never saw memory leaks on mac. it's pokemon only issue?

@cherrytwizzler

This comment has been minimized.

Copy link

cherrytwizzler commented Jan 8, 2017

My mac has the same issue with pokemon sun and virtue's last reward
I don't have my computer on me rn but I know it has 8G ram and it's running on El capitan ver. 10.11.5
My game gets the device has run out of application memory message at about 20G of memory usage on activity monitor though but I guess that's because you have more ram than I do

@pippo2931

This comment has been minimized.

Copy link
Contributor

pippo2931 commented Jan 8, 2017

@mailwl See #1701 too.
There is a bunch of other games that have the same problem:
Paper Mario Sticker Stars, Yokai Watch, Shin Megamy Tensei 4
In top you can see CMPRS memory building up.

One way to slow the leak is to disable "scaled resolution"

@wwylele

This comment has been minimized.

Copy link
Member

wwylele commented Jan 8, 2017

I am not a macOS user. If possible, could someone using macOS debug citra, and see if this memory is "leaked"(meaning no live reference to them), or actually be occupied by some object? (for example a big vector or map) Which object is it?

We used to have a similar issue, which turns out to be an std::unordered_map being inflated by items whose hash are wrongly calculated. Probably we can think in this way.

@roberthharvey

This comment has been minimized.

Copy link

roberthharvey commented Jan 8, 2017

@wwylele how? which debugger...

@mailwl

This comment has been minimized.

Copy link
Contributor

mailwl commented Jan 8, 2017

Xcode is good

@roberthharvey

This comment has been minimized.

Copy link

roberthharvey commented Jan 8, 2017

@wwylele umm... how do you debug a live program in Xcode?...

@FernandoS27

This comment has been minimized.

Copy link
Contributor

FernandoS27 commented Jan 8, 2017

It's quite probably a problem with OpenGL Drivers in Mac.

http://aras-p.info/blog/2007/07/14/debugging-story-video-memory-leaks/

a fast fix would be forcing an unbinding of the textures when flushing the texture cache.

@Subv

This comment has been minimized.

Copy link
Member

Subv commented Jan 8, 2017

@roberthharvey Could you please try to use an OpenGL memory profiler to see if the GPU textures are what's causing the leak? Please report the video memory usage when playing the affected game.

@FernandoS27

This comment has been minimized.

Copy link
Contributor

FernandoS27 commented Jan 8, 2017

add this:
GLuint tmp[1] = {texture_to_flush};
glDeleteTextures(1,tmp);

to: https://github.com/citra-emu/citra/blob/master/src/video_core/renderer_opengl/gl_rasterizer_cache.cpp#L756

if it reduces the leaks then that's what's happening.

@roberthharvey

This comment has been minimized.

Copy link

roberthharvey commented Jan 8, 2017

@FernandoS27 still goes mental
screen shot 2017-01-09 at 3 27 10 am

@jroweboy

This comment has been minimized.

Copy link
Member

jroweboy commented Jan 8, 2017

@roberthharvey that bit of code wasn't meant to fix the terminal spam (which is harmless). what about the ram usage?

@roberthharvey

This comment has been minimized.

Copy link

roberthharvey commented Jan 8, 2017

@Subv this?

screen shot 2017-01-09 at 3 31 28 am

[Screen Recording 2017-01-09 at 3.30.46 AM.mov.zip](https://github.com/citra-emu/citra/files/692402/Screen.Recording.2017-01-09.at.3.30.46.AM.mov.zip)

@jroweboy I think its worse... ramped up really quickly...

Sample of Citra.txt
screen shot 2017-01-09 at 3 35 07 am

@pippo2931

This comment has been minimized.

Copy link
Contributor

pippo2931 commented Jan 8, 2017

Still leaking.
One thing I noticed that reduces the leak is using the native resolution.

@roberthharvey

This comment has been minimized.

Copy link

roberthharvey commented Jan 8, 2017

@pippo2931 I found dropping to the lowest was the best.

@Subv opening the graphics debugger make the app unesponsive but it does not crash or pause emulation.

screen shot 2017-01-09 at 3 41 06 am

@Lord-Kamina

This comment has been minimized.

Copy link

Lord-Kamina commented Jan 8, 2017

Just chiming in to say I was just running a version I compiled myself with pokemon sun on a hackintosh with an i7-3770 and a GTX980 and virtual memory didn't go above 3GB. Oddly enough though, I think it runs better on my actual 2011 MBP (Sandy bridge i7 can't remember exact model and Radeon 6770)

@FernandoS27

This comment has been minimized.

Copy link
Contributor

FernandoS27 commented Jan 8, 2017

the line I told to add, compare before adding the line and after adding it. Leaks won't be done but they should reduce significantly (there's still FBO leaking...)

@pippo2931

This comment has been minimized.

Copy link
Contributor

pippo2931 commented Jan 9, 2017

I don't see a big change
After two minutes, 4X resolution, same scene, same game, 1 GB leaked.
Original
PID COMMAND %CPU TIME #TH #WQ #POR MEM PURG CMPRS PGRP PPID
47756 citra-qt 90.2 02:00.58 14/1 9 279 481M+ 0B 1023M+ 47756 38372
With line change
PID COMMAND %CPU TIME #TH #WQ #POR MEM PURG CMPRS PGRP PPID
7011 citra-qt 85.0 02:03.43 14/1 9 294 489M+ 0B 1008M+ 47011 38372

I assume that the compressed memory is the leaked memory because when compressed reaches 20GB my system crashes.

Native resolution has a bigger active memory usage, but a slower leakage to compressed.
PID COMMAND %CPU TIME #TH #WQ #POR MEM PURG CMPRS PGRP PPID
48533 citra-qt 98.1 05:06.83 14/1 9 276 3373M+ 0B 214M 48533 38372

@archshift

This comment has been minimized.

Copy link
Contributor

archshift commented Jan 9, 2017

@pippo2931 I've tried a few games, and can't reproduce it. Admittedly not the games you listed, though. Must not be some universal thing.

@archshift

This comment has been minimized.

Copy link
Contributor

archshift commented Jan 9, 2017

Never mind, it's happening on the Yo-Kai demo.

@FernandoS27

This comment has been minimized.

Copy link
Contributor

FernandoS27 commented Jan 9, 2017

Well in that case let's make sure where the issue is.

Run citra without hardware renderer, if the problem persists, run it without shader jit, if the problem persists run it without cpu jit.

@pippo2931

This comment has been minimized.

Copy link
Contributor

pippo2931 commented Jan 9, 2017

Run citra without hardware renderer: leak
run it without shader jit: no leak - Only 263MB in use

@cherrytwizzler

This comment has been minimized.

Copy link

cherrytwizzler commented Jan 9, 2017

I tried running w/out the shader but the same thing happened after a few minutes (and the emulation was also very slow compared to running it with the shader)
screen shot 2017-01-08 at 10 43 50 pm

@cherrytwizzler

This comment has been minimized.

Copy link

cherrytwizzler commented Jan 9, 2017

and running without the cpu jit does impede the leakage for a little before falling back into the same trend

@FernandoS27

This comment has been minimized.

Copy link
Contributor

FernandoS27 commented Jan 16, 2017

Well I'll check this out next once I find my doodle for my hackintosh.

@pippo2931

This comment has been minimized.

Copy link
Contributor

pippo2931 commented Jan 23, 2017

Add Zelda Majoras Mask to the list.

@bouch44

This comment has been minimized.

Copy link

bouch44 commented Feb 18, 2017

Has anyone found a solution to this? About a month later and no posts =/ Hoping so, seems like I can only run for about 10-15 minutes before Application Memory message returns. Hopefully have saved at that point.... Any help would be greatly appreciated =]

@roberthharvey

This comment has been minimized.

Copy link

roberthharvey commented Mar 29, 2017

so, I have not ran this app since this issue, no point. but it has been some time now so devs any news?

anyone find a fix/workaround

@cherrytwizzler

This comment has been minimized.

Copy link

cherrytwizzler commented May 13, 2017

@roberthharvey the most recent builds of citra fixed the issue I was having with pokemon sun on my mac. I was able to play for a solid hour without any issues. Maybe try downloading the most recent nightly and see what happens
However, the problem still persists with other games such as shin megami 4 and majora's mask idk why

@JayFoxRox

This comment has been minimized.

Copy link
Member

JayFoxRox commented May 20, 2017

All this talk without progress just lowers Signal to Noise ratio.

If you want it fixed, bisect it [google how to bisect / what bisecting does and do it]

@B3n30

This comment has been minimized.

Copy link
Contributor

B3n30 commented Jul 19, 2017

I spent some time, trying to find the issue. Here are my results:

  • It's not a memory leak. The memory get freed as soon as the emuThread is destroyed
  • It's some memory OpenGL uses (probably for textures) and it never gets freed.
    Using OpenGL Monitor Driver shows exactly that behavior:

bildschirmfoto 2017-07-19 um 17 02 04

The first raising is while having the emu-window open. Closing the emu-window doesn't cause the textures to get destroyed. Only by starting the game again, the emuThread (and therefore all textures) get destroyed.
@roberthharvey

This comment has been minimized.

Copy link

roberthharvey commented Jul 19, 2017

so ok, this was a problem in unity a while back, the fix there was a string that effectively forced non-viewed textures to be unloaded from memory stack.

Resources.UnloadUnusedAssets();

probably the wrong language, probably not the fix, hope it still helps!

@pippo2931

This comment has been minimized.

Copy link
Contributor

pippo2931 commented Dec 9, 2017

I don't see this anymore on High Sierra and latest citra.

@wwylele

This comment has been minimized.

Copy link
Member

wwylele commented Mar 5, 2018

Fixed by #3281 as reported so closing. Feel free to reopen if it is not the case.

@wwylele wwylele closed this Mar 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment