[New Module Request] GPUs on non-NixOS systems: beyond NixGL

[exzombie]

Program/Service Name

non-nixos-gpu

Upstream Repository

https://github.com/exzombie/non-nixos-gpu

Configuration Documentation

Instructions for importing into HM

HM module options

Reason for Addition

Many of us have spent considerable effort making NixGL easy to use with HM. I'm tagging @Smona here because I think they will be interested, but there were many people involved. I myself went to some length to make package wrapping work as smoothly as possible, so I hope you will appreciate how much I dislike NixGL. Don't get me wrong: it's a great tool for running an odd app in an ad-hoc manner, which is what it was conceived for, AFAICT. But as a profile-wide solution wrapping all packages that need it (or even the whole session), it is not the best approach.

The problem is that the wrappers cause symbol conflicts when a wrapped program runs another program that comes from the host OS, not from Nixpkgs. An example is described here. The more libraries from Nixpkgs deviate from the host system, the more probable symbol conflicts. It makes Vulkan (which brings in more dependencies than OpenGL) pretty much unusable when you are using HM on an LTS distro, but OpenGL is not immune.

Recently, I discovered how NixOS handles GL and Vulkan, and it was a facepalm moment. All we need to do is put libraries into /run/opengl-driver. That's all. I was stunned. So many bright people spending so much time piling workarounds on top of workarounds when the proper solution is so much simpler.

So, I made the flake linked above. It's possible to run it directly, and it will set up the system properly, as long as you provide the correct version of Nixpkgs. It's all described in the README. But I also made a HM module. It can be used as a separate flake input, that's how I'm using it now. But I would like to contribute this module to HM so that it's visible to more people. I see two options:

1. Keep the HM module where it currently is, and it would be used as it is used right now, by adding a flake input and importing the module from there. If this path is chosen, I will open a PR with a documentation update containing instructions on how to do it. Kind of like what's been done for NixGL.
2. Add the HM module to HM itself. If this path is chosen, there will be no external dependencies for users to deal with.

Personally, I'm in favor of option 2. While importing NixGL into HM was not appropriate because it is complex and is developed at its own cadence, my module is much simpler. I do not foresee much maintenance beyond the inevitable teething pains.¹

Note that I would not deprecate the NixGL module. It is still useful for people who do not have root/sudo access to their machines.

Thoughts?

Footnotes

1. I can just see Nvidia being a pain point. It always is … ↩

[Smona]

Awesome! This indeed sounds like a much cleaner solution. I'm no longer using any non-nixos linux systems, so i don't know how much i'll be able to help push this forward, but I hope this can get merged into HM as a 0-dependency and global fix with much better UX than manual program wrapping!