init: nixgl module

[Smona]

Description

This PR integrates nixGL into home manager in a way that does not introduce a nixGL dependency, and attempts to make user configuration as simple as possible. This accomplishes the same goal as #5332, namely making it simpler for users to run applications which require libGL on non-nixos systems managed by home manager. There's some elaboration on why I think this is a better API in the original issue.

It makes use of a wrapper which I have been using for some months to run a few GPU-bound applications on Ubuntu. Judging by post reactions it seems that many other users have also found success with this wrapper. By default it is a a no-op, but if a user has configured a nixGL.prefix, then it will symlink all files from the original package into a new one, except for binaries which are replaced by a wrapper script calling them with the configured prefix. Unlike other wrappers proposed in #3968, all derivation attributes from the original package are preserved, so the result of the wrapper can be passed along to program modules for additional overriding. And since the program binary itself is replaced, the program will be launched in the nixGL context regardless of where it is called from (terminal, desktop file, etc).

The wrapper function is made available on lib.nixGL.wrap, so users can wrap applications which require libGL like so:

    home.packages = [ (config.lib.nixGL.wrap pkgs.example) ];

    programs.kitty.package = (config.lib.nixGL.wrap pkgs.kitty);

I'm very open to changing option/wrapper paths if it would help get this merged. Just having the wrapper and the option would be enough for users to wrap packages with nixGL ergonomically.

Wrapping packages by default

The default no-op behavior and derivation attribute preservation of this wrapper means that HM modules for applications could wrap their default package with nixGL. This would have the benefit of tracking which applications need nixGL to function properly on non-nixos systems, and saving end users time by making nixGL.prefix the only option they need to set to get these applications working. If a user wanted to undo the default wrapping for certain applications, they could simply override programs.<application>.package to a non-wrapped package. This PR originally included examples for kitty and firefox, which both benefit from nixGL on non-nixos systems. However, @exzombie brought up some valid concerns about doing this, particularly detecting and preventing double-wrapping, so in the interest of getting the wrapper itself merged this default wrapping has been removed, to be left for future improvement.

Checklist

• Change is backwards compatible.

• Code formatted with ./format.

• Code tested through nix-shell --pure tests -A run.all or nix develop --ignore-environment .#all using Flakes.

• Test cases updated/added. See example.

  TODO

• Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  See CONTRIBUTING for more information and recent commit messages for examples.

• If this PR adds a new module

  • Added myself as module maintainer. See example.

Maintainer CC

@kira-bruneau @rycee

Alternative to #5332
Closes #3968

[jonahbron]

This is great! Would it work for passing into programs.${program}.package as well?

[Smona]

@jonahbron yes! the wrapped package can be used interchangeably with the original one, so you can pass it to any option that's expecting a package.

[neiios]

Just tried out the PR, and it seems to not work with packages like easyeffects that use a separate debug output. At the same time, the module works well with other programs like mpv.

# this one doesnt work for me
services.easyeffects = {
  enable = true;
  package = (config.lib.nixGL.wrap pkgs.easyeffects);
};

When using the snippet above I get this error trace:

error: builder for '/nix/store/2gkv48bzdgrvkd6vnscjbgc8y175hmnv-nixGL-easyeffects-7.1.6.drv' failed to produce output path for output 'debug' at '/nix/store/2gkv48bzdgrvkd6vnscjbgc8y175hmnv-nixGL-easyeffects-7.1.6.drv.chroot/nix/store/aw3ajpz9s05n44kmzjgc2844y5qw15sb-nixGL-easyeffects-7.1.6-debug'
error: 1 dependencies of derivation '/nix/store/q1y0c3d2lpb5djkxr38m7823abyjkpzz-easyeffects.service.drv' failed to build
error: 1 dependencies of derivation '/nix/store/mn47qf0y738dmap03p38b5pspalckcnw-home-manager-path.drv' failed to build
error: 1 dependencies of derivation '/nix/store/3fld8n8hwynfhq4pbchhbrf6vr6rwlqj-man-paths.drv' failed to build
error: 1 dependencies of derivation '/nix/store/b5mqsb81l7y7vrs2y4nlr21jx9w0q6hk-nixGL-easyeffects-7.1.6-fish-completions.drv' failed to build
error: 1 dependencies of derivation '/nix/store/317843r43f295ad9sylz9mlysyrs8caw-home-manager-generation.drv' failed to build

@Smona can this issue be reproduced on your end?

[Smona]

