# nvidia-drivers-390.x and libglvnd

## NathanZachary

Hello all,

I had to do some research to find out a little more about libglvnd and the whole point of switching away from eselect-opengl in favour of it.  After these changes, though, my graphics rendering has been quite sluggish.  I'm currently using the 390.x nvidia driver (for my ancient GTX 470).  I see that direct rendering is enabled:

```

# glxinfo | grep -i render

direct rendering: Yes

    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 

    GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, 

Extended renderer info (GLX_MESA_query_renderer):

OpenGL renderer string: llvmpipe (LLVM 9.0.1, 128 bits)

    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 

    GL_MESA_ycbcr_texture, GL_NV_conditional_render, GL_NV_depth_clamp, 

    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 

    GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_fog_distance, 

    GL_EXT_polygon_offset_clamp, GL_EXT_read_format_bgra, GL_EXT_render_snorm, 

    GL_MESA_shader_integer_functions, GL_NV_conditional_render, 

    GL_OES_element_index_uint, GL_OES_fbo_render_mipmap, 

```

However, it looks like there is no reference to nvidia:

```

# glxinfo | grep -i opengl

OpenGL vendor string: VMware, Inc.

OpenGL renderer string: llvmpipe (LLVM 9.0.1, 128 bits)

OpenGL core profile version string: 3.3 (Core Profile) Mesa 20.0.1

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 20.0.1

OpenGL shading language version string: 1.40

OpenGL context flags: (none)

OpenGL extensions:

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 20.0.1

OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

OpenGL ES profile extensions:

# glxinfo | grep -i nvidia

# 

```

This doesn't seem right to me, and is likely the reason for the sluggish graphics rendering.  Does anyone have some documentation on the changes necessary to make this work as intended?

Cheers,

Nathan Zachary

----------

## Ionen

libglvnd support was added to the 390 ebuild only recently (in ~arch), I honestly wouldn't be surprised if it simply doesn't work right now, but I don't use 390 to be able to confirm.

