Add Vulkan Support to RetroPie for Pi 4?

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

dankcushions

@bluestang

done (and additionally with another supported extension): https://github.com/stenzek/duckstation/pull/1121

I still have graphical anomalies...

ya, will be no change till we see a fix for https://gitlab.freedesktop.org/mesa/mesa/-/issues/3758

bluestang

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

@bluestang

done (and additionally with another supported extension): https://github.com/stenzek/duckstation/pull/1121

Kudos for the PR and also getting the other extension supported!

I still have graphical anomalies...

ya, will be no change till we see a fix for https://gitlab.freedesktop.org/mesa/mesa/-/issues/3758

I was thinking about submitting my specific issue to Mesa with the caveat that I don't get the same graphical glitches using the Vulkan driver or just provide more info to the existing issue. In my specific case, I'm getting sprite draw issues where it's unreadable.

I already have an issue opened on Mesa with lr-flycast using the Vulkan driver.

The developers are looking for more real-world use cases to bug test the driver with.

dankcushions

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

I was thinking about submitting my specific issue to Mesa with the caveat that I don't get the same graphical glitches using the Vulkan driver or just provide more info to the existing issue.

it is already confirmed as not happening in the vulkan (v3dv) driver: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3758#note_701947

I already have an issue opened on Mesa with lr-flycast using the Vulkan driver.

you may want to try and get a backtrace with a debug build of flycast.DEBUG=1 buildflag, typically. that should make the trace a bit more useful.