Emulator Issues #6101
closed
Excessive VRAM usage in Pokémon XD: Gale of Darkness
100%
Description
Game Name?
Pokémon XD: Gale of Darkness
Game ID?
GXXP01
What version of Dolphin were you using?
3.5-429
64 or 32 bit Dolphin?
64 bit
What version of Dolphin used to work?
3.5-426 and previous versions
What Operating System were you using and what are your hardware
specifications?
Windows 7 64 bit
i7-2600k
Geforce 580 GTX
8 GB RAM
Any other relevant information or links to logs:
The video memory usage (NOT system memory) steadily rises while Pokemon XD: Gale of Darkness, especially when fighting a lot of trainers, e.g. at Mt. Battle.
I noticed this by watching the msi afterburner hardware monitor showing the video memory load increasing continuously.
Also, there seem to be a lot of random crashes and freezes (fps drop to zero), i don't know if this is related to the problem.
However you can clear the video memory "manually" by changing the texture cache accuracy (either from safe to fast, or from fast to safe, doesn't matter)
This happens in all versions 3.5-429 and above with all backends and does not happen in revisions 3.5-426 and below as far as i can tell.
Other GC games don't seem to affected by this.
Updated by degasus almost 12 years ago
- Status changed from New to Questionable
Introduced by revision 1141af64f64b - TextureCacheBase: Do not assume EFB copies can safely be deleted when we think they're "unused".
This is common, if the game copys the efb content to different places. But we can't know if this texture may ever be used again, so we have to store it.
How much vram do dolphin use if you don't clear it with your "workaround" ? btw, I think your workaround is a bug.
Does the crashes also happens on 3.5-426?
Updated by skidau almost 12 years ago
Yes, it's a memory leak because the efb copies have no means to expire, bar shutting down Dolphin.
Updated by julian.bragard almost 12 years ago
The video memory will actually increase until it's full, in my case consuming the whole 1.5 GB of vram my graphics card has (if dolphin hasn't crashed until then of course).
3.5-426 seems to be stable
Updated by degasus almost 12 years ago
skidau: efb copys shouldn't expire at all, so just don't expire shouldn't result in a memory leak.
but 1.5 GB textures are quite too much. So maybe overwriting textures (they should be deleted there) isn't working?
Updated by NeoBrainX almost 12 years ago
- Status changed from Questionable to Accepted
- Category set to gfx
- Operating system N/A added
EFB copies don't get invalidated at all with EFB2tex intentionally (not even when a new EFB copy partially overwrites an existing EFB copy etc).
As a solution, we should encode EFB copy data to RAM when we really need to free up some VRAM. Should be easy enough for anyone to fix, since it's basically just a matter of changing around the EFB copy interfaces.
The true solution of course would be to finally get any kind of resource manager into Dolphin, but I guess no one bothers to write the code for it :(
Updated by degasus almost 12 years ago
"not even when a new EFB copy partially overwrites an existing EFB copy etc"
isn't this the bug?
ok, if row_length matches, the textures should be upgraded, but if not, shouldn't we drop the old one?
Updated by NeoBrainX almost 12 years ago
"isn't this the bug?"
Not really, since the behavior is intended. It's stupid, but so is the whole EFB2Texture hack. You could ofc try invalidating existing copies on overwrites and see how many games get broken with that.
Updated by NeoBrainX over 11 years ago
- Priority set to High
- Milestone set to Current
Updated by
Updated by NeoBrainX over 11 years ago
- Milestone deleted (
Current)
This is not going to get fixed for 4.0, I fear.
I don't want to touch any of the texture cache code anymore, it's just so fundamentally broken. Someone implement the texcache-rewrite changes properly already >_>
As a workaround, lower your Internal Resolution or disable scaled EFB copies.
Updated by NeoBrainX almost 11 years ago
- Milestone set to Current
Let's maybe keep this in mind for the next release...
Updated by
Updated by JMC4789 over 10 years ago
- Milestone changed from Current to Next
Because of stuff like Locking, The TexCache rewrite, and other things being basically blocked until after next release, I'm moving this to milestone-next.
Updated by phire over 9 years ago
Does this bug still exist? Some stuff in texture cache was fixed up.
Updated by julian.bragard over 9 years ago
Just tested with 4.0-6454: Seems to be still valid as described above.
Updated by mimimi about 9 years ago
Needs to be tested if 4.0-7664 fixed this. Maybe also test of 4.0-7630 improved the problem for efb2tex before the real fix.
Updated by julian.bragard about 9 years ago
4.0-7664 seems to have fixed it! After an hour of gameplay with efb2texture aswell as efb2ram, the VRAM usage is still stably hovering between 400 and 500 MB (with 300MB idle).
Graphics Card: Geforce 760, 2GB VRAM
Updated by JMC4789 about 9 years ago
- Status changed from Accepted to Fixed
- % Done changed from 0 to 100