Add Vulkan Support to RetroPie for Pi 4?

bluestang

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

@bluestang incredible, please let me know when it gets implemented, I can not wait for it to get implemented, I love my Dreamcast fighting games so having Vulkan support is a must, specially for MvC2

I am also looking towards LR PPSSPP Vulkan support specially for a better Guilty Gear XX Accent Core Plus experience (it is not that good on the pi not even in the standalone PPSSPP) but my priority is Dreamcast and specially LR Flycast

It already is, you just need to build lr-flycast with "HAVE_VULKAN=1" as well as the other build flags that are in lr-flycast.sh.

lr-ppsspp works as well with code modifications as well. However, performance is not good, I would stick with GLES until Igali can make improvements to the Vulkan code and implement more features.

sergioad

@bluestang ok, thank you very much, I will wait until then for both to get the improvements come

bluestang

@BuZz If and whenever you integrate your MESA script into RetroPie you may want to patch the debian rules to build the packages with buildtype=release.

With the default settingbuildtype=plain I did notice worse performance overall.

BuZz

@bluestang got more detail on build parameter changes? Probably should be fed upstream if Debian package isn't being built with the best options. Unless they adjust this outside of their repo when building packages from their repo.

Note my goals here are for testing upstream releases as closely as possible, apart from the addition of our build flags (but I often disable them also for testing as Raspbian builds binaries that work on armv6 etc).

bluestang

@buzz
https://docs.mesa3d.org/meson.html#options - build options for MESA. I know that debhelper passes default optimization parameters but they are fairly generic. The command dpkg-buildflags --status will show you what is being passed on.

The default parameter for dh_auto_configure is passing buildtype=plain for meson though. However, in MESA upstream the default meson parameter is buildtype=debugoptimized for debug builds or it should probably be buildtype=release for most users for max performance.

The CFLAGS should be passing through with the DEB_MAINT_APPEND options and I did see those in the log.

On a side note, are you sure that CFLAGS are being passed on to the SDL2 builds? I had a verbose log enabled and I didn't see them, only the default ones being passed by the debhelper.

bluestang

@BuZz am I correct in understanding that the debhelper will override build and CFLAGS flags, etc since it relies on the maintainer using their own flags? (dpkg-buildflags)

I have been building and using the latest SDL2 (v2.0.15) for some time now and I noticed that if I explicitly use the debhelper options to specify the CFLAGS that retropie_setup.sh script uses those flags specified and it will pass through onto the log, otherwise they do not. See snippet below:

(this was on 64-bit RPiOS w/ RPi4)

debian/rules override_dh_auto_configure
make[1]: Entering directory '/home/pi/RetroPie-Setup/tmp/build/sdl2/2.0.15+1rpi'
CFLAGS=" -mcpu=cortex-a72 -O2 -g -O3 -fdebug-prefix-map=/home/pi/RetroPie-Setup/tmp/build/sdl2/2.0.15+1rpi=. -fstack-protector-strong -Wformat -Werror=format-security" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" CXXFLAGS=" -mcpu=cortex-a72 -O2 -g -O3 -fdebug-prefix-map=/home/pi/RetroPie-Setup/tmp/build/sdl2/2.0.15+1rpi=. -fstack-protector-strong -Wformat -Werror=format-security" FCFLAGS="-g -O2 -fdebug-prefix-map=/home/pi/RetroPie-Setup/tmp/build/sdl2/2.0.15+1rpi=. -fstack-protector-strong" FFLAGS="-g -O2 -fdebug-prefix-map=/home/pi/RetroPie-Setup/tmp/build/sdl2/2.0.15+1rpi=. -fstack-protector-strong" GCJFLAGS="-g -O2 -fdebug-prefix-map=/home/pi/RetroPie-Setup/tmp/build/sdl2/2.0.15+1rpi=. -fstack-protector-strong" LDFLAGS="-Wl,-z,relro" OBJCFLAGS="-g -O2 -fdebug-prefix-map=/home/pi/RetroPie-Setup/tmp/build/sdl2/2.0.15+1rpi=. -fstack-protector-strong -Wformat -Werror=format-security" OBJCXXFLAGS="-g -O2 -fdebug-prefix-map=/home/pi/RetroPie-Setup/tmp/build/sdl2/2.0.15+1rpi=. -fstack-protector-strong -Wformat -Werror=format-security"  dh_auto_configure -Bbuilddir/all -- --disable-dummyaudio --disable-video-dummy --enable-video-kmsdrm --disable-video-wayland --disable-rpath --disable-video-directfb --disable-nas --disable-esd --disable-arts
	cd builddir/all && ../../configure --build=aarch64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=\${prefix}/lib/aarch64-linux-gnu --libexecdir=\${prefix}/lib/aarch64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking --disable-dummyaudio --disable-video-dummy --enable-video-kmsdrm --disable-video-wayland --disable-rpath --disable-video-directfb --disable-nas --disable-esd --disable-arts