@neiios thank you for testing it! That's an interesting test case since I can't imagine easyeffects benefiting from nixGL. But I could see this potentially affecting other packages with debug outputs.

I'm able to reproduce your issue with the same configuration, but interestingly that configuration builds just fine for me if I use the same wrapper as config.lib.nixGL.wrap imported from a local file. Going to have to look a bit deeper.

[karmakarmeghdip]

Any updates on this? Will this be merged?

[Smona]

@neiios can you try again with 680108f? Overriding separateDebugInfo to false fixed your test case for me!

[neiios]

@neiios can you try again with 680108f? Overriding separateDebugInfo to false fixed your test case for me!

On the latest commit, easyeffects works for me as well!

[jonahbron]

I tried the wrapper with Prusa Slicer today but it did not make a difference, the 3D viewer didn't work either way (it does when I download and install the binary from the website). Happy to help debug of there's any info I can provide. Here's the output:

$ prusa-slicer
Gtk-Message: 09:12:14.981: Failed to load module "canberra-gtk-module"
Gtk-Message: 09:12:14.983: Failed to load module "canberra-gtk-module"

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.117: gtk_cell_layout_get_cells: assertion 'GTK_IS_CELL_LAYOUT (cell_layout)' failed

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.118: gtk_cell_layout_get_cells: assertion 'GTK_IS_CELL_LAYOUT (cell_layout)' failed

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.120: gtk_cell_layout_get_cells: assertion 'GTK_IS_CELL_LAYOUT (cell_layout)' failed

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.121: gtk_cell_layout_get_cells: assertion 'GTK_IS_CELL_LAYOUT (cell_layout)' failed

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.123: gtk_cell_layout_get_cells: assertion 'GTK_IS_CELL_LAYOUT (cell_layout)' failed

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.123: gtk_cell_layout_get_cells: assertion 'GTK_IS_CELL_LAYOUT (cell_layout)' failed

(prusa-slicer:58991): GLib-WARNING **: 09:12:15.166: getpwuid_r(): failed due to unknown user id (750198)

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.309: gtk_widget_set_size_request: assertion 'width >= -1' failed

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.309: gtk_widget_set_size_request: assertion 'width >= -1' failed

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.318: gtk_cell_layout_get_cells: assertion 'GTK_IS_CELL_LAYOUT (cell_layout)' failed

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.318: gtk_cell_layout_get_cells: assertion 'GTK_IS_CELL_LAYOUT (cell_layout)' failed

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.319: gtk_cell_layout_get_cells: assertion 'GTK_IS_CELL_LAYOUT (cell_layout)' failed

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.319: gtk_cell_layout_get_cells: assertion 'GTK_IS_CELL_LAYOUT (cell_layout)' failed

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.320: gtk_cell_layout_get_cells: assertion 'GTK_IS_CELL_LAYOUT (cell_layout)' failed

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.320: gtk_cell_layout_get_cells: assertion 'GTK_IS_CELL_LAYOUT (cell_layout)' failed

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.320: gtk_cell_layout_get_cells: assertion 'GTK_IS_CELL_LAYOUT (cell_layout)' failed

(prusa-slicer:58991): Gtk-CRITICAL **: 09:12:15.321: gtk_cell_layout_get_cells: assertion 'GTK_IS_CELL_LAYOUT (cell_layout)' failed
09:12:17: Debug: window wxTreeCtrl@0x75bedb0 ("treeCtrl") lost focus even though it didn't have it
09:12:17: Debug: window wxTreeCtrl@0x75bedb0 ("treeCtrl") lost focus even though it didn't have it
09:12:17: Debug: window wxTreeCtrl@0x75bedb0 ("treeCtrl") lost focus even though it didn't have it
09:12:17: Debug: window wxTreeCtrl@0x75bedb0 ("treeCtrl") lost focus even though it didn't have it
09:12:17: Debug: window wxTreeCtrl@0x75bedb0 ("treeCtrl") lost focus even though it didn't have it
09:12:17: Debug: window wxTreeCtrl@0x75bedb0 ("treeCtrl") lost focus even though it didn't have it
09:12:17: Debug: window wxTreeCtrl@0x75bedb0 ("treeCtrl") lost focus even though it didn't have it
09:12:17: Debug: window wxTreeCtrl@0x75bedb0 ("treeCtrl") lost focus even though it didn't have it

[Smona]

