Citra-Nightly-2104 on Pi5 (screen issue) - Nintendo 3DS

DTEAM

Here's the log from /home/pi/.local/share/citra-emu/log

We can see many errors even if it loads and many warnings in the log

New edition: here is the log without Vulkan but with the GraphicsAPI: "software" mode (which loads correctly):
https://pastebin.com/Q2vNdFBF

Differences beetween the 2 logs are only the addition of those lines for Graphic API Vulkan :

[  61.456002] Render.Vulkan <Info> video_core/renderer_vulkan/vk_instance.cpp:CollectTelemetryParameters:664: VK_DRIVER: V3DV Mesa 23.2.1
[  61.456006] Render.Vulkan <Info> video_core/renderer_vulkan/vk_instance.cpp:CollectTelemetryParameters:665: VK_DEVICE: V3D 7.1.7
[  61.456008] Render.Vulkan <Info> video_core/renderer_vulkan/vk_instance.cpp:CollectTelemetryParameters:666: VK_VERSION: 1.2.255
[  61.456030] Render.Vulkan <Info> video_core/renderer_vulkan/vk_instance.cpp:operator():430: Enabling extension: VK_KHR_swapchain
[  61.456032] Render.Vulkan <Info> video_core/renderer_vulkan/vk_instance.cpp:operator():430: Enabling extension: VK_KHR_image_format_list
[  61.456033] Render.Vulkan <Warning> video_core/renderer_vulkan/vk_instance.cpp:operator():439: Extension VK_EXT_shader_stencil_export unavailable.
[  61.456034] Render.Vulkan <Warning> video_core/renderer_vulkan/vk_instance.cpp:operator():439: Extension VK_EXT_external_memory_host unavailable.
[  61.456036] Render.Vulkan <Info> video_core/renderer_vulkan/vk_instance.cpp:operator():430: Enabling extension: VK_EXT_tooling_info
[  61.456037] Render.Vulkan <Info> video_core/renderer_vulkan/vk_instance.cpp:operator():430: Enabling extension: VK_KHR_timeline_semaphore
[  61.456039] Render.Vulkan <Warning> video_core/renderer_vulkan/vk_instance.cpp:operator():439: Extension VK_KHR_portability_subset unavailable.
[  61.456040] Render.Vulkan <Warning> video_core/renderer_vulkan/vk_instance.cpp:operator():439: Extension VK_EXT_extended_dynamic_state unavailable.
[  61.456041] Render.Vulkan <Info> video_core/renderer_vulkan/vk_instance.cpp:operator():430: Enabling extension: VK_EXT_custom_border_color
[  61.456042] Render.Vulkan <Info> video_core/renderer_vulkan/vk_instance.cpp:operator():430: Enabling extension: VK_EXT_index_type_uint8
[  61.456043] Render.Vulkan <Warning> video_core/renderer_vulkan/vk_instance.cpp:operator():439: Extension VK_EXT_fragment_shader_interlock unavailable.
[  61.456043] Render.Vulkan <Info> video_core/renderer_vulkan/vk_instance.cpp:operator():430: Enabling extension: VK_EXT_pipeline_creation_cache_control
[  61.456045] Render.Vulkan <Warning> video_core/renderer_vulkan/vk_instance.cpp:operator():439: Extension VK_KHR_fragment_shader_barycentric unavailable.
[  61.472567] Render.Vulkan <Warning> video_core/renderer_vulkan/vk_instance.cpp:CreateFormatTable:305: Format B8G8R8Unorm unsupported, falling back unconditionally to R8G8B8A8Unorm
[  61.500407] Render.Vulkan <Info> video_core/renderer_vulkan/vk_stream_buffer.cpp:CreateBuffers:176: Creating Stream buffer with size 128 KiB with flags { DeviceLocal | HostVisible | HostCoherent }
[  61.625900] Render.Vulkan <Info> video_core/renderer_vulkan/vk_stream_buffer.cpp:CreateBuffers:176: Creating Upload buffer with size 524288 KiB with flags { DeviceLocal | HostVisible | HostCoherent }
[  61.979534] Render.Vulkan <Info> video_core/renderer_vulkan/vk_stream_buffer.cpp:CreateBuffers:176: Creating Download buffer with size 16384 KiB with flags { DeviceLocal | HostVisible | HostCoherent }
[  62.011588] Render.Vulkan <Info> video_core/renderer_vulkan/vk_stream_buffer.cpp:CreateBuffers:176: Creating Stream buffer with size 65536 KiB with flags { DeviceLocal | HostVisible | HostCoherent }
[  62.055379] Render.Vulkan <Info> video_core/renderer_vulkan/vk_stream_buffer.cpp:CreateBuffers:176: Creating Stream buffer with size 4096 KiB with flags { DeviceLocal | HostVisible | HostCoherent }
[  62.057886] Render.Vulkan <Info> video_core/renderer_vulkan/vk_stream_buffer.cpp:CreateBuffers:176: Creating Stream buffer with size 2048 KiB with flags { DeviceLocal | HostVisible | HostCoherent }
[  62.058809] Render.Vulkan <Info> video_core/renderer_vulkan/vk_stream_buffer.cpp:CreateBuffers:176: Creating Stream buffer with size 2048 KiB with flags { DeviceLocal | HostVisible | HostCoherent }

