Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
nvidia-drivers-390.x and libglvnd
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
NathanZachary
Moderator
Moderator


Joined: 30 Jan 2007
Posts: 2608

PostPosted: Thu Mar 19, 2020 3:30 am    Post subject: nvidia-drivers-390.x and libglvnd Reply with quote

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:

Code:

# 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:

Code:

# 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
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2884

PostPosted: Thu Mar 19, 2020 3:44 am    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
NathanZachary
Moderator
Moderator


Joined: 30 Jan 2007
Posts: 2608

PostPosted: Thu Mar 19, 2020 4:24 am    Post subject: Reply with quote

Looks like the driver is failing:

Code:

# 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:

Code:

# 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
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3458
Location: Canada

PostPosted: Thu Mar 19, 2020 4:31 am    Post subject: Reply with quote

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.
[
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2884

PostPosted: Thu Mar 19, 2020 4:57 am    Post subject: Reply with quote

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").
Back to top
View user's profile Send private message
NathanZachary
Moderator
Moderator


Joined: 30 Jan 2007
Posts: 2608

PostPosted: Thu Mar 19, 2020 5:25 am    Post subject: Reply with quote

@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
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2884

PostPosted: Thu Mar 19, 2020 7:01 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
NathanZachary
Moderator
Moderator


Joined: 30 Jan 2007
Posts: 2608

PostPosted: Thu Mar 19, 2020 6:02 pm    Post subject: Reply with quote

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:

Code:

/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:

Code:

# 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:

Code:

# 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:

Code:

[ 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.
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---
Back to top
View user's profile Send private message
NathanZachary
Moderator
Moderator


Joined: 30 Jan 2007
Posts: 2608

PostPosted: Thu Mar 19, 2020 6:05 pm    Post subject: Reply with quote

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
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---
Back to top
View user's profile Send private message
grooveman
Veteran
Veteran


Joined: 24 Feb 2003
Posts: 1217

PostPosted: Fri Aug 21, 2020 1:38 pm    Post subject: Reply with quote

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...
_________________
To look without without looking within is like looking without without looking at all.
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2884

PostPosted: Fri Aug 21, 2020 2:16 pm    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
grooveman
Veteran
Veteran


Joined: 24 Feb 2003
Posts: 1217

PostPosted: Fri Aug 21, 2020 2:44 pm    Post subject: Reply with quote

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 :)

G
_________________
To look without without looking within is like looking without without looking at all.
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2884

PostPosted: Fri Aug 21, 2020 2:46 pm    Post subject: Reply with quote

Well, glad to hear it works :) Honestly wasn't sure how it'd go on that setup.
Back to top
View user's profile Send private message
Maf
Guru
Guru


Joined: 15 May 2005
Posts: 310

PostPosted: Sun Aug 23, 2020 6:36 am    Post subject: Reply with quote

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]
Back to top
View user's profile Send private message
mrbassie
l33t
l33t


Joined: 31 May 2013
Posts: 826
Location: Go past the sign for cope, right at the sign for seethe. If you see the target you've missed it.

PostPosted: Sun Aug 23, 2020 6:00 pm    Post subject: Reply with quote

[quote="Ionen"]
grooveman wrote:
unless you want to use only one GPU (if that's possible, not familiar those laptops).


It is possible.
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1848

PostPosted: Tue Aug 25, 2020 1:11 pm    Post subject: Reply with quote

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:
Code:
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
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1848

PostPosted: Tue Aug 25, 2020 1:29 pm    Post subject: Reply with quote

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:
Code:
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
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2884

PostPosted: Tue Aug 25, 2020 5:53 pm    Post subject: Reply with quote

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:
Code:
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.
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2884

PostPosted: Tue Aug 25, 2020 6:17 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1848

PostPosted: Tue Aug 25, 2020 6:21 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1848

PostPosted: Wed Aug 26, 2020 1:35 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2884

PostPosted: Wed Aug 26, 2020 1:54 am    Post subject: Reply with quote

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) :| 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).
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1848

PostPosted: Wed Aug 26, 2020 2:52 am    Post subject: Reply with quote

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(??):
Code:
/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
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2884

PostPosted: Wed Aug 26, 2020 2:54 am    Post subject: Reply with quote

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:
Code:
        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.
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2884

PostPosted: Wed Aug 26, 2020 7:03 am    Post subject: Reply with quote

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 :| 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 :)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum