Description of changes

Split off from #332413.

Quoting my own comment from said PR:

So, the libgbm thing has been discussed a bunch on Matrix for a very long time, but I never sat down and wrote up a proper rationale for doing this. Here goes.

First, the original problem statement: libgbm is basically a fancy memory allocator API for your GPU. To allocate memory, it needs to talk to your graphics driver (duh).

In the case of Mesa, that driver is Mesa itself, which libgbm is also part of, so Mesa assumes (generally correctly) that the libgbm and Mesa on a system will always be from the same build. This is true for conventional distros, but we're, well, not very conventional. We can totally have applications built against an old libgbm running on top of new Mesa, and our users generally don't expect it to explode.

Unfortunately, it does, because the libgbm Mesa ("dri") backend talks to the driver using Mesa internal APIs, and if those no longer line up, kaboom. In fact, upstream noticed the potential kaboom, and made it so the application just aborts immediately instead of slowly melting.

This means that the state of the art for "I want to run an application built against another libgbm on my new drivers" is "don't", which is not great.

Now, Mesa 24.2 brings with it another problem: libgbm now links libgallium_dri, which is like 40 megabytes of stuff that needs to end up in mesa.out, because that's where libgbm lives. That's not really fatal, but still annoying.

So here's the proposed solution: libgbm actually has support for loadable backends, that's used by vendor drivers to provide their own implementations, just like libglvnd, ocl-icd, vulkan-loader etc already do. What if we use the same functionality for Mesa itself? Then libgbm basically becomes a driver loader, instead of a driver, and we put the matching gbm_dri.so into /run/opengl-drivers along with its Mesa, and never have the problem again.

The reason I think this could actually be wanted upstream as well is that anyone running their own local build of Mesa runs into the same issues unless they LD_PRELOAD the right libgbm, which is awkward and comes with the usual LD_WHATEVER caveats. It also makes the loader logic surprisingly simple (and it can be simplified even more, at the cost of making the patch more invasive) - we basically just try a bunch of named backends in order using the exact same code paths for Mesa and non-Mesa. Moving the libgallium_dri linked bits to a separate library also saves 40MB for any distro that wants to ship the drivers separately like we do.

The downside of this is that gbm_dri becomes public API, so it has to follow the usual GBM backend ABI stability constraints, but this doesn't seem to be a problem in practice, as the API has not changed in years.

Also, this does potentially unlock decoupling libgbm from Mesa entirely, which is something no one but NixOS probably cares about, but whatever.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.