libretro / libretro-uae

PUAE libretro
GNU General Public License v2.0
114 stars 61 forks source link

[RPi] Crash with Puae Libretro core when using Vulkan driver #517

Closed amverweij closed 2 years ago

amverweij commented 2 years ago

Using the current master branch of libretro-uae on a RPi4 (aarch64), when selecting the Vulkan driver in retroarch the core cashes on startup.

Doing the same with the puae2021 Libretro core from the 2.6.1 branch starts emulation as expected.

Platform: RPi4, aarch64 Kernel 5.15.27-v8+ Mesa 22.0.1

The crash was produced using Test Drive and Jim Power.

sonninnos commented 2 years ago

The frontend video driver should indeed not matter at all since the core is pure software video.. and the same goes with launched game. I've also been using Vulkan on Windows all the time.

In any case please at least provide verbose log, but crash log with DEBUG enabled would be best.

amverweij commented 2 years ago

Retroarch log file is here: retroarch.log

It started once correctly, but it crashed on the second try.

Call stack: coredumpctl.txt

amverweij commented 2 years ago

I was a bit surprised to see it start initially (that was the first time). Might be because it is compiled in debug now. The stack traces from before compiling it in debug appear similar in the sense that they also crash in libvulkan_broadcom.so.

It occurs to me that the crash in the second try is right where it mentions "[INFO] [Vulkan]: Destroying stale acquire semaphore." in the first try.

sonninnos commented 2 years ago

I don't get it, since that video stuff is the frontend's responsibility and thus out of the hands of the core, as the crash log also indicates. So you are positive that the old branch never crashes in the same way, and with the exact same config? And did it only start happening after the new branch was switched?

I noticed the crash being related to widget stuff, and also according to SET_SYSTEM_AV_INFO you are not using the current default "Allow Hz Change", which means you are getting quick refresh rate changes next to each other at startup, which may be the reason. (Current default uses the same 50.00 Hz for both 49.92 and 50.08, which minimizes rate changes without side effects.)

Then again it shouldn't even show the refresh rate change widget message without actually changing rates, which it is not doing, because: [INFO] [Video]: Timings deviate too much. Will not adjust. (Display = 60.00 Hz, Game = 49.92 Hz)

So please also try with fresh opts with the new version because the old version surely must have fresh opts, since it was recently created. I can't think of any other core option that has changed defaults and could trigger showing of widgets.

Please also change the title to say that it happens with RPi, since it for sure does not happen with Windows.

amverweij commented 2 years ago

I never had any problems with the old core. Puae2021 still works fine for me too. I will try with fresh settings, that's a good idea. It could be an upgrade issue.

amverweij commented 2 years ago

Well after recompiling mesa in debug, both the puae Libretro core and the puae2021 Libretro core fail with an assertion. Gdb log is here: gdb.txt It seems that the assertion assert(descriptor->image_view); is not satisfied. However since puae2021 survives this when mesa is not compiled with debug on, we can't conclude that this is the reason of the crash.

sonninnos commented 2 years ago

Does not make any sense, since again none of the functions in the log are PUAE core functions..

amverweij commented 2 years ago

After upgrading RetroArch to 1.10.3, the issue has gone away.

Maybe it was a duplicate of https://github.com/libretro/RetroArch/issues/13801.