[Pkg-utopia-maintainers] Bug#1107749: flatpak: Vulkan not working on dual-GPU system after upgrade to trixie

[Simon McVittie]

Control: retitle -1 flatpak: Vulkan not working on dual-GPU system after upgrade to trixie
Control: tags -1 + moreinfo help

On Fri, 13 Jun 2025 at 18:42:57 +0100, David Hoces Pérez wrote:
>My computer has two graphic cards available:
>
>$ DRI_PRIME=0 glxinfo | grep "OpenGL renderer"
>OpenGL renderer string: Mesa Intel(R) HD Graphics 4000 (IVB GT2)
>
>$ DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
>OpenGL renderer string: AMD TURKS (DRM 2.50.0 / 6.12.30-amd64, LLVM 19.1.7)
>
>However the environment variable seems to be ignored by Flatpak when I try to
>switch to the other graphic card:
>
>$ flatpak run --env=DRI_PRIME=1 de.haeckerfelix.Shortwave
>MESA-INTEL: warning: Ivy Bridge Vulkan support is incomplete

Dual-GPU has traditionally been a disaster area. I don't have a dual-GPU 
system myself and am not familiar with the necessary workarounds.

Note that DRI_PRIME affects OpenGL, not Vulkan, but the error and 
warning messages that you quoted would indicate use of Vulkan. There are 
other mechanisms for selecting a preferred GPU for Vulkan, but I'm not 
familiar with what the preferred/least-hackish of those mechanisms is.

Listing available GPUs with `switcherooctl list`, then comparing the 
output of `switcherooctl launch --gpu=GPU env` for each one, might be 
helpful?

>The same applications work well in the desktop environment (GNOME and
>Wayland) when they have been installed from a Debian package.

Note that upstream GTK (as found in the GNOME runtime and used by 
Flatpak apps) defaults to rendering using Vulkan, but Debian's GTK has 
been patched to keep its old default of rendering using OpenGL.

A more apples-to-apples comparison would be to use environment variable 
GSK_RENDERER=vulkan or GSK_RENDERER=gl to force a specific renderer:

     GSK_RENDERER=gl gnome-recipes
     flatpak run --env=GSK_RENDERER=gl org.gnome.Recipes

     GSK_RENDERER=vulkan gnome-recipes
     flatpak run --env=GSK_RENDERER=vulkan org.gnome.Recipes

If you can reproduce this with a GTK app that is small, simple and 
doesn't have extraneous permissions, that would help to concentrate 
debugging effort onto one specific scenario. GNOME Recipes is usually 
the one I use for debugging if the specific app doesn't matter.

flatpak(1) and Debian don't have control over the content, choice or 
precise behaviour of the graphics drivers inside the Flatpak container: 
those are chosen by the runtime maintainer. In the case of the GNOME 
runtime, they're inherited from the freedesktop SDK, 
<https://gitlab.com/freedesktop-sdk/freedesktop-sdk/> 
(more precisely, the 'org.freedesktop.Platform.GL.default' extension).

The exact behaviour of Vulkan rendering is likely to be an interaction 
between:

* the kernel drivers, which were previously from bookworm but are now
   from trixie (but you could potentially try installing a bookworm
   kernel and rebooting back into it in order to check whether this is
   relevant)

* the Wayland compositor, in your case GNOME Shell, which was previously
   from bookworm but is now from trixie, and the libraries it depends on

* the app itself and the libraries and user-space graphics drivers it
   depends on, which in the case of GNOME apps under Flatpak come from
   org.gnome.Platform and org.freedesktop.Platform.GL.default

Running Flatpak as, for example, `flatpak run -vv org.gnome.Recipes` 
would give more information about precisely what app, runtimes and 
drivers are in use, and how Flatpak is sharing device nodes with the 
container.

     smcv