Per discussion with x11@ libglvnd will be the only GL provider supported by ports.
The intent of this review is a request for comments, it won't go in until at least the next x11 meeting.
Details
Details
Diff Detail
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Comment Actions
I realize this all might be awkward for ancient nvidia-drivers (<=390, and it is awkward now with mesa-libs as the deps too), although we still do the hard link dance on them and should keep the weight of that complexity in those ports since they don't play nicely with multi-vendor setups. The ancient multi-vendor case should be handled by the nvidia-secondary-driver port for multi-vendor or the nvidia-driver-{304, 340, 390} hardlink icky for single vendor.
| Mk/Uses/gl.mk | ||
|---|---|---|
| 21 | ^ silly question [tm] -- do we really need to have such fine-grained USE_GL if everything is coming from graphics/libglvnd? | |
Comment Actions
Requires adjusting mesa-devel for missing libglvnd in GL_DEFAULT e.g.,
--- a/graphics/mesa-devel/Makefile +++ b/graphics/mesa-devel/Makefile @@ -65,9 +65,8 @@ OPTIONS_EXCLUDE_powerpc64= ${"${/usr/bin/ld:L:tA}"==/usr/bin/ld.lld:?LTO:} # LLV OPTIONS_EXCLUDE+= ${ARCH:Namd64:Ni386:Nx86_64:C/.+/anv i965 iris/} OPTIONS_EXCLUDE+= ${ARCH:Naarch64:Namd64:Ni386:Npowerpc64:Npowerpc64le:Nx86_64:C/.+/LIBUNWIND/} OPTIONS_EXCLUDE+= ${"${GL_DEFAULT:S/,/ /g:[-1]}"==${.CURDIR:T}:?COINST:} -OPTIONS_EXCLUDE+= ${"${GL_DEFAULT:S/,/ /g:[1]}"!=libglvnd:?GLVND:} OPTIONS_SLAVE+= ${"${GL_DEFAULT:S/,/ /g:[-1]}"!=${.CURDIR:T}:?COINST:} -OPTIONS_SLAVE+= ${"${GL_DEFAULT:S/,/ /g:[1]}"==libglvnd:?GLVND:} +OPTIONS_SLAVE+= GLVND OPTIONS_SUB= yes # Convert options to -D<type>-drivers=<driver1,driver2,etc>
| Mk/Uses/gl.mk | ||
|---|---|---|
| 17 | mesa-dri isn't handled by USE_GL yet, so use GL_DEFAULT directly. | |
| Mk/bsd.default-versions.mk | ||
| 55 | Adjust the comment GL_DEFAULT is no longer of tuple type. | |
| Mk/Uses/gl.mk | ||
|---|---|---|
| 21 | It's an interesting question. One thing this does do is provide a little bit of end to end check for the primary .so of each API since there is optionality within the libglvnd port. Although it seems the only one we expose from the underlying stacks is through OPTIONS X11, so we could just flatten this down to "gl" and "opengl" and go clean up all the consumers to use the right one. There are other foot guns around all this but the USE can provide a simple check and cognitive offload within the capabilities of the ports framework once we agree what we are trying to do | |
Comment Actions
Leave the variable for selecting libgbm until @jbeich can clarify how to handle this going forward.
Waiting for NVIDIA to convert libgbm.so into vendor-neutral loader for lib/dri/<vendor>_gbm.so. libgbm is currently ABI-tied to a particular Mesa version. Once vendor-neutral it can move into a separate package (e.g., libglvnd-gbm) in order to avoid pulling mesa-libs when only mesa-devel is desired. Before libmap.conf can be removed it's also necessary to abstract away mesa-dri because it depends on mesa-libs. OTOH, I didn't plan that far ahead because mesa-* ports are updated too infrequently.
DEFAULT_VERSIONS+=gl=mesa-devel are mainly used by @greg_unrelenting.technology (via DankBSD) and @evgeniy_khramtsov.org.
Comment Actions
Per discussion with x11@ libglvnd will be the only GL provider supported by ports.
Context missing; is there a log of the discussion?
Why would you want to remove an ability to build without libglvnd?
If there is a bug/regression in libglvnd, there would not be an easy way to link against mesa-{dri,devel} and check if an issue is libglvnd-related.
libglvnd does runtime dlopen(), it harms static linking, and the performance impact (of passing values around this library rather than linking to mesa-*) is not understood.
It may also harm HardenedBSD and/or "vm.imply_prot_max=1", because libglvnd does runtime patching (now optional):
https://gitlab.freedesktop.org/glvnd/libglvnd/-/commit/c1c60ac80aff5f8e788343ac902eb6959236411a
Also: https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/217#note_882796, what about RISC-V or any other obscure alt-arch with no asm code upstream?
libOpenGL might also become provided by something else in the future, no need to tie the graphics stack completely to this nvidia-made library, IMO.
Comment Actions
There is no direct log, PRs and reviews were used to record decisions or needs for discussion and this review is one of those results. If you want to join the next one it happens in 2 weeks.
Why would you want to remove an ability to build without libglvnd?
It's just an implementation decision and it hasn't been fully decided yet. There's a combinatorial explosion in ports with options and archs and everything else and we would prefer to support fewer options that benefit the most users by following the direction other freedesktop distros have gone. This is a pretty minor change for most users and developers, and there may be an increased support load by exposing options to people that tweak things without understanding them. Even now, there is increased friction on maintainers in supporting the tuple with build breakage if you turn off X11 (that we are fixing and that libglvnd helps with). I'd like to decrease friction, ultimately making mesa and mesa-devel play well together on the same system in time, because that is what upstream recommends.
If there is a bug/regression in libglvnd, there would not be an easy way to link against mesa-{dri,devel} and check if an issue is libglvnd-related.
This seems like pretty deep maintainer mode problems, I feel like anyone that is skilled enough to investigate issues here would know how to get through it. FreeBSD also has tools like boot environments that can be used to hack up the system for intense debugging sessions. On a scale of 1-10, how big of an issue is this to you?
libglvnd does runtime dlopen(), it harms static linking, and the performance impact (of passing values around this library rather than linking to mesa-*) is not understood.
On a scale of 1-10, how big of an issue is this to you? It seems to be a non-issue on popular Linux distros.
It may also harm HardenedBSD and/or "vm.imply_prot_max=1", because libglvnd does runtime patching (now optional):
We don't generally go out of the way to preempt issues for downstreams. HardenedBSD is welcome to influence this further in libglvnd and maybe submit a port OPTION to disable entrypoint patching.
https://gitlab.freedesktop.org/glvnd/libglvnd/-/commit/c1c60ac80aff5f8e788343ac902eb6959236411a
Also: https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/217#note_882796, what about RISC-V or any other obscure alt-arch with no asm code upstream?
Well, FreeBSD has a ways to go on RISC-V and the non-asm code can be used in research environments. The fact that it doesn't exist and that this is the default GL in major Linux distros tells me how big of an issue this is, and that it will probably get fixed by Linux users first if RISC-V becomes a popular graphical environment.
libOpenGL might also become provided by something else in the future, no need to tie the graphics stack completely to this nvidia-made library, IMO.
I thought of that as well, and nvidia might not always be the only organization with a different OpenGL implementation, but I think it's something we'd need to deal with as it comes. I suspect hypothetical vendors will want libglvnd dispatch for a variety of reasons.
Re nvidia-made library, that was a common sentiment in the past. The upstream contributor that helped me worked on intel and now google graphics. This is the direction freedesktop is going, and it will be helpful in mixing some combinations of mesa-lts and mesa-devel in the future. It's outgrown nvidia.
Comment Actions
PRs and reviews were used to record decisions or needs for discussion and this review is one of those results
While monitoring the FreeBSD-x11@, FreeBSD-desktop@, FreeBSD-multimedia@ and the FreeBSDDesktop gitter, I didn't see anything like "let's remove the ability to build without libglvnd".
Seems like this was discussed somewhere else, mind providing links to these discussions?
There's a combinatorial explosion in ports with options and archs and everything else
gl=* is related to DEFAULT_VERSIONS, I doubt that port maintainers QA any non-standard versions; it would not scale then. As it seems to me, it only makes sense to maintainers to test the two sets of options: *=on and *=off, to check for pkg-plist issues.
What kind of support burden do you imply? Currently, any tuple with mesa-devel is experimental (because mesa-devel is), leaving only libglvnd,mesa-dri and mesa-dri as tuples that port maintainers would want to QA; though as I mentioned, I doubt that gl=mesa-dri would be QA'ed due to maintainers not QA'ing any possible DEFAULT_VERSIONS. gl=mesa-dri (without libglvnd) is a non-default GL provider now; if some port would not build without libglvnd, then "patches are welcome", the same as with a non-default python or llvm/gcc version.
we would prefer to support fewer options that benefit the most users by following the direction other freedesktop distros have gone
I don't see the maintenance burden with leaving gl.mk as it is now. There has to be some other reason, like switching the ports tree to USE_GL=opengl where it can be done, so ports would lib-depend on GL library that does not have X11 symbols (you recently starting working on the experimental X11=off). There are downsides of *mandatory* libglvnd, with no ability to link ports directly to a mesa-* ports, and issues that come with runtime library opening rather than linking. For example, would it still be possible to use exploit mitigations that are harmed by runtime dlopen()? Cfi-icall comes to my head: https://www.freebsd.org/status/report-2018-09-2018-12.html#HardenedBSD-2018Q4-Update
"Please note that any application that calls function pointers resolved via dlopen + dlsym will require the cfi-icall scheme to be disabled."
Removing the ability to trivially test without libglvnd may backfire later, and it is not without issues itself: https://gitlab.freedesktop.org/glvnd/libglvnd#issues
"How should malloc(3) failures be handled?" "How should forking be handled?": would someone really want to build against this proprietary driver vendor hack in a custom poudriere make.conf set, if nvidia support was not a concern?
And also, "the direction of other freedesktop distros" seems to not be influenced by what users would want, but by what the sponsors like Red Hat want. Sometimes, unfinished software like PipeWire is being pushed to users; for example, it has hardcoded F32P (thus resampling in the majority of cases) for audio: https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/0.3.31/src/pipewire/impl-port.c#L603 https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/0.3.31/src/modules/module-protocol-pulse/module.c#L177 Libglvnd hack is pushed by hardware vendor to avoid breakage of their proprietary blob, IMO.
there may be an increased support load by exposing options to people that tweak things without understanding them
People will always tweak without understanding, should we get rid of DEFAULT_VERSIONS and many other customization options in the ports tree then?
there is increased friction on maintainers in supporting the tuple with build breakage if you turn off X11 (that we are fixing and that libglvnd helps with).
X11=off is mainly for headless setups, embedded device drivers that can't provide libGL (thus can't build with X11), and experiments/debloating. With the default libglvnd, there is now the gl.pc alias/hack to opengl.pc, which helps with libGL X11-only pkgconfig dependency, yes. X11=off without libglvnd implies absense of desktop OpenGL, software that requires desktop OpenGL symbols may not build; people who do that likely know what they do, and can be educated if needed.
ultimately making mesa and mesa-devel play well together on the same system in time
It is the case now, you are only removing the ability to have standalone mesa-d{ri,evel} without libglvnd here.
that is what upstream recommends
Citation needed.
I feel like anyone that is skilled enough to investigate issues here would know how to get through it
Would you want to patch ports just to get rid of libglvnd? Would patching scale for a full desktop if consumer ports make assumptions about libglvnd presence?
Would a user know git enough to create a custom branch and git rebase when needed?
It seems to be a non-issue on popular Linux distros
Many things are a non-issue for Linux, this is why some people use FreeBSD.
HardenedBSD is welcome to influence this further in libglvnd and maybe submit a port OPTION to disable entrypoint patching.
It likely would not end with the port option only, some consumer ports would need to be excluded from cfi-icall, which would harm the security of HardenedBSD desktop.
Note: I don't use HardenedBSD myself and can't test that.
the non-asm code can be used in research environments
The comment said that pure C dispatching does not work with the newer OpenGL extensions.
it will probably get fixed by Linux users first if RISC-V becomes a popular graphical environment
With the HiFive Unmatched coming, llvmpipe and a framebuffer will be the first things to get to the desktop.
Obscure alt-arches use the legacy SVG library via DEFAULT_VERSIONS now, so why can't libglvnd be optional as well?
this is the default GL in major Linux distros
What distros do that? I am aware that Gentoo links to libglvnd by default, no idea about other distros.
it will be helpful in mixing some combinations of mesa-lts and mesa-devel in the future
What kind of mixing do you imply? libglvnd with mesa-dri only, and libglvnd with mesa-devel only?
Now, by default, it is possible to mix both mesa-dri and mesa-devel by installing both of them and choosing via env(1).
On a scale of 1-10, how big of an issue is this to you?
2/10, I only provide feedback because I was pinged by jbeich. FYI, I now use gl=libglvnd,mesa-devel.
I may sound rude and/or annoyed, keep in mind that I am not.
Comment Actions
It was my first meeting. The last ~12 threads on freebsd-x11@ have the other results. This review is where further libglvnd work is being discussed, it seems to be working because here you are :). If you are good at note taking and social media there's plenty of room to help spread the good word on FreeBSD Desktops, neither are something I have any interest in.
There's a combinatorial explosion in ports with options and archs and everything else
What kind of support burden do you imply? Currently, any tuple with mesa-devel is experimental (because mesa-devel is), leaving only libglvnd,mesa-dri and mesa-dri as tuples that port maintainers would want to QA; though as I mentioned, I doubt that gl=mesa-dri would be QA'ed due to maintainers not QA'ing any possible DEFAULT_VERSIONS. gl=mesa-dri (without libglvnd) is a non-default GL provider now; if some port would not build without libglvnd, then "patches are welcome", the same as with a non-default python or llvm/gcc version.
Support burden includes interactions like this, and I don't mean that to say you are doing anything wrong, but it does have a cost. There are only so many hours in the day and my interest in volunteering is putting more wood behind less arrows.
we would prefer to support fewer options that benefit the most users by following the direction other freedesktop distros have gone
For example, would it still be possible to use exploit mitigations that are harmed by runtime dlopen()? Cfi-icall comes to my head: https://www.freebsd.org/status/report-2018-09-2018-12.html#HardenedBSD-2018Q4-Update
HardenedBSD is not FreeBSD. This falls into your "patches are welcome" above. My responsibility is to make FreeBSD work and fix issues within it.
And also, "the direction of other freedesktop distros" seems to not be influenced by what users would want, but by what the sponsors like Red Hat want. Sometimes, unfinished software like PipeWire is being pushed to users; for example, it has hardcoded F32P (thus resampling in the majority of cases) for audio: https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/0.3.31/src/pipewire/impl-port.c#L603 https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/0.3.31/src/modules/module-protocol-pulse/module.c#L177 Libglvnd hack is pushed by hardware vendor to avoid breakage of their proprietary blob, IMO.
I say this in jest with a friendly smile, a lot of this reads like someone teleporting from 2014 to tell someone in 2021 that nvidia will have a graphics hegemony. We all know. There are more tangible issues to me that you don't seem to weight properly such as common software now being able to use EGL contexts within X11, and a desire for multi-vendor GPUs of any variety because we have an exceptionally advanced interconnect called PCIe that allows one to do such things.
there may be an increased support load by exposing options to people that tweak things without understanding them
People will always tweak without understanding, should we get rid of DEFAULT_VERSIONS and many other customization options in the ports tree then?
Absolutely :). I'm just one contributor but more wood behind less arrows. I run FreeBSD main on ports main, and want to put more wood behind less arrows.
that is what upstream recommends
Citation needed.
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10557
this is the default GL in major Linux distros
What distros do that? I am aware that Gentoo links to libglvnd by default, no idea about other distros.
EL 8, OpenSUSE, Fedora, etc. We are pretty late to the party, it was starting to cause issues, I was embarrassed by the impasse and decided to fix it.
On a scale of 1-10, how big of an issue is this to you?
2/10, I only provide feedback because I was pinged by jbeich. FYI, I now use gl=libglvnd,mesa-devel.
I may sound rude and/or annoyed, keep in mind that I am not.
Sure, I appreciate your technical passion but I'll tell it to you straight from my perspective: the majority of this sounds like "what about this, what about that" and I am here to bias for action. If you are interested in getting in on the craft, start sending patches, I'll provide review and help shuttle them through the procedures and politics and mentor you for a bit. Jan posted technical review. Be more like Jan if you want me to take your position more seriously.
Comment Actions
Per discussion with x11@ libglvnd will be the only GL provider supported by ports.
Context missing; is there a log of the discussion?
There is no direct log, PRs and reviews were used to record decisions or needs for discussion
Seems like this was discussed somewhere else, mind providing links to these discussions?
It was my first meeting.
There is a lack of transparency here.
common software now being able to use EGL contexts within X11
mpv EGL surface/context creation can be tested via --hwdec=vaapi --vo=gpu for Intel (and AMD if its VA-API driver is installed), see:
https://lists.freebsd.org/archives/freebsd-x11/2021-June/000048.html
I can't trivially test Xorg, though the lack of reports of broken VA-API for mpv and Xorg suggests that mpv can work with EGL surfaces (and libglvnd did not fix EGL surface creation for mpv because it was not broken without libglvnd before). Maybe you mean multi-vendor EGL on X11 and/or other consumer? Is there any PR to reproduce this if not related to multi-vendor? I think you likely refer to some KDE-related ports that build with CMake: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246767#c21
the majority of this sounds like "what about this, what about that"
Informing about implications of changes is related to reviews. Port maintainers might consider the amount of work for downstreams like HardenedBSD, though the opinion of x11@ is clear. Upstream mesa amber/libglvnd plan was not referenced anywhere until now; thanks for posting references, it is now clear why you want to drop libglvnd-less mesa: providing needed mesa parts without libglvnd in future needs additional work in ports.
If you are interested in getting in on the craft, start sending patches
I do when I am interested; my interest area is non-standard Gentoo like setups/bleeding edge/experiments, likely of no use for the majority of users. I am currently on hiatus, and I want to return back with an efficient workflow set up before getting on the craft.
People will always tweak without understanding, should we get rid of DEFAULT_VERSIONS and many other customization options in the ports tree then?
Absolutely :)
I can't sense if it is sarcasm or not (it is 2021), but I wish it is.
Comment Actions
You're welcome to attend future meetings. I run them and have for a while now. Would you like me to send you an invite? We took notes in the past, but I've fallen down on that duty for a while. I can start again since there's no reason not to other than laziness on my part...
And nothing is set in stone here. If there's new information, like a reasonable use case, it's super easy to change direction. Since it was buried deep in the graphics stack, with no clear use case known at the time, the thought was the danger from it being an option and breaking things was larger than a speculative benefit. If there's an actual benefit, that would change things.
Comment Actions
Thanks, but I wouldn't take the invite because reasons, and this is likely also the case for other parties that may become interested in the content of meetings. Publishing some content of meetings would improve transparency, sure. Replying here because your question was here. Feel free to discuss meeting-related things using email if needed, this review is not the best place to discuss meetings or mentoring.
Comment Actions
There is no lack of transparency. X11 changes are discussed in a number of places, IRC, Gitter, mailing lists and on the bi-weekly call. This change was made a phabricator review just to facilitate discussions, and phabricator is the official FreeBSD code review tool.
common software now being able to use EGL contexts within X11
mpv EGL surface/context creation can be tested via --hwdec=vaapi --vo=gpu for Intel (and AMD if its VA-API driver is installed), see:
https://lists.freebsd.org/archives/freebsd-x11/2021-June/000048.html
I can't trivially test Xorg, though the lack of reports of broken VA-API for mpv and Xorg suggests that mpv can work with EGL surfaces (and libglvnd did not fix EGL surface creation for mpv because it was not broken without libglvnd before). Maybe you mean multi-vendor EGL on X11 and/or other consumer? Is there any PR to reproduce this if not related to multi-vendor? I think you likely refer to some KDE-related ports that build with CMake: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246767#c21the majority of this sounds like "what about this, what about that"
Informing about implications of changes is related to reviews. Port maintainers might consider the amount of work for downstreams like HardenedBSD, though the opinion of x11@ is clear. Upstream mesa amber/libglvnd plan was not referenced anywhere until now; thanks for posting references, it is now clear why you want to drop libglvnd-less mesa: providing needed mesa parts without libglvnd in future needs additional work in ports.
HardenedBSD is it's own project. We can't take that into account for changes to the FreeBSD ports tree.
In general, reducing the number of combinations of options reduces the number of combinations that needs to be tested and verified, and it also reduces the number of support cases that needs to be dealt with.
As has been pointed out here, and if you are following upstream, libglvnd seem to be the direction that upstream is taking, and several Linux distributions have already caught on. Not doing this in FreeBSD will only increase our support burden, since we will have to manage more of our graphics stack without upstream support, and over time, upstream will perhaps stop supporting using mesa without libglvnd entirely.
I still do not understand why this change is causing such a controversy.
Regards
Niclas
Comment Actions
Here is the draft update that will go out soon: https://github.com/freebsd/freebsd-quarterly/pull/361. Like @zeising I am a bit surprised by the volume of feedback here, because it's low level plumbing that will just work for most people. We could use some more interested people in this area. A lot of what I am citing or telling was learned through reading PRs, MRs, emailing, IRC and such so I don't think our aim is off the mark versus other projects (including for instance freedesktop itself) on this stack.
common software now being able to use EGL contexts within X11
mpv EGL surface/context creation can be tested via --hwdec=vaapi --vo=gpu for Intel (and AMD if its VA-API driver is installed), see:
https://lists.freebsd.org/archives/freebsd-x11/2021-June/000048.html
I can't trivially test Xorg, though the lack of reports of broken VA-API for mpv and Xorg suggests that mpv can work with EGL surfaces (and libglvnd did not fix EGL surface creation for mpv because it was not broken without libglvnd before). Maybe you mean multi-vendor EGL on X11 and/or other consumer? Is there any PR to reproduce this if not related to multi-vendor? I think you likely refer to some KDE-related ports that build with CMake: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246767#c21
Yes KDE and Firefox are two major software that will be in tree soon.
Informing about implications of changes is related to reviews. Port maintainers might consider the amount of work for downstreams like HardenedBSD, though the opinion of x11@ is clear. Upstream mesa amber/libglvnd plan was not referenced anywhere until now; thanks for posting references, it is now clear why you want to drop libglvnd-less mesa: providing needed mesa parts without libglvnd in future needs additional work in ports.
Should we mention it somewhere else? That is actionable feedback.
If you are interested in getting in on the craft, start sending patches
I do when I am interested; my interest area is non-standard Gentoo like setups/bleeding edge/experiments, likely of no use for the majority of users. I am currently on hiatus, and I want to return back with an efficient workflow set up before getting on the craft.
Ok, take care of what you must to and I'll be happy to work with you later.
And like Warner said, nothing here is set in stone, it can always be changed or doubled back later.
This comment was removed by jbeich.