Made obsolete by libglvnd.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=23dc0bb21d5e0c00b0274cdcc2d1f19fbfd474fa commit 23dc0bb21d5e0c00b0274cdcc2d1f19fbfd474fa Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2020-08-11 21:35:51 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-08-11 23:24:24 +0000 profiles: Mask app-eselect/eselect-opengl for removal Bug: https://bugs.gentoo.org/728286 Signed-off-by: Matt Turner <mattst88@gentoo.org> profiles/package.mask | 5 +++++ 1 file changed, 5 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0820792c9b5e8ca898167fa0c94a24ec7f4efbb4 commit 0820792c9b5e8ca898167fa0c94a24ec7f4efbb4 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2020-08-11 21:34:13 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-08-11 23:24:24 +0000 profiles: use.force USE=libglvnd Bug: https://bugs.gentoo.org/728286 Signed-off-by: Matt Turner <mattst88@gentoo.org> profiles/base/use.force | 5 +++++ 1 file changed, 5 insertions(+)
Shouldn't this also depend on #713546? I'm still on the 390 series driver, and it seems that glvnd support is somewhat broken on 390 series drivers. Without a new nvidia-drivers 390 release that implements the patch described in #713546, 390-series users are out of lock.
(In reply to Jan Seeger from comment #2) > Shouldn't this also depend on #713546? > I'm still on the 390 series driver, and it seems that glvnd support is > somewhat broken on 390 series drivers. > Without a new nvidia-drivers 390 release that implements the patch described > in #713546, 390-series users are out of lock. It should have, but I forgot about that bug. Fortunately, NVIDIA has suggested a config file solution, so I don't expect the bug to remain unresolved for long.
Why it was done? libglvnd is a wrapper with additional overhead for CPU, memory and storage. Many users with single graphical adapted (especially with small singleboard computers) may prefer to use GL calls directly, without wrapper. libglvnd require locking for many functions, so it could slowdown graphical operations.
(In reply to Karlson2k from comment #4) > Why it was done? > libglvnd is a wrapper with additional overhead for CPU, memory and storage. > Many users with single graphical adapted (especially with small singleboard > computers) may prefer to use GL calls directly, without wrapper. > libglvnd require locking for many functions, so it could slowdown graphical > operations. Basically none of that is true. libglvnd is shipped as part the downloadable nvidia-drivers. Do you think they would add an extra wrapper with lots of overhead to their proprietary drivers? Rhetorical question...
Sorry for the spam, but could you please add #713546 to the "depends on"? I worry this may be forgotten, borking my system in the process, and I can't do it myself.
(In reply to Matt Turner from comment #5) > (In reply to Karlson2k from comment #4) > > Why it was done? > > libglvnd is a wrapper with additional overhead for CPU, memory and storage. > > Many users with single graphical adapted (especially with small singleboard > > computers) may prefer to use GL calls directly, without wrapper. > > libglvnd require locking for many functions, so it could slowdown graphical > > operations. > > Basically none of that is true. > > libglvnd is shipped as part the downloadable nvidia-drivers. Do you think > they would add an extra wrapper with lots of overhead to their proprietary > drivers? Rhetorical question... but not all most recent downloadable nvidia-drivers support the libglvnd USE flag. here a dell d630 with NV135 card, nouveau driver not work for X11(seems use nv86 driver for nv135), and only with nvidia-drivers-340.108-r1 driver support, all works well. the driver nvidia-drivers-340.108-r1 has been out of support for months, with kernel 5.5 as the most recent kernel version supported, with kernel 5.5 out of portage, long term kernel 5.4 is the most recent kernel version supported. to use the nvidia-drivers-340.108-r1 which does not support libglvnd USE flag, and which blocks mesa and xorg-server that forced to use libglvnd, libglvnd USE flag need not be forced. and the eselect-opengl pkg should not be removed from the portage
(In reply to Matt Turner from comment #5) > libglvnd is shipped as part the downloadable nvidia-drivers. Do you think > they would add an extra wrapper with lots of overhead to their proprietary > drivers? Rhetorical question... If someone did something it doesn't mean that something is reasonable or good choice, especially in other situations. libglvnd is several megabytes, it is definitely not a "thin layer". And it has internal locking of resources, which may produce even worse negative impact. Why not to give people a choice?
While I second the comment that libglvnd should not be forced (even if the alternative is "you can only install one GL implementation at a time"), I ran a local OpenGL test suite and found no significant difference in runtime: -libglvnd r=0m21.188s u=0m13.474s s=0m3.570s r=0m21.167s u=0m13.519s s=0m3.548s r=0m21.211s u=0m13.523s s=0m3.555s r=0m21.208s u=0m13.480s s=0m3.501s r=0m21.107s u=0m13.520s s=0m3.525s +libglvnd r=0m21.235s u=0m13.457s s=0m3.558s r=0m21.197s u=0m13.486s s=0m3.542s r=0m21.213s u=0m13.576s s=0m3.518s r=0m21.122s u=0m13.506s s=0m3.545s r=0m21.191s u=0m13.539s s=0m3.486s So it seems the concerns about performance, at least, are misplaced.
(In reply to Andrew Church from comment #9) > While I second the comment that libglvnd should not be forced (even if the > alternative is "you can only install one GL implementation at a time"), I > ran a local OpenGL test suite and found no significant difference in runtime: > [....] > So it seems the concerns about performance, at least, are misplaced. Did you run tests in multithread mode? How many threads were used? I saw comparison of performance of Intel graphics with modesetting driver and Intel driver. In most tests the difference was about 2-3%, but in some tests the difference was hundreds of times. Maybe some tricky but real case will demonstrate significant difference with/without libglvnd?
(In reply to Karlson2k from comment #10) > Did you run tests in multithread mode? How many threads were used? The tests run up to 8 threads in parallel. I grant that they're mostly behavior/correctness tests rather than stress tests and so they don't specifically attempt to cause mutex collisions, but I would expect at least a minor effect if there was any nontrivial overhead from libglvnd. > Maybe some tricky but real case will demonstrate significant difference > with/without libglvnd? Perhaps, but I don't have such a case to offer. From my viewpoint, the stronger argument against mandatory libglvnd is the risk of bugs in libglvnd itself, if not now then as OpenGL is extended in the future, and the (admittedly small, but not negligible) storage requirement for the installed files, given that the package offers no benefit to users with a single installed GPU. At any rate, that discussion is probably best reserved for another bug if the forced USE=libglvnd remains past removal of eselect-opengl.
Honestly guys, you're grasping at straws. No one has even claimed that there's a performance loss before. I'm not going to waste my time attempting to prove a negative. Andrew, thank you for running benchmarks -- but please don't waste your time either :) And complaints about the size of the package? Portage says its install directory is 6.7 MiB for multilib. Portage reports that the install directory of media-libs/mesa is 100.6 MiB for me with USE=libglvnd and 102.9 MiB without. Are you seriously advocating for keeping a bunch of complexity around so that you can avoid a 4% increase in disk space on your OpenGL implementation? I hope you don't use VIDEO_CARDS=radeonsi because it requires llvm and is 168 MiB on disk for me. I think we skipped denial, but I've seen anger and bargaining, so can we move on to the next stages of grief, preferably on to acceptance?
(In reply to Matt Turner from comment #12) > I think we skipped denial, but I've seen anger and bargaining, so can we > move on to the next stages of grief, preferably on to acceptance? I was actually thinking of going with "fork". https://github.com/achurch/noglvnd
(In reply to Matt Turner from comment #12) > Honestly guys, you're grasping at straws. > [...] > I think we skipped denial, but I've seen anger and bargaining, so can we > move on to the next stages of grief, preferably on to acceptance? Acceptance must be reasonable. What we have: Cons: 1. Enforcing libglvnd gives users less flexibility 2. Single GPU users (~97% on x86, ~100% on other arches) do not have any benefits from libglvnd. 3. libglvnd can cause problems with other software, which can be easily avoided by excluding libglvnd, but it's not possible with libglvnd enforced. 4. Future version of libglvnd may introduce additional compatibility problems. 5. Potential performance loss, now or in future. 6. More disk space consumption. More RAM consumption. Even a few megabytes of RAM could be important on embedded devices. Pros: 1. No need to maintain eselect-opengl 2. ??? Have I missed something?
commit 89f9953622c7bcd709c802cb21c2d0a86f9765d1 Author: Piotr Karbowski <slashbeast@gentoo.org> Date: 2020-09-12 22:38:20 +0200 app-eselect/eselect-opengl: tree clean. Signed-off-by: Piotr Karbowski <slashbeast@gentoo.org>
So removing this package makes the libglvnd USE flag untoggleable since turning it off pulls eselect-opengl in as a hard dependency. Which means that, if you need to run a pre-compiled program that doesn't have libglvnd support for whatever reason, now you can't without setting up a custom overlay and adding eselect-opengl back in... And all to save a few KB in the repository... Gee... Thanks guys... Why not leave this in until x11 and mesa drop support for non libglvnd compile options? Or update those packages that have libglvnd options to not depend on this one and let us muddle through on our own? This is kind of the worst possible design choice here... It's not like Gentoo is only used to run programs that are built from source on Gentoo.
I'm not sure what you're talking about, but we can use less snark and condescension. libglvnd supports and offers the same OpenGL ABI. There's no reason a binary application should not work with libglvnd.
(In reply to Matt Turner from comment #17) > I'm not sure what you're talking about, but we can use less snark and > condescension. > > libglvnd supports and offers the same OpenGL ABI. There's no reason a binary > application should not work with libglvnd. I've got a couple of pre-compiled QT 5.4 apps I'm supporting. If you try to use them with libglvnd, they segfault as soon as they try to initialize the GL stuff. Without libglvnd they work fine. So it's obviously not exactly the same. I am currently working with the developer to get them updated, and I can patch eselect-opengl back in until then, so it's not the end of the world. But is eselect-opengl really that much of a maintenance nightmare that it makes sense to force use of libglvnd when mesa and xorg have not chosen to do so and we still have a libglvnd USE flag? I mean, if it is, then sure, get rid of it. But maybe take the dependency on it out of the packages that have the libglvnd USE flag and insert a link to the documentation on how to do it manually into the package messages instead. Apologies for the snark. Spending 30 minutes tracking down why the libglvnd flag was on after a system update when it was set to be globally off put me in something of a grumpy mood.
Please maintain the backwards compatibility: emerge: there are no ebuilds to satisfy ">=app-eselect/eselect-opengl-1.0.9". (dependency required by "x11-drivers/nvidia-drivers-340.107-r1::gentoo" [installed]) (dependency required by "x11-base/xorg-drivers-1.20-r2::gentoo[video_cards_nvidia]" [ebuild]) (dependency required by "x11-base/xorg-server-1.20.8-r1::gentoo[xorg]" [ebuild]) (dependency required by "@selected" [set]) (dependency required by "@world" [argument]) My GPU is in a legacy driver only: # package.mask # The 343.22 NVIDIA driver will ignore this GPU. >=x11-drivers/nvidia-drivers-341.0.0
