The Libretro Team
patreon
Changing behavior of “gl” and “glcore” video drivers
🕑 Added 2020-10-13 20:09:55 +0000 UTCSome important changes for the next version of RetroArch relevant to the OpenGL driver - please read (full article here).
What are they ?
“gl” and “glcore” are 2 video drivers available on desktop computer :
- “gl” is an OpenGL 2.0+ driver, when used with a version above 3.0 it’s called OpenGL Compatibility and can support up to OpenGL 4.6, but some GPU drivers don’t have that OpenGL Compatibility mode.
- “glcore” is an OpenGL 3.1+ driver, it’s also called OpenGL Core, it supports up to OpenGL 4.6.
OpenGL is one of graphics API that can be used to draw 3D with you GPU, it is the most widely supported by devices and emulators.
What changed ?
Until now, when launching a core with an OpenGL renderer, RetroArch would consider both “gl” and “glcore” video drivers as valid choices, meaning you could launch a core internally using OpenGL Compatibility with the “glcore” video driver, and a core internally using OpenGL Core with the “gl” video driver. It’s not possible anymore, now cores will try to force the video driver matching what they want. This change only concerns platforms with OpenGL Core support, meaning platforms like android and many others aren’t concerned. Here is a list of cores using OpenGL and how they will be affected.
The following cores will always try to force the “glcore” driver :
- kronos
- citra
- beetle-psx-hw
- mupen64plus_next (on linux)
- melonDS
The following cores will always try to force the “gl” driver :
- openlara
- parallel-n64
- yabasanshiro
- mupen64plus_next (on windows)
- boom3
The following cores are compatible with both (some of them might work better with a peculiar driver depending on your gpu though), so they’ll try to use your current driver :
- duckstation
- dolphin
- ishiiruka
- ppsspp
- flycast
- desmume
Why was this change needed ?
Maybe you are one of the lucky guys who didn’t encounter major issues with the previous behavior, but there are actually several reasons to change this :
- some cores will glitch if the video driver doesn’t match the context they are requesting
- cores will usually perform faster if you use the video driver they expect
- OpenGL compatibility isn’t reliable for cores that require OpenGL versions above 3.0, because some GPU drivers don’t support this, so it’s safer to force OpenGL Core in those cases
- to be honest, it makes more sense like this, it leverages user experience, and we shouldn’t ignore what is requested by the core
Should i change something on my setup ?
The first thing you should make sure, is that the setting “Allow cores to change video drivers” is turned on (that’s the default), as far as i know turning this setting off was used as a workaround for some of the issues fixed by those commits, so i don’t see a scenario anymore where it could be anything but harmful.
The second thing you should do, is update the cores mentioned above if you are using them, half of them were patched over the last few weeks, in preparation for those changes. Sadly our buildbot currently has troubles building some of those cores, so i recommend manually installing them from the newer builds available at https://github.com/hunterk/libretro_builds until the new buildbot is ready (for dolphin, you might have to install vc_redist from here).
The third thing you should do if those changes prevent a core from working on your setup, is to mention me (@barbudreadmon) on github or discord so that i can look into your issue.
Last but not least, there are 2 settings you might optionally consider changing :
- if you are currently using the setting “shared hardware context”, you should probably consider turning it off, it adds rendering latency while it shouldn’t be necessary anymore with those changes (the cores that actually require this setting will force it).
- if your GPU is less than 15 years old and your platform supports “glcore”, you should probably consider using “glcore” over “gl” as default OpenGL video driver, it generally produce better overall results.
