flyinghead
PlayStation Vita support
vpk generated by ci: https://github.com/flyinghead/flycast/actions/runs/8161057694/artifacts/1299537862
@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 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.
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)
@Rinnegatamante elf is now available: https://github.com/flyinghead/flycast/actions/runs/8184592546/artifacts/1305003593
The crash is caused by wrong settings on vitaGL. vitaGL needs to be compiled with HAVE_WRAPPED_ALLOCATORS=1
Oh, it seems you also used SDL2 from vdpm. That one has no vitaGL support. You need this fork: https://github.com/Northfear/SDL
New build available with SDL2 from https://github.com/Northfear/SDL (and compiled with VIDEO_VITA_VGL=ON)
New build is prefetching on gl_CompileAndLink apparently :/
Here's the coredump analysis: https://pastebin.com/PxwiQ3Td
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
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.
It looks like glDetachShader is missing, and called in gl_CompileAndLink()
This last build does launch fine but has some vmem issues still when launching any rom. I'll let Bythos know.
@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
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
@scribam Also, add __vita__ to this ifdef
https://github.com/flyinghead/flycast/blob/d703d6298cc30b28d2dfc63006283bd4493e4ff1/core/linux-dist/main.cpp#L453
With the handler hacked in, it's now dying at sh4_sched_request due to a failed verify
Invalid cycle count comes from this function: https://github.com/flyinghead/flycast/blob/de89d8cfedb6b6b914b8287fca30beefc8412e09/core/hw/sh4/modules/serial.cpp#L131
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
I can reproduce the issue on Android arm32 as well. Although it doesn't crash, it's still not correct. Looking into it.
Fixed on master: https://github.com/flyinghead/flycast/commit/6115a918b2edaab7fc0d4930a8f1e6fc387783fc
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?
I rebased the branch onto master, removed the kubridge submodule to include it in the ci directly and squashed the latest ifdef changes
@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?
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
Underclocking the SH4 should help. This is basically what idle skip was doing on some code blocks.
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.
Yes, it's technically possible to go below 100 MHz but deviating too much may cause other issues.
@Rinnegatamante @bythos14 How is the new build with the last 3 commits added? Is performance good enough?