flyinghead / flycast

Flycast is a multiplatform Sega Dreamcast, Naomi, Naomi 2 and Atomiswave emulator
GNU General Public License v2.0
1.39k stars 169 forks source link

PlayStation Vita support #1440

Open scribam opened 7 months ago

scribam commented 7 months ago

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

flyinghead commented 7 months ago

@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 commented 7 months ago

@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 commented 7 months ago

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 commented 7 months ago

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

Rinnegatamante commented 7 months ago

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

scribam commented 7 months ago

New build available with vitaGL compiled with HAVE_WRAPPED_ALLOCATORS=1

Rinnegatamante commented 7 months ago

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 commented 7 months ago

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

Rinnegatamante commented 7 months ago

New build is prefetching on gl_CompileAndLink apparently :/

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

flyinghead commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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

Rinnegatamante commented 6 months ago

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

bythos14 commented 6 months ago

@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 commented 6 months ago

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 commented 6 months ago

@scribam Also, add __vita__ to this ifdef

https://github.com/flyinghead/flycast/blob/d703d6298cc30b28d2dfc63006283bd4493e4ff1/core/linux-dist/main.cpp#L453

bythos14 commented 6 months ago

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

bythos14 commented 6 months ago

Invalid cycle count comes from this function: https://github.com/flyinghead/flycast/blob/de89d8cfedb6b6b914b8287fca30beefc8412e09/core/hw/sh4/modules/serial.cpp#L131

bythos14 commented 6 months ago

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 commented 6 months ago

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

flyinghead commented 6 months ago

Fixed on master: https://github.com/flyinghead/flycast/commit/6115a918b2edaab7fc0d4930a8f1e6fc387783fc

Rinnegatamante commented 6 months ago

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 commented 6 months ago

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

flyinghead commented 6 months ago

@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 commented 6 months ago

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 commented 6 months ago

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

bythos14 commented 6 months ago

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 commented 6 months ago

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

scribam commented 6 months ago

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

Rinnegatamante commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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.

scribam commented 4 months ago

Branch updated with master

scribam commented 3 months ago

Branch updated with latest dev

scribam commented 3 months ago

Updated with latest dev and conflicts fixed in core/ui/gui.cpp

scribam commented 1 month ago

Branch updated with latest master and kubridge is now installed with vdpm