Project

General

Profile

Actions

Emulator Issues #6101

closed

Excessive VRAM usage in Pokémon XD: Gale of Darkness

Added by julian.bragard about 11 years ago. Updated over 8 years ago.

Status:
Fixed
Priority:
Urgent
Assignee:
-
Category:
GFX
% Done:

100%

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

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.

Actions #1

Updated by degasus about 11 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?

Actions #2

Updated by skidau about 11 years ago

Yes, it's a memory leak because the efb copies have no means to expire, bar shutting down Dolphin.

Actions #3

Updated by julian.bragard about 11 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

Actions #4

Updated by degasus about 11 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?

Actions #5

Updated by NeoBrainX about 11 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 :(

Actions #6

Updated by degasus about 11 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?

Actions #7

Updated by NeoBrainX about 11 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.

Actions #8

Updated by NeoBrainX about 11 years ago

  • Priority set to High
  • Milestone set to Current
Actions #9

Updated by Billiard26 almost 11 years ago

  • Issue type set to Bug
Actions #11

Updated by NeoBrainX over 10 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.

Actions #12

Updated by NeoBrainX about 10 years ago

  • Milestone set to Current

Let's maybe keep this in mind for the next release...

Actions #13

Updated by delroth almost 10 years ago

  • Priority changed from High to Urgent
Actions #14

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

Actions #15

Updated by phire almost 9 years ago

Does this bug still exist? Some stuff in texture cache was fixed up.

Actions #16

Updated by julian.bragard almost 9 years ago

Just tested with 4.0-6454: Seems to be still valid as described above.

Actions #17

Updated by mimimi over 8 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.

Actions #18

Updated by julian.bragard over 8 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

Actions #19

Updated by JMC4789 over 8 years ago

  • Status changed from Accepted to Fixed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF