Skip to content
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

[BUG?] kronos flickering when gl video driver is used #10486

Closed
barbudreadmon opened this issue Apr 21, 2020 · 12 comments · Fixed by #10601
Closed

[BUG?] kronos flickering when gl video driver is used #10486

barbudreadmon opened this issue Apr 21, 2020 · 12 comments · Fixed by #10601

Comments

@barbudreadmon
Copy link
Contributor

barbudreadmon commented Apr 21, 2020

Other cores requesting a glcore context seem to be fine when ran with gl (actually i only tested flycast since i don't know any other core requesting glcore), except kronos for some reason : it's flickering (it doesn't with glcore video driver).

Could be a RA issue (something shader related) or not. Ultimately, since glcore is requested, RA should probably auto-switch to glcore video driver if available, the same way it does when vulkan is the current video driver.

@barbudreadmon barbudreadmon changed the title [BUG?] missing auto-switch from gl to glcore when glcore context is requested [BUG?] kronos flickering when gl video driver is used Apr 21, 2020
@i30817
Copy link
Contributor

i30817 commented Apr 21, 2020

Other cores requesting a glcore context seem to be fine when ran with gl

I'll direct you to try ppsspp on a wayland-only self-built retroarch to see a crash with this (wayland only forces a glcore context, then then retroarch forces a null renderer for some reason then it crashes).

If you run ppsspp on a retroarch with only x11 support it runs (in XWayland). Note, not with both x11 and wayland support, just x11. This forces me to have two self-builds of retroarch (besides i disliking flatpak and snap, those builds are buggier than a self build due to using super outdated dependencies in a effort to be 'stable').

@barbudreadmon
Copy link
Contributor Author

@i30817 Meaning there would be at least 2 cases of issues when running glcore cores with the gl video driver ? Did you open an issue about this one ?

@i30817
Copy link
Contributor

i30817 commented Apr 21, 2020

I opened/commented in issues both here and in ppsspp but the ppsspp authors simply aren't the maintainers of the libretro code in spite of it being upstreamed. If people want to fix that, they need to open a PR upstream, not wait for them to fix something that admittedly doesn't actually affect their default program configuration (that forces X11/XWayland i suspect). I doubt it'll get fixed otherwise.

It's also not certain that the problem is it trying to run in glcore in gl or ppsspp having special requirements for using a glcore context that are not being triggered in a desktop (as opposed to a arm phone). The only thing i managed to backtrace was 'this is failing when trying to init the context' and i deduced it was because of glcore in gl because disabling wayland (which forces glcore) avoided the crash.

edit: openlara also crashes on this config.

Basically if you want to test this, building retroarch without x11 things and with wayland and trying to run every core on wayland will more or less tell you what cores crash at start because of missing context on a 'glcore environment' because wayland forces RA to run with a glcore context (even if it's configured with gl). This is because opengl drivers in linux have unfortunate non-optional dependencies on X11. glcore is also 'opengl, but without a bunch of deprecated crap', so it's possible some cores crash for depending on deprecated crap, but i'd expect a different error message than a null context then.

@barbudreadmon
Copy link
Contributor Author

@i30817 could you confirm if things improved or not on ppsspp and/or openlara ?

@i30817
Copy link
Contributor

i30817 commented May 9, 2020

I just did, openlara i didn't try but ppsspp still crashes. Note, as a reminder: I'm testing this on a wayland environment with a RA build of:

./configure --disable-discord --disable-qt --enable-zlib --disable-7zip --disable-sdl --disable-vulkan --disable-cdrom --disable-sdl2 --disable-xvideo --enable-opengl_core --disable-opengl1 --disable-xinerama --enable-wayland --disable-x11 && make

And i tried both kinds of video driver, 'glcore' and 'gl'. I've read that wayland forces a glcore context for getting rid of X11 dependencies on the opengl drivers and general modernization of the driver.

If i boot either retroarch with X11 support (so it goes to XWayland) or maybe (didn't try it) that compile above in Xorg, ppsspp runs.

I think to figure this out it will have to be a dev working on linux with RA builds disabling x11.

@i30817
Copy link
Contributor

i30817 commented May 9, 2020

If you have any code you want me to try i can do it. Sort of.

@i30817
Copy link
Contributor

i30817 commented May 9, 2020

Openlara with the ps1 tomb raider 1 levels has a funny flashing purple corruption with a square fixed small 'screen' in the lower left that appears to be a 'flat' texture in gl and in the glcore driver just has a blackscreen. TBF it also has a horrid frame rate on that blackscreen because my GPU is a awful thing from 2008 so maybe it's just a core bug.

I can hear Lara's footsteps if i press forward so it's a renderer problem, not a crash.

@i30817
Copy link
Contributor

i30817 commented May 9, 2020

Ok, openlara started working when i setup 'gl' driver and 'core->hardware shared context: on' and 'core->allow cores to switch video driver: off', so there is some multivariable config issue here.

In that same config ppsspp still crashes though.

edit: changing to glcore made the blackscreen return for openlara and the crash continue for ppsspp.

@barbudreadmon
Copy link
Contributor Author

Ok, so from what i gather :

  • openlara requires "gl" video driver to work on your setup, which i guess void the theory of wayland only supporting "glcore" ?
  • ppsspp doesn't work under wayland, whatever the settings

It might be totally unrelated to the issue i fixed then, my issue was about RA not listening the core's request, causing glitches in the process (seems legit when a core expects a type of context and you give it something else).

@i30817
Copy link
Contributor

i30817 commented May 9, 2020

Mmm, i think it's more like openlara uses X11 and it's getting redirected to XWayland as soon as i turned 'hardware shared context', which has a misleading name:

This is the description of the option, and remember it started working with when it was turned on:

'Give hardware-rendered cores their own private context. Avoids having to assume hardware state changes inbetween frames'

The other missing part of the puzzle (IMO) is that the gl driver works*. I think that might be explained when you examined the platform specific parts of openlara:
https://github.com/XProger/OpenLara/blob/39137fc3c4c07fdc0745badcb007fac8c136dcf4/src/platform/nix/main.cpp

It's full of calls like 'XSetWMProtocols' and 'GLXContext ctx = glXCreateContext'. That says to me it requires Xorg on linux, and thus gets shuffled to XWayland even if the compile of RA doesn't support Xorg, specifically because of the 'hardware shared context', and without that option, it tries to to use what RA gives it, and has a black screen because it's glcore.

* (in these conditions, though without that shared context purple defect happens, which might be a defective transition from the frontend glcore to 'gl'; while the other has a black screen)

PPSSPP appears more sensitive. When I complained about this upstream they mentioned that to use glcore (in phones) they needed to use a additional call to 'prepare' the context.

hrydgard/ppsspp#12145 (comment)

I'll be honest and say that I don't really understand if RA itself runs under the 'gl driver' with x11 or not, or it is falling-back to XWayland, or if it fallbacks to 'glcore' and just doesn't say anything.

Fun!

@blikblum
Copy link

blikblum commented Jun 24, 2020

I still have flickering issues when using Kronos with gl driver (Games like sega rally, daytona usa flickers). If i manually switch the driver to glcore or vulkan, it works fine

Using Retroarch 1.8.9 on windows 10. NVIDIA Geforce MX230

This is the relevant log section when running with gl driver:

[INFO] Requesting OpenGL context.
[INFO] [SRAM]: Ignorando carregamento da SRAM..
[INFO] Versão da API libretro: 1
[INFO] Compilado contra a API: 1
[INFO] [Cheats]: Load game-specific cheatfile: C:\Users\camar\AppData\Roaming\RetroArch\cheats\Kronos\SEGARALLY.cht
[INFO] [Audio]: Set audio input rate to: 44100.00 Hz.
[INFO] [Video]: Video @ fullscreen
[INFO] [Video]: Using HW render, OpenGL driver forced.
[INFO] [Video]: Using configured "gl" driver for GL HW render.
[INFO] [GL]: Found GL context: wgl
[INFO] [GL]: Detecting screen resolution 1920x1080.
[INFO] [WGL] extensions: WGL_ARB_buffer_region WGL_ARB_create_context WGL_ARB_create_context_no_error WGL_ARB_create_context_profile WGL_ARB_create_context_robustness WGL_ARB_context_flush_control WGL_ARB_extensions_string WGL_ARB_make_current_read WGL_ARB_mult
[INFO] [WGL]: Adaptive VSync supported.
[INFO] [WGL]: wglSwapInterval(1)
[INFO] [GL]: Vendor: NVIDIA Corporation, Renderer: GeForce MX230/PCIe/SSE2.
[INFO] [GL]: Version: 4.6.0 NVIDIA 446.14.
[INFO] [GL]: Using resolution 1920x1080
[INFO] [GL]: Default shader backend found: glsl.
[INFO] [Shader driver]: Using GLSL shader backend.

EDIT: Here is the log when driver is configured to vulkan:

[INFO] Requesting core OpenGL context (3.3).
[INFO] [SRAM]: Skipping SRAM load..
[INFO] Version of libretro API: 1
[INFO] Compiled against API: 1
[INFO] [Cheats]: Load game-specific cheatfile: C:\Users\camar\AppData\Roaming\RetroArch\cheats\Kronos\SEGARALLY.cht
[INFO] [Audio]: Set audio input rate to: 44100.00 Hz.
[INFO] [Video]: Video @ fullscreen
[INFO] [Video]: Using HW render, OpenGL driver forced.
[INFO] [Video]: "vulkan" saved as cached driver.
[INFO] [Video]: Forcing "glcore" driver.
[INFO] [GLCore]: Found GL context: wgl
[INFO] [GLCore]: Detecting screen resolution 1920x1080.
[INFO] [WGL] extensions: WGL_ARB_buffer_region WGL_ARB_create_context WGL_ARB_create_context_no_error WGL_ARB_create_context_profile WGL_ARB_create_context_robustness WGL_ARB_context_flush_control WGL_ARB_extensions_string WGL_ARB_make_current_read WGL_ARB_mult
[INFO] [WGL]: Adaptive VSync supported.
[INFO] [WGL]: wglSwapInterval(1)
[INFO] [GLCore]: Initializing HW render (1024 x 1024).
[INFO] [GLCore]: Max texture size: 32768 px, renderbuffer size: 32768 px.
[INFO] [GLCore]: Vendor: NVIDIA Corporation, Renderer: GeForce MX230/PCIe/SSE2.
[INFO] [GLCore]: Version: 4.6.0 NVIDIA 446.14.
[INFO] [GLCore]: Using resolution 1920x1080

@barbudreadmon
Copy link
Contributor Author

Yes, the fix was reverted...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants