26
home-manager now has a built in option to wrap packages with NixGL, for non-nixos systems (home-manager.dev)
submitted 1 year ago by to c/nix@programming.dev
12 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 1 year ago (6 children)

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.

  • permalink
  • fedilink
  • source
  • hideshow 6 child comments
    •
  • [–] [S] 1 point 1 year ago* (last edited 1 year ago) (5 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 2 points 1 year ago (4 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] [S] 2 points 2 months ago* (last edited 2 months ago) (3 children)

    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.enable to true. Seems the docs have been updated: https://home-manager.dev/manual/unstable/usage/gpu-non-nixos.html#sec-usage-gpu-non-nixos

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 2 months ago (2 children)

    Oh 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 1 point 2 months ago (1 child)

    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-gpu

    Oops, 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 base package, 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 tmpfile or the like, then it does autostart.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 2 months ago

    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.

  • permalink
  • fedilink
  • source
  • parent