In Development – RetroArch ANGLE support – OpenGL support for UWP and more

ANGLE is middleware developed by Google that serves as an OpenGL compatibility layer on systems where OpenGL support is either spotty or missing entirely. It converts OpenGL calls to Direct3D 9/11.

In this video, you will see ANGLE being used on RetroArch UWP. In specific, it allows us to run OpenGL cores now on the Xbox One, where only Direct3D 11/12 are available as graphics APIs. Mupen64plus Next is shown running in this video on an Xbox One S with fairly acceptable results.

Will this be ready for the next version?

We don’t know yet if this will make it for version 1.8.2.

Let us tell you though what this will entail in the future –

  • There will likely be two binaries from now on for the desktop Win32 Windows version – one with ANGLE, one without. The non-ANGLE version will use your system-provided OpenGL driver, while the ANGLE version will use the ANGLE version of the OpenGL dynamic libraries.
  • ANGLE works over OpenGL ES. This means that ANGLE requires separately compiled cores targeting OpenGL ES 2/3 instead of desktop OpenGL. What this means is that 1) we need separate cores since the current OpenGL cores available for Windows assume that desktop OpenGL will be targeted, and 2) a libretro core has to have a working OpenGL ES 2 or 3 implementation in order for it to work. This will mean that currently, cores like Quake 2/3/Doom 3 won’t work since there are no working OpenGL ES 2 codepaths in those cores. However, Mupen64plus Next and Flycast do have OpenGLES 2 codepaths.

What usecases are there for using ANGLE instead of regular OpenGL?

There are several scenarios imaginable where you would want to use ANGLE. Here are some of them –

  • UWP (shorthand for Universal Windows Platform) allows you to make one binary that will work on Windows Mobile 10, Windows 10 and Xbox One. The only graphics API available for UWP programs is Direct3D 11 or 12. So for OpenGL cores to work, a middleware layer like ANGLE which converts OpenGL to Direct3D is our only option. Therefore, ANGLE allows us to run OpenGL ES 2 cores on the Xbox One.
  • Certain graphics cards might have nonexistent OpenGL support on Windows 10 and therefore fall back to Microsoft’s reference OpenGL 1.1 drivers. This is pretty much the worst case imaginable and really limits what you can do with OpenGL on such graphics cards. Intel HD 2000/3000 series integrated GPUs are pretty much in this position. For such GPUs, ANGLE might be your only option to get any kind of acceptable level of hardware accelerated graphics support with openGL-based cores.
  • OpenGL driver support might be stagnating for certain graphics cards, and therefore several bugs go unresolved in their OpenGL driver implementations. ANGLE is a good way to work around that assuming you are OK with an OpenGL ES 2/3 feature set.

We will fill you in as things develop how ANGLE will fit into RetroArch’s future releases. For now, the path seems clear – separate core versions for the emulators that have viable OpenGL ES 2/3 codepaths, and separate binaries at least on Windows desktop for an ANGLE-enabled and non-ANGLE enabled version. The redist (redistributable) will also need to be updated to include the extra dynamic library dependencies.

RetroArch 1.7.4 – Metal 2 macOS version available now!

RetroArch with Metal 2 support for macOS High Sierra users!

Up until now, we had three versions of RetroArch for macOS/OSX users:

  • RetroArch for OSX PowerPC (10.5) – For users with an old PowerMac or iBook/Powerbook. You should have at least Mac OS X version 10.5 (Leopard) installed in order for this version to work. Cores are packaged with this version because our buildbot does not serve fresh 32bit PowerPC cores for OSX.
  • RetroArch for OSX 32bit Intel (10.6) – For users with an old MacBook that has a 32bit Intel processor (for instance, 1st generation MacBook). In order to use this, you should have at least MacOS X version 10.6 (Snow Leopard) installed. Cores are packaged with this version because our buildbot does not serve fresh 32bit Intel cores for OSX.
  • RetroArch for macOS/OSX 64bit Intel (10.6) – This is what you are likely wanting to use on a modern Mac computer. You should have at least MacOS X/macOS version 10.7 (Lion) installed. Cores are distributed separately on our buildbot.

We are now adding a fourth one:

  • RetroArch for macOS 64bit Intel with Metal 2 support (10.13) – This version has all of the features of ‘RetroArch for macOS/OSX 64bit Intel’ plus a Metal 2 video driver. This version requires at least macOS 10.13 (High Sierra), a fairly modern version of macOS. For this version, we default to the Metal video driver by default.

If you have relatively modern Mac and you want to enjoy the latest in cutting edge technology, you should definitely try out this latest version. Get it by going to our Downloads page, and click on the download link below macOS High Sierra (or later).

