Performance problem on android kitkat, 1.9.4 runs better

[gloxyria]

Hi I usually use ppsspp 1.9.4 and it runs pretty smooth on everything. Have seen the latest version with much more feature unfortunately it isn't as smooth as 1.9.4 and even few games have bug too. Like nayuta no kiseki in 1.9.4 it runs just fine


But on latest version the texture gone missing and it became very lag


I know that my phone is very old but it still do it's job or are you stop supporting kitkat now?

[Panderner]

@gloxyria what device are you using?

[sum2012]

How about v1.10 ?
https://www.ppsspp.org/files/1_10/ppsspp.apk

[unknownbrackets]

I seem to remember not that long ago, we added depth rounding due to z-fighting for this particular game. Maybe it's not working so well on this device's GPU...

-[Unknown]

[hrydgard]

There's no intention of stopping kitkat support. As Unknown says, this is probably some interaction between a bugfix/workaround and possibly a graphics driver bug or similar....

[gloxyria]

I tried 1.10.3.1376 and it already like that.

[Panderner]

@gloxyria how's the stable 1.10 worked?

[LunaMoo]

@gloxyria since it's most likely caused by a workaround for a minor graphic glitch happening in one part of the game, you could just disable it. I think to do it on android, you'd have to create a file called "compat.ini" and paste this text inside:

[PixelDepthRounding]
# Nayuta no Kiseki might improve with pixel depth rounding. See issue #8744.
# Disabled as potential cause of #14223
ULJM06113 = false
NPJH50625 = false
ULJM08069 = false
NPJH50625 = false

save it then place that file inside "PSP/SYSTEM/" on your sdcard(or just create it inside that folder).
(Anyone please correct me if that's not correct override path for compat file as I'm typing this while being pretty tired.)

[hrydgard]

You're better off taking compat.ini from the PC version (or extract from the APK, or download from github), then adding those lines. Otherwise it will override a lot of important settings for other games, too.

[ghost]

@gloxyria what is your phone gpu?

[ghost]

I can't reproduce your issue on my old android Lollipop Mali-450 GPU I'm using ppsspp latest development apk from buildbot

Nayuta No Kiseke

GE Dump
nayuta.ppdmp.zip

But I have a gfx issue on dirt 2
dirt2.ppdmp.zip

[ghost]

@gloxyria no feedback outdated?

[ghost]

This game is also very lag on my Oppo a3s Snapdragon 450.
PixelDepthRounding ON

PixelDepthRounding OFF

Removing this from PixelDepthRounding improve the performance but might affect #8744?

[ghost]

This area still heavily lag even PixelDepthRounding is disable.
Nayuta.zip

[ghost]

Disable PixelDepthRounding can make this game smooth but the glitch/flickering will reappear as mention here #8744

Smooth_2022-09-23-23-44-21.mp4

PixelDepthRounding fixes it but the performance penalty is huge:(

PixelDepthRounding_2022-09-23-23-43-56.mp4

[hrydgard]

We should possibly expose our fallback to pixel depth rounding that we normally only use on ES 2.0, as an option on ES 3.0 and Vulkan too... (the /256th depth range thingy)

[ghost]

There's also something wrong on the smoke color effects.

Hardware Transform ON
Smooke is black

Hardware Transform OFF
Smooke is brown

BTW I can also reproduce the black smooke in software.

GE dump.
NPJH50625.ppdmp.zip.zip

[ghost]

Might be good to tag this as a performance issue and remove the no feedback/outdated tag.

[unknownbrackets]

Interesting. The smoke is shown brown in the frame dump (software only, missing in the hardware frame dump):

Software gets it wrong, there are also some smaller accuracy issues (like the circle in the top left, some details of objects, and the talk bubble):

Hardware looks similar as far as the smoke (otherwise, circle is differently wrong, it's brighter, but otherwise pretty good.)

Bubble looks like another case of DrawRectangle doing some interpolation wrong, at 230/236. Circle at 231/236 could be the same.

But the main event: Smoke drawn at 173/236, it's a texture in VRAM at 04198e00, but it's CLUT8 I only see this rendering to bloom buffers in the frame dump. The CLUT here was captured as RAM, and was loaded as just 24 colors which is all grayscale.

Lots of flags enabled: lighting (light0), dither (shouldn't matter), blend (standard src.a/inverse), atest (> 7), and ztest (>=). Vertex colors are opaque white. So it practically has to be lighting. And the light0 specular color is #b29c66. So maybe this is related to #16189. But here, the specular coefficient is 0.

If I force ignore the diffuse_factor check (which was important for Virtua Tennis or something, iirc), it does show:

The diffuse_factor is coming from (directional, so this is directly lpos):
diffuse_factor = L(-0.606312, 0.776037, -0.173646) dot WN(0.000000, 0.000000, 1.000000) = -0.173646

The vertex has no normal, but the last vert had 0, 0, 1 explicitly passed (well, 00, 00, 7F.) It is using separate specular.

-[Unknown]

[ghost]

There's also a transition effects graphics glitches might be related to #13529

Record_2022-10-11-16-20-45.mp4

[ghost]

There's also a transition effects graphics glitches might be related to #13529

Record_2022-10-11-16-20-45.mp4

ClearToRAM Does fix this!

[unknownbrackets]

We should possibly expose our fallback to pixel depth rounding that we normally only use on ES 2.0, as an option on ES 3.0 and Vulkan too... (the /256th depth range thingy)

I tried GPU_SCALE_DEPTH_FROM_24BIT_TO_16BIT on Vulkan desktop, and the rendering issue from #8744 returned. So that's probably actually still broken on GLES2, and relies on rounding specifics. I hate when games use equal depth tests... Made a mistake, the frame dump didn't apply the compat option for some reason.

-[Unknown]

[unknownbrackets]

Has the performance improved?

There's also a transition effects graphics glitches might be related to #13529
Record_2022-10-11-16-20-45.mp4

ClearToRAM Does fix this!

This might actually be rendering the transition a bit wrong - Falcom has a tendency to try to make speedy transitions, and they might've done some effect here that's being missed. Unfortunately, I don't have the PSP version of this game (which is coming to PC soon officially.)

It'd be best if we could hook whatever function it's accessing framebuffer VRAM from. Does the transition look the same in software rendering as it does with ClearToRAM? That would confirm if there's any effect.

-[Unknown]

[ghost]

Block Transfer Effects can also fixes the transition effects but slow down the game unlike in ClearToRAM.

Screenrecording_20221113_105027_org.ppsspp.ppsspp.mp4

[ghost]

Vulkan is still faster than Opengl in this game.