@jonahbron I don't see any libGL/GLX related errors in those logs, so my guess would be that those packaging issues are unrelated to this change? Especially given that Gtk-CRITICAL errors are considered known and ignored by the project. I would expect that if nixGL weren't working properly here, you would see glXChooseFBConfig failures instead.

[exzombie]

I finally found some time to look at this. I like the approach, it is elegant. It falls a bit short, though. I'll work on extending if, hopefully later today. But I wanted to write this comment immediately just in case something comes up (as it often does) preventing me from working on this for another week.

The current implementation of wrapping falls short on packages that contain .desktop files which refer to the full path to the executable. For these packages, the binary is wrapped, but the .desktop file refers to the unwrapped binary. I have a solution to that, and plan to refactor it for inclusion into the module.

Using a single wrapper prefix can only provide OpenGL from a single vendor. This is insufficient because you surely also want Vulkan, and you may want some flexibility as to which vendor you use, e.g. for Prime offloading. This stuff gets hairy pretty fast. My own wrappers are more complete, and also quite straightforward to use, but the implementation is quite hairy. I'll try to refactor them and propose them for inclusion in this PR. My goal is to allow the user to fully use an Optimus laptop without having to know the internals of nixGL. And to keep things simple for people who don't have an Optimus laptop.

And last, I'm not convinced wrapping some packages by default the way it's done now is a good idea. If we wrap every package that needs this, it would be great, but it's not feasible. If we wrap just a couple of common packages, I imagine users would be stumped as to why some packages don't work while others do. If, instead, we wrap nothing by default, and clearly document (e.g. in the User Manual) that anything needing graphics acceleration needs to be wrapped and how to do it, it would empower users.

But, in the end, I don't have strong feelings about this. If someone wants to invest effort into wrapping lots of stuff by default, I wouldn't mind too much. Just note that the wrapper would need to be extended so as to detect and avoid double wrapping: I think it's a given that the project of default wrapping would take some time, and in the meantime, users would wrap stuff themselves. This would cause issues later when HM starts wrapping a package that wasn't wrapped before.

Which begs the question: has anyone tried simply wrapping all the packages in their home configuration? Perhaps it doesn't cause any problems, and we could go with that?

[Smona]

@exzombie thank you for the careful review! You brought up some very good points regarding wrapping packages by default, particularly the double-wrapping concern, so I've removed those changes from this PR for now.

I'll review the rest of your proposed changes ASAP, since you've brought up a use case I didn't really consider. It looks like you primarily want to support customizing the opengl vendor on a per-package basis, but I also want to make sure config modules that use this wrapper can be easily re-used across systems with different graphics device setups for people like me who are reusing the same HM modules across multiple systems in a flake. We may want to just leave that up to user-defined settings which get passed into the wrapper along with the package, which I think your change would support. but I want to make sure I understand both use cases and how they interact first.

[giggio]

See how I tested it: #3968 (comment)

[AkechiShiro]

Hello @Smona, thanks a lot for starting this effort.

Any way forward with this PR, could you please apply @XYenon's recommandation ?

If you are too busy to work on it, let me know, I'll see if I can help

[Smona]

I've applied part of @exzombie's suggestion, to rewrite .desktop files with absolute paths to the original derivation to point to the version wrapped with nixGL instead. Some of the other changes (the prime/offloading support) still have issues to work out, so we may want to hold off on those to get a basic version out sooner which supports the majority of use cases.

I've also switched to makeWrapper as suggested by @XYenon, with a small modification to correct the wrapper output path. The resulting script is mostly the same, but this has the benefit of consistency with the rest of HM/nixpkgs, and ensuring that the value of nixGL.prefix is a valid executable at build time.

Is there anything else needed to get this ready to merge?

[exzombie]

I've applied part of @exzombie's suggestion, to rewrite .desktop files with absolute paths to the original derivation to point to the version wrapped with nixGL instead. Some of the other changes (the prime/offloading support) still have issues to work out, so we may want to hold off on those to get a basic version out sooner which supports the majority of use cases.

I'm not familiar with how this kind of thing is handled in HM; is it acceptable to merge an "early preview", when it is known that the user-facing options will have to change in an incompatible manner in the future?

BTW, which issues have you found? I'm aware of the emacs problem you've had but that I couldn't reproduce to investigate. Was there something else?

[vigress8]

Have been using this, works great

[timoleistner]

Works great, except that when I have hyprlands wayland.windowManager.hyprland.enable flag set to true while trying to (config.lib.nixGL.wrap pkgs.hyprland) in my home.packages, I have a package collision. If I dont use this flag I dont have the hyprland.nix config. Mentioned here for kitty.

