Egl bug on rpi4 with master mesa?

[ghost]

Mesa topic

https://gitlab.freedesktop.org/mesa/mesa/issues/1976#note_285659

Hi guys, ive found an issue on master ppsspp (i need to apoint the commit reference later, but the build its from a month ago) under mesa 19.2 and next versions too. I detected the problematic commit, reverted and its runnkng now (the all idea was because now we have 3.1 es on mesa). Did you have a clue of what happening with egl surface?

Thanks for this emu... masterpiece.

[unknownbrackets]

We should only be creating the one surface. Ultimately, we just want a single backbuffer to draw to - the paltform glue just tries to work that out, so we can churn out frames in the main emulator code.

It may be possible we're choosing a wrong EGL config, or that one is rejected in some way so we try another. That would mainly happen here:

ppsspp/SDL/SDLMain.cpp

Line 621 in 56e2e08

glctx->Init(window, x, y, mode, &error_message);

I don't have an affected device, so I can't put breakpoints anywhere, but I can tell you what should happen and answer questions as needed.

-[Unknown]

[ghost]

I need to retry it on master, since this was a while ago. Maybe it's fixed somehow. Great 2020.

[unknownbrackets]

Someone on Discord just experienced this again, so it's still an issue.

-[Unknown]

[ghost]

Indeed, its present on master

[neilmunday]

We should only be creating the one surface. Ultimately, we just want a single backbuffer to draw to - the paltform glue just tries to work that out, so we can churn out frames in the main emulator code.

It may be possible we're choosing a wrong EGL config, or that one is rejected in some way so we try another. That would mainly happen here:

ppsspp/SDL/SDLMain.cpp

Line 621 in 56e2e08

glctx->Init(window, x, y, mode, &error_message);

I don't have an affected device, so I can't put breakpoints anywhere, but I can tell you what should happen and answer questions as needed.

-[Unknown]

For me at least on my Raspberry Pi 4, I do not have a Vulkan backend so that line of code is never being executed.

[unknownbrackets]

Here is where we create the window surface:

ppsspp/SDL/SDLGLGraphicsContext.cpp

Line 257 in 56e2e08

g_eglSurface = eglCreateWindowSurface(g_eglDisplay, eglConfig, g_Window, nullptr);

It should be happening once, but then I recall #7533. What if you force USING_EGL off or comment out this line?
https://github.com/hrydgard/ppsspp/blob/master/CMakeLists.txt#L70

Maybe SDL is getting the window surface. That said, we may have problems with getting a correct / usable backbuffer if we just take whatever SDL gives us.

-[Unknown]

[hrydgard]

Having a usable (with stencil/z) backbuffer is only a problem for non-buffered rendering though - with buffered rendering we don't really care. Although slow platforms like this is one of the main uses for non-buffered anyway maybe...

[neilmunday]

Just to confirm, under a X11 desktop this works for me:

cmake -DARMV7=ON -DUSING_EGL=OFF -DUSING_GLES2=OFF -DUSING_X11_VULKAN=OFF -DUSE_WAYLAND_WSI=OFF -DUSING_FBDEV=OFF

[ghost]

Obviously.. without gles/egl it will work.. the thing it's x11 and gles/egl only.

[unknownbrackets]

Well, I'm actually mainly worried SDL2 would pick a 10-bit backbuffer format that doesn't actually work (like we used to) on some platforms. I assume it just uses these parameters?

ppsspp/SDL/SDLMain.cpp

Lines 546 to 551 in 2405157

	SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
	SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8);
	SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8);
	SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 24);
	SDL_GL_SetAttribute(SDL_GL_STENCIL_SIZE, 8);
	SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);

-[Unknown]

[ghost]

Yeah, maybe it's SDL... I will not test it again bc I use retropie on my raspbian now and it doesn't use x11.

[unknownbrackets]

Can anyone test this again with latest master? I've made it so even if you include USING_EGL, we'll hopefully continue anyway with SDL's EGL on error.

