Talk:NVIDIA: Difference between revisions

(6 intermediate revisions by 2 users not shown)

Line 1:

== Some recommendations for the NixOS NVIDIA usage ==

For a Gnome user it is useful to add the svicheroo-control application in the package section of the configuration.nix and enable svicheroo-control service.

If there are a kernel-panic, hanging or freezing of the system on poweroff or rebooting with the NVIDIA 550 version driver, as it known https://forums.developer.nvidia.com/t/series-550-freezes-laptop/284772 , it is necessary to use the beta version of the NVIDIA driver package.

== Non-NixOS section ==

The section cutrrently suggests using NixGL.

In my limited experience, a more "convenient" option has been to symlink (e.g. via systemd-tmpfiles) the host's driver libraries to `/run/opengl-driver/lib` which is already in all executable's RPATHs, but I don't know how robust that is when it comes to libc. At least a mention of `/run/opengl-driver/lib` and RPATHs existing would be quite appropriate on this page.

I would also mention that on darwin `nix run` seems to work out of the box with opengl apps - for visibility

--[[User:SomeoneSerge|SomeoneSerge]] ([[User talk:SomeoneSerge|talk]]) 21:46, 17 March 2022 (UTC)

== cudnn ==

We need a section that clarifies the correspondence between cudnn and cudatoolkit, as well as how to properly override these in applications. The cudnn-vs-cudatoolkit problem is that we now how multiple static attributes of the form `cudnn_${cudnnVer}_cudatoolkit_${cudaVer}`, which may cause confusion. For example, we package cudatoolkit=11.6 (and our users may choose to build e.g. pytorch against cudatoolkit 11.6), but there's no cudnn_X_cudatoolkit_11_6 attribute. Refer to this issue: https://github.com/NixOS/nixpkgs/pull/164338

Another aspect of the problem is in overriding downstream derivations, that take as inputs both cudnn and cudatoolkit.

For example, (speaking of nixpkgs-21.11) when a user overrides pytorch to use cudatoolkit_11, the build fails because pytorch gets two conflicting versions of cuda: cudatoolkit_11 from the user, and cudatoolkit_10 through the dependency on cudnn. Until we've fixed these issues on nixpkgs, we should at least make them and the workarounds visible to the users to reduce frustration. See e.g. https://discourse.nixos.org/t/cant-get-pytorch-to-recognise-override/12082

--[[User:SomeoneSerge|SomeoneSerge]] ([[User talk:SomeoneSerge|talk]]) 21:58, 17 March 2022 (UTC)

== some old sections without a signature - cleanup? ==

I have a few issues with the '''By making a FHS user env''' section

@@ Line 1: / Line 1: @@
+== Some recommendations for the NixOS NVIDIA usage ==
+For a Gnome user it is useful to add the svicheroo-control application in the package section of the configuration.nix and enable  svicheroo-control service.
+If there are a kernel-panic, hanging or freezing of the system on poweroff or rebooting with the NVIDIA 550 version driver, as it known https://forums.developer.nvidia.com/t/series-550-freezes-laptop/284772 , it is necessary to use the beta version of the NVIDIA driver package.
+== Non-NixOS section ==
+The section cutrrently suggests using NixGL.
+In my limited experience, a more "convenient" option has been to symlink (e.g. via systemd-tmpfiles) the host's driver libraries to `/run/opengl-driver/lib` which is already in all executable's RPATHs, but I don't know how robust that is when it comes to libc. At least a mention of `/run/opengl-driver/lib` and RPATHs existing would be quite appropriate on this page.
+I would also mention that on darwin `nix run` seems to work out of the box with opengl apps - for visibility
+--[[User:SomeoneSerge|SomeoneSerge]] ([[User talk:SomeoneSerge|talk]]) 21:46, 17 March 2022 (UTC)
+== cudnn ==
+We need a section that clarifies the correspondence between cudnn and cudatoolkit, as well as how to properly override these in applications. The cudnn-vs-cudatoolkit problem is that we now how multiple static attributes of the form `cudnn_${cudnnVer}_cudatoolkit_${cudaVer}`, which may cause confusion. For example, we package cudatoolkit=11.6 (and our users may choose to build e.g. pytorch against cudatoolkit 11.6), but there's no cudnn_X_cudatoolkit_11_6 attribute. Refer to this issue: https://github.com/NixOS/nixpkgs/pull/164338
+Another aspect of the problem is in overriding downstream derivations, that take as inputs both cudnn and cudatoolkit.
+For example, (speaking of nixpkgs-21.11) when a user overrides pytorch to use cudatoolkit_11, the build fails because pytorch gets two conflicting versions of cuda: cudatoolkit_11 from the user, and cudatoolkit_10 through the dependency on cudnn. Until we've fixed these issues on nixpkgs, we should at least make them and the workarounds visible to the users to reduce frustration. See e.g. https://discourse.nixos.org/t/cant-get-pytorch-to-recognise-override/12082
+--[[User:SomeoneSerge|SomeoneSerge]] ([[User talk:SomeoneSerge|talk]]) 21:58, 17 March 2022 (UTC)
+== some old sections without a signature - cleanup? ==
 I have a few issues with the '''By making a FHS user env''' section