Add Vulkan Support to RetroPie for Pi 4?

bluestang

@BuZz I made the jump to the 5.9 kernel and KMS video driver for the exact reasons @Brunnis stated.

I modified the sdl2.sh script to install v2.0.12 and I also installed upstream MESA with my own script.

With my MESA script though, I did not have to install libdrm2-.4.102. It installs the needed KMS/V3D/VC4 drivers and dependencies as was provided by the devs that worked the RPi4 Vulkan driver. In addition, I did some digging and I didn't see vc4 changes from 2.4.100 to 2.4.102 in libdrm...for the other Gallium drivers yes, but nothing for the RPi. My RetroPie image is still using libdrm2-4.100 and I'm running the latest of MESA, 5.9 kernel, and sdl2 v2.0.12.

I say all that to say, that your Mesa script could cut down on the dependencies needed if you strictly built the MESA stack for just the RPi drivers. This may be better in the long run since not all the dependencies are needed for the meson builder in upstream MESA. It will also save some space as you only build the Gallium drivers required for RPi - v3d,vc4,kmsro.

I need to try out the latest SDL2 with the atomic stuff but I will get to that at a later date.

BuZz

@bluestang as I have explained before I wanted to minimise my patch set. As this was made for my purposes, I want to build it with everything included as it would be when the Raspbian packages are updated.

I'm not interested in building a minimal Mesa.

bluestang

@buzz @mitu @dankcushions

There was an issue created about a week ago in upstream MESA to get Vulkan running in KMS/DRM. This involved getting the KHR_display extension added to the Pi4 Vulkan code base.

A contributor has done this and I am happy to report that RetroArch now works in KMS/DRM with the Pi4 Vulkan driver. It will be sometime before it gets merged into upstream MESA but it can be tested for now.

I've only tested FBNeo and MAME2K3+ and they work great. I did have to specify 1080p resolution using the retroarch.cfg settings:

video_fullscreen_x = "1920"
video_fullscreen_y = "1080"

Otherwise, it would default to 4K (my TV) which is a bit too much for the GPU.

I need to recompile 3D emus (i.e. Duckstation) with Vulkan support and do some more testing but I'd figure I'd pass along the news if you want to try it out too.

Some notes about my setup: (4GB Pi4)

5.9.3 kernel (32-bit)
vc4-kms-v3d display driver
MESA Vulkan build script here - https://pastebin.com/FnwWzbF2
RetroArch v1.9.0 with Vulkan support enabled
SDL2 v2.0.12 with Vulkan support enabled

dankcushions

@bluestang duckstation requires 64bit, fyi. i’ll try adding vulkan to my WIP branch soon

bluestang

@dankcushions said in Add Vulkan Support to RetroPie for Pi 4?:

@bluestang duckstation requires 64bit, fyi. i’ll try adding vulkan to my WIP branch soon

I am aware, here is the 64-bit version script - https://pastebin.com/9hggpAcK to install Vulkan on the Pi4. The only difference is dropping the neon flags since in 64-bit that is guaranteed.

I re-compiled RetroArch with the master branch since it now has your PRs with the correct GLES contexts for Duckstation. (3.1 is now the selected renderer)

I also tested out Vulkan w/ Duckstation and it worked in KMS/DRM. Here is the log for that - https://pastebin.com/z1FBuvWx

I tried FlyCast also but ran into segmentation faults. I need to do some more investigating.

Darksavior

@bluestang Do you have build scripts for ra1.9.0 vulkan and sdl2 vulkan?

bluestang

@darksavior said in Add Vulkan Support to RetroPie for Pi 4?:

@bluestang Do you have build scripts for ra1.9.0 vulkan and sdl2 vulkan?

The easiest way is to add the x11 platform flag to the system.sh script within the Pi4 function. This is not something that should be done unless you are prepared for possible broken builds.

I'm also using the master branch from RetroArch now as that has the proper GLES context selection now merged in.

Darksavior

@bluestang I'll wait for a proper script then.
Trying 5.10 with kms driver since building the kernel makes my pads work. Not trying 64bit since I use redream and the pegasus-frontend.

bluestang

Direct display support is now part of the Pi4's MESA repo. Vulkan apps can now take advantage of rendering direct to the display without using X11 , etc.

Some emulators have this support and some do not. Vulkan implementations across various 3D emulators vary a bit. Because the Vulkan API is explicit in nature, it falls on the developer to implement their windowing system of choice.

@vanfanel is working some SDL KMS changes but not sure what the exact changes are. As of now Vulkan support in SDL2 KMS/DRM is non-existent. Hopefully he can change that soon.

bluestang

@BuZz @dankcushions @mitu

https://www.raspberrypi.org/blog/vulkan-update-were-conformant/

There is one last MR pending but it is a trivial change. As my last post says some emus work, some do not.

I’ll be re-addressing my issue with lr-flycast shortly. DuckStation was working on 64-bit, I’d forgotten how well the soundtrack was for Ace Combat 2. Mame emus worked fine for me.

Darksavior

@bluestang Can you test out Beetle PSX with vulkan?

DreamcastKid

@bluestang said in Add Vulkan Support to RetroPie for Pi 4?:

https://www.raspberrypi.org/blog/vulkan-update-were-conformant/

Nice to hear some good news this year :)