Some important things you should know about Metal 2 – not all of the devices that can run macOS 10.13 necessarily support this. Here is a compatibility list of all supported hardware:

  • MacBook (Early 2015 or newer)
  • MacBook Pro (Mid 2012 or newer)
  • MacBook Air (Mid 2012 or newer)
  • Mac mini (Late 2012 or newer)
  • iMac (Late 2012 or newer)
  • Mac Pro (Late 2013)

What is Metal, and why is it relevant?

Up until the ’10s, Mac OS X has relied on the crossplatform OpenGL API to provide hardware accelerated rendering to developers writing Mac applications. However, since 2014, there has been an industry-wide push towards lower-level APIs, and Apple in specific decided to go with its own proprietary graphics API. This API is called Metal, and was first premiered with iOS 7 and Apple A7 devices. It has since some years ago made the switch to macOS as well, and this year the API has been bumped to version 2.

Apple has announced OpenGL will be deprecated in the future, its graphics driver stuck with the dated OpenGL 4.1 spec for years now. While we regret this industry wide push away from a standardized, cross-platform graphics API, we have been forced to move with the times and instead cater to all the major graphics APIs. There is no longer the potential for one single graphics API to cater to all platforms.

With the release of RetroArch 1.7.4, we have achieved an important milestone: we now have fully functioning graphics drivers for the three major next-generation graphics APIs. This includes Khronos’ Vulkan API (added to RetroArch since 2016), Microsoft’s Direct3D 11/12 (added to RetroArch since earlier this year), and now Apple’s Metal 2 for macOS. Thanks to Hans-Kristian Arntzen’s SPIRV-Cross middleware, we can reuse the same shaders across Direct3D/Vulkan/Metal. We therefore are very close to having a universal shader specification that will work on all the major platforms.

We are now ready for a future when Apple will outright kill OpenGL support, while at the same time we have ensured that we have one common set of shaders that can be used across all these video drivers. The developer who has added Metal 2 support to RetroArch has already indicated he intends to bring this over to iOS and tvOS as well. And who knows, maybe even backwards compatibility with Metal 1 could arrive.

How complete is the Metal video driver right now?

Fairly complete. You get:

  • Fully functioning menu drivers. XMB, MaterialUI and RGUI should work fine.
  • XMB shader pipeline effect should work as expected.
  • You can take screenshots.
  • You can go into fullscreen mode.
  • You can use slang shaders with the Metal video driver, the same shaders that can be used with Vulkan/D3D10/D3D11/D3D12.

Things that have still yet to be added which the author is considering adding:

  • Recording support independent of ffmpeg.
  • Support for the libretro API’s RETRO_ENVIRONMENT_GET_CURRENT_SOFTWARE_FRAMEBUFFER.
  • Hardware renderer context support, so that libretro cores could make use of the Metal API.

General changelog

– COMMON: Support for “OEM-102” key (usually ‘\’ on Euro keyboards).
– MENU/QT/WIMP: Add option to filter extensions inside archives when adding to a playlist.
– METAL: Add screenshot support.

Beetle PSX HW PSA for Windows/AMD GPU users – update your drivers!

Written by rz5

From at least February to mid August there was a bug on beetle-psx’s GL renderer that only affected users with AMD GPUs.

This bug was exposed when user ‘orbea’ corrected a mistake in glsm (an OpenGL state manager, made by libretro, used in beetle-psx), where it would it would hint that beetle-psx wanted a version 3.1 core profile OpenGL rendering context but, by specification, the ‘core profile’ is only from version 3.2 onward.

It is still unknown why, but after orbea’s patch, AMD GPUs would render black frames on every situation except for FMVs.
Intel and Nvidia GPUs were unaffected.
Trying to find out what was wrong was very frustrating. CodeXL and RenderDoc were briefly used in the expectation that they would point out obvious API mistakes or perform API call order analysis and give a warning e.g. “are you sure you want to change this complex colored frame for a single-colored frame and present it?”

It is unfortunate that sometimes bugs like this pop up and due to the blackbox nature of closed-source proprietary drivers, using a debugger like gdb becomes unfruitful for hobby developers when you arive at the point where your opensource the code starts calling into driver code.
Then one begins to wonder: was it one of my commits in the past? Is our code going against the OpenGL spec in some way that triggers this behavior on the typically strict spec-following AMD drivers? Is it our fault at all?

And while this bug was active, users affected by it surely grew frustrated at the lack of progress and some even got dissuaded from using beetle-psx altogether.

Eventually, in mid August, update 18.8.1 came out for AMD’s Radeon Software graphics software and that seemingly fixed the bug. Which seems to indicate towards the problem being on the AMD driver side, not in beetle-psx.