Open Mershl opened 3 years ago
Thank you very much for your feedback! Some of the issues are currently known and we are working to fix them.
Things I've noticed in direct comparison to the AppImage:
At the moment, we do not plan to replace AppImage with Flatpak, so we can fix the issues while a more feature-complete distribution is around.
- Vulkan Devices are not listed when choosing Vulkan API
Which graphics card are you using? If your answer is NVIDIA, then the issue is tricky, you need to check if you have the NVIDIA proprietary driver portal system installed by examining the output of flatpak list
command. You should see something similar as follows:
Name Application ID Version Branch Installation
Citra org.citra_emu.citra nightly-1711 stable user
Mesa org.freedesktop.Platform.GL.default 21.1.1 20.08 system
Mesa org.freedesktop.Platform.GL.default 21.1.1 20.08 user
nvidia-465-31 org.freedesktop.Platform.GL.nvidia-465-31 1.4 system
nvidia-465-31 org.freedesktop.Platform.GL.nvidia-465-31 1.4 user
openh264 org.freedesktop.Platform.openh264 2.1.0 2.0 system
openh264 org.freedesktop.Platform.openh264 2.1.0 2.0 user
Breeze Gtk theme org.gtk.Gtk3theme.Breeze 3.22 system
Adwaita theme org.kde.KStyle.Adwaita 5.15 system
KDE Application Platform org.kde.Platform 5.15 system
KDE Application Platform org.kde.Platform 5.15 user
KDE Software Development Kit org.kde.Sdk 5.15 system
Yuzu org.yuzu_emu.yuzu mainline-0-655 stable user
As you can see, the items begin with nvidia-
are driver portals, if you don't have them installed, you need to install them (with the correct version matching the ones on your host system).
- Compatibility column is set to "Not Tested" and does not refresh
This is because the Flatpak version of Yuzu is built using FlatHub CI and their CI system forbids connecting to the Internet while building. Our current build system will fetch a compatibility list via the network during build time, so the compatibility list will be missing. We are currently working to fix this in a similar fashion as Citra did.
- The default Light Theme is actually Dark. (Tested on Gnome 40 with Yaru Theme)
This is likely due to an interoperability issue with themes. Default themes are handled by the host system and will always match the colors and styles with the themes you are currently using on the host system.
- Starting a game with Vulkan crashes yuzu with
Unhandled SIGSEGV at rip 0x0055a5cfe49000
This is likely due to the first issue you mentioned with unable to select Vulkan devices. I can't reproduce this issue on my device:
- Running a game with OpenGL boots, but immediately turns the window fully transparent. The log fills with:
Again, the last two issues are probably the byproduct of the first one you mentioned. We need you to upload a copy of the log to verify the issue.
Added my specs to the main post.
Vulkan Devices are not listed when choosing Vulkan API
Found the culprit for that. mesa provides 2 ICD loaders for AMDGPU - radeon and lavapipe (lvp). Setting VK_ICD_FILENAMES to only include radeon will result in the Vulkan device selection of Yuzu being empty, and the crash. Leaving the VK_ICD_FILENAMES unset will make the device selection of Yuzu working as intended. Unfortunatly due to an upstream mesa issue it's currently necessary to restrict the available ICDs to radeon (e.g. https://gitlab.freedesktop.org/mesa/mesa/-/issues/4828).
Starting a game with Vulkan crashes yuzu with Unhandled SIGSEGV at rip 0x0055a5cfe49000
This issue is resolved while VK_ICD_FILENAMES is unset. Tested with mesa 21.1.1.
Running a game with OpenGL boots, but immeditaly turns the window fully transparent. The log fills with: Wayland specific. Running the flatpak without wayland socket fixes this issue.
This issue remains and also applies to Vulkan, now that is boots and runs. Games start (Audio is playing, but the window turns fully transparent). Log still fills with dri_create_context: requested glthread but driver is missing backgroundCallable V2 extension
and QWaylandGLContext::makeCurrent: eglError: 3002, this: 0x7f51f1d55200
. Tested with Gnome 40.2 (wayland session).
socket=wayland
from the apps permission makes Yuzu fallback to Xwayland.With both workarounds in place games boot and run as expected using OpenGL and Vulkan.
Thanks for your investigation!
Found the culprit for that. mesa provides 2 ICD loaders for AMDGPU - radeon and lavapipe (lvp). Setting VK_ICD_FILENAMES to only include radeon will result in the Vulkan device selection of Yuzu being empty, and the crash. Leaving the VK_ICD_FILENAMES unset will make the device selection of Yuzu working as intended. Unfortunatly due to an upstream mesa issue it's currently necessary to restrict the available ICDs to radeon (e.g. https://gitlab.freedesktop.org/mesa/mesa/-/issues/4828).
I am afraid this is not something I could workaround at the moment. I will however ask Flatpak folks for ideas (if they ever reply to my messages that is).
This issue remains and also applies to Vulkan, now that is boots and runs. Games start (Audio is playing, but the window turns fully transparent). Log still fills with
dri_create_context: requested glthread but driver is missing backgroundCallable V2 extension
andQWaylandGLContext::makeCurrent: eglError: 3002, this: 0x7f51f1d55200
. Tested with Gnome 40.2 (wayland session).
I have removed socket=wayland
starting version mainline-0-657
as suggested.
Sorry for the ping, are there any other issues since mainline-0-667
?
Hi @liushuyu, I've went on a testing spree yesterday with yuzu 667 and all games I own.
socket=wayland
is locally forced. I'm not quite sure what is breaking here. Thanks for disabling it per default for now - this fixes it.VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.i686.json:/usr/share/vulkan/icd.d/radeon_icd.x86_64.json
resulting in 0 Vulkan devices in Flatpak Yuzu" bug is still present. This is a regression of Flatpak Yuzu compared to AppImage Yuzu. AppImage Yuzu will still find the correct Vulkan device as expected, but Flatpak Yuzu will list 0 Vulkan devices with the env var set.GPU cache garbage collection
, which allowed SSBU to run for longer than 2 hours when running with 1 player (see below).Thank you very much for your report!
I also received some reports from other members of the community, I will document the findings here as well:
xdg-desktop-portal
) and Arch Linux packaged Xfce suites. Tested on some other Linux distributions with Xfce and found no issue.Added my specs to the main post.
Vulkan Devices are not listed when choosing Vulkan API
Found the culprit for that. mesa provides 2 ICD loaders for AMDGPU - radeon and lavapipe (lvp). Setting VK_ICD_FILENAMES to only include radeon will result in the Vulkan device selection of Yuzu being empty, and the crash. Leaving the VK_ICD_FILENAMES unset will make the device selection of Yuzu working as intended. Unfortunatly due to an upstream mesa issue it's currently necessary to restrict the available ICDs to radeon (e.g. https://gitlab.freedesktop.org/mesa/mesa/-/issues/4828).
- This behaviour is different to the AppImage (which works with VK_ICD_FILENAMES restricted to radeon).
- Workaround for now: ensure VK_ICD_FILENAMES is unset.
Starting a game with Vulkan crashes yuzu with Unhandled SIGSEGV at rip 0x0055a5cfe49000
This issue is resolved while VK_ICD_FILENAMES is unset. Tested with mesa 21.1.1.
Running a game with OpenGL boots, but immeditaly turns the window fully transparent. The log fills with: Wayland specific. Running the flatpak without wayland socket fixes this issue.
This issue remains and also applies to Vulkan, now that is boots and runs. Games start (Audio is playing, but the window turns fully transparent). Log still fills with
dri_create_context: requested glthread but driver is missing backgroundCallable V2 extension
andQWaylandGLContext::makeCurrent: eglError: 3002, this: 0x7f51f1d55200
. Tested with Gnome 40.2 (wayland session).
- Workaround for now: Removing
socket=wayland
from the apps permission makes Yuzu fallback to Xwayland.With both workarounds in place games boot and run as expected using OpenGL and Vulkan.
Is there a reason why Wayland is not working?
Oh and please set this variable instead of removing the wayland socket: QT_QPA_PLATFORM=xcb
Oh and please set this variable instead of removing the wayland socket: QT_QPA_PLATFORM=xcb
Hi @iMonZ, can you please elaborate on this? From a Gnome LookingGlas point of view (ALT+F2 -> lg
) both ways seem to have the same effect. Yuzu will run through XWayland on Wayland, instead of native.
This issue remains and also applies to Vulkan, now that is boots and runs. Games start (Audio is playing, but the window turns fully transparent). Log still fills with dri_create_context: requested glthread but driver is missing backgroundCallable V2 extension and QWaylandGLContext::makeCurrent: eglError: 3002, this: 0x7f51f1d55200. Tested with Gnome 40.2 (wayland session).
Tested on Gnome 41.0 (wayland) and latest yuzu flatpak. This issue still shows once native Wayland (--socket=wayland
) is enabled. The following warning is logged when run with --socket=wayland
:
dri_create_context: requested glthread but driver is missing backgroundCallable V2 extension
Hi @liushuyu,
Thank you very much for pushing this flatpak. I've been running some tests with this first release on flathub.com.
Tested on:
Things I've noticed in direct comparison to the AppImage:
Qt: Session management error: None of the authentication protocols specified are supported
Unhandled SIGSEGV at rip 0x0055a5cfe49000
I'll continue testing to find the sources of these issues.