Nixgl: https://github.com/nix-community/nixGL
Also, it seems like this requires the latest “stateversion”, since this is a new feature.
This is pretty big, because it makes it easy to use applications that use the GPU from nixpkgs on non Nixos systems.
Yeah this happened a while ago, it’s been in stable since 25.05 i think. Nixgl isn’t really a good solution for me though, but luckily i recently found another option of populating the /run directory with the nix drivers, the same way nixos does it. This seems to solve all the issues i had and makes nix on non-nixos much more powerfull to me. Since i can install game launchers and entire compositors with it, and programs that require the native system drivers will still be able to work inside of that nix-installed compositor. I’m thinking of switching back to void now and i’m working on a non-nix home manager setup.
Can you share your setup? I’d really like that because I don’t think nixgl works with GPPU apps like CUDA or lc0 (chess engine that uses gpu).
EDIT:
Is this it: https://github.com/juipeltje/configs/blob/54e971f6a6da47d6cfd02a6409be97d5e1051b0f/scripts/cron/nix-drivers.sh ?
Although this seems like it would just symlink opengl? What if I wanted GGPU like OpenCL or CUDA?
Edit2: wait, I think I might be misunderstanding how it works. I think nixgl already supports opencl, because it’s mesa that implements opencl and opengl. But how would I get mesa support? I don’t think the symlink to /run trick works.
Sorry for keeping you hanging, i actually got the idea from here you can ignore the nixgl stuff because that wouldn’t be needed anymore, but the important part is building a derivation with those drivers in it, and then symlink those folders to /run. It should work with rocm/cuda as well but i haven’t troed that yet. I’ve done some basic testing in a vm while i’m working on the config and so far for opengl stuff it has been working fine.
Coming back to these docs a year later, it looks like something like it’s possible to enable it for everything by default by setting
targets.genericLinux.enabletotrue. Seems the docs have been updated: https://home-manager.dev/manual/unstable/usage/gpu-non-nixos.html#sec-usage-gpu-non-nixosOh that’s cool that they actually acknowledge the issue now and have adressed it like this. It looks it does still assume systemd though? Since it’s using tmpfiles.d. Since i’m on a non-systemd distro i’ll probably keep using my own script that runs at boot through my service manager. I’ve updated my config a little since then cause i used to symlink from my home folder, which caused issues on my server where multiple users needed the drivers. I now symlink it directly from the store. Also looking back at my old comment, i did end up trying to use rocm and it worked just fine.
Ah. You’re on Void. Indeed, it does look like Void doesn’t have an implementation of systemd-tmpfiles. Here is the file from my system, it’s only creating a single symlink, which is basically the same thing you are doing:
[moonpie@nefertem home-manager]$ cat /etc/tmpfiles.d/non-nixos-gpu.conf L+ /run/opengl-driver - - - - /nix/store/2r6vmqh1vkivsrmr6n1vh1862i2qndqz-non-nixos-gpuOops, the below is for artix. I was nosy but not nosy enough and I saw a comment where you mentioning you used void after you wrote all of this. I’m gonna leave it here since it was an enjoyable rabbit hole.
I did some digging, and it looks like it is possible to use systemd-tmpfiles outside of systemd. It’s just a binary that creates files/directories/symlinks based on a format, so it’s pretty easy to extract, or reimplement entirely.
Artix has their own, an extraction from the systemd package: https://packages.artixlinux.org/packages/system/x86_64/etmpfiles/
It looks like that package is required by the
basepackage, which is the core package set declaring the minimal dependencies needed to have a working system, so it’s highly likely you have it installed.I think it automatically starts too, but I can’t find a hard source for this. Based on this page: https://wiki.artixlinux.org/Main/Migration#Download_the_Artix_packages it looks like etmpfiles is needed before you select/install the init system, which suggests that. This reddit post, where a user has an issue where etmpfiles isn’t installed, so their service manager complains and dies.
If you have a service named something related, like
tmpfileor the like, then it does autostart.Yeah, i was using Void but atm i’m using Guix. From what i can tell Guix doesn’t have an implementation for it either, but my current setup works so that’s good lol. I just have a shepherd service that executes the script in my users’ .nix-profile as root. The tmpfiles.d method is basically what this project is doing as well. I ended up not using it because of that, but i also don’t like that it adds more projects that you have to depend on to get it working compared to the manual setup that we’re doing.
I thought this was going to automatically wrap all my packages in NixGL. But this is about the way more convenient NixGL set-up that happened to home-manager last year, yes?
Yeah, but I only discovered it now.
Looking on github though, it looks like people combine builtins.map with this to wrap a bunch of packages at once though.
I’m also mapping the wrapper over a list and combining it with unmodified packages.
I suppose that is the Nix-y way, but I can’t help but feel like it’s a bit…manual? I always wondered if I should just wrap all of my home-manager packages that way!
Huh. The page was updated, reviewing it a year later. It does look like there is an option to automatically give GPU to all Nix/home-manager programs now. If you set
targets.genericLinux.enabletotrue, then it should work.Thanks for the heads up!
The new hostwide flag is very convenient. It probably won’t work for me because I’m sticking to stock SteamOS for now, and it’s very immutable. But I’m giving it a try asap!