and this

[  62.232942] Render.Vulkan <Info> video_core/renderer_vulkan/vk_pipeline_cache.cpp:LoadDiskCache:165: Loading pipeline cache with size 57 KB

gvx64

@DTEAM For what little it is worth, my honest opinion is that it is probably not worth it to try to get Citra working on the Pi using Vulkan unless we can find an experienced graphics developer to work on it. Vulkan support on Citra looks very preliminary - if it had a couple more years of development time before the plug got pulled on Citra development I think this might have not been the case. Vulkan is a very complex API to program for and even dolphin required 1000's of commits before its Vulkan backend matured enough to become usable. For example, if you watch the below video showing Citra running on the Pi5, specifically the portions where Sun/Moon is played you will see that the screen duplication issue is far from the only issue that Citra has running Vulkan. It looks like it also has major issues with rendering pretty much anything 3D:

I actually built your version of Citra and ran Etrian Odyssey Untold The Millennium Girl and using an existing save file. Using Vulkan, it handled the menu system really well but the screen went black as soon as I entered a dungeon (where there is rendering of 3d polys). Please let me know if you have a different experience here.

Honestly, I don't understand why Raspberry Pi OS still doesn't support GLES 3.2. Apparently the Pi's GPU is compliant, it's just that the drivers don't support it. In this case, I suspect that Citra's GLES 3.2 support is far more mature than Vulkan and Citra would likely be running quite well on the Pi using that API. Do you think that there is any chance that we can get the MESA folks to revisit GLES 3.2 compliance? It sounded like they were very close a few years ago on the Pi4 and then just stopped and moved over to Vulkan. I really believe that support for the GLES 3.2 API would be more valuable for emulation than Vulkan.

retropieuser555

@gvx64 said in Citra-Nightly-2104 on Pi5 (screen issue) - Nintendo 3DS:

@DTEAM For what little it is worth, my honest opinion is that it is probably not worth it to try to get Citra working on the Pi using Vulkan unless we can find an experienced graphics developer to work on it. Vulkan support on Citra looks very preliminary - if it had a couple more years of development time before the plug got pulled on Citra development I think this might have not been the case. Vulkan is a very complex API to program for and even dolphin required 1000's of commits before its Vulkan backend matured enough to become usable. For example, if you watch the below video showing Citra running on the Pi5, specifically the portions where Sun/Moon is played you will see that the screen duplication issue is far from the only issue that Citra has running Vulkan. It looks like it also has major issues with rendering pretty much anything 3D:

I actually built your version of Citra and ran Etrian Odyssey Untold The Millennium Girl and using an existing save file. Using Vulkan, it handled the menu system really well but the screen went black as soon as I entered a dungeon (where there is rendering of 3d polys). Please let me know if you have a different experience here.

Honestly, I don't understand why Raspberry Pi OS still doesn't support GLES 3.2. Apparently the Pi's GPU is compliant, it's just that the drivers don't support it. In this case, I suspect that Citra's GLES 3.2 support is far more mature than Vulkan and Citra would likely be running quite well on the Pi using that API. Do you think that there is any chance that we can get the MESA folks to revisit GLES 3.2 compliance? It sounded like they were very close a few years ago on the Pi4 and then just stopped and moved over to Vulkan. I really believe that support for the GLES 3.2 API would be more valuable for emulation than Vulkan.

Fwiw 3DS emulation is in a weird flux right now given there's multiple competing software that is all derivatives of Citra it appears.

Give it a few years for an obvious front running to come forward, as a bunch of them right now do boot into arm64 (I'm using Panda3ds and found it's good for Fantasy Life, Pushmo and some others) but they're in very early stages of development

DTEAM

@retropieuser555 @gvx64

