[GH-ISSUE #4508] Emulation reduced to ~20% of previous speed, since v0.9.5-251-g345a4cc

kerem commented

2026-03-18 04:19:13 +03:00

Owner

Originally created by @Elwood89 on GitHub (Nov 11, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/4508

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

Originally created by @Elwood89 on GitHub (Nov 11, 2013). Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/4508 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

kerem closed this issue

2026-03-18 04:19:18 +03:00

kerem commented

2026-03-18 04:19:24 +03:00

Author

Owner

@hrydgard commented on GitHub (Nov 11, 2013):

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

@hrydgard commented on GitHub (Nov 11, 2013): Thanks for reporting. Certainly not intended, I will investigate soon.

kerem commented

2026-03-18 04:19:29 +03:00

Author

Owner

@hrydgard commented on GitHub (Nov 11, 2013):

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

@hrydgard commented on GitHub (Nov 11, 2013): Do you have this speed issue in all games or just some? If so which ones?

kerem commented

2026-03-18 04:19:34 +03:00

Author

Owner

@jbakach commented on GitHub (Nov 11, 2013):

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

@jbakach commented on GitHub (Nov 11, 2013): I notice that in all games, the games become too slow.

kerem commented

2026-03-18 04:19:40 +03:00

Author

Owner

@Elwood89 commented on GitHub (Nov 11, 2013):

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.

@Elwood89 commented on GitHub (Nov 11, 2013): 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.

kerem commented

2026-03-18 04:19:45 +03:00

Author

Owner

@Fei-Lix commented on GitHub (Nov 11, 2013):

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?

@Fei-Lix commented on GitHub (Nov 11, 2013): 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?

kerem commented

2026-03-18 04:19:50 +03:00

Author

Owner

@hrydgard commented on GitHub (Nov 11, 2013):

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 commented on GitHub (Nov 11, 2013): 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.

kerem commented

2026-03-18 04:19:55 +03:00

Author

Owner

@hrydgard commented on GitHub (Nov 11, 2013):

@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 commented on GitHub (Nov 11, 2013): @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.

kerem commented

2026-03-18 04:20:00 +03:00

Author

Owner

@hrydgard commented on GitHub (Nov 11, 2013):

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.

@hrydgard commented on GitHub (Nov 11, 2013): 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.

kerem commented

2026-03-18 04:20:05 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Nov 11, 2013):

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 commented on GitHub (Nov 11, 2013): 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]

kerem commented

2026-03-18 04:20:10 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Nov 11, 2013):

What timing are you getting in the two versions?

-[Unknown]

@unknownbrackets commented on GitHub (Nov 11, 2013): What timing are you getting in the two versions? -[Unknown]

kerem commented

2026-03-18 04:20:15 +03:00

Author

Owner

@hrydgard commented on GitHub (Nov 11, 2013):

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 commented on GitHub (Nov 11, 2013): 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.

kerem commented

2026-03-18 04:20:20 +03:00

Author

Owner

@hrydgard commented on GitHub (Nov 11, 2013):

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 commented on GitHub (Nov 11, 2013): 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.

kerem commented

2026-03-18 04:20:25 +03:00

Author

Owner

@hrydgard commented on GitHub (Nov 11, 2013):

  // 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 commented on GitHub (Nov 11, 2013): ``` // 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.

kerem commented

2026-03-18 04:20:30 +03:00

Author

Owner

@hrydgard commented on GitHub (Nov 11, 2013):

Fixed it.

@hrydgard commented on GitHub (Nov 11, 2013): Fixed it.

kerem commented

2026-03-18 04:20:36 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Nov 11, 2013):

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

-[Unknown]

@unknownbrackets commented on GitHub (Nov 11, 2013): Ah, darn it. I was only testing hashing speed not invalidation... (my main test case was a video that invalidated every single frame.) -[Unknown]

kerem commented

2026-03-18 04:20:41 +03:00

Author

Owner

@hrydgard commented on GitHub (Nov 11, 2013):

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

@hrydgard commented on GitHub (Nov 11, 2013): Closing this as the problem is most likely fixed. @Elwood89 , please report here and reopen if you see it again.

kerem commented

2026-03-18 04:20:46 +03:00

Author

Owner

@Elwood89 commented on GitHub (Nov 12, 2013):

Correct, the problem is fixed, thank you!

@Elwood89 commented on GitHub (Nov 12, 2013): Correct, the problem is fixed, thank you!

kerem commented

2026-03-18 04:20:51 +03:00

Author

Owner

@Fei-Lix commented on GitHub (Nov 12, 2013):

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

@Fei-Lix commented on GitHub (Nov 12, 2013): @hrydgard sorry late reply, the problem is also fixed here, thanks!

Rows
Columns

[GH-ISSUE #4508] Emulation reduced to ~20% of previous speed, since v0.9.5-251-g345a4cc #1842