Changing behavior of “gl” and “glcore” video drivers

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 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.

RetroArch Steam – Beta 1 key giveaway (Read more for details)

All keys are gone. Thanks for participating!

New beta testing keys will be available on 9/26/2020 – for the exact time check this page here.

As you probably already know, a year ago we announced that RetroArch would be releasing on Steam. We have worked hard on this for a fair while now. The process is slower than expected due to reasons beyond our control.

It’s been a lengthy process and we have had to significantly retool things to conform to Steam’s policies and guidelines, one of which is no Core Updater (just like on Google Play now).

While we wait for our release candidate build to be manually approved by Steam (which we’ve been told is a lengthy process), in the meantime we will start giving away beta testing keys. We want to gather as much feedback as possible from users so that the final experience on Steam lives up to people’s expectations.

So with that in mind, we are giving away keys for our first beta test version, Beta 1.

How do you get a Steam beta key?

Although we want everyone to be involved in this testing process, we cannot do it all at once. We will distribute the codes for a while at the link down below.

For Patreon users: We feel it’s important to express our gratitude to the people who gave their support when we fell on hard times with the hacking attack. Patreon subscribers can request their testing key by sending us a Direct Message on Patreon.


NOTE: These keys are not being sold, and as per Steam’s rules regarding crowdfunding, we are allowed to do this. We refer to the following section:

You can use the keys for crowdfunding rewards and give to your supporters. Before the game launches, you can also give your supporters beta keys if you wish, but these keys should only be owned by your supporters, and unless beta access is available for sale through Steam, these keys should not be sold elsewhere outside of a crowdfunding campaign.

Steam version details

So what’s different when using the Steam version right now vs. the regular version?

  • No core updater. You install cores through Steam Store instead. After you install RetroArch, you install the Libretro core DLCs that are available separately. We have made 10 cores available as DLC so far. They are all free and are already available on Steam.
  • All updateable assets (including shaders, overlays, etc) are pre-packaged and updated with new RetroArch builds. Basically, nothing is downloadable from our servers, everything goes through Steam.
  • No Desktop Menu.
  • Remote Play support. See next paragraph.

Remote Play support

RetroArch on Steam has full Remote Play support. This means that you will be able to play any multiplayer game online with another Steam user that also has a RetroArch beta key.

This feature is exclusive to the Steam version, and has the following advantages:
* Not dependent on RetroArch’s netplay functionality
* Because of this, it does not depend on serialization in order to work
* It apparently works very well, on par with something like Parsec and perhaps even better

NOTE: Right now, Player 2 needs to use a gamepad in order to be recognized as player 2. If Player 2 uses the keyboard instead, RetroArch will mistakenly think it’s Player 1 instead.

Which cores are available right now on Steam?

The following cores are currently available: