Add Vulkan Support to RetroPie for Pi 4?

bluestang

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

@bluestang do you think the dolphin emulator can be compiled in the near future to run the Vulkan driver on the Pi 4 or will depend on the dolphin developers to make it happen?

Sorry for the delayed reply, but dolphin has to be compiled on 64-bit AFAIK.

The libretro one fails for me, and standalone worked but it was slow.

The Vulkan driver will help with some emulators but not all. The truth of the matter is that the limitation is in the hardware and the software can only do so much to overcome that.

sergioad

Friends how is Flycast doing with Vulkan? My Christmas present is a pi 4 with aluminum case to run Dreamcast games so I am anxious to get my hands into it and play right away

bluestang

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

Friends how is Flycast doing with Vulkan? My Christmas present is a pi 4 with aluminum case to run Dreamcast games so I am anxious to get my hands into it and play right away

Flycast runs with the current RPi4 driver but it does have some quirks. There have been performance gains seen by those that have tested it out.

The Vulkan code in Libretro Flycast needs some chgs, because it mixes Vulkan 1.0 and 1.1 features but doesn’t do proper checks to sort it out, but rather makes assumptions based on extensions used in both versions of the Vulkan API. It doesn’t account for the RPi4 v3dv state where it is 1.0 conformant but also has 1.1 features but is not 1.1 conformant...yet. Other devices would be in the same boat too if their use case was the same.

For FWIW, upstream Flycast integrated the proper checks, which is checking the driver’s instance version vs extension checks. I’ve been working on this in my spare time to mirror what is being done in upstream but I don’t have any timeline as to when I will submit PR(s). The Vulkan backend was completely revamped in upstream, and it is not an easy backport for me since I’m also learning the Vulkan API too.

sergioad

@bluestang Ok, thank you very much

bluestang

@sergioad
My PR was merged into lf-flycast. It just implements the proper way of checking the gpu’s supported Vulkan API. IMO the Vulkan backend needs more chgs but this PR will get it working if you have Vulkan installed for your RPi4.

sergioad

@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

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.