Project

General

Profile

Actions

Emulator Issues #636

closed

Safe texture cache massive slowdown, ends in crash when resizing screen.

Added by federelli over 15 years ago.

Status:
Fixed
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

What steps will reproduce the problem?

  1. Play Metroid Prime USA till the game slow downs to less than 1fps. Try
    swaping in and out of scanner a bunch of times on a low fps area (eg
    magmoor cavern).
  2. Resize the screen when that happens.
  3. Whatch the emulator shutdown with no error msg.

What is the expected output? What do you see instead?
Normal behaviour when resizing, no shutdown, no slowdown.

What version of the product are you using? On what operating system?
r2397 WX SP3 32bit JIT/JITIL, been happening for quite some revisions now,
over 500 at least.

Please provide any additional information below.
Does not happen with safe texture cache on, and also without it the game
runs 5 times as fast, although without it, it also crashes with a TLB error


Related issues 1 (0 open1 closed)

Has duplicate Emulator - Emulator Issues #655: Safe Texture Cache huge slowdown buDuplicate

Actions
Actions #1

Updated by gustavorios2 over 15 years ago

I never have tested Metroid Prime... but safe texture here don't seems to cause any
slowdown here in my games...

Actions #2

Updated by federelli over 15 years ago

Happens in r2069 too, it's the oldest build i got.

I'll add some more to the descripion, the game slows down to a massive less than 1
fps. Alt-tabbing fixes the slowdown, exiting fullscreen also fixes the slowdown, but
when returning to fullscreen, or reziging the screen, the emulator closes with no
warning. Only happens with safe texture cache on as far as i can tell, sadly you
can't play more than 10 seconds without safe texture cache on, the game is so fast
without it on tho.

Actions #3

Updated by federelli over 15 years ago

Safe Texture Cache is only used by Metroid Prime afaik.

Actions #4

Updated by sl1nk3.s over 15 years ago

Not only, it fixes some issues with fonts in a few games, and also seems to fix a
color issue in Starfox assault during transmissions. it may as well fix other games...

Actions #5

Updated by federelli over 15 years ago

Well, give it a try if you can, scenes were u get 10 fps with safe texture cache, you
get 50 without.

Actions #6

Updated by federelli over 15 years ago

I'm exagerating tho, it's probably 20% faster without sfc on.

Actions #7

Updated by federelli over 15 years ago

Another bug, enabling and disabling SFC makes some texture change color.

Actions #8

Updated by federelli over 15 years ago

By SFC i meant STC.

A game where STC kills performance too is in Resident Evil Remake's in-game menu,
from 30fps it goes to 5fps, not exagerating.

Actions #9

Updated by zantezuken over 15 years ago

Confirmed. STC causes overall slowdown (~30%). Tested with MP1 and ToS.

Actions #10

Updated by Anonymous over 15 years ago

Issue 655 has been merged into this issue.

Actions #11

Updated by federelli over 15 years ago

While STC does kill performance, it is not the cause for the massive slowdowns and
crashes, if someone would care to rename the issue, please do.

Actions #12

Updated by zantezuken over 15 years ago

Yeah, I agree. It just kill performance, not random slowdowns.

Actions #13

Updated by marcus over 15 years ago

So this doesn't happen when it's disabled?

Actions #14

Updated by federelli over 15 years ago

Read what i commented, it does.

Actions #15

Updated by marcus over 15 years ago

sorry...I kinda missed that...

Actions #16

Updated by federelli over 15 years ago

Recap:

STC causes a 20-90% slowdown depending on the game.

Something else, causes a massive slowdown to less than 1 fps which makes the emu
crash when resizing the screen.

Actions #17

Updated by marcus over 15 years ago

Sounds like the texture cache becomes full, and that's why it slows down. When you
resize the screen, it just completely overloads and implodes.

Actions #18

Updated by Autoran1 over 15 years ago

The issue was commited first time in rev1878 by magumagu, i can only make a patch
file to fix this slowdowns up to 1879

Actions #19

Updated by marcus over 15 years ago

+1 for effort in the research department, Autor.

So we just have to look up where the problem is in r1878 and then revert it. I'll
see what I can do to find it, but I probably won't have a clue.

Actions #20

Updated by Autoran1 over 15 years ago

my mistake first time issue was commited in 1872

Actions #21

Updated by marcus over 15 years ago

Again, thanks for your effort (It makes what I want to do easy).

No wonder I couldn't find anything in r1878...

Actions #22

Updated by Autoran1 over 15 years ago

Glad to help, i spent all yesterday for tests and found that problems of slowdowns
is in Source/Core/VideoCommon/Src/TextureDecoder.cpp now i now for sure that
slowdowns occured in 1880, made some tests: i've compiled OGL r1941 with
TextureDecoder.cpp r1878 and now i can play MP2 without slowdowns

Actions #23

Updated by marcus over 15 years ago

In your testing, you probably made a patch file which fixes the problem. Why don't
you host it somewhere and post a link to it, and see if the devs will commit it.

Actions #24

Updated by Autoran1 over 15 years ago

