NixOS application are unable to find OpenGL drivers

[dukc]

Describe the bug
Despite having specified the wanted graphic drivers in configuration.nix:

services.xserver.videoDrivers = [ "amdgpu" "radeon" "cirrus" "vesa" "nouveau" ];

...the applications just fall back to llvmpipe (meaning, no GPU used at all):

$ glxinfo | grep OpenGL
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 7.1, 128 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.1.5
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.1 Mesa 19.1.5
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 19.1.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

Note that vmware does not even exist in the drivers I specified, yet the applications still find it somewhere. Needless to say, 3D-gaming is incredibly slow.

And running hwinfo --gfxcard somehow lists the drivers that I want to use, despite glxinfo being unable to do that:

$ hwinfo --gfxcard | grep Driver
  Driver: "nouveau"
  Driver Modules: "nouveau"
  Driver: "amdgpu"
  Driver Modules: "amdgpu"

(It said this even before I added services.xserver.videoDrivers to configuration.nix)

To Reproduce
Steps to reproduce the behavior:

1. Enable x11 and xfce
2. install and run hwinfo --gfxcard and add the drivers it says to services.xserver.videoDrivers
3. if it still does not appear, you could try to add the rest of my OpenGL configuration, described in additional context (EDIT: you need to set it, otherwise won't happen)

Expected behavior
glxinfo returning info for (at least) two renderers, one for each GPU. And programs to use them.

Additional context
I don't know if this is related, but I post it in case it is. I have added this to configuration.nix to combat other problems I've had with OpenGL:

EDIT: confirmed to be related.

hardware.opengl.package = (import (pkgs.fetchzip {
      name = "old-nixpkgs";
      url = "https://github.com/NixOS/nixpkgs/archive/0a11634a29c1c9ffe7bfa08fc234fef2ee978dbb.tar.gz";
     sha256 = "0vj5k3djn1wlwabzff1kiiy3vs60qzzqgzjbaiwqxacbvlrci10y";
  }) {}).mesa.drivers;
  hardware.opengl.driSupport32Bit = true;

I use an older Mesa because I had serious graphical glitches in xfce (starting from second login for each user account) with the current NixOS Mesa. This fixed it.

Metadata

• system: "x86_64-linux"
• host os: Linux 5.4.44, NixOS, 20.03.2107.70717a337f7 (Markhor)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.3.6
• channels: "nixpkgs-20.09pre234797.206dc0cfacd"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:

# a list of nixos modules affected by the problem
module: nixos.mesa

Any help to get GPUs working appreciated.

[dukc]

Confirmed that using the older mesa is required to cause the problem. If I remove the lines about hardware.opengl from configuration.nix, this problem disappears (was the problem a bug in the first place? I don't know, please tell me). But it does not help me, because the graphical glitching in xfce is too severe with the default mesa version.

[rnhmjoj]

Note that vmware does not even exist in the drivers I specified, yet the applications still find it somewhere.

I'll try to clear the confusion. There are in a fact 3 parts of a driver:

1. The kernel driver, which does the actual talking to the hardware. This is provided as a kernel module and is enabled by
   adding it to the boot.initrd.availableKernelModules option.

2. The device-dependent X (DDX), which is the component of the X server that draws the screen. This is provided by several packages which you install by setting services.xserver.videoDrivers.

3. The Gallium driver in Mesa. Mesa is collection of graphics API (like OpenGL, Direct3D, etc.), which are themselves implemented in a lower-level API called Gallium. The Gallium drivers implement this API either using the kernel driver of the GPU (like nouveau) or software rendering (like llvmpipe). You don't need to enable/install these drivers: they are all available within mesa.

I think VMware is just the original author of the llvmpipe driver: it has nothing to do with virtualisation.

...the applications just fall back to llvmpipe (meaning, no GPU used at all):

Can you check you don't have the LIBGL_ALWAYS_SOFTWARE variable set to true? Maybe you did some testing and forgot to remove it.

You should also try forcing nouveau by setting GALLIUM_DRIVER=nouveau and check with glxinfo.

[dukc]

I'll try to clear the confusion. There are in a fact 3 parts of a driver:
[snip]

Thanks for the info. Well, this explains why LLVM pipe is always available.

I think VMware is just the original author of the llvmpipe driver: it has nothing to do with virtualisation.

Didn't think otherwise, since it was after the vendor label

...the applications just fall back to llvmpipe (meaning, no GPU used at all):

Can you check you don't have the LIBGL_ALWAYS_SOFTWARE variable set to true? Maybe you did some testing and forgot to remove it.

No effect.

You should also try forcing nouveau by setting GALLIUM_DRIVER=nouveau and check with glxinfo.

glxinfo errored out, same error message as if I wrote GALLIUM_DRIVER=nonexistent glxinfo. Same with amdgpu.

But, I managed to partially fix the problem. Or rather, Nix did it for me. Since glxinfo found amdgpu worked at the newer graphically glitching Mesa, I thought that perhaps changing the order of the drivers would resolve the graphical glitches without having to downgrade Mesa.
services.xserver.videoDrivers = [ "nouveau" "amdgpu" "radeon" "cirrus" "vesa" ];, commented out the OpenGL package override and ran nixos.rebuild boot.

The rebuild downloaded so much stuff that I suspect it constitutes almost everything I've installed so far. Then I realised that I had added another channel since the last rebuild, so it apparently wanted to update the binaries to match with the Nix store.

After rebooting, there were no graphical glithes. glxinfo says amdgpu, so Nouveau wasn't found (wasn't either with the glitching OpenGL). So it seems the system update fixed the glitches. Thanks!

Even with only the integrated GPU, I'm seeing much better gaming performance. Since the discrete GPU is NVIDIA, does this mean specifying an unfree driver to services.xserver.videoDrivers or is there something else I could try?

[rnhmjoj]

Even with only the integrated GPU, I'm seeing much better gaming performance.

That's not surprising considering nouveau is mostly written mostly by reverse engineering, while amdgpu is officially supported by AMD.

is there something else I could try?

Well, I don't see you doing anything wrong and I would expect Mesa to pick up the correct driver, nouveau, so I would try opening an issue in the Mesa tracker.

[dukc]

Sorry for the needlessly late reply.

That's not surprising considering nouveau is mostly written mostly by reverse engineering, while amdgpu is officially supported by AMD.

No, I wasn't comparing AMDgpu to Nouveu, I was comparing it to LLVMPipe.

Well, I don't see you doing anything wrong and I would expect Mesa to pick up the correct driver, nouveau, so I would try opening an issue in the Mesa tracker.

Thanks you. That's what I'm going to do when I get to that. I might first try to override the drivers with the unstable channel Mesa. If I happen to get Nouveau working that way, I'll leave a message here.

But anyway, It seems be a Mesa issue, not a Nixpkgs one, so no reason to keep this issue open anymore.

[GrabbenD]

@dukc I've just encountered this issue! Do you remember the solution?

#228586

[dukc]

No, sorry, I didn't manage to get Nouveau working.

I did some playing by prefixing application running command with DRI_PRIME and MESA_GL_VERSION_OVERRIDE flags. I think I got hwinfo to claim "nouveau" that way, while Steam still said "amdgpu". Games didn't run faster and sometimes an OS freeze happened so either Nouveau worked very badly for me or I didn't actually fully enable it. The latter explanation is more likely IMO.

Since I'm lazy I haven't actually reported the issue to Mesa.

[GrabbenD]

Thanks for reporting back @dukc . From my understanding the issue was a mismatch between mesa in upstream (nixpkg) versus compositor's version.

Regarding wrong primary display adapter, I wasn't able to solve it either.

Since you mentioned it, I removed my NVIDIA GPU and I can confirm that amdgpu/mesa driver is prone to hard crashing with DX12 games over Proton 8/7 :/

[dukc]

Had an another go trying to troubleshoot my Nouveau issue. Didn't get it working, but gained a bit of insight of the problem so decided to share it here.

Someone was having very similar problems here. In the same spirit, I spent time reading my journalctl -b --no-hostname | less. The driver does load but doesn't support my chipset:

tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]: (II) [drm] nouveau interface version: 1.3.1
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]: (EE) Unknown chipset: NV167