Thanks for your comments. With your work with Dolphin for the Pi, I was hoping you would respond to this thread. I'm happy to hear your thoughts. I'm currently chatting with one of the people who wants to restart the project. If you feel like commenting or helping out on this thread, you're more than welcome.

https://github.com/Borked3DS/Borked3DS/issues/330

He seems to be interested to help for Pi5

For GLES 3.2 I saw Mesa and GLes in the same sentence here. Don't know if it can help
https://www.glfw.org/docs/latest/compile.html

https://discourse.glfw.org/t/glfw-and-mesa/176

DTEAM

@gvx64 said in Citra-Nightly-2104 on Pi5 (screen issue) - Nintendo 3DS:

I actually built your version of Citra and ran Etrian Odyssey Untold The Millennium Girl and using an existing save file. Using Vulkan, it handled the menu system really well but the screen went black as soon as I entered a dungeon (where there is rendering of 3d polys). Please let me know if you have a different experience here.

Yes but I didn't play with the API setups. We don't have this problem with Vulkan on Microsoft Windows. I always compare the game performance on both systems and I agree with you, the development of this emulator on Linux/Mesa (Pi5) with Vulkan is not at the same level than the one on Microsoft Windows.

I'm looking forward to seeing if someone with the skills will take this on with the Borked3DS project. It's one of the only new projects alive that continues where Citra left off.

Thanks again for your comments!

gvx64

@DTEAM I appreciate your kind words. The thing is that I am not an actual software dev like the people who create these emulators. I am just notoriously bad at giving up on things once I start which somewhat masks my lack of experience to a degree. That said, even on dolphin-rpi most of my work was rolling-back and rolling-forward the commits of actual devs, filling in a few blanks here and there and then just handling the debugging of the code.

On the topic of GL ES 3.2, I did some more reading and it sounds like Broadcom actually has internal drivers that are fully GL ES 3.2 conformant for the Raspberry Pi's GPU but they won't share it with Raspberry Pi Foundation. The Rapsberry Pi Devs have not been able to pass all of the necessary GLES 3.2 conformance tests using their own drivers and so I don't know if they are still actively pursuing it (source: https://forums.raspberrypi.com/viewtopic.php?t=260995#p1589780). I know that Raspberry Pi4's Secondary Memory Interface details eventually found its way into the hands of the general public (and that was Broadcom internal for a long time) and so who knows what might happen one day with those working GL ES 3.2 drivers. I believe that releasing these drivers (at least to the Pi engineers) would go along way to provide the missing piece to the puzzle of GL ES 3.2 support on the Pi. GL ES 3.2 which would deliver significant benefit to emulators on the Pi like Citra, dolphin, AetherSX2, and probably a lot of others so if somebody at Broadcom reads this, please do the right thing.

Anyways, I do not want to get anybody's hopes up as I am not experienced with graphics programming (which is why I am voiding Vulkan completely) and this may not work out all but I am investigating if it might be feasible to replace the GLES 3.2 API entry points in Citra that are not supported by the Pi with supported ones. It does seem that my Pi4 running the current MESA Bookworm drivers does support at least some GL ES 3.2 extensions and so it is possible that it may only require a reasonable amount of modification to the opengl renderer backend to get it to the point of functionality on the Pi. I can already get the build of citra you linked above to launch in via GL if I do the following:

Edit the file in the citra sourc-code before compiling:
../src/citra/default.ini.h (line 107) change to:

use_gles = 1

