PlayStation Vita support

[scribam]

No description provided.

[scribam]

vpk generated by ci: https://github.com/flyinghead/flycast/actions/runs/8161057694/artifacts/1299537862

[flyinghead]

@Rinnegatamante Do we need the "Use Simple Shaders" option? What is the benefit for users to select advanced/not simple shaders? and how to decide which setting to use?

[Rinnegatamante]

@Rinnegatamante Do we need the "Use Simple Shaders" option? What is the benefit for users to select advanced/not simple shaders? and how to decide which setting to use?

I added it cause some games were artifacting with "complete" shaders if i remember correctly.

[Rinnegatamante]

Mhhh for me it still crashes although, can we make the CI split out also the unstipped elf? (So i can look into the cause of the crash)

[scribam]

@Rinnegatamante elf is now available: https://github.com/flyinghead/flycast/actions/runs/8184592546/artifacts/1305003593

[Rinnegatamante]

The crash is caused by wrong settings on vitaGL.
vitaGL needs to be compiled with HAVE_WRAPPED_ALLOCATORS=1

[scribam]

New build available with vitaGL compiled with HAVE_WRAPPED_ALLOCATORS=1

[Rinnegatamante]

Oh, it seems you also used SDL2 from vdpm. That one has no vitaGL support. You need this fork: https://github.com/Northfear/SDL

[scribam]

New build available with SDL2 from https://github.com/Northfear/SDL (and compiled with VIDEO_VITA_VGL=ON)

[Rinnegatamante]

New build is prefetching on gl_CompileAndLink apparently :/

Here's the coredump analysis:
https://pastebin.com/PxwiQ3Td

[flyinghead]

It looks like the crash happens in gl_CompileShader and probably caused by a NULL OpenGL function (PC == 0).
Probable stack trace:

gl_CompileShader()
gl_CompileAndLink()
initQuad()
gl_create_resources()
OpenGLRenderer::Init()

Other OpenGL functions have already been called at this point so it's not a general glad issue but it looks like at least one of these functions is missing:

glCreateShader
glShaderSource
glCompileShader
glGetShaderiv
glGetShaderInfoLog

[Rinnegatamante]

https://github.com/Rinnegatamante/vitaGL/blob/master/source/lookup.c#L29-L420

These are all the available gl functions resolveable via vglGetProcAddress/eglGetProcAddress/SDL_GL_GetProcAddress.
In my fork, i recall having to ifdef out some gl funcs cause unavailable on vitaGL indeed.

[flyinghead]

It looks like glDetachShader is missing, and called in gl_CompileAndLink()

[Rinnegatamante]

This last build does launch fine but has some vmem issues still when launching any rom. I'll let Bythos know.

[bythos14]

@scribam The os_InstallFaultHandler function in linux/common.cpp is overriding the one in vita_fault_handler.cpp. Fully ifdef out the ones in common.cpp for the vita

[scribam]

Thank you for your help @bythos14. I pushed a commit to ifdef out the os_InstallFaultHandler and os_UninstallFaultHandler functions in linux/common.cpp for the vita.

A new build is available for testing

[bythos14]

@scribam Also, add __vita__ to this ifdef

flycast/core/linux-dist/main.cpp

Line 453 in d703d62

#if defined(__unix__)

[bythos14]

With the handler hacked in, it's now dying at sh4_sched_request due to a failed verify

[bythos14]

Invalid cycle count comes from this function:

flycast/core/hw/sh4/modules/serial.cpp

Line 131 in de89d8c

void SCIFSerialPort::updateBaudRate()

[bythos14]

Okay, it's seemingly being caused by a sign extension on the input to SCBRR2_write, causing the input to go from 0xFF to 0xFFFFFFFF. Patching the ELF to write SCBRR2 with strb instead of str allows me to boot in game

[flyinghead]

I can reproduce the issue on Android arm32 as well. Although it doesn't crash, it's still not correct.
Looking into it.

[flyinghead]

Fixed on master: 6115a91

[Rinnegatamante]

Bythos referred that with these changes game do finally boot although performances are worse than the og Vita fork. Anything in particular that could've caused it in latest changes to the codebase?

[scribam]

I rebased the branch onto master, removed the kubridge submodule to include it in the ci directly and squashed the latest ifdef changes

[flyinghead]

@Rinnegatamante it's around 500 commits if I'm not mistaken so it's hard to tell.
Do you know if this is something on the renderer side or the emulation thread size?

[bythos14]

One reason I've found for the performance difference is the removal of the idle skip hack in the dynarec. It helps the framerate a bit in Sonic adventure. Although even with it put back in, the framerate doesn't hit 30FPS nearly as often as it did before. Haven't done much digging to figure out why, although maybe it might be related to some of the other changes in commit 095e5ed

[flyinghead]

Underclocking the SH4 should help. This is basically what idle skip was doing on some code blocks.

[bythos14]

The problem with that is that I'm already at the lowest underclock allowed in the GUI (100MHz) and I expect that trying to go lower would harm the overall performance more than help it.

[flyinghead]

Yes, it's technically possible to go below 100 MHz but deviating too much may cause other issues.

[scribam]

@Rinnegatamante @bythos14 How is the new build with the last 3 commits added? Is performance good enough?

[Rinnegatamante]

On my Discord server, a guy that did test the last build reported that some games do run better, others do run worse, some games that used to crash, now run fine and some others that used to run fine, now crash. So I guess, it's ok-ish.
@bythos14 last time also reported that newer builds, in general, will require higher downclocks than older build due to new, more accurate cycling counting. (Which is why the question about the 100 MHz max downclocking)

[bythos14]

Yeah, the three latest commits shouldn't have any significant effect on performance. Having tested it a bit, below 100MHz downclock didn't provide any benefit for the games I have. So, as Rinne said, it's ok-ish

[Shinriji]

I was the one that tested the latest build and posted at the discord server, and after that post I played some more over the weekend and my opinion slightly changed. Several popular games crashes right at the bios screen or early in-game (Crazy Taxi and several others) that used to work. Framerate of the dev build is 20%-30% worse in most of the tested games comparing to the current version, also performance of the dev build deteriorates over time (Gigawing). Loading times are also slightly worse.

There is some rare improvements, though. Some graphical glitches are fixed (Bangai-oh), and I found 2 games that actually performs better than the current version (Cleopatra Fortune and Gunbird 2).

Of course, I tested with my 15 or so games, so a small fraction of the library, and more extensive testing is needed. But right now, the current version is way better for most users.