It certainly "should" be showing nvidia in those greps if libglvnd is working normally and nvidia-drivers are in-use by xorg+kernel without having to do anything special (at most may want to confirm in your Xorg.0.log it's still loading nvidia drivers).

----------

## NathanZachary

Looks like the driver is failing:

```

# grep -i nvidia /var/log/Xorg.0.log

[    26.645] (**) |   |-->Device "nvidia"

[    26.660] (II) LoadModule: "nvidia"

[    26.662] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so

[    26.667] (II) Module nvidia: vendor="NVIDIA Corporation"

[    26.668] (II) NVIDIA dlloader X Driver  390.132  Fri Nov  1 03:36:28 PDT 2019

[    26.669] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs

[    26.678] (II) NVIDIA(0): Creating default Display subsection in Screen section

[    26.678] (==) NVIDIA(0): Depth 24, (==) framebuffer bpp 32

[    26.678] (==) NVIDIA(0): RGB weight 888

[    26.678] (==) NVIDIA(0): Default visual is TrueColor

[    26.678] (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)

[    26.678] (**) NVIDIA(0): Option "TripleBuffer" "0"

[    26.678] (**) NVIDIA(0): Option "Coolbits" "12"

[    26.678] (**) NVIDIA(0): Option "RegistryDwords" "PowerMizerEnable=0x1; PowerMizerDefaultAC=0x3;"

[    26.678] (**) NVIDIA(0): Enabling 2D acceleration

[    26.678] (WW) NVIDIA(GPU-0): Invalid RegistryDword entry: ""; discarding.

[    26.678] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X

[    26.678] (EE) NVIDIA(0):     log file that the GLX module has been loaded in your X

[    26.678] (EE) NVIDIA(0):     server, and that the module is the NVIDIA GLX module.  If

[    26.678] (EE) NVIDIA(0):     you continue to encounter problems, Please try

[    26.678] (EE) NVIDIA(0):     reinstalling the NVIDIA driver.

[    27.064] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:3:0:0

[    27.064] (--) NVIDIA(0):     CRT-0

[    27.064] (--) NVIDIA(0):     CRT-1

[    27.064] (--) NVIDIA(0):     DFP-0 (boot)

[    27.064] (--) NVIDIA(0):     DFP-1

[    27.064] (--) NVIDIA(0):     DFP-2

[    27.065] (II) NVIDIA(0): NVIDIA GPU GeForce GTX 470 (GF100) at PCI:3:0:0 (GPU-0)

[    27.065] (--) NVIDIA(0): Memory: 1310720 kBytes

[    27.065] (--) NVIDIA(0): VideoBIOS: 70.00.35.00.70

[    27.065] (II) NVIDIA(0): Detected PCI Express Link width: 16X

[    27.082] (--) NVIDIA(GPU-0): CRT-0: disconnected

[    27.082] (--) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock

[    27.082] (--) NVIDIA(GPU-0): 

[    27.098] (--) NVIDIA(GPU-0): CRT-1: disconnected

[    27.098] (--) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock

[    27.098] (--) NVIDIA(GPU-0): 

[    27.131] (--) NVIDIA(GPU-0): DELL U2410 (DFP-0): connected

[    27.131] (--) NVIDIA(GPU-0): DELL U2410 (DFP-0): Internal TMDS

[    27.131] (--) NVIDIA(GPU-0): DELL U2410 (DFP-0): 330.0 MHz maximum pixel clock

[    27.131] (--) NVIDIA(GPU-0): 

[    27.131] (--) NVIDIA(GPU-0): DFP-1: disconnected

[    27.131] (--) NVIDIA(GPU-0): DFP-1: Internal TMDS

[    27.131] (--) NVIDIA(GPU-0): DFP-1: 165.0 MHz maximum pixel clock

[    27.131] (--) NVIDIA(GPU-0): 

[    27.164] (--) NVIDIA(GPU-0): DELL U2410 (DFP-2): connected

[    27.164] (--) NVIDIA(GPU-0): DELL U2410 (DFP-2): Internal TMDS

[    27.164] (--) NVIDIA(GPU-0): DELL U2410 (DFP-2): 330.0 MHz maximum pixel clock

[    27.164] (--) NVIDIA(GPU-0): 

[    27.171] (==) NVIDIA(0): 

[    27.171] (==) NVIDIA(0): No modes were requested; the default mode "nvidia-auto-select"

[    27.171] (==) NVIDIA(0):     will be used as the requested mode.

[    27.171] (==) NVIDIA(0): 

[    27.171] (II) NVIDIA(0): Validated MetaModes:

[    27.171] (II) NVIDIA(0):     "DFP-0:nvidia-auto-select,DFP-2:nvidia-auto-select"

[    27.171] (II) NVIDIA(0): Virtual screen size determined to be 3840 x 1200

[    27.176] (--) NVIDIA(0): DPI set to (93, 95); computed from "UseEdidDpi" X config

[    27.176] (--) NVIDIA(0):     option

[    27.180] (II) NVIDIA: Using 6144.00 MB of virtual memory for indirect memory

[    27.180] (II) NVIDIA:     access.

[    27.183] (II) NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon

[    27.183] (II) NVIDIA(0):     may not be running or the "AcpidSocketPath" X

[    27.183] (II) NVIDIA(0):     configuration option may not be set correctly.  When the

[    27.183] (II) NVIDIA(0):     ACPI event daemon is available, the NVIDIA X driver will

[    27.183] (II) NVIDIA(0):     try to use it to receive ACPI event notifications.  For

[    27.183] (II) NVIDIA(0):     details, please see the "ConnectToAcpid" and

[    27.183] (II) NVIDIA(0):     "AcpidSocketPath" X configuration options in Appendix B: X

[    27.183] (II) NVIDIA(0):     Config Options in the README.

[    27.223] (II) NVIDIA(0): Setting mode "DFP-0:nvidia-auto-select,DFP-2:nvidia-auto-select"

[    27.328] (==) NVIDIA(0): Disabling shared memory pixmaps

[    27.328] (==) NVIDIA(0): Backing store enabled

[    27.328] (==) NVIDIA(0): Silken mouse enabled

[    27.329] (==) NVIDIA(0): DPMS enabled

[    27.329] (II) NVIDIA(0): [DRI2] Setup complete

[    27.329] (II) NVIDIA(0): [DRI2]   VDPAU driver: nvidia

[    27.541] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=7 (/dev/input/event10)

[    27.541] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=8 (/dev/input/event11)

[    27.541] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=9 (/dev/input/event12)

[    27.541] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=3 (/dev/input/event9)

```

I wouldn't think that my nvidia-specific X settings would cause problems, but maybe they are invalid now:

```

# cat /etc/X11/xorg.conf.d/nvidia.conf 

Section "Device"

   Identifier   "nvidia"

   Driver      "nvidia"

   VendorName   "NVIDIA Corporation"

   BoardName   "GeForce GTX 470"

   Option      "TripleBuffer" "0"

   Option      "Coolbits" "12"

   Option      "RegistryDwords" "PowerMizerEnable=0x1; PowerMizerDefaultAC=0x3;"

EndSection

```

Thanks for your thoughts so far.

Cheers,

Nathan Zachary

----------

## dmpogo

Honestly speaking, if you are to use nvidia-drivers, it is better to disable all DRM support in the kernel completely.

Saying that, your opengl is indeed not provided by nividia but by MESA, so it will be slow.  Critical error is

[    26.678] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X

[    26.678] (EE) NVIDIA(0):     log file that the GLX module has been loaded in your X

[    26.678] (EE) NVIDIA(0):     server, and that the module is the NVIDIA GLX module.  If

[    26.678] (EE) NVIDIA(0):     you continue to encounter problems, Please try

[    26.678] (EE) NVIDIA(0):     reinstalling the NVIDIA driver.

[

----------

## Ionen

Configuration looks fine (seems to be discarding the RegistryDword but that should be just a warning).

The glx module is likely trying to use GL libraries and failing. If it's failing with libglvnd but not with eselect-opengl (Edit: may want to try to revert with USE=-libglvnd globally, if still broken could try to revert to stable -r1 drivers too), then my personal bets would be that the libglvnd support for 390 is broken unless someone else can confirm it works (I wouldn't say that normally, but as I said, it was added very recently and I'm not sure if really been tested beyond "it builds fine").

----------

## NathanZachary

@Ionen, those are good points.  I will do some further testing soon.  For now, the only bug that I can see related to the 390.x nvidia drivers and libglvnd is this one:

https://bugs.gentoo.org/711942

----------

## Ionen

Seen a similar report in #gentoo with 390.132-r2+libglvnd (glx failing to load, llvmpipe being used), can't confirm but does reinforce the possibility of it being a bug.

Edit: EGL apparently does work as expected, this looks xorg/glx-specific

----------

## NathanZachary

I did some further testing, but alas, still haven't been able to get GLX working with libglvnd and nvidia-drivers-390.x.  At first, I thought it may be that the nvidia GLX driver wasn't being loaded at all, and found the following locations for it:

```

/usr/lib64/libGLX_nvidia.so

/usr/lib64/extensions/nvidia/libglx.so

lrwxrwxrwx  1 root root    24 Mar 17 22:12 libGLX_nvidia.so -> libGLX_nvidia.so.390.132

lrwxrwxrwx  1 root root    24 Mar 17 22:12 libGLX_nvidia.so.0 -> libGLX_nvidia.so.390.132

```

along with some other nvidia drivers:

```

# ls -lh /usr/lib64/xorg/modules/drivers/

total 7.9M

-rwxr-xr-x 1 root root 109K Mar 17 22:15 modesetting_drv.so

-rw-r--r-- 1 root root 7.8M Mar 17 22:12 nvidia_drv.so

```

So, I tried overriding the module paths in my nvidia.conf:

```

# cat /etc/X11/xorg.conf.d/nvidia.conf 

Section "Files"

   ModulePath   "/usr/lib64/xorg/modules/"

   ModulePath   "/usr/lib64/extensions/nvidia/"

EndSection

Section "Device"

   Identifier   "nvidia"

   Driver      "nvidia"

   VendorName   "NVIDIA Corporation"

   BoardName   "GeForce GTX 470"

   Option      "TripleBuffer" "0"

   Option      "Coolbits" "12"

   Option      "RegistryDwords" "PowerMizerEnable=0x1; PowerMizerDefaultAC=0x3;"

EndSection

```

Manipulating the ModulePath generally resulted in a "No screens found" error, though, so I removed those directives.  I haven't yet found a way to further troubleshoot the error regarding the nvidia driver failing to initialise the GLX module:

```

[ 91296.570] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X

[ 91296.570] (EE) NVIDIA(0):     log file that the GLX module has been loaded in your X

[ 91296.570] (EE) NVIDIA(0):     server, and that the module is the NVIDIA GLX module.  If

[ 91296.570] (EE) NVIDIA(0):     you continue to encounter problems, Please try

[ 91296.570] (EE) NVIDIA(0):     reinstalling the NVIDIA driver.

```

I did try to rebuild nvidia-drivers, but that proved ineffective.

----------

## NathanZachary

Also, I found the components section of the nvidia-drivers README to be informative:

https://download.nvidia.com/XFree86/Linux-x86_64/390.132/README/installedcomponents.html

----------

## grooveman

This looks like the same exact issue I've been struggling with...

https://forums.gentoo.org/viewtopic-t-1114466-highlight-llvmpipe.html

Perhaps this is a bug...

----------

## Ionen

 *grooveman wrote:*   

> This looks like the same exact issue I've been struggling with...
> 
> https://forums.gentoo.org/viewtopic-t-1114466-highlight-llvmpipe.html
> 
> Perhaps this is a bug...

 Didn't look at your issues in depth but it's probably related bug #713546, if so may also want to see this post. Do be warned that this is more of a workaround and it may not play well with multi-gpu setups, unless you want to use only one GPU (if that's possible, not familiar those laptops). Basically workaround will load nvidia's glx module and be done with it much like eselect-opengl used to do.

I don't think it's possible to have a true fix for this given libglvnd support on 390.xx is only partial and nvidia probably will never fix it (support for 390 will also end completely at the end of 2022 much like 340 did recently). Afraid I don't have a solution to make a proper use of your laptop with offloading on current gentoo (hopefully someone else knows better).

----------

## grooveman

Holy cow, Ionen!

You nailed it!  I did as post #16 and #17 said to do in the bug, and it works!  Thank you!!

I was losing all hope there  :Smile: 

G

----------

## Ionen

Well, glad to hear it works  :Smile:  Honestly wasn't sure how it'd go on that setup.

----------

## Maf

The solution from https://forums.gentoo.org/viewtopic-p-8490710.html#8490710 fixed the problem for me as well (if only temporarily, we'll see...)

@OP: please mark topic as [SOLVED]

----------

## mrbassie

[quote="Ionen"] *grooveman wrote:*   

> unless you want to use only one GPU (if that's possible, not familiar those laptops). 

 

It is possible.

----------

## tld

Wow...Just starting to read about all this. My MythTV frontend needs the 390 drivers and the last thing I want is to break that. I see that my upcoming update uninstalls eselect opengl and is adding libglvnd to nvidia-drivers and mesa. Am I to understand that, with the removal of that eselect that this is the only option?

So I take is that, at least for now, this setup should be OK with the addition of that new /etc/X11/xorg.conf.d/nvidia.conf file?

Tom

EDIT: I currently have this file under /etc/X11/xorg.conf.d. I certainly never added that, and it doesn't appear to belong to any packages:

```
cat /etc/X11/xorg.conf.d/20opengl.conf 

Section "Files"

   ModulePath "/usr/lib/opengl/nvidia"

   ModulePath "/usr/lib/xorg/modules"

EndSection
```

Any idea what that is, and whether or not is should stay there with these changes? Thanks!

Tom

----------

## tld

One thing I can see right off regarding the suggested fix is that it's intended for 64-bit and this is an older 32-bit front and. I think this is probably what I want in that nvidia.conf file:

```
Section "OutputClass"

    Identifier "nvidia"

    MatchDriver "nvidia-drm"

    Driver "nvidia"

    Option "AllowEmptyInitialConfiguration"

    ModulePath "/usr/lib/opengl/nvidia"

EndSection
```

I'm not looking forward to rolling the dice with all this. I see that nvidia-drivers does have a "compat" USE to allow the non-GLVND library to be installed. Has the removal of that eselect made that option impossible?

Tom

----------

## Ionen

 *tld wrote:*   

> I currently have this file under /etc/X11/xorg.conf.d

 eselect changes aren't managed by portage given created at run time, so when you remove an eselect module it doesn't cleanup what's left behind unless it has its own postrm() cleanup function.

eselect opengl notably used:

```
ENV_FILE="${EROOT}/etc/env.d/000opengl"

XORGD_FILE="${EROOT}/etc/X11/xorg.conf.d/20opengl.conf"
```

Both can (and imo, should) be removed after switching to libglvnd.

Edit: USE=compat doesn't seem to do a whole lot looking at the ebuild and wasn't needed even with eselect-opengl, on newer nvidia-drivers it also no longer affect the GL library (only EGL). I imagine the option will just be removed in the future (I "think" it may have been there to use very old binaries and the like). That aside, if absolutely need to use non-libglvnd with gentoo you'll unfortunately be on your own.

----------

## Ionen

Also, looks like bug #713546 has finally reached a resolution so self-added workaround for module path should no longer be needed with >=nvidia-drivers-390.138-r2.

Edit: It also force-selects the nvidia driver given auto-detection may not be doing so well, likely removes the need for any user-made configuration at all.Last edited by Ionen on Tue Aug 25, 2020 6:22 pm; edited 2 times in total

----------

## tld

Thanks for the replies! I think you're correct and I have no choice but to go with all the new libglvnd stuff. One good sign is that I can add the above nvidia.conf to /etc/X11/xorg.conf.d with my existing setup and it at least doesn't break anything. I suspect that you're correct in that the existing 20opengl.conf probably should be removed after I upgrade. Thanks!

Tom

----------

## tld

 *Ionen wrote:*   

> Also, looks like bug #713546 has finally reached a resolution so self-added workaround for module path should no longer be needed with >=nvidia-drivers-390.138-r2.

 Wow...looking at the config file that r2 ebuild adds, I don't think that module path works for 32-bit systems...at least I sure have no such path:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cb335d5d9efcb79e99a8c8fc2fbce91610050bcd

I'll probably go with the above config and hope for the best. I'm not looking forward to rolling the dice with this one at all.

If this goes sideways on me and simply doesn't work, I'm not at all clear how/if I could revert any of this. Would recompiling with -libglvnd and emerging eselect-opengl even work?

Tom

----------

## Ionen

Hmm, if I install 390 I don't have that path either (on 64bit), the fix looks wrong for everyone.

This is supposed to be "/usr/lib64/extensions/nvidia" and in your case it'd likely be "/usr/lib/extensions/nvidia" not that I have a 32bit system to check.

Edit: Made a note of it in the bug, hopefully it'll be re-opened and revised. This comment #8 from all the way back to March with a patch mostly had it right and used $(get_libdir)  :Neutral:  Wish it had gotten some attention before the "libglvnd supporting" version of 390 was dumped still-broken into stable and this whole rushed removal process then forced people to use it (there's no real going back to non-libglvnd, flag is profile forced and things about to be removed -- and I doubt something sensible like temporarily reverting this for at least few months is going to happen).

----------

## tld

 *Ionen wrote:*   

> Hmm, if I install 390 I don't have that path either (on 64bit), the fix looks wrong for everyone.
> 
> This is supposed to be "/usr/lib64/extensions/nvidia" and in your case it'd likely be "/usr/lib/extensions/nvidia" not that I have a 32bit system to check.

 Here's all I can find...keeping in mind that I haven't updated yet...maybe the new stuff adds directories(??):

```
/usr/lib -type d | grep nvidia

/usr/lib/OpenCL/vendors/nvidia

/usr/lib/opengl/nvidia

/usr/lib/opengl/nvidia/lib

/usr/lib/opengl/nvidia/extensions
```

Does the fact that those all have opengl in the path possibly indicate that they may not be related to the new libglvnd setup, or is that still technically opengl?

 *Ionen wrote:*   

> 
> 
> Edit: Made a note of it in the bug, hopefully it'll be revised. This comment #8 from all the way back to March with a patch mostly had it right and used $(get_libdir)  Wish it had gotten some attention before the "libglvnd supporting" version of 390 was dumped still-broken into stable and this whole rushed removal process then forced people to use it (there's no real going back to non-libglvnd, flag is profile forced and things about to be removed -- and I doubt something sensible like temporarily reverting this for at least few months is going to happen).

 I absolutely HATE the way this has been handled. Add to the mix that I'm on 32bit and this one is scary as hell. I could literally end up having to go to my clonezilla backups...horrible.

Tom

----------

## Ionen

 *tld wrote:*   

> Here's all I can find...keeping in mind that I haven't updated yet...maybe the new stuff adds directories(??)

 It does, I had a look at the ebuild and there's this:

```
        if use libglvnd; then

            local extensions_dir="/usr/$(get_libdir)/extensions/nvidia"

        else

            local extensions_dir="/usr/$(get_libdir)/opengl/nvidia/extensions/"

        fi
```

So the above directory will exist when you build with USE=libglvnd.

----------

## Ionen

 *tld wrote:*   

> I absolutely HATE the way this has been handled.

 I do feel nvidia-drivers (or at least the older one) is in need of a new maintainer that actually use it. One mostly left the bug alone for months despite the proposed workaround, and the other trying to fix it in their place doesn't have the hardware to test the changes they're making  :Neutral:  While I guess I could've made a patch myself, since I don't use 390 either I didn't want to casually do that.

Edit: well, comment #32 at least sound more promising, hopefully sorts it out with testing included  :Smile: 

----------

## tld

Wow...not looking good here. There's still a recompile of one unrelated program finishing on that update, but I just tried my frontend after stopping it and reloading the nvidia kernel module. I get a desktop with this config in /etc/X11/xorg.conf.d/nvidia.conf:

```
Section "OutputClass"

    Identifier "nvidia"

    MatchDriver "nvidia-drm"

    Driver "nvidia"

    Option "AllowEmptyInitialConfiguration"

    ModulePath "/usr/lib/extensions/nvidia"

EndSection
```

However it uses almost the entire CPU doing anything at all...hopeless. Then I noticed that for some reason the nvidia-drm module wasn't loaded when it was before with the old driver and old setup. I see that compiling nvidia-drivers was warning me that the kernel didn't have CONFIG_DRM or CONFIG_DRM_KMS_HELPER. Apparently I never did and it didn't matter. I'm re-compiling the kernel with that now.

Unrelated stuff: I also ran into this one that you're familiar with: https://forums.gentoo.org/viewtopic-t-1110078-start-0.html

I just temporarily blocked that update to get around that. I also had the update to x11-libs/cairo-1.16.0-r4 fail and had to block that. The error was just this:

```
collect2: error: ld returned 1 exit status

make[4]: *** [Makefile:605: cairo-sphinx] Error 1

make[4]: Leaving directory '/var/tmp/portage/x11-libs/cairo-1.16.0-r4/work/cairo-1.16.0-abi_x86_32.x86/util/cairo-sphinx'

make[3]: *** [Makefile:1003: all-recursive] Error 1

make[3]: Leaving directory '/var/tmp/portage/x11-libs/cairo-1.16.0-r4/work/cairo-1.16.0-abi_x86_32.x86/util'

make[2]: *** [Makefile:780: all] Error 2

make[2]: Leaving directory '/var/tmp/portage/x11-libs/cairo-1.16.0-r4/work/cairo-1.16.0-abi_x86_32.x86/util'

make[1]: *** [Makefile:909: all-recursive] Error 1

make[1]: Leaving directory '/var/tmp/portage/x11-libs/cairo-1.16.0-r4/work/cairo-1.16.0-abi_x86_32.x86'

make: *** [Makefile:760: all] Error 2

 * ERROR: x11-libs/cairo-1.16.0-r4::gentoo failed (compile phase)
```

NOT happy with this so far. I'm hoping that DRM in the kernel will make a difference.

Tom

----------

## Ionen

Yeah the glapi issue only happen while switching as explained and is known to happen with cairo too, "properly" preventing it would be a large scale effort so I don't think that'll be fixed. But once switched it won't come back so it's not that bad, people doing smaller frequent world updates are less likely to hit it too.

I don't use DRM nor its config options, so I'm not sure if that can help (I don't load nvidia-drm either), and I believe DRM support was somewhat early stage in 390 too. I guess the OutputClass matching on nvidia-drm could be related though, not sure how these match exactly.

Is glx properly being used? Does `glxinfo | head` show NVIDIA and not something like llvmpipe? The latter would likely indicate the OutputClass wasn't used.Last edited by Ionen on Wed Aug 26, 2020 12:15 pm; edited 1 time in total

----------

## tld

 *Ionen wrote:*   

> Is glx properly being used? Does `glxinfo | head` show NVIDIA?

 Apparently not:

```
glxinfo | head

name of display: :0.0

display: :0  screen: 0

direct rendering: Yes

server glx vendor string: SGI

server glx version string: 1.4

server glx extensions:

    GLX_ARB_context_flush_control, GLX_ARB_create_context, 

    GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, 

    GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 

    GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile,
```

Should I post my entire X log? I do see one warning in there:

```
[   653.440] (WW) Warning, couldn't open module xtrap

[   653.440] (EE) Failed to load module "xtrap" (module does not exist, 0)
```

Not sure if that's significant.

Tom

----------

## Ionen

So no GLX initialization errors? (they would have (EE) in front)

If not I'm not quite what's happening here either  :Sad: 

Edit:

Maybe driver wasn't loaded at all and could use a simple Device section like:

```
Section "Device"

   Identifier  "nvidia"

   Driver      "nvidia"

EndSection
```

If already had one or didn't help, seeing the log anyway may give hints.

Edit2: Also, example of configuration for 390 that should be working here minus the lib64. I'm sure it's just something small and can get this working fine.Last edited by Ionen on Wed Aug 26, 2020 12:39 pm; edited 2 times in total

----------

## tld

 *Ionen wrote:*   

> So no GLX initialization errors? (they would have (EE) in front)
> 
> If not I'm not quite what's happening here either 
> 
> Edit:
> ...

 Yea...I have these:

```
[   653.458] (**) NVIDIA(0): Enabling 2D acceleration

[   653.458] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X

[   653.458] (EE) NVIDIA(0):     log file that the GLX module has been loaded in your X

[   653.458] (EE) NVIDIA(0):     server, and that the module is the NVIDIA GLX module.  If

[   653.458] (EE) NVIDIA(0):     you continue to encounter problems, Please try

[   653.458] (EE) NVIDIA(0):     reinstalling the NVIDIA driver.
```

My xorg.conf is very old, though I do have the "nvidia" driver for sure. Here's the Device section:

```
Section "Device"

        Identifier  "Card0"

        Driver      "nvidia"

        VendorName  "nVidia Corporation"

        BoardName   "GT 430"

        VideoRam    131072

        Option      "TripleBuffer" "True"

        Option      "NoLogo" "true"

        BusID       "PCI:1:0:0"

        Option  "Coolbits"      "1"

EndSection
```

Keep in mind that this was all working before.

Tom

----------

## Ionen

Yeah okay, that's "probably" the bug we've been going on about already then. I guess it's not picking up the ModulePath.

I guess "nvidia-drm" could have something to do with it given the outputclass match, I'm honestly not familiar with this whole matching system.

What happen if you set the modulepath globally, like:

```
Section "Files"

  ModulePath  "/usr/lib/extensions/nvidia"

EndSection
```

And the path does exist now right? Should have a libglx.so symlink + versioned library.

Edit: also did the nvidia-drivers install that bogus currently-broken nvidia-390.conf? I guess it could be conflicting too  :Neutral: 

----------

## tld

 *Ionen wrote:*   

> What happen if you set the modulepath globally, like:
> 
> ```
> Section "Files"
> 
> ...

 I'd actually just tried adding that to nvidia.conf file and it failed completely with "no screens found". THIS is ugly.

I'm actually recompiling the entire kernel now, only because I can't be sure that it wasn't built on gcc 9.2. I'm currently running gcc 9.3. Doubt that will help though.

EDIT: Yes by the way...that path is there now:

```
find /usr/lib/extensions/nvidia

/usr/lib/extensions/nvidia

/usr/lib/extensions/nvidia/libglx.so.390.138

/usr/lib/extensions/nvidia/libglx.so
```

Tom

----------

## tld

 *Ionen wrote:*   

> Edit: also did the nvidia-drivers install that bogus currently-broken nvidia-390.conf? I guess it could be conflicting too 

 No...all that's in that directory is my nvidia.conf.

Tom

----------

## Ionen

Hmm, would need to see the full log but I get the feeling that failing further with global path would mean nvidia driver didn't load at all after all. Rebuilding the kernel+drivers may in fact help, if in doubt rebuild libglvnd and xorg-server too just to be sure everything's fine (mesa doesn't matter).

----------

## tld

OMG...looks like I got it! In my config, instead of this:

```
Section "Files"

  ModulePath  "/usr/lib/extensions/nvidia"

EndSection
```

...as per this:

https://713546.bugs.gentoo.org/attachment.cgi?id=624156

...I used this in my config:

```
Section "Files"

  ModulePath  "/usr/lib/extensions/nvidia,/usr/lib/xorg/modules"

EndSection
```

...and GLX is working using nvidia...just wow.

Tom

----------

## Ionen

Ohh, I guess if using global section both paths are indeed needed unlike with OutputClass and that's why it was worse (my bad for not knowing). But I assume the OutputClass was indeed not matching then.

Well anyhow, glad to hear it works  :Smile: 

----------

## tld

 *Ionen wrote:*   

> Ohh, I guess if using global section both paths are indeed needed unlike with OutputClass and that's why it was worse (my bad for not knowing). But I assume the OutputClass was indeed not matching then.
> 
> Well anyhow, glad to hear it works 

 Thanks for the help! What's even more interesting is that, with that Files section above, apparently I don't need that OutputClass section at all! I just commented it out and still get nvidia GLX just fine. Confusing beyond words.

EDIT: Those failed upgrades all worked when run after the others...even that screwy ld error upgrading cairo. So that one was clearly some issue with the upgrade order.

Tom

----------

## Ionen

 *tld wrote:*   

> Those failed upgrades all worked when run after the others...even that screwy ld error upgrading cairo. So that one was clearly some issue with the upgrade order.

 libglvnd+nvidia can be considered a mesa alternative (nvidia provides libraries, and libglvnd the headers), making mesa hardly relevant.

When ebuilds need EGL/GLES/etc.. they usually depend on mesa directly, and for GL either mesa or more usually virtual/opengl (which is mostly just mesa too but could be updated), and thus portage doesn't think nvidia-drivers matters and opt to rebuild it last.

But now we have >300 ebuilds that depend on mesa, >700 for virtual/opengl. For what I think would be a complete+proper fix all of those would need a virtual to alternatively depend on libglvnd+nvidia-drivers, and preferably be tested to see if they build with _just_ those and no mesa installed (then mesa could be depcleaned even, I mean I did build mesa-progs with egl/gles2/gl .. without mesa). I don't think that's gonna happen  :Confused:  And now that eselect-opengl is going away, less people will be switching anyway so the issue will just be swept under the rug. Could always make more workarounds like xorg-server did but that'll probably just make things worse (that blocker caused a lot of nonsense), so unless go all out might as well leave it alone and help users that run into it directly.

That aside, xorg-server does need 1 single header file from mesa (that could be made optional with some work), so don't try removing mesa at home  :Smile: 

----------

## tld

Yea...I thought I saw mention that in theory mesa was irrelevant with this. Sounds like quite a complex mess around that.

Tom

----------