[Smona]

@timoleistner you should just need to pass the wrapped hyprland to wayland.windowManager.hyprland.package, instead of including it in home.packages. that should be done in general for any programs which are configured via dedicated home-manager modules.

[timoleistner]

I see. This works. Amazing, thank you for this, I hope it gets merged soon.

[AkechiShiro]

What is currently blocking this PR at the moment, I don't think there are any pending changes requested ?

Are we waiting on feedback from more people to try the PR before it gets merged ?

@vigress8 @jonahbron @giggio @XYenon

[giggio]

What is currently blocking this PR at the moment, I don't think there are any pending changes requested ?

Are we waiting on feedback from more people to try the PR before it gets merged ?

@vigress8 @jonahbron @giggio @XYenon

I don't know what is keeping it from being merged. I've been using it since then and it works fine.

[Smona]

As far as I know, this change is ready to go and all feedback has been addressed. This is my first time contributing to HM so I'm not sure whose approval is needed to merge this, but I think it's in a good state.

The only issue I could see causing some hesitance to merge is that @exzombie has put together a PR which extends this one by adding support for dual-GPU systems (and much more thorough documentation). The options interface in their PR is incompatible with this one, so releasing this one would require a deprecation warning if theirs is adopted later. I do think their interface is more complete, and likely makes the right compromises considering all use cases. That being said, their PR hasn't been tested as thoroughly as this one, and I don't have the hardware to test it myself. So I think it would be worth merging this PR now, to cover the majority of use cases, and then letting @exzombie or someone else make a followup PR later, where the community can weigh in on how best to support varying hardware configurations.

I just pushed the only other change I had planned for this PR, which improves documentation to help avoid confusion about what to do with the wrapped package and better explain what the wrapper function does:

[AkechiShiro]

@rycee any input or feedback on this PR if you have some time for a review maybe ?

[exzombie]

Well, if anyone cares to test my PR, it's right there. I don't mind if this one is merged first, I just think that we could save ourselves an interface change.

[Ashe]

I really hope we can move this along, sorry for replying without much substance but I don't see a reason why this can't be merged and I think it'd be great. If there's information in another thread where discussion is taking place it might be great to just give an update on this one once in a while :)

[jackmac92]

If this change is ready to go I think it would be great to merge now for broader testing/feedback (without integrating it in other modules by default yet)

[Smona]

@jackmac92 that's great to hear! This PR is ready to go on my end, so please merge it at your discretion or let me know what needs to be done to get it ready on y'all's end.

[jackmac92]

I don't have perms to actually merge 😅

I've just been following this and related PRs/issues for a bit, think I'd ultimately like to use the more expansive setup from @exzombie 's PR, but seems like there is more uncertainty about how to move forward there and releasing something seems great for opt-in testing

Understand there would be an interface change, but I, and I think most others that are "early adopters" can deal with that

[exzombie]

I've just been following this and related PRs/issues for a bit, think I'd ultimately like to use the more expansive setup from @exzombie 's PR, but seems like there is more uncertainty about how to move forward there and releasing something seems great for opt-in testing

To be clear, there isn't really any uncertainty anymore, at least not from my side. Enabling Vulkan by default turned out not to be possible, and that's that. But if anyone has opinions or uncertainties about the interface, I'm all ears :)

[jackmac92]

@exzombie the uncertainty I'm talking about is just that your PR into @Smona 's branch has conflicts

If yours is fully good to go, and the idea is to bypass this config, I think you should just open a new PR against
this repo not Smona's fork, right?
(trying to usher something along)

[Smona]

My motivations for merging this as-is were 1) not wanting to delay merging of the basic functionality, and 2) a desire to be able to thoroughly test the contents of my PRs. At this point, it seems like keeping this PR simpler is not speeding up a merge, and may actually be blocking it. In the interest of uniting our efforts, I will gladly merge @exzombie's PR here once:

• merge conflicts are resolved
• The comment I just left is addressed.
• I've been able to confirm that the functionality I need works (the parts covered by this change in its current state). I can commit to testing that within a week of the above two.

Even if there are problems with the multi-GPU side of that PR that I can't catch (I don't think there will be), multi-GPU support is the right goal to work towards, and any issues that might arise should be easily fixable post-merge, without changing the interface.

EDIT: I just want to say I appreciate @exzombie for working against this PR, so that the discussion isn't fractured and my commits can remain in the history :)

[exzombie]

