Open SomeoneSerge opened 4 days ago
hardware.userSpaceDrivers (too long, but relatively unambiguous)
hardware.userSpaceDrivers (too long, but relatively unambiguous)
My argument for impure-drivers
is that there are "userspace drivers" which we link purely and they just work. Ideally, we shouldn't be needing an option like hardware.opengl.enable
, and we shouldn't be needing /run/opengl-driver
. But we do, so we grant ourselves this one ugly hack, and we provide a convenience option for NixOS users to support this semi-impure Nixpkgs software automatically, while non-NixOS users have to deal with wrappers and containers.
I also like accelerators
/acceleration
, because then there's nothing to argue about wrt the package set options
We can fix that on non-NixOS too, if we just load the drivers from normal locations like /usr. I don't like impure
because that implies there's a pure option, which there isn't. Also, I was going to propose a change following @Atemu's plan (e.g. hardware.opengl.drivers.mesa.enable = true;
, etc), for the next staging cycle (because it's annoyingly invasive to all the loaders).
We can fix that on non-NixOS too, if we just load the drivers from normal locations like /usr
H'm, this has far-going consequences. To clarify, you're suggesting that we selectively let loaders like libglvnd
scan /usr
, or that we extend addDriverRunpath
to patchelf all of Nixpkgs this way?
We let loaders can /usr, yes.
because it's annoyingly invasive to all the loaders
The NixOS options API change can happen independently from the loader implementation. We don't need to have all the functionality which the new API could provide us with from the get-go. Mapping the existing functionality onto it would be a perfectly reasonable first step IMHO.
We can fix that on non-NixOS too, if we just load the drivers from normal locations like /usr.
I actually tried this a while back and this is not trivially possible as you still get glibc mismatches.
Now onto the hardest problem in all computer science: Naming.
Before we discuss different names, I think it's good to first define how to measure their merit.
I think a good benchmark for naming NixOS options is whether a non-technical user would be able to discover the relevant option via text search or, reversely, how tech-savy they would need to be in order to know the correct terms to be able to find the desired option.
I believe that the term "drivers" to be perfectly understandable by non-technical people and even the mainstream to a degree. Hardware drivers is not a new concept or term that we'd need to teach to the current "target audience" of NixOS.
If a NixOS user searches for "nvidia drivers" or "nvidia", they should trivially be able to discover e.g. hardware.acceleration.drivers.nvidia.enable
.
I don't like the term "accelerators" or "acceleration [APIs]". To know this term or connect it with configuring your GPU, you must have a bit of experience in the field of accelerated computing. As a recent CS graduate myself, this isn't something I'd expect my fellow graduates to know. While they will have at least made contact with accelerated compute and likely heard of OpenGL and/or CUDA, most will likely not connect this term with it.
There are two saving graces here however:
hardware.acceleration.api.vulkan.enable
.I also simply do not think there is a better term.
I concur with @K900's opinion on the impure
prefix.
One could do away with the term "driver" entirely here by calling userspace drivers acceleration API implementations instead. This way we wouldn't cause any confusion around whether we're talking about whether the "driver" is a kernel driver or userspace library.
I don't think this is worth pursuing though because referring to accel API implementations as "drivers" is quite common. Namespacing both API and implementation/driver config under e.g. hardware.acceleration.{driver,api}
should make it clear enough.
Random thoughts:
impure
is a bit confusing: implies the existence of a pure option, and isn't immediately obvious to me in what sense it is "impure". Also worth bearing in mind that this will be the official, recommended setting.hardware.opengl.enable
.Smirking: "A non-technical user will be confused by "drivers" much less than a technical one"
We let loaders [s]can /usr[/lib], yes.
Since this was brought up, I'll mention https://github.com/NixOS/nixpkgs/pull/273389: here the goal was to allow one library (libcuda.so
from cuda_compat
) to load certain dependencies (libnvrm*.so
) from the "system locations". I think this is fairly similar. The complication was that just the libnvrm*.so
were incomplete and had transitive dependencies which in turn caused conflicts with the respective Nixpkgs* libraries (e.g. libstdc++) depending on the order of loading libraries and the driver into the process.
Yeah we can't have it perfectly working, but we can at least have it usually-mostly-working, as long as your nixpkgs libc is ~newer than your drivers.
Yeah we can't have it perfectly working, but we can at least have it usually-mostly-working, as long as your nixpkgs libc is ~newer than your drivers.
Unlesss maybe we mess around with the dynamic loader. I'm still comprehending the implications of https://github.com/NixOS/nixpkgs/pull/248547#issuecomment-1995469926. Is there a separate issue to track /usr/lib
and /etc/ld.so.cache
for driver loaders?
Issue description
The
hardware.opengl.enable
option, as well as the relatedaddOpenGLRunpath
hook and the/run/opengl-driver
path, have been historically very confusing (e.g. it's not obvious one has to "enable opengl" in order to use cuda). https://github.com/NixOS/nixpkgs/issues/141803 introduced an arguably better name for the hook,addDriverRunpath
: although it's not obvious what a "driver" is until you read the documentation, the new name isn't misleading anymore. It's also less ambiguous as to which characters could be upper-case. The/run/opengl-driver/lib
is so far kept for compatibility purposes, which is fine because it's mostly invisible to the users. https://github.com/NixOS/nixpkgs/pull/320228 shattered the status quo concerning the nixos option name, introducinghardware.graphics.enable
. However, this might not yet be the permanent solution.The hook and the option should have consistent names:
addDriverRunpath
doesn't trivially map intohardware.graphics.enable
.A number of alternative names had been suggested^hardware-gpu^impure-drivers. More notably, an alternative and more fine-grained configuration scheme was proposed by @Atemu^atemu-scheme.
Common concerns that have been raised:
hardware.{gp,}gpu
,hardware.graphics
,hardware.opengl
, etc aren't actually just about GPUs, graphics, or OpenGL; these options will concern a variety of external devices (e.g. TPUs) and integrated processors' features, and a variety of software stacks (e.g. Vulkan, OpenCL).hardware.{impure-,}drivers
,hardware.accelerators
, even if technically correct, are non-suggestive; they're likely to confuse the user on the first encounter.A related note is that Nixpkgs (
pkgs
) also has options, and some of them concern "accelerators" and "devices":config.cudaSupport
,config.cudaCapabilities
,config.rocmSupport
; @NixOS/cuda-maintainers (CC @NixOS/rocm-maintainers) have been considering to aggregate this kind of options into a hierarchy: e.g.config.accelerators.{cuda,rocm}.enable
instead of{cuda,rocm}Support
,config.accelerators.cuda.gencodes
instead ofcudaCapabilities
, etc. We have also been considering adding similar global configuration options for OpenCL, MKL, etc - which would also fit reasonably well underconfig.accelerators
. Whatever the name, Nixpkgs' option names should be consistent with NixOS and the hook too.CC @Atemu @K900