-[Unknown]

[kaiomatico]

It works great so far without bleeding edge firmware (so no rpi-update, kernel 4.19 32 bit), I just made a ./b.sh --rpi, see screenshot

I will further test it with the bleeding edge firmware now

[kaiomatico]

Also works fine with the latest firmware (after rpi-update the kernel bumps to 5.4.42), I tested armv7l and aarch64 with the previously built binary, no problem at all! :-) If you want me to test different cmake arguments just tell me to maybe further improve / optimize performance

[unknownbrackets]

Great, I guess we should update the mesa bug - we were actually in the wrong here, SDL was initing EGL and then we were too.

-[Unknown]

[kaiomatico]

Good to know. By the way I am currently compiling a 64 bit version (see the 64 bit container here https://www.raspberrypi.org/forums/viewtopic.php?p=1621085#p1621085 ) of PPSSPP and I used the following settings in the cmake file
ARCH_FLAGS "-march=armv8-a+crc -mtune=cortex-a72 -funsafe-math-optimizations"
Are these flags correct? Maybe the performance will be significantly improved by using 64 bit (I hope ^^)
Maybe this is of interest for more raspberry pi users, if you want to close this issue I can join the discord this weekend to chat further about this

[kaiomatico]

Oh nevermind, it segfaults as soon as the first frame is in-game (the ppsspp menu loads fine), but no wonder because the container passes the graphics through with llvmpipe. So we have to wait until a proper 64 bit os is released for the pi 4

I: gpu_features.cpp:175: GPU Vendor : VMware, Inc. ; renderer: llvmpipe (LLVM 7.0, 128 bits) version str: OpenGL ES 3.0 Mesa 18.3.6 ; GLSL version str: OpenGL ES GLSL ES 3.00
I: gpu_features.cpp:294: OpenGL ES 3.0 support detected!

I: SDLMain.cpp:117: SDL: Trying a different device
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4568:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4568:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4568:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5047:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default
E: SDLMain.cpp:121: Failed to open audio: ALSA: Couldn't open audio device: No such file or directory
loading control pad mappings from gamecontrollerdb.txt: SUCCESS!
I: NativeApp.cpp:810: NativeInitGraphics
I: thin3d_gl.cpp:967: Linking shaders.
I: thin3d_gl.cpp:967: Linking shaders.
I: NativeApp.cpp:905: NativeInitGraphics completed
I: GLRenderManager.cpp:201: Running first frame (0)
Segmentation fault

[hrydgard]

Huh. Still wouldn't expect it to crash, but probably not worth debugging.

Anyway, glad it works in 32-bit now!

[kaiomatico]

The Raspberry Pi foundation just released an official 64 Bit beta, (https://www.raspberrypi.org/forums/viewtopic.php?f=117&t=275370) , so I am compiling it for 64 Bit now. If everything works well I will create a pull request with changes to the cmake file and b.sh script. I will also try to benchmark if there is a performance improvement :-)

[kaiomatico]

So I was able to successfully compile and run everything fine in 64 Bit, but sadly there was no performance gain compared to 32 bit. I hoped the ARM64 JIT is more powerful. However in order to install libsdl2-dev I had to get out of the debian "dependency hell" using sudo dpkg -P libraspberrypi-doc libraspberrypi-dev. I will tell the raspberry pi developers about this, so support on the PPSSPP site is alright! :) I will create a pull request at the weekend ;) to add the support in the b.sh script

[hrydgard]

Well, it's good for the future - the ARM64 jit is more likely to get improvements than the ARM32 one. But it's quite likely that you are instead bottlenecked by graphics drivers. Hopefully you'll see an improvement once Vulkan drivers are available for the RPI4 some time in the future...

[unknownbrackets]

Should we close this given it has been worked around?

-[Unknown]

[kaiomatico]

I'm fine with closing it. But I'm not the OP^^