treewide: big opengl cleanups

[K900]

Description of changes

This is long overdue.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[mweinelt]

Manual build probably requires updating nixos/doc/manual/configuration/gpu-accel.chapter.md.

[K900]

Yep, forgot to commit all the renames. Should be there now.

[SuperSandro2000]

We should probably mention, that this was a no-op in the first place

[Tungsten842]

I am not sure that "graphics" is a good name in this case.
Consider that hardware.opengl.extraPackages is currently also used by: opencl and level-zero.
I believe that putting compute only APIs in a "graphics" namespace causes unnecessary confusion, the previous naming, hardware.drivers seemed more appropriate in this case: #158079

[K900]

hardware.drivers is even worse, because it gives you absolutely no idea what "drivers" there are or why you should care. graphics is suboptimal, but accelerators is way too non-obvious.

[Atemu]

The idea would be to have hardware.drivers.vulkan, hardware.drivers.opengl etc. which would make it quite obvious which drivers there are. Even non-nerdy people use the term "drivers" to refer to this software component. If they typed "vulkan drivers nvidia" into search.nixos.org, I believe they'd find the correct option.

I also take issue with graphics though, especially as many signs point to more task-specific accelerator hardware in the future that has nothing to do with graphical processing.
I'd find enabling drivers for a compression accelerator via hardware.graphics equally confusing as configuring Vulkan via hardware.opengl. Let's not repeat that mistake.

I agree that accelerator is much to technical of a term but I simply know of no better term that is neutral with respect to the task being carried out.

Additionally, uninformed users should never need to be touching these. A typical desktop user for instance should only have to enable a desktop session and/or Steam and those would in turn enable the accelerator APIs typically required for those use-cases.
Anyone who does need to touch these manually ought to learn some terminology. I think that's a reasonable ask.

I won't block on this as this is already an improvement over the status quo and I've clearly not found the priority to produce code for my preferred options API but please consider my design choices and why I made them.

[K900]

Really the problem with separating the options like what you're proposing is that Mesa is all of those at the same time, and Mesa is what most people will be running. Technically, we could separate OpenGL, OpenCL, Vulkan, VAAPI etc lookup paths, since they're symlinks anyway, and just link the right manifests into place, but that feels like a lot of work for questionable gain?

[Atemu]

Really the problem with separating the options like what you're proposing is that Mesa is all of those at the same time

Not quite and that's an issue. It's a geat implementation of most of the most critical and useful acceleration APIs but by far not all of them. I love mesa but I don't think it's a good idea to equate it with hardware acceleration as a whole. There is a world outside of Mesa and it does not support every accel API under the sky and that's an issue if you center your NixOS options around everything being mesa. Think CUDA, ROCm, oneAPI etc. or even just alternative implementations of the APIs mesa supports for which there are valid use-cases.
This is also again quite graphics-centric thinking as there are far more hardware accelerators than just GPUs but require userspace drivers in much the same way.

Mesa is what most people will be running

That is true but enforcing that through the design of the NixOS options is the wrong way of achieving that IMO. Ensuring the user has the most sensible drivers installed should be handled through use-case-driven sane defaults.

Technically, we could separate OpenGL, OpenCL, Vulkan, VAAPI etc lookup paths, since they're symlinks anyway, and just link the right manifests into place, but that feels like a lot of work for questionable gain?

You don't have to do but designing it like that leaves you the option to should that become relevant. In my initial implementation I still threw them into /run/opengl-driver but you could totally separate it in the implementation later you wanted to.

Speaking of which, I had a draft with some progress somewhere with some more notes and discussion but I'm having a really hard time finding it. I'll link it here when I find it.

[Atemu]

Found it: #141803 (comment)

[K900]

I do really like your draft. I'll see if I can muster the spoons to actually try implementing it, because it does not seem too difficult now...

[jonringer]

I'll defer to @Atemu on this matter. I removed most of the references of opengl from packaging concerns, module re-design I like their direction, and looks like the related information was already brought up.

[K900]

OK, let's just send this, and I'll try a more ambitious cleanup over the weekend.

[github-actions]

Backport failed for release-24.05, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-24.05
git worktree add -d .worktree/backport-320228-to-release-24.05 origin/release-24.05
cd .worktree/backport-320228-to-release-24.05
git switch --create backport-320228-to-release-24.05
git cherry-pick -x 951601ccab7c3e8f9afa3ed78f2046863e6fa81d 98cef4c27326d0f9e521654441929c1c7c64f8e9 1e3c610b8442bb22be3ca39542894f16d3c94d5c

[K900]

Definitely not.

[themaxhero]

hardware.drivers is even worse, because it gives you absolutely no idea what "drivers" there are or why you should care. graphics is suboptimal, but accelerators is way too non-obvious.

What about hardware.gpu?

[K900]

It's not really just GPUs, but anyway, I'll have a PR with a more granular approach to this eventually.

[JohnRTitor]

Definitely not.

Is there a reason not to? Due to nixos-hardware not being versioned, about time we get bug reports from stable users.

[K900]

It's an API break. We don't do those on stable releases. nixos-hardware should just use the old options for now, and remove the removed ones.

[SomeoneSerge]

Oh, not sure how I missed this. This is great and indeed long overdue, thank you @K900!

Regarding the naming, I think hardware.graphics isn't much different from hardware.opengl and about as misleading. As you say it's not "just gpus", and it's not "just graphics". I still like hardware.drivers (personal preference: hardware.impure-drivers) as the most precise so far. I am not concerned with how much or little information this name conveys to an uninformed reader on the first encounter. NixOS is in the process of establishing essentially a new concept here: separating pure dependencies/services from those that must be kept impure. As long as the new name (whatever it be) makes sense, is reasonably documented and pointed at with mkRenamedOptionModule, it's perfectly reasonable to introduce a new term once in a while.

[jhvst]

Why was setLdLibraryPath removed?

[Atemu]

AFAICT because the last driver relying on this terrible hack was removed (AMDGPU-PRO).

It should receive a mkRenamedOptionModule though.

What's your use-case?