cai

Why don’t you tell us what you really think?

Are you sure? It seems like WDDM has a user-mode “User-mode display driver” - which looks to me like the HW-specific part of Mesa: it’s invoked by the D3D runtime - and a “Display miniport driver”, which is in the kernel.

See https://learn.microsoft.com/en-us/windows-hardware/drivers/display/windows-vista-and-later-display-driver-model-operation-flow

That said, no doubt Linux’s ability to reset drivers is way, way behind… We’re coming up on 20 years since Windows could recover from a graphics driver reset reliably without losing the desktop, and only partial hacks exist on Linux today.

I really need to get around to building a sample HTML page to show how unsafe having WebGL enabled on Linux browsers is. One long shader, and your desktop is a goner.

If you use any accelerated graphics (GTK4 anyone?), you cannot and must not bundle all your dependencies.

Conceptually, graphics drivers have two parts: The part in the kernel (e.g. amdgpu), and the part loaded as a library from the system into the application (e.g. Mesa).

Mesa - or any other GL/Vulkan implementation - is loaded from the system into the application as a library. Mesa relies on system libc, system LLVM (!!!), a particular libc++, etc.

If you ship libGL (and LLVM etc), you must re-release your software with upgraded deps whenever new graphics cards are released (and should whenever bugs are fixed). Your software is literally incompatible with (some) newer computers.

For the proprietary Nvidia libGL - which, again relies on system glibc - you can’t legally include it.

Flatpak solves this by separating out ‘graphics driver libraries’ as a unique type of runtime, and having a shitload of special rules & custom hacks to check the system libGL, open source or proprietary, maybe substitute a Flatpak provided libGL, with all the deps that libGL needs, and make it compatible with whatever app & whatever app runtime.

Actually correctly solving the libGL debacle is half the value of Flatpak to me.