VF2 has three sound output modes: HDMI/PWMDAC/Bluetooth. Will changing the sound output mode improve it? 
Iāve noticed the projects over at Harbour Masters Ā· GitHub now support building with a USE_OPENGLES option.
It took me some while to figure these out, it turned out I needed an 8 GB swapfile to compile any of them. I tried two, Mario Kart and Zelda OOT, with mixed results.
Mario Kart 64 runs slow no matter what you do to graphics settings. Surprisingly, the emulated version is quicker once it compiles its shaders. Must be the huge tracks it is loading, or something?
Zelda on the other hand is very playable. Fullscreen 1920x1080 you only experience dips to 14 fps at the biggest of areas - since the game is designed to run at 20, I call that a win. The only issue is that parts of the graphics are simply missing. Half of Epona is gone, as is half of Hyrule Castle from distance, next to several other random things. I swapped around the OTR files with a fully working concurrent amd64 copy with no effect, so I guess itās the shaders or something.
Iām surprised to see Ocarina working so well, even with half of it gone. Might try to compile Majora in the future and report how it goes.
2 Likes
ā¦ so Iāve tested Star Fox 64 (āStarshipā) and Majoraās Mask (ā2ship2harkinianā) from HarbourMasters.
Star Fox 64 does not run well, not even the title screen does. I blame the shadows and move on.
Majoraās Mask is surprisingly playable. Much like Ocarina it will have an occasional framerate dip, here they happen on scene flyovers when entering a place, and, similar to Ocarina, whenever particles take up a portion of the screen, either as floaty semitransparent pixels, or whenever Tatl or Navi get closeups. I expect Termina Field to chug more (particles, semitransparent slime enemies, large draw distance) ā¦ but I did not play far enough to get to Termina Field because frankly I find this game spiteful and annoying. The big take is that all textures are working fine. So they should be working in Ocarina, too, and I should first try building a āReleaseā version, then, provided they still donāt show, probably file a bug report over at Shipwright 
Majoraās Mask is not a game I like. Its native build is also not something I was ever expecting to be able to play on this device, though.
Edit: what a ride this machine has been. To think I was once happy to get Abiword and DosBox working.
Almost forgot, this is a clock I use in SwayWM to ditch swaybar/waybar/GUI info bars entirely. Bound it to appear as a floating, 10% transparent app on (Win)+c. (Win)+f then makes it a (100% opaque) screensaver. Same button combo to get back to desktop. (Win)+D to get rid of it.
Just a tip, you can adjust the colors before compilation. (I inverted them to turn my Wayland machines into nice dark desktop/wall clocks whenever their screen isnāt being used.)
2 Likes
I havenāt used Sway for a few years. Since I learned to use Labwc on ArchLinux-CTW, Iāve been using Labwc with xfce4-panel in Starfive_Debian. It continues the habits of Openbox and XFce4. 
I figure this is the best place to ask: has anyone gotten a web browser working at something other than a snailās pace? For me, Chromium complains about missing VK_KHR_surface and ERROR:ui/ozone/platform/wayland/gpu/gbm_pixmap_wayland.cc:93] Cannot create bo with format=RGBA_8888 and usage=Scanout|Rendering|Texturing under Vulkan. Firefox uses WebRender so it only has GLES as an available backend, and itās not happy either: libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglTerminate: DRI2: failed to add configs. So to use either Iām forced to fall back to software rendering which makes things effectively unusable.
Iām forced to run the compositor (in this case Sway) under GLES because WLR_RENDERER="vulkan" gives Could not match drm and vulkan device. Both Niri and cosmic-comp are at various different levels of ānot workingā because they use Smithay which wants syncobjs, and
2127 ioctl(66, DRM_IOCTL_SYNCOBJ_EVENTFD, 0x3fd1545468) = -1 EOPNOTSUPP (Operation not supported)
2127 ioctl(46, DRM_IOCTL_SYNCOBJ_CREATE, 0x3fd1539348) = -1 EOPNOTSUPP (Operation not supported)
When I Google around I find Vulkan Driver Broken? VK_KHR_SURFACE unsupported but itās completely dead with no leads. This is the only thread with real activity thatās talking about graphics 
To be honestā¦ no.
I had the most the most luck with Firefox from the repo - not even the one advertised as āoptimizedā in the boardās official manual, just vanilla - where I can get those web3d things (like the aquarium demo) to work. Youtube is unusable. It does report to use the gpu, but itās still very slow, BUT part of it has to do with Google hindering Firefox when recognized. So youād want a browser spoofer. But that takes resources to use, so the end result is the same: slow.
I tried alternative browsers, Links and Links2 would probably work. Dillo Plus works fine, but is still an X11 app. The more advanced modern ones, like Ladybird, do not build.
If youāre going to compile Chromium, try building it, if possible, with wayland and GLES2 enabled and X11 and OpenGL disabled - so it will have nothing but wayland/gles to default to. I havenāt tried it yet (and frankly for all the bloat it comes with Iām not sure Iād want to) but that seems to be the rule of thumb with this boardās gfx stack. Like, itās almost like it thinks it supports X11 and OpenGL, so whenever it gets a chance, it tries to fall back to them. But it does not support X11 and OpenGL sufficiently at all, of course.
ā¦ Vulkan? No. No vulkan here. Driver very broken in many places
1 Like
I donāt care too much about video decode (actually if you build the wave5 kernel module thatās in mainline Linux already, just not enabled by default for StarFive architecture, it works as far as I can tell, but itās v4l2 and not vaapi so Iām not sure about browser support), but I couldnāt get compositing to be accelerated / I was dealing with solely software rendering for HTML elements. Even debugging why this was happening would take ages because there would be multiple seconds of delay between me wanting to input something (like navigating to about:support or scrolling thru one of the pages). I could get Chromium to have hardware accelerated canvas and somewhat accelerated WebGL, but I couldnāt get Firefox to accept the GPU at all.
What flags/CLI args/etc did you use for Firefox?
I think itās worth mentioning separately that if there were a wave4 kernel module (or if someone gets the StarFive wave4 stuff working on a modern ffmpeg) one could likely play/stream fully through sunshine/moonlight. I looked into this a bit ago but I donāt have the energy to make it happen, and now that I have a working display Iām not sure how much I care.
Someone used AI to help with VA-API for the Rockchip RK3588.
Perhaps it can help if anyone wants to try with the VF2.
What flags/CLI args/etc did you use for Firefox?
MOZ_ENABLE_WAYLAND=1 (MESA_LOADER_DRIVER_OVERRIDE=pvr and SDL_VIDEODRIVER=wayland might also help)
I should note that at one point on official debian my GPU just stopped working; it happened to all my installations eventually. So then I made a copy of the driver and renamed it to whatever it was looking for and it has been working ever since.
Edit
libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglTerminate: DRI2: failed to add configs
Hmm a wild shot but from my experience this sometimes means it should have been compiled with -lEGL linker tag
Edit 2: now I am not sure my Firefox uses GPU to accelerate canvas, anymore ā I only assume it does since it renders 3D at a reasonable pace and reports the correct GPU on the info page - but is so slow to render the internet it might actually not be the case. Are the renderers separate? Can you view the WebGL Aquarium on your Firefox?
1 Like
Yes: for Chromium my screenshot shows software compositing. For Firefox, see Firefox Hardware acceleration - Fedora Project Wiki . This was my main issue with both (I never took a screenshot of Firefox): browsing the web is horribly slow because all the page rendering is going through the CPU (which canāt handle it). So all Iām looking for is hardware-accelerated compositing.
I didnāt have egl-wayland installed: Iāve installed the package remotely, and once Iām physically back at the system Iāll try Firefox again and see if having egl-wayland helps.
Yea, for me, it seems the page elements are not being processed by the GPU, but rather in software. Web3D is accelerated, though, oddly enough. Please post here if you find any solution to this. 
A report on a brighter note, I tried building Xash3D along HLSDK-Portable, it went smoothly and Half-Life works fine. Building Xash3D has several renderer options, gles2 and gles3-compat both work well, gles3-compat is slightly slower, but looks nicer. Seeing this in action confirms my suspicions that the GPU is capable of Dreamcast/Gamecube level of 3D graphics.
So Iām guessing Counter-Strike works well, too. Which, well, might be of interest to a few people.
2 Likes
One of the contributors of Yamagi Quake 2 asked me to test OpenGL ES1 on the VF2. Really fast, but doesnāt render everything (notably blood). He hopes to optimize OpenGL ES3 in the future.
This is the build command: make -j4 WITH_SDL3=no with_gles1
Update: You can make the blood particles visible with the following command in the game console: gl1_pointparameters 0
And restart. vid_restart
2 Likes
Haha, when I first saw your video, I thought it was about the K3 
Itās nice to see things run on this gpu, even nicer to see them run smoothly. Yea it can do it, just needs support.
Speaking of the K3, whatever you build on VF2 should work on it. Could you, er, maybe compile Flycast emulator on that machine and showcase it? >_> there will be lots (5-7) of errors, but I promise youāll learn something Flycast considers all freelance GLES as āGLESā and Appleās GLES as āGLES2ā, by the way
Do it for the views, be the first 
you can test it using sonic adventure 2 trial, since itās trial I think itās legal to showcase (crush 40 wonāt hunt you down)ā¦
Flycast works good without the Dreamcast system rom? To avoid any legal issues, I might try some homebrew. Or I can try to find some games in a thrift shop.
I have some really stupid emulation prepared on the K3. But itās so slow, itās embarrassing.
Did you get Flycast working? I installed glslang-dev, and Iām not really sure what Iām doing, but I tried cmake like this: cmake .. -DARCHITECTURE=rv64gcv
Now Google Breakpad dump_writer_common raw_context_cpu.h is telling me that this code has not been ported to your platform yet.
Any hints?
I forgot about this post, but this the command I used on the K3.
git clone --recursive https://github.com/flyinghead/flycast.git
cd flycast
cmake -B build -DUSE_BREAKPAD=OFF -DUSE_HOST_SDL=ON -DUSE_OPENGL=ON -DUSE_GLES2=OFF -DUSE_GLES=ON -DCMAKE_BUILD_TYPE=Release -DARCHITECTURE=rv64gcv
cmake --build build --config Release
Iām not claiming this is ābetterā, but it works. Perhaps I can try to add some more extensions to test if that makes things a bit faster. On the VF2 I assume you have to omit v in the architecture string, as there is no support for vectors. I kept Vulkan, as we have a working Vulkan driver. And as earlier mentioned, I installed glslang-dev.
I didnāt make any changes to /core/types.h. I donāt know what you changed there.
With the other three files I commented out throwing the error.
/core/build.h
/core/linux/context.cpp
/core/hw/sh4/sh4_core_regs.cpp
So I assume we donāt have something like Dynarec working.
I tested with Volgarr the Viking, as the Dreamcast port was released for free. I only get a couple of frames per second, but still impressive to see it works at all. And quitting the emulator will leave me with a black screen, meaning I have to do a hard reset.
1 Like
Awesome, you actually did it! And the fact that it works slow for you makes me hopeful (since itās not the GPU, itās all the missing RV64 opcodes thatās making it slow). Maybe you can try duckstation next (when you see #error and compiler stopsā¦ just turn that error into a ā#warningā ā¦ what could go wrong? >_>)
By the way Iām trying figure out why your Luanti on K3 is so slow. It never ran like this for me on the VF2, not even when I had postproduction enabled. It can be choppy like in your video, but only if I fill it with mods and only until it finishes generating chunks. Itās steady at 30 fps at 1920x1080, well, mobs might chop the framerate, but never like yours. Are you sure youāre running on GLES? Iāve seen the game prefer any other option unless Iāve explicitly turned off everything else at compilation time.
I need to refactor some of the above posts, or statements made within. Mupen64PlusQt works, just needs a cli app properly linked. It adds things to launch line, so it makes emulation run even better than the cli version on its own.
Iāve also sacrificed parts of my sanity and played through the insanely sadistic and consistently awful game that is Majoraās Mask. It runs very well. It chops up the framerate when loading scenes, but does not dip on Termina Field or anyplace else. It still made me almost smash my cart with a hammer (but this thing cost like 200.- DM back in the day). There is a reason I have not played it in 15 years, hfs
Now to fix the actually good Zelda game, I guess.
Duckstation lists compatibilty with RV64 on Github, but perhaps the developer never tested it on actual hardware?
CPU Recompiler/JIT (x86-64, armv7/AArch32, AArch64, RISC-V/RV64).
I built Luanti like this: cmake . -DRUN_IN_PLACE=TRUE -DENABLE_GLES2=ON
Perhaps there is a way to go to GLES1?
Here you can see the renderer in Luanti (timestamp in the URL).
With DuckStation, I assume you mean SwanStation that you listed earlier?
Iām able to build it with Vulkan on the K3. I had to enable Wayland (-DUSE_WAYLAND=ON) to get it working (and the other fixes you mentioned).
Lazy people can try PCSXR, as you can install it from the Debian repo and a lot of games will run without a PS1 BIOS.