nix-community/nixGL

Note: Another NVIDIA graphics card driver address

cathaysia opened this issue · 3 comments

My operating system is RHEL9 and my graphics card is RTX3060. The driver versions available can be found in this list:https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/precompiled/ .But the drivers in the list and the list in http://download.nvidia.com/XFree86/Linux-x86_64/ are not one-to-one.

NVIDIA has two driver source download graphics driver:

This information can be found in https://github.com/NVIDIA/yum-packaging-precompiled-kmod/#download-a-nvidia-driver-runfile . I fork this repo then change the url, it works: 28432f4

Related: #118

It seems trivial to fix when nvidiaHash is supplied, as pkgs.fetchUrl accepts urls, which is a list of url. These urls will be tried in order. pkgs.fetchUrl requires a hash to make the result derivation be fixed-output.

However, when nvidiaHash is null, we are using builtins.fetchUrl. This function only naively download a single url, there is no arguments like urls.

Maybe we can define a fetchUrls function that accept a list of urls and try them one by one, catching failed fetching with tryEval. (This does not work. Fetch error cannot be catched.)

Or we can also firstly use pkgs.fetchUrl to make a fixed-output derivation, then use overrideAttrs to remove outputHash, making it non-fixed. (This does not work too. Downloading from inside a sandboxed build with non-fixed output (i.e. output hash not given in advance) is expected to fail. NixOS/nix#2472 (comment))

The documentation about download link of TRD runfile can be found at https://docs.nvidia.com/datacenter/tesla/tesla-installation-notes/index.html#runfile.

Message originally posted as #120


The Nvidia tesla line is not supported by the XFree86 proprietary dirver, it has a specific "data center" one: https://www.nvidia.fr/Download/driverResults.aspx/193507/en-us

If we want to support that card lineage, we'll probably want to find some heuristics to detect them in the auto detection script.

I don't have a good solution to propose for this issue, but I quickly hacked my way out of this with: picnoir@487f718. Ic could be useful for people hitting this same issue :). I only tested the GLX interface, the EGL one could be entirely broken with this patch.

Note: on the GLX side, it seems like xorg/libglvnd is getting confused by this card and assumes it's supposed to be driven by Mesa. You need to hint it to the right vendor name using __GLX_VENDOR_LIBRARY_NAME.