Change:
Directory renaming is now out of scope This directory is also being used as the way to get access to the host machines gpu drivers. I think it's another source of confusion for many users to have to add so that they can get a vulkan game / cuda workload / opencl workload to work. I think we should deprecate this prior to the 21.11 release, and fully move it to something like or something more representative of the desired affect. This was done in cc EDIT: roadmap (2.5 years later... lol): addOpenGLRunpath -addDriverRunpath Init addDriverRunpath: Deprecate : -autoAddDriverRunpath Init autoAddDriverRunpath: Deprecate cudaPackages.autoAdd{OpenGLRunpathHook,DriverRunpath}: NixOS Module changes: TODO
For the transition period ( NixOS 21.11), I think keeping the old would help alleviate a lot of the pain, would just like to get the ball rolling away from using explicitly
I agree. Also, on a related note, having to specify your graphics driver at the xserver level in the module system feels wrong to me. I'm still not exactly sure how it maps given names to driver packages either.
I propose two changes: move -- make a symlink to for backwards compatibility of existing derivations -- add a
potential future work as well: -- Until 21.11 EOL, have it add both and , to avoid system vs package invariance
I'm also kind of wondering whether is just another fallacy in naming, and we should really be exposing something like, would be even more appropriate, as other hardware-accelerated devices such as tpus, fpga's, and others would also likely need to import "libraries which are determined by the system, and need to be available at runtime".
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Should we, in addition, consider using a libc-versioned directory? Motivated by
Decided to rename this issue since renaming the underlying path was deemed too risky for potential breakages.
Could you provide some context as to why? My naive assumption was that we'd have a new path but: have both new and legacy path to rpath via the hook; new path preferred provide a legacy symlink pointing at the new path in NixOS which would be quite trivial.
TBH, I'm not sure how much value there is to migrating the filesystem path (unless we splay the paths further to increase granularity). I suspect what users see in practice is the nixos option path
For the NixOS module change, I came up with these terms: acceleration API = an API standard which intends to provide hardware-assisted compute acceleration such as OpenGL, Vulkan or CUDA driver = userspace library component which implements one or more hardware-based acceleration APIs The usage of the NixOS options API would then look a little like this: Individual drivers would also have a option which is a package selector for the specific package to use aswell as driver-specific settings. (More on the package selector data type when I have a more concrete implementation but it'd allow setting 64/32 bit using a single value.) Each acceleration API would have a option which is an attrset with driver names as keys and package selectors as values. These could then be overridden indivually. The intention behind this is to enable use-cases where e.g. different versions of the same driver are required for different APIs or a specific driver must be disabled for one API but enabled in all others. All enabling a driver would do would be to insert the driver's package into the options of all APIs that it implements. Additionally, accel APIs have a option if the API supports setting one and of course API-specific knobs. Here's an example of how a non-trivial driver config could look like: It's currently not possible to know which implements which driver and all drivers are thrown into the same directory but the NixOS API drafted above requires this information for fine-grained control, so we will have to define an interface here. I've been thinking of defining the output to contain all driver bits and subdivide it into driver subdirs like this vulkan/... cuda/... opengl/... Alternatively, I had thought of using multiple outputs; one for each driver. I kinda like that approach more as it generally strikes me as cleaner and has the potential to reduce closure size ( is ~200M) but am not sure about potential naming conflicts or other downsides of those. In light of this, I'd also like to propose to split the global lib dirs into accel API subdirs for clean separation. Though as said, the NixOS options are a lot more critical to UX and therefore the first steps. Global path name and other changes are almost entirely tangential and could happen independantly but I'd appreciate if they came after the NixOS options changes such that we can let the knowledge we gained from the NixOS options influence their design. Anyhow, that's my current draft. Let me know what you think.
My naive assumption was that we'd have a new path but: That was my initial take as well, but there's community projects like nixGL and others who likely have hard coded the path. And there's a potential that we could never fully remove it without breaking someone
Forgive my ignorance, but wouldn't it be ok to make those kinda breaking changes by deprecating in one release and then removing one or two releases later? Surely nixos isn't promising to never change paths because someone might be using the old location? EDIT:I don't mean to imply we shouldn't consider non-breaking options where possible
nixGL only sets the LDLIBRARYPATH? Although in all probability we must break someone's workflow... Fun fact: cudaPackages don't ship the driver (except for for jetsons). All the relevant stuff comes with nvidia_x11 or with the datacenter driver. Interesting. Would we somehow have to filter the glvnd/opencl loader/vulkan loader configs that come with the drivers to enforce that the declarative configuration be implemented?
nixGL appears to be actively maintained. I don't think we need to worry about breaking it as they can simply adapt. Also, we could simply keep providing the old path in both NixOS and binaries with a preference for the new path and that should work out fine. Oh, okay. I'll leave it to you CUDA people to figure that out. I will only be lifting drivers to this interface on a best-effort basis and the rest will keep using their legacy interface with a minor implementation change. Though if you forsee possible issues you could have mapping your driver to this interface, let me know so that we can design the interface better from the start. That or simply write our own. Though I'll only be adding the option where it is feasible; currently, I only know that Vulkan has sane mechanisms for this. Some issues I still need to think about:How to handle drivers that only support 64 bit? Will have to filter that somehow How to handle APIs that can only have a single exclusive driver? Only have a option on the API, rather than ? Have but only install the default driver?
I think NixGL doesn't care about , it probably just exports an ?
The original protest against renaming the path: I feel more strongly about the NixOS options being intuitive than the implementation consistent.
I think was more concerned with it being placed under rather than some other directory in because is very much NixOS-specific while the current is not.
I believe I got all of the packages. Once merged, I should be able to deprecate
This thread is over my head, but I would like to check it , , and need the same? All three have GPU or CUDA support options.
This is more about deprecating usage of the term , as it's a bit of a misnomer. I don't see usage of the legacy OpenGL helpers in those packages.
Talked to , we concluded that we can close this ticket and have a more "NixOS options" specific ticket to represent that work.
Going to do one last pass on documentation to ensure all references have been updated. I'll close this ticket after that sweep
I wonder if needs an update. I'm not offering a PR because I'm out of context. Arrived here from a warning in nixos-rebuild. And I'm still wondering how this is being triggered [still investigating].
Arrived here from a warning in nixos-rebuild. And I'm still wondering how this is being triggered [still investigating]. It should come from the toplevel scope now, so it should never need to default to pulling them out of cudaPackages. I can update the nix expression though.

Discussion:
| Find libraries | `configurePhase` | Missing dependency on a `dev` output | Add the missing dependency | The `dev` output typically contain CMake configuration files | | Find libraries | `buildPhase` or `patchelf` | Missing dependency on a `lib` or `static` output | Add the missing dependency | The `lib` or `static` output typically contain the libraries | <del> In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`cudaPackages.autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=cudaPackages.autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary. </del> <ins> In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary. </ins>