-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PPSSPP libretro core crashes on wayland #12145
Comments
Does it happen if you build the core yourself? |
Yes, I built RetroArch and the core from sources, and get the same error log |
Same experience. Build the one from here and from libretro, running it on a self compiled RA with :
So a setup without X11 (it slows down the very weak video card unacceptably in gnome 3 probably because it's running in XWayland). I'm using the udev input driver though, and don't use sdl drivers 1 or 2. |
https://www.khronos.org/opengl/wiki/OpenGL_Loading_Library#GLEW_.28OpenGL_Extension_Wrangler.29
edit: but:
|
If using a core profile, -[Unknown] |
Ah, if i disable EGL on the retroarch compile i need to also disable KMS. I'll try to disable both and build to see if that works. Not that it helps the poor users that don't build, but hey. edit: blackscreen, aka: 'null' driver. Of course. I'm pretty sure gl worked without falling back to egl before on this ancient gpu but... |
Ok the 'root' cause of this and the other openlara problem is probably this (if you're using wayland like i am): https://unix.stackexchange.com/questions/511134/why-wayland-is-using-opengl-es-instead-of-opengl to remove awkward dependencies (X11), wayland uses currently only opengl-es, which probably means RA is probably using it in 'on the sly' my case where i compiled without X11 (X11 emulation slowed down the menu) and with wayland support and i still used When i just now tried to remove even opengl-es (and leave opengl) with
Which looks to be supporting evidence that the 'gl' driver is more like a 'gles/egl' driver on this situation and as was already mentioned by @unknownbrackets , PPSSPP doesn't like that without a further setup. |
Well, in theory we detect GLES if we're given such a context. We should support either. In fact, on Windows you need only enable this flag: ppsspp/Windows/GPU/WindowsGLContext.cpp Line 40 in 1c8ac05
And you'll be able to use a GLES context. That doesn't actually require setting the core context flag (a core context is a desktop GL concept.) That said, the libretro code seems to only try glew when USING_GLES2 is not defined, so I assume it isn't: ppsspp/libretro/LibretroGLContext.cpp Line 20 in aa927e0
The libretro code never sets experimental:
-[Unknown] |
I tried
in LibretroGLContext.cpp But it didn't work, so i'm giving up and leaving this to someone that knows what they're doing debugging. Bug manifests in a terrible card on a RA compile without X11 and with wayland running a recently compiled ppsspp core got from libretro-super. I also tried compiling retroarch with X11 support, but that also didn't work. Which might not be surprising since it said this I didn't try to run it on GNOME3 on X11 yet, but i expect it to work. edit: it does... until it crashes on savestate but that is another bug already reported. I wish RA was a rust project... |
Heads up, it's also possible to avoid this bug by building RA with wayland disabled and x11 enabled, though the cores will be slower (because they're running in XWayland) Both enabled won't work, because RA always chooses the 'native' driver backend. So now i have two retroarch executables with different bash Aliases for when i want to run ppsspp. Meh. |
Tried this again. Now the core doesn't work even on the X11 compile. Both crash in the same way. If i disabled egl in the retroarch configure, both blackscreen (but the game is running which is easy to see with the menu sound) and present this (didn't bother with full logs):
|
@tbocek can you create a pull request with your commit? |
Created a pull request, please test first! -> #13598 |
I cannot test atm, my main computer and drive had a mechanical failure. |
This issue is being closed because it hasn't been updated with feedback. It's hard to tell when fixes in PPSSPP might fix other games, and sometimes certain settings or cheats may cause bugs that can't be fixed. If you have more information or can confirm it still happens in the latest git builds, please reply to this issue and it'll be reopened. If you have a new issue with the same game, just create a new issue instead. -[Unknown] |
Can confirm the issue persists on my Arch, with retroarch v1.9.14 and libretro-ppsspp 31516-1. |
I'm not sure what "31516-1" means, and 31516 doesn't seem to be a commit. I'll reopen, but since someone already made a change to fix this it'd be best to provide additional information. -[Unknown] |
I have a new computer and i'm running on X so this might not mean anything but i can run gl now without falling back to glcore. I usually force vulkan but i renamed the config/PPSSPP dir for this run, changed the main RA driver to gl, turned off ' cores can change driver ' RA option, quit and started RA again and started a psp game. It ran and the driver was gl in retroarch settings. I'm in x. Since ubuntu lts is on x. Restarting or closing the core crashes though. Anyway, output: output
|
@unknownbrackets @hrydgard I think we can close this issue. Thank you. |
What happens?
Using PPSSPP core, starting a game results in a crash:
The issue only occurs on Wayland.
What should happen?
ppsspp's core should not crash under wayland.
What hardware, operating system, and PPSSPP version?
Fedora 30, tested with multiple ppsspp cores versions from http://buildbot.libretro.com/nightly/linux/x86_64/
I guess this could be due to the version of glew headers installed on the buildbot ? But I can't find any documentation about the libretro's buildbot.
The text was updated successfully, but these errors were encountered: