[Feature request]: Use VirGL or something similar to utilize host mesa drivers

[RossComputerGuy]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Suggestion

With this feature, the mesa build in Flatpak runtimes can be trimmed down. This would also allow using the right driver on systems which requires a specific mesa for or build (example: Asahi Linux) without updating or changing the runtimes. Using VirGL or something similar, Flatpak would pass GPU commands and other things throu the sandbox and to the host system. This may be difficult to implement but worth the benefits.

[alyssarosenzweig]

virgl can be slow

[chergert]

I'm just going to leave a technical comment about implementation, not whether or not this is something we'd want in Flatpak.

I talked @airlied about this a few months back primarily from the standpoint of how many GL bugs I tend to get upstream in GTK-based GNOME applications (GTK, Builder, Ptyxis, Text Editor, VTE, etc) with Flatpak. They almost always tend to be in the form of version skew or simply the GL extensions not having all the patches the distro has (Asahi for example).

What I was told (assuming I understood it correctly) is that we would need a user-space component to do some of the shuffling back-and-forth that Qemu is doing now. There are some tests in the Mesa repository which do this, which might serve as an example in the form of a virpipe mode over a unix socket.

If using DMA-BUF we may have additional work to do here but that could potentially work well with the DMA-BUF work happening in Mutter/GTK/etc.

[RossComputerGuy]

@chergert That certainly is interesting. This idea of mine came from when I was at SCALE/NixCon NA. Being able to pass the mesa driver through the host and to each Flatpak process would likely fix a lot of issues with unique systems. I certainly have had unique problems with things like Discord and OBS. Discord doesn't have the fonts rendering right because it uses software rendering. OBS crashes because of some sort of segfault or issue with the mesa inside of the Flatpak runtime.

There are some tests in the Mesa repository which do this, which might serve as an example in the form of a virpipe mode over a unix socket.

This sounds like a good solution to be able to load the driver on the host side. Would we just have a sandboxed driver which we force load in or do we only compile mesa with that driver? If it could be possible to override the socket to the driver so you could use a Flatpak shipped Mesa then that would be awesome for a use case I have.

[chergert]

No matter what you choose there is non-trvial code to write. And even if you implement it is no guarantee it will work everywhere or with every host/guest driver configuration. I also can't speak to anything regarding the security of such a system or if there are any benefits from that standpoint (which tends to be the reason most people want it "sandboxed").

It's just the path of least resistance IMO.

[swick]

There are at two more approaches to making it possible to use the host mesa drivers in flatpak

1. r-o map host /usr into flatpak and use libcapsule to load mesa libs into their own linker namespace (steam solution)
2. create mesa drivers with only glibc as a dependency by statically linking everything and use them on the host and in flatpak; add a glibc flatpak extension to make sure old runtimes keep working with the new driver

The first solution is kind of fragile, the second one seems more robust but requires distributions to ship a statically compiled mesa driver which can be huge (on the other hand, reusing it for flatpak means no additional storage cost).