| Summary: | x11-drivers/nvidia-drivers-390.132-r2 USE=libglvnd - (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X log file that the GLX module has been loaded ... | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Nathan Zachary (RETIRED) <NathanZachary> |
| Component: | Current packages | Assignee: | Jeroen Roovers (RETIRED) <jer> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bgo, dabbott, eugene.nikolaev, hjckr, jan.seeger, jstein, kroemmelbein, lander.ghekiere, lephilousophe, stefantalpalaru, stevee, wtt6 |
| Priority: | Normal | Keywords: | NeedPatch, PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://github.com/gentoo/gentoo/pull/17267 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 728288 | ||
| Attachments: |
emerge --info
Xorg.0.tar.gz Write Xorg configuration snippet adding missing path to ModulePath |
||
|
Description
Nathan Zachary (RETIRED)
2020-03-19 22:24:26 UTC
Created attachment 622914 [details]
emerge --info
Created attachment 622916 [details]
Xorg.0.tar.gz
Same issue as Nathan with x11-drivers/nvidia-drivers-390.132-r2 and the new libglvnd use flag.
# 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,
# 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.2
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.2
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.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
Just to validate that there wasn't some other update that caused this problem on my system, I reverted the relevant packages via the following procedure:
1. Set "-libglvnd" in /etc/portage/make.conf
2. emerge -C mesa xorg-server nvidia-drivers libglvnd
* Yes, there was probably a safer method here, but it easily avoided blocks
3. emerge -av mesa xorg-server nvidia-drivers
4. emerge -av @x11-module-rebuild
5. eselect opengl set nvidia
Resulting in the same package versions:
=media-libs/mesa-20.0.1-r1
=x11-base/xorg-server-1.20.7
=x11-drivers/nvidia-drivers-390.132-r2
and trading out =media-libs/libglvnd-1.3.1 for =app-eselect/eselect-opengl-1.3.1-r4
Now, X seems to be using the nvidia GLX module:
# glxinfo | grep -i render
direct rendering: Yes
OpenGL renderer string: GeForce GTX 470/PCIe/SSE2
GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth,
GL_KHR_robustness, GL_KTX_buffer_region, GL_NVX_conditional_render,
GL_NV_conditional_render, GL_NV_copy_depth_to_color, GL_NV_copy_image,
GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite,
GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted,
GL_KHR_robustness, GL_KTX_buffer_region, GL_NVX_conditional_render,
GL_NV_conditional_render, GL_NV_copy_depth_to_color, GL_NV_copy_image,
GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite,
GL_EXT_multisampled_render_to_texture,
GL_EXT_multisampled_render_to_texture2, GL_EXT_occlusion_query_boolean,
GL_EXT_render_snorm, GL_EXT_robustness, GL_EXT_sRGB,
GL_NV_blend_equation_advanced, GL_NV_conditional_render,
GL_NV_packed_float_linear, GL_NV_path_rendering,
GL_OES_fbo_render_mipmap, GL_OES_geometry_point_size,
# glxinfo | grep -i opengl
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 470/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 390.132
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 390.132
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 390.132
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
# glxinfo | grep -i nvidia
server glx vendor string: NVIDIA Corporation
client glx vendor string: NVIDIA Corporation
OpenGL vendor string: NVIDIA Corporation
OpenGL core profile version string: 4.6.0 NVIDIA 390.132
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL version string: 4.6.0 NVIDIA 390.132
OpenGL shading language version string: 4.60 NVIDIA
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 390.132
So it does seem related to libglvnd.
Cheers,
Nathan Zachary
Comment on attachment 622916 [details]
Xorg.0.tar.gz
You stored a single file in a tar archive? Why not compress it directly?
This difference between 390 and newer branches with USE=libglvnd might be relevant.
--- nvidia-drivers-390.132-r2.ebuild 2020-03-15 21:35:29.555564068 +0100
+++ nvidia-drivers-435.21-r1.ebuild 2020-03-10 09:22:44.185664097 +0100
@@ -302,13 +292,8 @@
doins ${NV_X11}/nvidia_drv.so
# Xorg GLX driver
- if use libglvnd; then
- local extensions_dir="/usr/$(get_libdir)/extensions/nvidia"
- else
- local extensions_dir="/usr/$(get_libdir)/opengl/nvidia/extensions/"
- fi
- donvidia ${NV_X11}/libglx.so.${NV_SOVER} \
- "${extensions_dir}"
+ donvidia ${NV_X11}/libglxserver_nvidia.so.${NV_SOVER} \
+ /usr/$(get_libdir)/xorg/modules/extensions
# Xorg nvidia.conf
if has_version '>=x11-base/xorg-server-1.16'; then
Main problem here is that 390 version isn't modular enough and still uses a full proprietary version of libglx on server side. Newest versions of nvidia-drivers use a libglxserver_nvidia module on server side that avoids to override the loaded libglx. I attach a patch to the current ebuild which adds NVidia libglx path to the Xorg module search path. Created attachment 624156 [details, diff]
Write Xorg configuration snippet adding missing path to ModulePath
Hello, When I tried apply patch from above, I got an error: * Applying nvidia-glx.patch ... can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- /usr/portage/x11-drivers/nvidia-drivers/nvidia-drivers-390.132-r2.ebuild 2020-03-17 18:31:12.426447691 +0100 |+++ nvidia-drivers-390.132-r2.ebuild 2020-03-22 09:48:09.399574792 +0100 -------------------------- No file to patch. Skipping patch. 2 out of 2 hunks ignored [ !! ] * ERROR: x11-drivers/nvidia-drivers-390.132-r2::gentoo failed (prepare phase): * patch -p1 failed with /etc/portage/patches/x11-drivers/nvidia-drivers-390.132-r2/nvidia-glx.patch * * Call stack: * ebuild.sh, line 125: Called src_prepare * environment, line 4152: Called default * phase-functions.sh, line 855: Called default_src_prepare * phase-functions.sh, line 920: Called __eapi6_src_prepare * environment, line 422: Called eapply_user * environment, line 1312: Called eapply '/etc/portage/patches/x11-drivers/nvidia-drivers-390.132-r2/nvidia-glx.patch' * environment, line 1282: Called _eapply_patch '/etc/portage/patches/x11-drivers/nvidia-drivers-390.132-r2/nvidia-glx.patch' The patch must be applied on the ebuild not through epatch_user mechanism @Phillipe, your patch (creating a nvidia-glx.conf which overwrites the "ModulePath") doesn't work with hybrid graphic systems like my Thingpad W520 with a build in intel and a discrete nvidia card. In my case i left the x11-drivers/nvidia-drivers-390.132-r2 as is and modified only the bumblebee.conf file in order to resolve the glx-problem. Cheers, Ralf (In reply to Ralf Elmering from comment #11) > @Phillipe, > your patch (creating a nvidia-glx.conf which overwrites the "ModulePath") > doesn't work with hybrid graphic systems like my Thingpad W520 with a build > in intel and a discrete nvidia card. > > In my case i left the x11-drivers/nvidia-drivers-390.132-r2 as is and > modified only the bumblebee.conf file in order to resolve the glx-problem. Is it safe to conclude that this is this a problem that cannot be fixed in the 390 branch at all (until Nvidia fix it in the libraries)? I.e. USE=libglvnd is broken in general for 390? I would say so. In post-390 drivers NVidia provides a Xorg server extension which is loaded aside Xorg libglx.so. In 390 and before, NVidia provides a replacement libglx.so which doesn't work with any non-NVidia implementations (namely Mesa). My patch just overrides the loading of the GLX extension like eselect does (without messing with symlinks though). I think that, for 390 branch, NVidia stopped halfway and provide a glvnd implementation with works client side but miss the part server side to be really useful. As 390 branch is in maintenance, I suppose it won't get a better support for this. (In reply to Philippe Valembois from comment #8) > Created attachment 624156 [details, diff] [details, diff] > Patch fixing the loading of NVidia libglx.so This patch has fixed the problem for me currently. Would greatly appreciate if this became in some capacity part of the main repo or could be applied outside of the repo. Patch applied to nvidia-drivers-390.138-r100 in my overlay: https://github.com/stefantalpalaru/gentoo-overlay I asked the libglvnd maintainer for guidance, and he suggested that nvidia-drivers should install an xorg.conf.d file. See https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/208#note_596647 Could someone give that a shot? (In reply to Matt Turner from comment #16) > I asked the libglvnd maintainer for guidance, and he suggested that > nvidia-drivers should install an xorg.conf.d file. See > https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/208#note_596647 > > Could someone give that a shot? I got rid of eselect-opengl and mesa in order to try installing the current 390.x driver with libglvnd. I then added the mentioned section to the end of my /etc/X11/xorg.conf.d/nvidia.conf file: # 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 "AllowUnofficialGLXProtocol" "1" Option "RegistryDwords" "PowerMizerEnable=0x1; PowerMizerDefaultAC=0x3" EndSection Section "OutputClass" Identifier "nvidia" MatchDriver "nvidia-drm" Driver "nvidia" Option "AllowEmptyInitialConfiguration" ModulePath "/usr/lib64/extensions/nvidia/" EndSection Thereafter, it seems to be working: # glxinfo | grep -i render direct rendering: Yes OpenGL renderer string: GeForce GTX 470/PCIe/SSE2 GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, GL_KHR_robustness, GL_KTX_buffer_region, GL_NVX_conditional_render, GL_NV_conditional_render, GL_NV_copy_depth_to_color, GL_NV_copy_image, GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite, GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted, GL_KHR_robustness, GL_KTX_buffer_region, GL_NVX_conditional_render, GL_NV_conditional_render, GL_NV_copy_depth_to_color, GL_NV_copy_image, GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite, GL_EXT_multisampled_render_to_texture, GL_EXT_multisampled_render_to_texture2, GL_EXT_occlusion_query_boolean, GL_EXT_render_snorm, GL_EXT_robustness, GL_EXT_sRGB, GL_NV_blend_equation_advanced, GL_NV_conditional_render, GL_NV_packed_float_linear, GL_NV_path_rendering, GL_OES_fbo_render_mipmap, GL_OES_geometry_point_size, # glxinfo | grep -i opengl OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 470/PCIe/SSE2 OpenGL core profile version string: 4.6.0 NVIDIA 390.138 OpenGL core profile shading language version string: 4.60 NVIDIA OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 4.6.0 NVIDIA 390.138 OpenGL shading language version string: 4.60 NVIDIA OpenGL context flags: (none) OpenGL profile mask: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 390.138 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions: Thanks for the update and proposed fix! Cheers, Nathan Zachary Comment on attachment 624156 [details, diff] Write Xorg configuration snippet adding missing path to ModulePath >--- /usr/portage/x11-drivers/nvidia-drivers/nvidia-drivers-390.132-r2.ebuild 2020-03-17 18:31:12.426447691 +0100 >+++ nvidia-drivers-390.132-r2.ebuild 2020-03-22 09:48:09.399574792 +0100 >@@ -171,10 +171,14 @@ > > if ! [ -f nvidia_icd.json ]; then > cp nvidia_icd.json.template nvidia_icd.json || die > sed -i -e 's:__NV_VK_ICD__:libGLX_nvidia.so.0:g' nvidia_icd.json || die > fi >+ >+ echo 'Section "Files"' > nvidia-glx.conf >+ echo " ModulePath \"/usr/$(get_libdir)/extensions/nvidia,/usr/$(get_libdir)/xorg/modules\"" >> nvidia-glx.conf What is /usr/$(get_libdir)/extensions/nvidia ? Looks like a typo or like it serves no purpose. >+ if use libglvnd; then >+ newins {,10-}nvidia-glx.conf >+ fi I wonder if it matters whether USE=libglvnd. Shouldn't it also work without the Nvidia Xorg module being actively used? All that the configuration snippet did was to add two paths to ModulePath, right? (In reply to Jeroen Roovers from comment #18) > I wonder if it matters whether USE=libglvnd. Shouldn't it also work without > the Nvidia Xorg module being actively used? All that the configuration > snippet did was to add two paths to ModulePath, right? Yes, I think we want to ignore that proposed solution and go with what's referenced in comments 16 and 17. Just FYI, the approach in the path is from Ubuntu packages. I may have just copied paths and adapted them without further thinking. IMO approach in comments #16/#17 and in #8 are similar, it's just a matter of adding a module path to the server. For the glvnd USE flag, I think it should be kept as hybrid graphics (comment #11) can't work with -390 and libglvnd because we have to replace libglx in Xorg server to make NVidia implementation work. In this case, libGLX (client-side) from Mesa doesn't work anymore because it can't find its matching server implementation (provided by glvnd). (In reply to Philippe Valembois from comment #20) > Just FYI, the approach in the path is from Ubuntu packages. > I may have just copied paths and adapted them without further thinking. > > IMO approach in comments #16/#17 and in #8 are similar, it's just a matter > of adding a module path to the server. > > For the glvnd USE flag, I think it should be kept as hybrid graphics > (comment #11) can't work with -390 and libglvnd because we have to replace > libglx in Xorg server to make NVidia implementation work. In this case, > libGLX (client-side) from Mesa doesn't work anymore because it can't find > its matching server implementation (provided by glvnd). Please suggest a config file that will allow that to work. I don't think there is one. Hence, the need to keep libglvnd USE flag around. Unsetting it let user choose the implementation he wants to use through eselect opengl. The recommendation from upstream is to use primusrun. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cb335d5d9efcb79e99a8c8fc2fbce91610050bcd commit cb335d5d9efcb79e99a8c8fc2fbce91610050bcd Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2020-08-25 17:12:58 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-08-25 17:42:45 +0000 x11-drivers/nvidia-drivers: Add xorg.conf file to set ModulePath Closes: https://bugs.gentoo.org/713546 Signed-off-by: Matt Turner <mattst88@gentoo.org> x11-drivers/nvidia-drivers/files/nvidia-390.conf | 7 +++++++ ...-drivers-390.138-r1.ebuild => nvidia-drivers-390.138-r2.ebuild} | 3 +++ 2 files changed, 10 insertions(+) I don't think the fix is right. It points to "/usr/lib/nvidia/xorg" but I installed 390 and that directory doesn't exist. Formerly suggested path was "/usr/lib64/extensions/nvidia" although probably also needs consideration for non-lib64 users. (In reply to Ionen Wolkens from comment #25) > although probably also needs consideration for non-lib64 users. Well, I think the old comment #8 had the right direction, generated a simple file with $(get_libdir) rather than a static one (minus not needing to specify both paths). Alternatively I guess the libglx.so{,.390.138} could be installed somewhere else if that's preferable. Currently defined by: if use libglvnd; then local extensions_dir="/usr/$(get_libdir)/extensions/nvidia" else local extensions_dir="/usr/$(get_libdir)/opengl/nvidia/extensions/" fi The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4b39ac5d997c6201aa3f3441f3a3dab040b9c281 commit 4b39ac5d997c6201aa3f3441f3a3dab040b9c281 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2020-08-26 05:31:05 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-08-26 05:32:11 +0000 x11-drivers/nvidia-drivers: Fix libdir Thanks to Ionen Wolkens for noticing the mistake. Bug: https://bugs.gentoo.org/show_bug.cgi?id=713546 Signed-off-by: Matt Turner <mattst88@gentoo.org> x11-drivers/nvidia-drivers/files/nvidia-390.conf | 2 +- ...ia-drivers-390.138-r2.ebuild => nvidia-drivers-390.138-r3.ebuild} | 5 ++++- 2 files changed, 5 insertions(+), 2 deletions(-) That's still wrong. Sorry maybe I should've put more emphasis on that the entire path was wrong, the libdir was just was an additional issue. It's installing the libglx.so module in /usr/<libdir>/extensions/nvidia/ as the ebuild snipplet from comment #26 shows. not /usr/<libdir>/nvidia/opengl/ I do think /usr/<libdir>/nvidia/xorg from the .conf file is a better location than extensions/nvidia, so changing where it installs could be considered as well. I give up. Someone with hardware, please write a damn patch that satisfies you. Well I don't either, I just built the thing and checked where it installed things. I don't think it's sorcery. I'm working on it. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=16721b5ac2192d993b6d9c743ce8244f1e90055e commit 16721b5ac2192d993b6d9c743ce8244f1e90055e Author: Stephan Hartmann <stha09@googlemail.com> AuthorDate: 2020-08-26 10:12:29 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-08-26 16:54:58 +0000 x11-drivers/nvidia-drivers: fix path to GLX module Tested with GeForce GTX 560 Ti Bug: https://bugs.gentoo.org/713546 Closes: https://github.com/gentoo/gentoo/pull/17267 Signed-off-by: Stephan Hartmann <stha09@googlemail.com> Signed-off-by: Matt Turner <mattst88@gentoo.org> x11-drivers/nvidia-drivers/files/nvidia-390.conf | 2 +- ...vidia-drivers-390.138-r3.ebuild => nvidia-drivers-390.138-r4.ebuild} | 0 2 files changed, 1 insertion(+), 1 deletion(-) |