Add Vulkan Support to RetroPie for Pi 4?

myzar

@bluestang sorry for having wasted your time , i had some leftover of an old vulkan pkg and it was using that not the new one, purged and removed it and wow flycast is indeed faster , i'm testing daytona and i can see the difference

BuZz

@myzar are you comparing performance against the older packaged mesa driver? There are performance improvements with GLES in the latest mesa drivers so you should check with that also.

myzar

@buzz i'm switching live between the gles and vulkan driver with the fps counter enabled , in daytona is 6/7 fps higher and never dips below 30fps like the gles does, overall is a better experience. Yeah the gles driver is faster than it used to be for sure, daytona used to run like crap. Now it's okish with the gles driver and verygood with vulkan

BuZz

@myzar sounds good.

bluestang

@myzar I'm glad you got it sorted. As development progresses, things should get better under Vulkan for the Pi 4.

myzar

@bluestang yeah i'm impressed that it works with flycast , it's an early not optimized driver , the future looks bright , i wonder if we can get ppsspp to work too with the same speedup

rubencg

@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?

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