Emulation reduced to ~20% of previous speed, since v0.9.5-251-g345a4cc

[Elwood89]

Hello!

On my S3 (Exynos/ Mali400) one of the commits between v0.9.5-245-gb310edc and v0.9.5-251-g345a4cc (there are no builds in between) made most games run much slower than before, about 1/5 of previous performance (ie. Wipeout runs 7 fps instead of 30-40). Heck, even the gray save screens are running at 6-7 fps ;).

Maybe this is known to you, as I see that you are working hard on the ARM JIT, and perhaps this is intentional, but since noone posted about this I decided to make an issue.

The changes between 9.5-245 and 9.5-251 were:

• cache hashing tweaks, disable second cache on mobile
• patch-2Attempt to fix Colin Mcrae Dirt 2 Crash correctly
• Handcode the non-NEON texcache hash as well on ARM.Well, it could be a better algorithm, but at least this uses LDMIA.
• Attempt to fix Colin Mcrae Dirt 2 Crash correctly#4482

[hrydgard]

Thanks for reporting. Certainly not intended, I will investigate soon.

[hrydgard]

Do you have this speed issue in all games or just some? If so which ones?

[jbakach]

I notice that in all games, the games become too slow.

[Elwood89]

The most demanding games took the biggest hit: Wipeout 35>7 fps GOW (menu) 18> 4 fps Locoroco 60>30 Ridge Racer 60>20-50fps Daxter seems unaffected (30/30 fps) Cars 1 - a bit slower, 10% maybe

The common "system" load/save screens are 7-8 fps in all games that use them.

[Fei-Lix]

I noticed this issue since that build was released and wanted to report it but I was thinking it might be a intended commit because I heard that second caching is disabled so it means expectedly it'll reduced a major % of speed. I tested: Hatsune Miku Project extend = at selecting menu (Free Play, DIVA Room, Rhythm Game, etc.) 85-100% into 45-54%. title menu seems fairly still at the same speed. PV seems still at the same speed?

[hrydgard]

I pushed a couple of experimental reverts, should result in a couple new builds to test to verify that it's not the texture hashing.

[hrydgard]

@RinkuFO , any big slowdown like that would be unintended. Sometimes we make changes that don't affect the devices we have or the games we test and don't notice that it slowed down other things. So reports like this are very useful.

I'm not seeing anything like a to-20% slowdown myself.

[hrydgard]

However I did notice that @unknownbrackets 's handcoded NEON texture hash is actually very slow. Code looks fine so no clue why, but I disabled it until we can investigate. Hope that that was the same problem you had.

[unknownbrackets]

For me, the handcoded one was faster (profiled several times.) So maybe it depends on the cpu?

Note that the function itself always takes a lot of time, either way.

-[Unknown]

[unknownbrackets]

What timing are you getting in the two versions?

-[Unknown]

[hrydgard]

With the handcoded texture hash, Wipeout when just out of the starting line on the first track runs at 27% on my nVidia Shield. With the other texture hash, it runs at 65-70%. So a pretty dramatic difference, something must be subtly broken.

[hrydgard]

My guess would be that it runs fast but one of the working registers is not cleared properly so it will end up mismatching hashes, creating too many textures.

vmov.i32 q0, #0\n

Does that really zero the full quad? I don't really know neon assembly language very well so I'm not sure.

[hrydgard]

  // Initialize cursor2.
  "movw r0, 0x0001\n"
  "movt r0, 0x0083\n"
  "movw r1, 0x4309\n"
  "movt r1, 0x4d9b\n"
  "vmov d2, r0, r1\n"
  "movw r0, 0xb651\n"
  "movt r0, 0x4b73\n"
  "movw r1, 0x9bd9\n"
  "movt r1, 0xc00b\n"
  "vmov d2, r0, r1\n"

Ah, the second d2 should be d3.

[hrydgard]

Fixed it.

[unknownbrackets]

Ah, darn it. I was only testing hashing speed not invalidation... (my main test case was a video that invalidated every single frame.)

-[Unknown]

[hrydgard]

Closing this as the problem is most likely fixed. @Elwood89 , please report here and reopen if you see it again.

[Elwood89]

Correct, the problem is fixed, thank you!

[Fei-Lix]

@hrydgard sorry late reply, the problem is also fixed here, thanks!