EDIT: I just want to say I appreciate @exzombie for working against this PR, so that the discussion isn't fractured and my commits can remain in the history :)

Oh, you're welcome. Truth be told, I would have kept your commits even if I were to open a new PR; it's important to give credit where credit's due. I wish there was a straightforward way to credit all those who have posted partial solutions to the various issues, there was a lot to learn from about this problem.

Anyway, I'll take a look at your comment in the coming days, then rebase. I never had a non-flake HM setup, so I'll need to think about this.

[Smona]

Okay, I've merged @exzombie's work into this PR! I think we're all aligned on the options interface now, and this change now includes support for dual-graphics systems.

Anyone who's following this PR and wants to help get it merged, please test the integration again with the latest commits and leave your feedback here. Most of you will only need to set nixGL.packages (and possibly nixGL.defaultWrapper if you use nvidia and/or prime). It would be especially helpful for those with dual-graphics systems to test the offload wrappers and prime support.

Thanks again @exzombie for making this integration work for more people!

[bevicted]

EDIT:

My original question was basically: where do I set nixGL.prefix, because it doesn't seem to work for me but I see it everywhere else.

Solution:
Nowhere, after reading the added doc in the PR I assume the behavior was changed, what I needed to do with home manager is:

(only including relevant parts)

# flake.nix
# include nixgl as an input and output
{
  inputs = {
    nixgl = {
      url = "github:nix-community/nixGL";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };
  outputs = {nixpkgs, nixgl, etc...};
    let
      # I passed it down as an overlay as well, hence pkgs.nixgl in home.nix
      # I have no idea why the passed down `nixgl` doesn't have the wrapper packages
      pkgs = import nixpkgs {
        inherit system;
        overlays = [
          nixgl.overlay
        ];
      };
    in {

}

# home.nix
{ config, pkgs, nixgl, ... }:

{
  imports = [
    # TODO: remove when https://github.com/nix-community/home-manager/pull/5355 gets merged:
    (builtins.fetchurl {
      url = "https://raw.githubusercontent.com/Smona/home-manager/nixgl-compat/modules/misc/nixgl.nix";
      sha256 = "1krclaga358k3swz2n5wbni1b2r7mcxdzr6d7im6b66w3sbpvnb3";
    })
  ];

  nixGL = {
    packages = nixgl.packages; # you must set this or everything will be a noop
    defaultWrapper = "mesa"; # choose from options
  };

  home.packages = [
    pkgs.nixgl.nixGLIntel # change this to what you need, find options in nixgl repo, use `home-manager switch --impure` when using nvidia or build will fail
    (config.lib.nixGL.wrap pkgs.alacritty)
  ];
}

I've spent a day on getting Alacritty installed by home-manager running, I am a broken man, I just hope this comment helps someone.

@Smona you're doing the lord's work

[jackmac92]

awesome work @Smona @exzombie ! I also got alacritty working for the first time following @bevicted's steps

misc questions:

• Any common errors to look out for when using vulkan?
• web browser/firefox setup? I wrapped firefox but still got Blocklisted; failure code FEATURE_FAILURE_GLXTEST_FAILED
• darwin support? I tried running on darwin but got a valgrind related build error

[exzombie]

@jackmac92

• Any common errors to look out for when using vulkan?

If your distro is "recent", in the sense that its executables use libraries sufficiently similar to those in the version of nixpkgs you are using, you would probably be fine. On my Ubuntu 22.04 system, I never noticed any issues until I updated to nixpkgs 24.05.

The issues arise when the wrapped program runs an executable provided by the distro, which I expect alacritty to do quite a lot. In that case, the library overrides needed for Vulkan can introduce symbol conflicts when libraries provided by nixpkgs are newer and have a different ABI than those in the distro. Something like the error shown below. For alacritty, a possible workaround would might be to unset LD_LIBRARY_PATH in your shell. But there are other programs spawning executables, and in that case, the problem is harder to solve.

/nix/store/ynz405a4ngxijdmdz1qjmfb0ffgigx98-emacs-pgtk-29.1/bin/emacs: /nix/store/xpxln7rqi3pq4m0xpnawhxb2gs0mn1s0-gcc-12.3.0-lib/lib/libstdc++.so.6: version `GLIBCXX_3.4.31' not found (required by /nix/store/7byfnpsk04l3q8rvvwc06acwjbkiy0j2-webkitgtk-2.42.4+abi=4.0/lib/libjavascriptcoregtk-4.0.so.18)