This may all be trivial but since retropie_setup.sh is built to pass through these flags everywhere else I'm unsure if that is happening with the sdl2.sh.

BuZz

@bluestang I believe our flags are passed through for sdl2. I looked into this before I think to confirm. I think i forced V=1 as makefile parameter and it shows them being used.

Try sudo __makeflags="V=1" ./retropie_packages.sh sdl2

(I did a quick test while writing this and the flags show up).

joelkolb

Does anybody have an idea of how to build PPSSPP (standalone, not Libretro core) with Vulkan support on the Pi 4? The build that is available in RetroPie has Vulkan listed as an option for the backend, but when I select it and reload it, it crashes. After loading it again, it resets itself back to OpenGL. I'm guessing it isn't properly built with Vulkan support as is. @bluestang maybe?

bluestang

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

Does anybody have an idea of how to build PPSSPP (standalone, not Libretro core) with Vulkan support on the Pi 4? The build that is available in RetroPie has Vulkan listed as an option for the backend, but when I select it and reload it, it crashes. After loading it again, it resets itself back to OpenGL. I'm guessing it isn't properly built with Vulkan support as is. @bluestang maybe?

The problem is that Vulkan on the Pi4 is not supported by standalone PPSSPP in the Linux KMS/DRM API. The issue is that SDL2 itself does not have proper support for Vulkan contexts using KMS/DRM. Work is being done to implement this so it will happen eventually.

If you were to run it in X11 it will work, but that is not a supported RetroPie configuration. In addition, performance is not better than OpenGL.

joelkolb

@bluestang I see. Thank you for the explanation. I guess I'll just have to wait.

bluestang

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

sudo __makeflags="V=1" ./retropie_packages.sh sdl2

Ah yes, thanks for the clarification.

On a side note, SDL2 had some recent commits that show a tangible performance increase for the Pi4 in EmulationStation. Unfortunately, these are post-release v2.0.14...

There is another minor issue with upstream SDL2. The Debian packaging files need to be updated in upstream as well. Building with debhelper compat v9 outputs many warnings that it is deprecated. It will build successfully but it should be updated to get rid of those warnings.

bluestang

Based on the 5.10 kernel thread in the Raspberry Pi forums, it appears that MESA updates through apt will only consist of bug fixes for the RPis. New features, i.e. Vulkan, are likely to appear with new version releases of Debian.

As best I can tell, Bullseye should be slated for a summer release but there is still no official date.

This news comes as a surprise.

busywait

@bluestang Hmm. I guess that goes for the 64-bit distro too.

Odd that they would choose to wait so long for Mesa to come via the upstream Debian, given the money they spent having the Vulkan API implemented.

Would a future RetroPie release ship with a local version of Mesa?

Manjaro just brought Mesa 20.3.3 into their stable release branch, along side Kernel 5.10.9. For fun I configured it to boot with full KMS, but then RetroArch (1.9.0) refused to start:
The path /dev/dri/ cannot be opened is not available

bluestang

@busywait
I am not familiar with Manjaro. RetroArch does work with the KMS driver. It’s been working on my end for several months without any real big issues.

The Pi4 Vulkan driver started to appear in the MESA 20.3.X releases and I can see it in the Debian Bullseye Packages.

2Play

@bluestang Hi my friend.
I ve been working the last month on Vulkan on Pi4
I think we should have a recap basis latest .
I ll share my latest too

SierraFOOL

Hallo, can i activate Vulkan for all cores in Retoarch/Retropie? Or should i activate it per core? In which Config File can i Test ist?

mitu

@sierrafool There's no switch to activate Vulkan in RetroPie as it is. Vulkan is not included in the RetroArch build and support for it is not present in Raspberry Pi OS. You'll need to manually compile MESA with Vulkan support and the same for RetroArch.

SierraFOOL

@mitu thanks, i Inderstand. Inhaber Compiler Mesa with Vulkan via pikiss. How can i Compile Retroarch with Vulkan Support? Can i See, how the Retropie Script Compile this and add a Vulkan Parameter?

mitu

@sierrafool You can see the RetroPie install script for RetroArch here, this includes the compilation switches used by RetroPie.

sergioad

How the development is going? I am hyped by the idea of Redream + Vulkan