Excited to see the new possibilities with emulation performance on Raspberry Pi :D

bluestang

@darksavior I believe there are still issues with this, I couldn't get it to work but DuckStation does work. Perhaps @dankcushions will get this merged soon?

dankcushions

@bluestang until retroarch release a new version, and that is accepted into retropie, we can't add lr-duckstation as it's dependent on my PR https://github.com/libretro/RetroArch/pull/11181 which is currently only in retroarch master.

i am curious how it fares in 32-bit, though! i have only tried it in aarch64, but arm32 support was recently added.

bluestang

@dankcushions I compiled RetroArch from master using your gles flags —enable-gles3_1 and —disable-gles3_2 and using the gl driver results in some graphics anomalies with DuckStation. I think it has to do with geometry shaders as my log shows they are not supported which struck me as odd at first.
The caveat is that they are in upstream Mesa repo and have been for some time. The problem at large is that the GLES driver reports v3.1 which is technically correct because tessellation shader support was never implemented AFAIK to officially get 3.2 conformance.
So we are sort of stuck in limbo because we have a GLES V3.1+ implementation in current state.
I’m sure you are aware of this but I wanted to put this in this thread for future reference.
The Vulkan 1.0 driver doesn’t have this specific issue.

dankcushions

@bluestang there are known shader issues with the mesa gles driver: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3758. these manifest as visual bugs apparently.

however i don’t know about any geometry shaders showing as not supported, but being supported by mesa. can you show your log and where it shows that upstream supports them?

bluestang

@dankcushions said in Add Vulkan Support to RetroPie for Pi 4?:

@bluestang there are known shader issues with the mesa gles driver: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3758. these manifest as visual bugs apparently.

however i don’t know about any geometry shaders showing as not supported, but being supported by mesa. can you show your log and where it shows that upstream supports them?

Here is the DuckStation log - https://pastebin.com/n39ULv5c - line 487.

Here is the MR for GS feature in v3d in MESA - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2731

dankcushions

@bluestang said in Add Vulkan Support to RetroPie for Pi 4?:

@dankcushions said in Add Vulkan Support to RetroPie for Pi 4?:

@bluestang there are known shader issues with the mesa gles driver: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3758. these manifest as visual bugs apparently.

however i don’t know about any geometry shaders showing as not supported, but being supported by mesa. can you show your log and where it shows that upstream supports them?

Here is the DuckStation log - https://pastebin.com/n39ULv5c - line 487.

Here is the MR for GS feature in v3d in MESA - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2731

thanks. the check for geo shaders is here:
https://github.com/stenzek/duckstation/blob/c375d04bad1b19b41410398ec6291c438a71ab4a/src/core/gpu_hw_opengl.cpp#L261

m_supports_geometry_shaders = GLAD_GL_VERSION_3_2 || GLAD_GL_ARB_geometry_shader4 || GLAD_GL_ES_VERSION_3_2;

so it's looking for GL_ARB_geometry_shader4

as for support in mesa, note this:
https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/docs/features.txt#L411-414

The following extensions are not part of any OpenGL or OpenGL ES version, and
we DO NOT WANT implementations of these extensions for Mesa.

  GL_ARB_geometry_shader4

i note that this is available as an EXT here:
https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/docs/features.txt#L375

GL_EXT_geometry_shader4 commands (expose in GL 3.2)   DONE

however from that comment, it makes me think it's not available in GLES contexts. it's not clear to me if GL_OES_geometry_shader(which is in the GLES 3.2 features section) is the same as GL_ARB_geometry_shader4 - if it is, maybe the check is incomplete. you could ask stenzak on the duckstation discord? https://discord.gg/Buktv3t

dankcushions

looking at
https://www.khronos.org/registry/OpenGL/extensions/OES/OES_geometry_shader.txt
and
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_geometry_shader4.txt

they seem the same to me! i'm going to attempt to integrate and see what happens. PR forthcoming.. maybe.

bluestang

@dankcushions said in Add Vulkan Support to RetroPie for Pi 4?:

looking at
https://www.khronos.org/registry/OpenGL/extensions/OES/OES_geometry_shader.txt
and
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_geometry_shader4.txt

Yep, I just checked the Khronos website as well. Looks like GL_ARB_geometry_shader4 was first part of the 1.1 extensions and GL_OES_geometry_shader was later added as a core feature for GL/GLES 3.2 extensions. That's why the GLAD_GL_ES_VERSION_3_2 check is there, because in theory you can't be GL/GLES 3.2 conformant without geometry shaders, but it doesn't cover the Pi 4's use case since we have the feature implemented but don't have 3.2 conformance.

This makes sense since GLES followed GL's standards when it was created.

they seem the same to me! i'm going to attempt to integrate and see what happens. PR forthcoming.. maybe.

I added the following to gpu_hw_opengl.cpp

m_supports_geometry_shaders = GLAD_GL_VERSION_3_2 || GLAD_GL_ARB_geometry_shader4 || GLAD_GL_OES_geometry_shader || GLAD_GL_ES_VERSION_3_2;

And the error is gone now.

I believe a PR is indeed the right avenue to add the feature for the devices that are not fully GL/GLES 3.2 compliant but do in fact have geometry shaders implemented.

I still have graphical anomalies...