Egl bug on rpi4 with master mesa?

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]

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]

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

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]