Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 728286 - app-eselect/eselect-opengl: Tree clean
Summary: app-eselect/eselect-opengl: Tree clean
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords: PMASKED
Depends on: 728288 728290 744715
Blocks: 342209 434956 508708 531842 534128 537686
  Show dependency tree
 
Reported: 2020-06-14 21:39 UTC by Matt Turner
Modified: 2020-10-12 22:00 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Turner gentoo-dev 2020-06-14 21:39:37 UTC
Made obsolete by libglvnd.
Comment 1 Larry the Git Cow gentoo-dev 2020-08-11 23:24:49 UTC
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(+)
Comment 2 Jan Seeger 2020-08-13 14:55:36 UTC
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.
Comment 3 Matt Turner gentoo-dev 2020-08-13 17:28:05 UTC
(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.
Comment 4 Karlson2k 2020-08-14 10:50:45 UTC
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.
Comment 5 Matt Turner gentoo-dev 2020-08-14 16:41:53 UTC
(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...
Comment 6 Jan Seeger 2020-08-21 09:33:26 UTC
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.
Comment 7 fkhp 2020-08-23 02:51:48 UTC
(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
Comment 8 Karlson2k 2020-08-24 07:17:11 UTC
(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?
Comment 9 Andrew Church 2020-08-24 11:43:56 UTC
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.
Comment 10 Karlson2k 2020-08-24 14:14:36 UTC
(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?
Comment 11 Andrew Church 2020-08-24 18:00:49 UTC
(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.
Comment 12 Matt Turner gentoo-dev 2020-08-25 19:21:42 UTC
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?
Comment 13 Andrew Church 2020-08-26 07:23:00 UTC
(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
Comment 14 Karlson2k 2020-08-27 10:32:09 UTC
(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?
Comment 15 Piotr Karbowski archtester Gentoo Infrastructure gentoo-dev Security 2020-09-12 20:43:17 UTC
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>
Comment 16 lperkins 2020-09-24 01:06:23 UTC
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.
Comment 17 Matt Turner gentoo-dev 2020-09-24 05:41:50 UTC
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.
Comment 18 lperkins 2020-09-24 17:41:57 UTC
(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.
Comment 19 WOLfgang Schricker 2020-10-12 22:00:17 UTC
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