Emulator

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

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.

Safe Texture Cache is only used by Metroid Prime afaik.

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...

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

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

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

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.

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

Issue 655 has been merged into this issue.

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.

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

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

Read what i commented, it does.

sorry...I kinda missed that...

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.

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.

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

+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.

my mistake first time issue was commited in 1872

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

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

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

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.

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

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

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

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

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

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.

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.

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

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?

Nop.

darn.

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

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.