and then, after building, launch Citra with the following command (you will need xinit after the env variables before the program path if you're are not in the desktop):

MESA_GLES_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERRIDE=320 /home/pi/citra/Build/bin/Release/citra-qt

Using this method, I am able to get good performance in the fmv and menu system of Etrian Odyssey Millennium Girl. No screen duplication and I can even edit the map screen. The game crashes when I enter a 3D dungeon because of a segfault that occurs from the fact that glMapBufferRange() function does not support gl_texture_buffer targets pre-GL ES 3.2, which is not surprising. I assume that any 3D rendering will generate a segfault at this point but it is more than I expected that 2D menus/maps and full-motion video cutscenes seem to work perfectly at least in this one game. Right now, I see more potential getting Citra on the Pi working using GLES than I do from Vulkan (especially in the context of me modifying this code with my limited abilities).

DTEAM

@gvx64

Thanks for your reply

Right now, I'm doing some testing (basically I create log files) for a new project that combines all previous projects. https://github.com/Borked3DS

-Currently, we managed to compile with a shell and load games with Vulkan with two screens. The guy (Rtiangha) fixed the bug mentioned above. To compile and have a better experience you also need MESA (faster) and CMake from the backport. We can run some games without problems like Mario Kart 7. Most games have a black screen issue or close after some menu selections.

Here are the two reported issues. One is closed and the other is active. Feel free to help us.

https://github.com/Borked3DS/Borked3DS/issues/330
https://github.com/Borked3DS/Borked3DS/issues/356

Maybe another way to fix the bug, will be the installation of MESA 24.3/Vulkan1.3. Don't know if I need to install Debian 13 - Trixies (in develop.) to do that or go above the actual backport limitations. I have read Vulkan 1.3 is stable on a Pi5

After that, in my mind, the hotkeys for gampepads will be the next big thing to fix, the rest will be fine tunings .

@gvx64 said in Citra-Nightly-2104 on Pi5 (screen issue) - Nintendo 3DS:

...
Using this method, I am able to get good performance in the fmv and menu system of Etrian Odyssey Millennium Girl. No screen duplication and I can even edit the map screen. The game crashes when I enter a 3D dungeon because of a segfault that occurs from the fact that glMapBufferRange() function does not support gl_texture_buffer targets pre-GL ES 3.2, which is not surprising. I assume that any 3D rendering will generate a segfault at this point but it is more than I expected that 2D menus/maps and full-motion video cutscenes seem to work perfectly at least in this one game. Right now, I see more potential getting Citra on the Pi working using GLES than I do from Vulkan (especially in the context of me modifying this code with my limited abilities).

This is very interesting. thanks

DTEAM

This post is deleted!

gvx64

@DTEAM said in Citra-Nightly-2104 on Pi5 (screen issue) - Nintendo 3DS:

@gvx64

After that, in my mind, the hotkeys for gampepads will be the next big thing to fix, the rest will be fine tunings .

Yes, good point. In addition to that I would like to add functionality allowing an analog stick to control a stylus cursor similar to how it is done in MelonDS. That said, I need to figure out the video backend problem before I think too much about that.

Regardless, continue with your good work here. I actually like that we are taking different routes to find a solution to the rendering problems on the Pi, if one of us hits a dead-end then there is a fallback.

DTEAM

@gvx64

I succeed to install MESA 25.0.0-1/Vulkan 1.4 (Debian 13 - trixie) with
deb http://ftp.de.debian.org/debian sid main
and
sudo apt install -t sid mesa-va-drivers

It's experimental, but will see. I'll do some test with Borked3DS and his official repo today

New editL : Unlike the "backport" option, the "sid" option creates slight bugs in Retropie. I don't recommend installing this version for now if you want your Retropie to be clean. They say that several bugs will be fixed in version 25.0.1. Do a backup first.

Retropie Bugs with what I did are for now :

audio mixer
line 181 system.sh
line 375 system.sh
line 963 package.sh

Also, I had to reinstall Dolphin and it works now. No impact on other emulators.

DTEAM

@gvx64

Borked3ds hit a dead end for now. I agree with you they need someboby with Vulkan skills

BTW. MESA 25.0.0 is unstable or hard to manage and it's more a problem than a solution for now. Also, I was not able to run and to compile/reinstall your dolphi-rpi with MESA 25.0.0. I'll go back with bookworm backport for now. I'll do another test in few months.

gvx64

@DTEAM Thank you for the updates on this. I actually didn't know when I made my first post on this thread that Vulkan on Citra was working fine on Windows. The amount of work needed to get it working on the Pi may not be as substantial as I thought, especially with the screen duplication issue has been corrected on the Borked3DS fork as you say.

I don't know much about Vulkan but if you think it would be worthwhile I can try building the Borked3DS build and seeing if I can figure out what the problem might by hacking around the old fashioned way. I can probably only fix something simple, but if nothing else I can probably at least tell you and the dev you are working with where the code is getting hung up.

DTEAM

@gvx64 said in Citra-Nightly-2104 on Pi5 (screen issue) - Nintendo 3DS:

I can try building the Borked3DS build and seeing if I can figure out what the problem might by hacking around the old fashioned way. I can probably only fix something simple, but if nothing else I can probably at least tell you and the dev you are working with where the code is getting hung up.

Yes please. I'm running MESA 24.3/Vulkan 1.3 (Debian testing) and it's pretty stable on Pi and all the emulators work well including your dolphin-rpi version. I'm not an expert but I think the problem with Borked3DS is not only a Vulkan problem. I think it doesn't handheld something else. See the last comment in this thread.