document design behind /run/opengl-driver

[kirelagin]

There is an explanation of what is going on here but I couldn’t find anything on why is it this way.

Currently this adds extra burden on non-NixOS as the symlink has to be maintained. To make things even more complicated the actual destination of the symlink on NixOS is a package that merges multiple drivers and it is not in nixpkgs, it is generated inside a nixos module.

Why is it necessary to find drivers at runtime?

[vcunat]

Many users want to use other drivers than those from mesa (including myself). For example, nouveau is typically much worse than the binary nvidia driver (in most respects). I think that using a different driver also implies the need to use the libGL*, libvdpau, etc. versions distributed with it.

[vcunat]

I can't see anything actionable about this issue.

[stapelberg]

I can't see anything actionable about this issue.

Can you supply a pointer to the documentation which the issue submitter asked for? If not, then why do you not consider writing the documentation an action item?

(FWIW, I’m interested in documentation as well, because chrome doesn’t start for me, complaining about a missing symbol in /run/opengl-driver/…, so any more information would be good to debug this issue.)

[vcunat]

But #6802 (comment) covers the point, I believe. Documenting the stuff might be nice.

[stapelberg]

Okay, so let me ask a couple of specific follow-up questions which are still unclear to me:

Many users want to use other drivers than those from mesa (including myself). For example, nouveau is typically much worse than the binary nvidia driver (in most respects).

Why does driver choice necessitate the additional symlink? I.e., why can my choice not just be another NixOS config option?

I think that using a different driver also implies the need to use the libGL*, libvdpau, etc. versions distributed with it.

Who could we ask to clarify this assumption?

[vcunat]

It is another NixOS option. The symlink management is automatic.

[vcunat]

I'm relatively certain about the assumption. I don't know anyone around nixos.org who would know with more certainty; maybe there's even noone. EDIT: it should be possible to ask some people around mesa upstream, for example.

[stapelberg]

For more context, I managed to solve the issue I was having: an old version of chrome (51) was still installed in root’s profile. Removing that version and instead installing chrome system-wide (via /etc/nixos/configuration.nix) solved the issue.

However, this behavior violates one of the assumptions I had about NixOS: I assumed that software, once installed, will keep working. This is clearly not the case if chrome breaks when I install a newer version of the mesa drivers.

So, let’s try to approach this issue from another angle: could we change the behavior so that we don’t run the risk of breaking installed software?

[vcunat]

The drivers are inherently impure; that's our design choice. @stapelberg: was this another instance of #16779?

[stapelberg]

Yes, that is precisely the error message I was getting. Strangely enough, I didn’t find that issue when googling the error message yesterday.

I feel the fact that drivers are impure should be better pointed out, this is the first time I read about it.

I have to say, I still don’t understand why drivers have to be impure (do they?). Is this to avoid combinatorial explosion (having to build software against all different drivers) or are there any other reasons?

[vcunat]

Yes, primarily. We have at least three OpenGL implementations.

[stapelberg]

Can we do a back-of-the-envelope calculation as to how much computational/storage resources we’re saving by doing this (provided resource savings are the main motivation)? It would make it easier to understand this trade-off for end users — the fact that a crucial part of my system is impure is pretty disappointing to me :|.

[vcunat]

You can point it by hand to whatever version you like, even a fixed one, without having to recompile anything. EDIT: or create a wrapper to do so automatically.

[stapelberg]

I don’t see how your comment addresses my question. I’m interested in having a pure system, not in switching drivers.

[vcunat]

You could hard-code the driver used during build-time, via a wrapper to the executables that sets $LD_LIBRARY_PATH. Then it would be "pure", i.e. always using the same libGL regardless of the system it's run on. If that system happened to be using a different type of in-kernel driver, such pure approach would cause problems, I think.

[dezgeg]

Can we do a back-of-the-envelope calculation as to how much computational/storage resources we’re saving by doing this (provided resource savings are the main motivation)? It would make it easier to understand this trade-off for end users.

The build products of the proprietary drivers are most likely non-redistributable due to their licenses, so the users of them would need to build most of the apps from source.

[stapelberg]

The build products of the proprietary drivers are most likely non-redistributable due to their licenses, so the users of them would need to build most of the apps from source.

I might be understanding the term “non-redistributable” wrong, but you don’t need to distribute the driver package itself to use it when compiling the remaining packages. So, in practice, users would need to build that one package, but not all reverse-dependencies.

If that system happened to be using a different type of in-kernel driver, such pure approach would cause problems, I think.

What problems?

[lukateras]

What problems?

The problem is that the (choice of) hardware that you run the operating system on is inherently impure, as in, if you change your video card, we can't emulate the old one to support packages that have been built with libGL.so that ships with the driver, meaning that packages that were compiled before that would break.

The idea of an operating system is to abstract away hardware differences, and if NixOS were to use OpenGL purely, it wouldn't do a good job at being an operating system.

If there had been such problem with any other device, say, network card, then swapping card with the new one would break all packages that have been built with the old card in mind. Fortunately, we don't have to do that, Linux streamlines most of driver madness.

[FRidh]

New issue related to this:
#60985

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[FRidh]

Related RFC NixOS/rfcs#121