Finally here's the fix for this issue, particaly reverted code from 1871
in Source/Core/VideoCommon/Src/TextureDecoder.cpp
i've changed this
line 80
// Notes (mb2): A relative important mess in data is needed for a good hash.
The safest way to satisfy this would be
// to perform the hash on the whole texture. But since it kills perf we use
some assuptions for speed:
// -First assumption: texture borders don't carry more different data than
the rest of the texture. We skip few
// texels on the edges.
// -Second assumption: consecutives lines may not differ that much. We skip
some lines regularly.
// -Third assumption: User info (messy datas), in textures, should be either
always centered or at the beginning.
// So we can stop hashing near the center.

    // very tweakable (Pokemon Colesseum texts are pretty good test cases, 

especially short ones)
const int edgeSkip = 3;
const int colSkip = 3;
const int rowSkip = 5;

    const int rowEnd = (width - edgeSkip)/4;
    const int byteWidth = TexDecoder_GetTextureSizeInBytes(width, 1, texformat);
    const int colEnd = height / 2 - edgeSkip;

to this
int sz = TexDecoder_GetTextureSizeInBytes(width, height, texformat);
and this
line 98
for (int y = edgeSkip; y < colEnd; y += colSkip)
{
for (int x = edgeSkip; x < rowEnd; x += rowSkip)
{
hash = _rotl(hash, 17) ^ ((u32 )src)[x+byteWidthy];
to this
if (sz < 2048) {
for (int i = 0; i < sz / 4; i += 13) {
hash = _rotl(hash, 17) ^ ((u32 *)src)[i];
}
return hash;
} else {
int step = sz / 13 / 4;
for (int i = 0; i < sz / 4; i += step) {
hash = _rotl(hash, 17) ^ ((u32 *)src)[i];

and everything workable again^_^
patch file is here http://rapidshare.com/files/204563013/SafeTextureCache.rar.html

Actions #25

Updated by Autoran1 over 15 years ago

there also fix for hack 844 in the patch but it seems it already fixed in latest
rev, so here an updated patch
http://rapidshare.com/files/204566165/SafeTextureCache.rar.html

Actions #26

Updated by marcus over 15 years ago

Well it builds! Now just wait until they commit it...

Actions #27

Updated by hrydgard over 15 years ago

  • Status changed from New to Accepted

Looks like this patch just reverts to old behaviour (plus changes a sign in the
projection matrix - was that meant to be included?). This might be a good thing - i
wrote the original hasher and am a bit suspicious of the newer one that you reverted
;)

Does it break Pokemon Colosseum?

Actions #28

Updated by hrydgard over 15 years ago

It does break it, but the normal texture cache works fine. That makes it sort of
acceptable for now :)

Actions #29

Updated by federelli over 15 years ago

Wow, tyvm Autor for taking your time to look into this, and ector too.

Actions #30

Updated by hrydgard over 15 years ago

  • Status changed from Accepted to Work started

Submitted a variant of this. Let me know if it helps. Pokemon be damned for now :)

Actions #32

Updated by federelli over 15 years ago

Testing some right now, hot-swapping STC's, now makes more artifacts appear than
before, shows up as texture corruption, white/magenta.

It seems to have no performance effect in Metroid at all now, good job, get the
artifact thingies out of the way and issue closed.

Actions #33

Updated by federelli over 15 years ago

Anyway now that we know that STC wasn't the cause for the slowness we gotta figure
out why.

Right now in r2588, when the game slows down to a crawl, <1fps, exiting fullscreen
brings it back to 50fps, and when going back to fullscreen it no longer crashes, but
eventually degrades back to <1fps slowly.

Actions #34

Updated by federelli over 15 years ago

Nvmd it just crashed on my 3rd/4rd fullscreen/windowed swapping.

Actions #35

Updated by marcus over 15 years ago

This sounds like it might be a duplicate of issue 588 (even though it's marked as
fixed, I'm still having occasional problems), but someone with a better knowlege of
the problem should look at it. Does memory consumption go up as the framerate drops?

Actions #36

Updated by federelli over 15 years ago

Nop.

Actions #37

Updated by marcus over 15 years ago

darn.

Actions #38

Updated by federelli over 15 years ago

Unable to reproduce this bug in r2728, whatever was touched, seemed to have fixed the
massive slowdown issue.

Actions #39

Updated by marcus over 15 years ago

  • Status changed from Work started to Fixed

we can probably close this now then,

Actions #40

Updated by federelli over 15 years ago

There is something seriously wrong with that room in Metroid. Now that we have the
logmanager this is what i get when i enter it.

This first line 8 times
36:16:640 E: Video .\Src\TextureMngr.cpp:475:
(TextureMngr::CopyRenderTargetToTexture) OpenGL error 0x502 - invalid operation

36:16:703 W: SI GBA 1 CMD_STATUS
36:16:703 E: Video .\Src\PixelShaderCache.cpp:180:
(PixelShaderCache::CompilePixelShader) OpenGL error 0x506 - (null)

36:16:703 E: Video glError 00000506 before PS!
36:16:734 W: SI GBA 1 CMD_STATUS
36:16:781 W: SI GBA 1 CMD_STATUS
36:16:781 E: Video .\Src\VertexShaderCache.cpp:138:
(VertexShaderCache::CompileVertexShader) OpenGL error 0x506 - (null)

36:16:812 E: Video glError 00000506 before VS!

and that last line repeats itself to infinity.

What you can see game wise is that most textures turn black and game slows down
massively to <1 fps until eventually it just stops rendering.

Resizing the window makes it go back to full fps, but it slowly degrades back again
to <1 fps.

So the only thing that has been fixed is the resize crash.

Actions

Also available in: Atom PDF