. It does support some other chipsets though:

tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]: (II) NOUVEAU driver
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]: (II) NOUVEAU driver for NVIDIA chipset families :
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         RIVA TNT            (NV04)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         RIVA TNT2           (NV05)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce 256         (NV10)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce 2           (NV11, NV15)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce 4MX         (NV17, NV18)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce 3           (NV20)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce 4Ti         (NV25, NV28)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce FX          (NV3x)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce 6           (NV4x)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce 7           (G7x)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce 8           (G8x)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce 9           (G9x)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce GTX 2xx/3xx (GT2xx)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce GTX 4xx/5xx (GFxxx)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce GTX 6xx/7xx (GKxxx)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce GTX 9xx     (GMxxx)
tammi 03 16:32:55 /nix/store/y5s10jdrni1gacvncwd9v96ca6ciyjz0-gdm-45.0.1/libexec/gdm-x-session[2017]:         GeForce GTX 10xx    (GPxxx)

. Even earlier in the log it turns out it's because lack of firmware (a few non-Nouveau lines hand-removed from between):

tammi 03 16:32:43 kernel: nouveau: detected PR support, will not use DSM
tammi 03 16:32:43 kernel: nouveau 0000:01:00.0: NVIDIA TU117 (167000a1)
tammi 03 16:32:43 kernel: nouveau 0000:01:00.0: bios: version 90.17.3d.00.80
tammi 03 16:32:43 kernel: nouveau 0000:01:00.0: pmu: firmware unavailable
tammi 03 16:32:43 kernel: nouveau 0000:01:00.0: fb: 4096 MiB GDDR5
tammi 03 16:32:43 kernel: nouveau 0000:01:00.0: DRM: VRAM: 4096 MiB
tammi 03 16:32:43 kernel: nouveau 0000:01:00.0: DRM: GART: 536870912 MiB
tammi 03 16:32:43 kernel: nouveau 0000:01:00.0: DRM: BIT table 'A' not found
tammi 03 16:32:43 kernel: nouveau 0000:01:00.0: DRM: BIT table 'L' not found
tammi 03 16:32:43 kernel: nouveau 0000:01:00.0: DRM: Pointer to TMDS table not found
tammi 03 16:32:43 kernel: nouveau 0000:01:00.0: DRM: DCB version 4.1
tammi 03 16:32:43 kernel: nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies

. The strange thing is, I do have tu117 in /run/current-system/firmware/nvidia/, and it's files are also listed if I do modinfo nouveau. One thing I notice is the symbolic link gsp.xz in tu117 directory, that is supposed to point to a directory in the neighbouring tu116 directory, is broken. Could potentially be the reason but seems unlikely, as the drivers tu116 represents also aren''t listed in working nouveau drivers yet it's directory contains no broken links.

I didn't come up with any fix attempts except explicitly enabling redistributable firmware, to no effect.