| Summary: | x11-misc/bumblebee depends on libglvnd use flags | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Kete Tefid <ketetefid> |
| Component: | Current packages | Assignee: | Pacho Ramos <pacho> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | hhfeuer, jstein, ketetefid, main.haarp, mihais23, pacho, proxy-maint, rei4dan, remy, Xeha |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Kete Tefid
2020-04-10 10:43:27 UTC
Thank you for the report. Please explain what you found out regarding the use flags. We need to have all information at hand before ticket assignment. That is why I ask you to * attach the logs and * paste the emerge info as described on https://wiki.gentoo.org/wiki/Attach_the_logs_to_the_bug_ticket Please reopen this ticket (Status:UNCONFIRMED) afterwards. This bug is not about a failed emerge, it is about how an enabled use flag, i.e. libglvnd breaks optirun/primusrun that are installed by x11-misc/bumblebee and x11-misc/primus. The mentioned packages compile just fine. It is the libglvnd flag that breaks the functionality of primusrun and optirun. As I already mentioned, this means whenever one wants to offload the task to the discrete GPU by using optirun or primusrun, the following error occurs: primus: fatal: failed to load any of the libraries: /usr/lib64/opengl/nvidia/lib/libGL.so.1:/usr/lib32/opengl/nvidia/lib/libGL.so.1:/usr/lib/opengl/nvidia/lib/libGL.so.1 When the system is built without libglvnd, primusrun and optirun work as intended. In fact, if we want to enable libglvnd flag, we need to take care of x11-misc/bumblebee and x11-misc/primus so that they will work while media-libs/libglvnd is present. Please let me know if you need more information. (In reply to Kete Tefid from comment #2) Maybe som info to shed some light on this: The move to libglvnd was taken (among other things) to enable proper render offload using the nvidia drivers to get rid of bumblebee. Regarding bumblebee, the primus-bridge is defunct anyway for nvidia drivers >418 due to removal of the non-glvnd compat libs. So for current nvidia-drivers, you'll have to switch to the virtual-gl bridge. Bumblebee is only still relevant for nvidia legacy users (driver 390). I actually don't know if the 390 drivers still use -libglvnd. Maybe this could be some kind of legacy support since 390 users don't have that much advantage from using libglvnd. Which nvidia-drivers version are you using? Glancing at the ebuilds, it looks like the primus/bumblebee ebuilds are setting paths, so need to be remerged after switching to libglvnd. (In reply to Maik from comment #3) > The move to libglvnd was taken (among other things) to enable proper render > offload using the nvidia drivers to get rid of bumblebee. You can't get rid of Bumblebee yet, because the use case of external displays hooked up on the Nvidia (as is common among laptops from Lenovo and others) is not covered by libglvnd. The Nvidia driver does not support reverse Prime. There's the option of doing this using intel-virtual-output and Bumblebee tho. Doesn't change the fact that the primus-bridge is dead anyway with current drivers, the rest of bumblebee still works. Not talking about the state of xf86-video-intel. So, again, which driver version are you using, maybe there could be some solution found so all users of hybrid graphics are happy with? (In reply to Maik from comment #3) > (In reply to Kete Tefid from comment #2) > Maybe som info to shed some light on this: > The move to libglvnd was taken (among other things) to enable proper render > offload using the nvidia drivers to get rid of bumblebee. > Regarding bumblebee, the primus-bridge is defunct anyway for nvidia drivers > >418 due to removal of the non-glvnd compat libs. So for current > nvidia-drivers, you'll have to switch to the virtual-gl bridge. Thanks for the info. It seems that still the primus backend works as I have it setup with the latest nvidia-drivers without libglvnd (see the end of comment), I might be wrong though. > Bumblebee is only still relevant for nvidia legacy users (driver 390). > I actually don't know if the 390 drivers still use -libglvnd. Maybe this > could be some kind of legacy support since 390 users don't have that much > advantage from using libglvnd. > > Which nvidia-drivers version are you using? I am using the latest stable one currently 440.64 > > Glancing at the ebuilds, it looks like the primus/bumblebee ebuilds are > setting paths, so need to be remerged after switching to libglvnd. I have done this to no avail. (In reply to haarp from comment #4) > (In reply to Maik from comment #3) > > The move to libglvnd was taken (among other things) to enable proper render > > offload using the nvidia drivers to get rid of bumblebee. > > You can't get rid of Bumblebee yet, because the use case of external > displays hooked up on the Nvidia (as is common among laptops from Lenovo and > others) is not covered by libglvnd. The Nvidia driver does not support > reverse Prime. There's the option of doing this using intel-virtual-output > and Bumblebee tho. You are exactly right as I have to rely on it on my Thinkpad P52. (In reply to Maik from comment #5) > Doesn't change the fact that the primus-bridge is dead anyway with current > drivers, the rest of bumblebee still works. > Not talking about the state of xf86-video-intel. > > So, again, which driver version are you using, maybe there could be some > solution found so all users of hybrid graphics are happy with? If it is dead, what solution should we take as an acceptable way instead of relying on primusrun or optirun to offload to the GPU? (so that if this libglvnd thing is the trend, we can adapt to it) emerge -pv nvidia-drivers mesa xorg-server These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/mesa-19.3.5::gentoo USE="X classic dri3 egl gallium gbm gles2 llvm vaapi vdpau -d3d9 -debug -gles1 -libglvnd -lm-sensors -opencl -osmesa -pax_kernel (-selinux) -test -unwind -valgrind -vulkan -vulkan-overlay -wayland -xa -xvmc" ABI_X86="32 (64) (-x32)" VIDEO_CARDS="i965 intel (-freedreno) -i915 -iris (-lima) -nouveau (-panfrost) -r100 -r200 -r300 -r600 -radeon -radeonsi (-vc4) -virgl (-vivante) -vmware" 0 KiB [ebuild R ] x11-base/xorg-server-1.20.7:0/1.20.7::gentoo USE="ipv6 suid udev xorg -debug -dmx -doc -elogind -kdrive -libglvnd -libressl -minimal (-selinux) -static-libs -systemd -unwind -wayland -xcsecurity -xephyr -xnest -xvfb" 0 KiB [ebuild R ] x11-drivers/nvidia-drivers-440.64:0/440::gentoo USE="X acpi compat driver gtk3 kms multilib static-libs tools uvm -libglvnd -wayland" ABI_X86="32 (64) (-x32)" 0 KiB The relevant info from /etc/bumblebee/bumblebee.conf [optirun] # Acceleration/ rendering bridge, possible values are auto, virtualgl and # primus. Bridge=primus # The method used for VirtualGL to transport frames between X servers. # Possible values are proxy, jpeg, rgb, xv and yuv. VGLTransport=proxy # List of paths which are searched for the primus libGL.so.1 when using # the primus bridge PrimusLibraryPath=/usr/lib/primus:/usr/lib32/primus # Should the program run under optirun even if Bumblebee server or nvidia card # is not available? AllowFallbackToIGC=false And the primus bridge is still working with the latest drivers. (In reply to Maik from comment #5) > So, again, which driver version are you using, maybe there could be some > solution found so all users of hybrid graphics are happy with? In my case, nvidia-drivers-440.59. In any case, until Nvidia supports reverse Prime (and they've made no indication that they're planning to), there simply isn't a satisfactory solution when external monitors are involved. On older hardware, you can run modesetting on the Intel and nouveau on the Nvidia. This works, but of course nouveau's rendering performance is abysmal. On newer hardware, you have to run Nvidia's driver on the Nvidia. Either run X directly on the Nvidia card, and lose the ability to switch it off. Or use intel-virtual-output via Bumblebee, which is low-performance and buggy, but still the best compromise. I'm really astonished that the primus bridge still works for you without the compat libs. Let's assume it does. the error primus: fatal: failed to load any of the libraries: /usr/lib64/opengl/nvidia/lib/libGL.so.1:/usr/lib32/opengl/nvidia/lib/libGL.so.1:/usr/lib/opengl/nvidia/lib/libGL.so.1 obviously still uses the old eselect paths which come from the primus ebuild: export PRIMUS_libGLa='/usr/$$LIB/opengl/nvidia/lib/libGL.so.1' so this should be changed, can you check if the primusbridge works when you set the export to the correct path manually? As a sidenote, nvidia already said they're looking into supporting the needed PRIME output sink capability. For some historical laughs, some time ago I came across a post from an nvidia dev from the early time of PRIME development on xork mailing list where he asked if anyone was interested in them implementing also the output sink and nobody cared to say 'yes'. (In reply to Maik from comment #5) > Doesn't change the fact that the primus-bridge is dead anyway with current > drivers, the rest of bumblebee still works. > Not talking about the state of xf86-video-intel. > > So, again, which driver version are you using, maybe there could be some > solution found so all users of hybrid graphics are happy with? https://github.com/amonakov/primus/issues/206#issuecomment-529549399 Seems like it should still work, with some workarounds Additionally, looks like we have https://github.com/felixdoerre/primus_vk in the works which we can look into. OK, I was not able to have access to a Gentoo machine with GLVND enabled, so I made a backup and continued testing on my own production laptop. In order to make primusrun work with GLVND two changes are required. The first: export __GLVND_DISALLOW_PATCHING=1 Another change was to make it point to the correct libraries with: export PRIMUS_libGLa='/usr/$LIB/libGL.so.1' I did some testing and primus seems to work fine. The first export command is not necessary for optirun (which is a part of bumblebee package) but the performance is awful relative to primus (over 2.5x increase with primus). So with these changes, primusrun and bumblebee will continue working with GLVND. Are there other implications? All in all, GLVND is a cool feature, however, most machines cannot rely on it as a replacement of bumblebee: - As stated by @haarp in some machines like Lenovo Thinkpad W & P series the HDMI and display ports are hardwired to the Nvidia chip and GLVND cannot work in reverse prime. - GLVND cannot completely turn off cards prior to Turing architecture, so those devices will see increase power consumption and worse battery life. Any card that is not Turing based will be put to the lowest state of power but not completely turned off. At this point, I am not sure what is the exact benefit of GLVND if it only helps very new cards like Nvidia RTX ones. This is while the state of hybrid graphics is only relevant in laptops and in those machines battery runtime is important. Sure the implementation is cool by itself, but what extra usability does it provide? It would be cool if a developer, or a person with knowledge of GLVND gives us information on this. Kete Tefid, you're confusing things which results in comparing apples to oranges. GLVND just makes it possible that different OpenGL implementations (mesa,nvidia,...) can now reside side by side instead of having some more or less crude method (eselect opengl, LD_PRELOAD,...) to manually switch between them. Bumblebee just starts an Xserver, it doesn't care for glvnd. In contrary, glvnd even helps for a much simpler bumblebee config since no extra library paths for client GL and GLX have to be set up. Same goes for VirtualGL. Obviously, primus is the same, it previously needed the export for the path to the nvidia libraries. With glvnd, this is not necessary anymore. Though I'm really anstonished that primus is actually working with glvnd enabled libs since it achieves its speed by some deep hack. Doesn't seem to be the case (anymore) so just the ebuild has to be changed. What you're really thinking of is bumblebee/primus vs. PRIME render offload. GLVND is just a prerequisite for that. What's the advatage of PRIME render offload over bumblebee? Simple: less overhead, maximum performance. You're asking for faster horses, I'd rather have a car. (In reply to Maik from comment #13) > Kete Tefid, you're confusing things which results in comparing apples to > oranges. > GLVND just makes it possible that different OpenGL implementations > (mesa,nvidia,...) can now reside side by side instead of having some more or > less crude method (eselect opengl, LD_PRELOAD,...) to manually switch > between them. > Bumblebee just starts an Xserver, it doesn't care for glvnd. In contrary, > glvnd even helps for a much simpler bumblebee config since no extra library > paths for client GL and GLX have to be set up. Same goes for VirtualGL. > Obviously, primus is the same, it previously needed the export for the path > to the nvidia libraries. With glvnd, this is not necessary anymore. > Though I'm really anstonished that primus is actually working with glvnd > enabled libs since it achieves its speed by some deep hack. Doesn't seem to > be the case (anymore) so just the ebuild has to be changed. > > What you're really thinking of is bumblebee/primus vs. PRIME render offload. > GLVND is just a prerequisite for that. > What's the advatage of PRIME render offload over bumblebee? Simple: less > overhead, maximum performance. > You're asking for faster horses, I'd rather have a car. Thanks for the explanation. Yes, I should have chosen the wording better by comparing PRIME offloading (with the use of GLVND) vs. bumblebee+primus. So the main advantage would be the speed increase which is very desirable, of course. Another item that is needed by (GLVND-enabled) PRIME offloading is use of the modesetting drivers instead of xf86-video-intel. Unfortunately, while being newer, it has some bugs that need to be ironed out (like increased power consumption after wake up from suspend/hibernate). Also, it is another block for those devices where Nvidia is wired to the output ports (which needs intel driver instead of modesetting). The lack of graphics output for some laptops and the inability of completely shutting down the discrete card will be a deal breaker for some people. However, those with newer setups will enjoy the faster implementation. Some feedback: I finally moved to GLVND + bbswitch only. The performance on prime offloading relative to primus and bumblebee was around 20% more for some games and CUDA applications I tested (I was expecting better performance though). Right now, I have to restart X for changing the implementation which is something I have accepted to do for the rest of life of this machine, in order to have a cleaner setup with the improved performance as the bonus. I created a solution for myself adopted from https://github.com/openSUSE/SUSEPrime. I think it can be a fair substitute for a bumblebee setup and it would be great if Gentoo provided something like that. |
