[RFC 0121] Migrate OpenGL References to API-Agnostic Terms #121
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,88 @@ | ||
| --- | ||
| feature: Use a more canonical name for hardware driver path and modules | ||
| start-date: 2022-02-03 | ||
| author: @jonringer | ||
| co-authors: | ||
| shepherd-team: @edolstra @colemickens @Ericson2314 | ||
| shepherd-leader: @colemickens | ||
| related-issues: https://github.com/NixOS/nixpkgs/issues/141803 | ||
| --- | ||
|
|
||
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| Currently, NixOS mounts video drivers under the path `/run/opengl-driver/`, | ||
| but should be mounted under a more generic `/run/current-system/drivers/` path. | ||
| The usage of opengl explicitly may have been an accurate name given the time | ||
| in which NixOS was first created; however, graphic drivers alone include much | ||
| more than just userland graphics libraries so this usages is now misaligned with | ||
| current paradigms. The misalignment with this path and the related Nixpkgs | ||
| utilities are a misnomer in most contexts, and contributes to Nixpkgs' | ||
| "weirdness budget". | ||
|
|
||
| # Motivation | ||
| [motivation]: #motivation | ||
|
|
||
| Video drivers ship many hardware acceleration libraries these days: vulkan, | ||
| opengl, opencl, video encoding, cuda, and many other userland libraries are | ||
| installed. Having all of these libraries placed under a single "opengl" header | ||
| is odd for many contributors, especially newcomers. This awkwardness is | ||
| compounded with other specialized hardware such as fpgas, tpus, and asics | ||
| where their function isn't related to graphics, however, also need to make | ||
| use of a "known good" path in which the related userland libraries will be mounted. | ||
|
|
||
| To remedy this misalignment, a new convention around placing those libraries | ||
| should be used, preferably `/run/current-system/drivers/`. | ||
|
|
||
| # Detailed design | ||
| [design]: #detailed-design | ||
|
|
||
| Most of the implementation of the current paradigms will continue, as there | ||
| will always be a need for some "impurity" around hardware based libraries. | ||
| The significant changes will be around naming conventions used within | ||
| Nixpkgs and NixOS. | ||
|
|
||
| Deprecate and move existing `/run/opengl-driver/` logic: | ||
| - Rename `hardware.opengl` options to `hardware.drivers` (pre 22.11) | ||
| - Rename `pkgs.addOpenGLRunpath` shell hook to `addHardwareRunpath` (pre 22.11) | ||
| - Alias `addOpenGLRunpath` to `addHardwareRunpath` for compatibility (pre 22.11) | ||
| - Update nixpkgs references of `/run/opengl-driver/` to point to `/run/current-system/drivers/` (post 22.11) | ||
|
There was a problem hiding this comment. If There was a problem hiding this comment. wouldn't this cause issues if someone were to do Will also require changes to "driver" builds, looks like only mesa has a |
||
| - Update `mesa.driverLink` to point to `/run/current-system/drivers/lib` (post 22.11) | ||
|
|
||
| For compatibility with existing nixpkgs packages, `/run/opengl-driver{,-32}/` will | ||
| be a symbolic link to `/run/current-system/drivers{,-32}/`. This will likely be | ||
| an indefinite change, or else older packages will not work on NixOS. Also, | ||
| we need to ensure compatibility with out-of-tree code which may have been built around | ||
| the opengl paths, such as [nixGL](https://github.com/guibou/nixGL). | ||
|
There was a problem hiding this comment. I think this means that both There was a problem hiding this comment. No, only one path will be written to the ELF files. Current PR to change the name of |
||
|
|
||
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| Technical churn. Doesn't provide any new or added benefit, other than | ||
| correcting a stale misnomer. | ||
|
|
||
| # Alternatives | ||
| [alternatives]: #alternatives | ||
|
|
||
| Continue to use `/run/opengl-driver` in it's current state. | ||
|
|
||
| # Unresolved questions | ||
| [unresolved]: #unresolved-questions | ||
|
|
||
| Is there a better name for the path, nixos module options, and nixpkgs hook? | ||
|
|
||
| This is also an opportunity to revisit the `hardware.opengl` module. Some | ||
| potential improvements could be: | ||
| - Move `hardware.opengl.package` + `hardware.opengl.extraPackages` to a single `hardware.drivers.packages` | ||
|
There was a problem hiding this comment. This makes replacing mesa in particular harder, as now it's a single list. Using an overlay isn't practical as it rebuilds far too much. Making this a set so you can do I originally commented this on the impl PR instead of the RFC accidentally. There was a problem hiding this comment. How special is I will concede that if it is special, that is not just an OpenGL thing, but also something that could be true in a Vulkan / many languages world. There was a problem hiding this comment. Having it as a set makes it easier to replace any specific package, we'd change anywhere in nixpkgs that sets it to eg do Mesa is sort of special - any system with working gl/vulkan is expected to have it, even when using other proprietary libs alongside it - but I don't think handling specifically for mesa is the right approach when we could make it easier to override any There was a problem hiding this comment. I agree with the general point here that in the modules system, lists are poorly composable. They can only be appended to, or replaced outright. We don't have the tools to allow a user to remove or replace an element from a configuration system list. There are too many options already that imo should be migrated to attrsets to let the user be in control. Let's not add more if we can. There was a problem hiding this comment. I wouldn't set across the board because names are arbitrary. Like, if I do There was a problem hiding this comment. You aren't doing anything wrong if you do that and it isn't much of a problem if you do that, unless you get it included in nixpkgs I guess. If you do that alongside something else setting There was a problem hiding this comment. I am not sure how express this, but we shouldn't design things around names. Perhaps other modules can make configurable what package they would add to this list, but unless we can characterize "structurally" how these package fit into different roles I would leave it just as is. There was a problem hiding this comment. Using a list to avoid the names is even worse, as your only options are to use an overlay and rebuild everything or to mkForce and have to keep track of any other entries that should be in the list. If we keep it as is and have .package and .extraPackages then we aren't relying on names but we're also only making it easy to override mesa, and it's even easier to accidentally include duplicate packages of different versions in the list as instead of relying on a name there's nothing to prevent dupes. e: I guess it's at least agreed that we shouldn't combine them into one list and that that's worse than the current approach? |
||
| - The current paradigm seems to be a compromise of `package` existing, but needed to adapt for other hardware acceleration libraries. | ||
| - Enable option can default to `hardware.drivers.packages != []` ? | ||
| - Move `services.xserver.videoDrivers` to `hardware.gpu.drivers`? | ||
| - Very awkward for sway users to need to set something in `services.xserver` | ||
|
|
||
| # Future work | ||
| [future]: #future-work | ||
|
|
||
| - Execute the actions outlined in the detailed design | ||
| - Update release notes | ||
| - Update documentation which mentions older usages of the shell hook or nixos options. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this is actually going in the right direction. There's already the problem where nixpkgs binaries are hardcoded to the
/run/opengl-driverpath, which prevents them from working on non-NixOS systems by default. With this change, this becomes even more NixOS specific. NixGL was created to fix this problem, but that's only a workaround, not a permanent solution.So I'd say rather than trying to fix the naming of something that's already problematic, how about we instead focus on fixing the problem at its core, then the misnaming will go away automatically when it's replaced with something better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Don't let perfect be the enemy of good".
I agree that the solution isn't ideal, but I can't think of a better one which can be achieved in a reasonable of time or significant work on how derivations work.
I just want Nixpkgs/NixOS in a better state. I'm fine delaying the heavier ramifications of using a different path (e.g
/run/current-system/sw/driver), which have already been postponed for allowing for a more seamless upgrade path for users.But I really just want the user facing "APIs" to be more intuitive (e.g.
hardware.gpu.drivers = [ "nvidia" ];rather thanservices.xserver.videoDrivers = [ "nvidia ];).This RFC has already been open for ~10 months, it's almost impossible to get anything moved through in this RFC process; this really encourages people to just create a nixpkgs PR, and get a sympathetic committer to merge it and avoid the RFC process altogether.