Why did you remove addOpenGLRunpath from libglvnd? Looks like an accident to me.

Sorry, quick high-level question. I just realized, will this only work for non-NixOS Linux users without extra setup, due to the X11 nature of libGLX_mesa.so? Maybe I'm missing something, but I didn't see any documentation telling macOS users to install XQuartz when they install nix.

Why did you remove addOpenGLRunpath from libglvnd? Looks like an accident to me.

Sorry i should have commented on that. But leaving it here leads to an infinite recursion because libglvnd -> addOpenGLRunpath -> mesa -> libglvnd. I am pretty sure it is unnecessary because it does not link against libGL or libEGL at all. It is the library used to detect which driver vendor you will need.

Sorry, quick high-level question. I just realized, will this only work for non-NixOS Linux users without extra setup, due to the X11 nature of libGLX_mesa.so? Maybe I'm missing something, but I didn't see any documentation telling macOS users to install XQuartz when they install nix.

Yeah swrast utilizes the xlib API to do rendering (see 1.4 What's the difference between "Stand-Alone" Mesa and the DRI drivers for a better explanation). This will only work on X11 systems. AFAICT you can't use swrast with XQuartz at all. This really isn't a problem on macOS because we can provide OpenGL.framework which contains Apple's proprietary libGL driver. Luckily, it supports all Apple hardware, and we don't have to mess with libglvnd at all. This will all become a huge problem though if apple ever decides to remove opengl support from macOS! I don't think even Apple would do that though.

Why did you remove addOpenGLRunpath from libglvnd? Looks like an accident to me.

Sorry i should have commented on that. But leaving it here leads to an infinite recursion because libglvnd -> addOpenGLRunpath -> mesa -> libglvnd. I am pretty sure it is unnecessary because it does not link against libGL or libEGL at all. It is the library used to detect which driver vendor you will need.

libglvnd provides a generic libGL/libEGL that programs should link to and use. It is a dispatch library which figures out the <vendor>, dlopens libGLX_<vendor>/libEGL_<vendor> and forwards calls to it. Possible vendor libraries are mesa_drivers (libGLX_mesa, ...) and nvidia-x11 (libGLX_nvidia, ...).

libglvnd needs to have /run/opengl-driver/lib in RUNPATH so that the vendor libraries are found by dlopen even in the absence of LD_LIBRARY_PATH. This was the whole point of #60985 and removing it would re-introduce #22760. The purpose of the RUNPATH is not to find libGL/libEGL but to find the vendor libraries.

My guess is that mesa needs some headers from libglvnd to build but does not link to any library. This can be solved by making a libglvnd-headers package and using that instead, and checking that there are no references left to it.

My guess is that mesa needs some headers from libglvnd to build but does not link to any library. This can be solved by making a libglvnd-headers package and using that instead, and checking that there are no references left to it.

Ok that sounds good! I will look into it now.

Otherwise does this seems like an okay thing to do? Things like nixGL would still be useful if you need the real drivers, but the fallback should be okay for at least some use cases.

I like a fallback in principle but we need to address the problem of people misunderstanding how their software works. Specifically: someone starts a graphics-heavy application from Nix on a non-NixOS system. It starts but is slow for some reason. As I feel people don't expect that to happen because wrong drivers were chosen; instead they think it's a problem with their current drivers or their video card is slow or something and will lose time debugging.

This can be solved if a debug message of some sort is displayed (e.g. "Falling back to software rendering; if you are on non-NixOS you need nixGL to run applications with hardware rendering."); maybe a patch to libglvnd?

I tried building glxinfo from this branch on debian, and I get the following result:

cycle detected in the references of '/nix/store/lwg87blivdmh3sfkgb3703hwxjbdgl0r-mesa-noglu-18.3.4-drivers' from '/nix/store/ns68h0xiakx3gaanxr5163y6j3nqm09y-mesa-noglu-18.3.4-swrast'
cannot build derivation '/nix/store/f79znzzhv1xb5vkb5pka4mykpz2zwzk5-libGL-1.0.0.drv': 1 dependencies couldn't be built
error: build of '/nix/store/f79znzzhv1xb5vkb5pka4mykpz2zwzk5-libGL-1.0.0.drv' failed

being somewhat a newbie on nix, I am missing something? (building with nix-shell $NIXPKGS -A glxinfo with the branch checkout in NIXPKGS)

Any movement on this?

Hello, I'm a bot and I thank you in the name of the community for your contributions.

Nixpkgs is a busy repository, and unfortunately sometimes PRs get left behind for too long. Nevertheless, we'd like to help committers reach the PRs that are still important. This PR has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

If this is still important to you and you'd like to remove the stale label, we ask that you leave a comment. Your comment can be as simple as "still important to me". But there's a bit more you can do:

If you received an approval by an unprivileged maintainer and you are just waiting for a merge, you can @ mention someone with merge permissions and ask them to help. You might be able to find someone relevant by using Git blame on the relevant files, or via GitHub's web interface. You can see if someone's a member of the nixpkgs-committers team, by hovering with the mouse over their username on the web interface, or by searching them directly on the list.

If your PR wasn't reviewed at all, it might help to find someone who's perhaps a user of the package or module you are changing, or alternatively, ask once more for a review by the maintainer of the package/module this is about. If you don't know any, you can use Git blame on the relevant files, or GitHub's web interface to find someone who touched the relevant files in the past.

If your PR has had reviews and nevertheless got stale, make sure you've responded to all of the reviewer's requests / questions. Usually when PR authors show responsibility and dedication, reviewers (privileged or not) show dedication as well. If you've pushed a change, it's possible the reviewer wasn't notified about your push via email, so you can always officially request them for a review, or just @ mention them and say you've addressed their comments.

Lastly, you can always ask for help at our Discourse Forum, or more specifically, at this thread or at #nixos' IRC channel.

still important to me

I would also like to use something like this for non-performance critical drawing (such as drawing graphs in mcrl2). I also ran into the cycle error that @baloo encountered.

I marked this as stale due to inactivity. → More info

not stale :(

I marked this as stale due to inactivity. → More info

sigh

not stale :(

Stale is to describe that in over a year nothing happened in this PR which is correct.

Why did you remove addOpenGLRunpath from libglvnd? Looks like an accident to me.

Sorry i should have commented on that. But leaving it here leads to an infinite recursion because libglvnd -> addOpenGLRunpath -> mesa -> libglvnd. I am pretty sure it is unnecessary because it does not link against libGL or libEGL at all. It is the library used to detect which driver vendor you will need.

libglvnd provides a generic libGL/libEGL that programs should link to and use. It is a dispatch library which figures out the <vendor>, dlopens libGLX_<vendor>/libEGL_<vendor> and forwards calls to it. Possible vendor libraries are mesa_drivers (libGLX_mesa, ...) and nvidia-x11 (libGLX_nvidia, ...).

libglvnd needs to have /run/opengl-driver/lib in RUNPATH so that the vendor libraries are found by dlopen even in the absence of LD_LIBRARY_PATH. This was the whole point of #60985 and removing it would re-introduce #22760. The purpose of the RUNPATH is not to find libGL/libEGL but to find the vendor libraries.

Thank you!

No longer relevant as Mesa will automatically fall back to software drivers now.