With the joint efforts of the PPSSPP community and StarFive Technology software team, PPSSPP 1.16 added a New JIT backend for RISC-V, based on IR.
You can play PSP games on VisionFive 2 Now! The frame rate and performance of the game are constantly improving, and developers are welcome to try it out. Go to downloads to get it!
This video is about playing God for War on RISC-V SBC VisionFive 2 using this new JIT backend implemented by Unknown (unknownbrackets (Unknown W. Brackets) · GitHub).
Did you install a GPU driver to get this to run, and if so, how?
For graphics, currently you have to use GLES. As long as you’re using the Debian image, you should be able to just use the included driver. For Vulkan, there’s an issue in the driver and it’s unusably slow. It may default to Vulkan still, in which case you’d need to change to GLES.
The IR is a custom IR - PPSSPP’s jit for RISC-V is now using that IR, and I’ve also written a new jit for x64 (~10% faster, depends on the game) and arm64 (about even, disappointingly, with the old jit) that use the IR as well. But it’s custom-designed for our purposes - debugging metadata, cycle tracking, and specific ops to match the PSP’s complex matrix-based SIMD coprocessor.
A note for performance on the VisionFive 2 - you’ll likely want to turn on “lazy texture hashing”. This can result in a few graphical glitches, but currently the texture hashing is very expensive. Also, the community has created a patch for God of War which reduces its internal FPS to 30 FPS, and this makes it far more playable on ARM and RISC-V devices of VisionFive 2’s performance class.
-[Unknown]
I’m gonna try it on the ArchLinux image. I’ve been maintaining the PKGBUILD for mesa for Arch and recently got retroarch and a few SDL2 apps that use GLES working well.
I noticed it’s not in github actions or the release page. Do you need help with CI? I could try to set something up to run on “docker on qemu riscv64” aka docker buildx. I did something similar with psptoolchain but never finished it end to end.
Maybe I’ll finish the psptoolchain one first so you can get an idea what it would look like 
I decided to give it a try, but I don’t see any binaries. Are there any build instructions for Debian on VF2?
This should basically work from the source:
git clone --recurse-submodules https://github.com/hrydgard/ppsspp.git
cd ppsspp
cmake -DCMAKE_RELEASE_TYPE=Release -DUSING_EGL=ON -DUSING_GLES2=ON -GNinja -Bbuild -S.
MIMALLOC_SHOW_ERRORS=0 mold --run cmake --build build -j4
./build/PPSSPPSDL
You can pick between clang and gcc, just use update-alternatives to set your preference beforehand. You can skip mold if you want, but I recommend it - it links much faster (you’ll need apt-get install git build-essential cmake mold ninja-build.)
In the past I had to rebuild SDL for GLES to work. I just did it last time I updated the image, without checking if it’s still necessary. If it is still needed, I just used ./configure --disable-video-opengl for it.
I also had to run these, but again might’ve been a problem from a previous image only:
sudo ln -s /usr/lib/riscv64-linux-gnu/libGLESv2_PVR_MESA.so /usr/lib/riscv64-linux-gnu/libGLESv2.so
sudo ln -s /usr/lib/riscv64-linux-gnu/libEGL.so.1 /usr/lib/riscv64-linux-gnu/libEGL.so
If anyone wants to contribute / maintain binaries, that’s always appreciated. All the builds outside Windows and Android are contributed.
A RISC-V GitHub Actions setup would be convenient if it could slot in to running the normal build commands. It would actually be most convenient there to just directly cross compile - compiling within qemu doesn’t seem all that useful, except a way to make builds take longer. Could run tests within qemu though.
-[Unknown]
Yeah the qemu compilation is pretty slow indeed. But it saves a lot of headaches. C/C++ is such a pain in the ass to cross-compile.
I got it built and running on the VF2 ArchRiscv image but only on X11, when I tried wayland I got an EGL_BAD_NATIVE_WINDOW error any time I tried to interact with (hover mouse over) the ppsspp window. Any ideas about that @unknownbrackets ? It might be my fault as I’m using best-guess flags with starfive’s buildroot patches to build mesa. But thought I should mention it just in case.
The docs have some description about the error here eglCreatePlatformWindowSurface - EGL Reference Pages
Do you have a custom pkgbuild for sdl2?
Nope I just use env vars as below
export QT_QPA_PLATFORM="wayland;xcb"
export SDL_RENDER_DRIVER="opengles2"
export SDL_VIDEO_GL_DRIVER='GLESv2_PVR_MESA'
export MESA_LOADER_DRIVER_OVERRIDE="pvr"