Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DRAFT] Add recipe for libglvnd #25919

Closed
wants to merge 6 commits into from
Closed

Conversation

traversaro
Copy link
Contributor

@traversaro traversaro commented Mar 30, 2024

This is just an experiment triggered by @h-vetinari comment in conda-forge/gymnasium-feedstock#32 (comment) . It is nowhere complete, and if anyone wants to continue working on this feel free to open a new PR or ask me for write permission on my fork.

This PR packages libglvnd for conda-forge, reducing the need for CDT packages when working with libraries that need to link OpenGL and related libraries.

For now, I just tested it with glxgears and eglgears from https://gitlab.freedesktop.org/mesa/demos, verifying that the correct libGL.so.1 is loaded via cat /proc/<pid>/maps | grep libGL.so, on a Ubuntu 22.04 WSL system. glxgears worked fine out of the box, probably because it finds /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 via GLX_EXT_libglvnd. Instead eglgears was failing, as by default libglvnd looks for EGL's icd (see https://gitlab.freedesktop.org/glvnd/libglvnd/-/blob/v1.7.0/src/EGL/icd_enumeration.md?ref_type=tags) in $CONDA_PREFIX/share/glvnd/egl_vendor.d . As conda-forge does not ship any EGL implementation (and does not plan to do so), I just added a patch that make sure that libglvnd looks in /usr/share/glvnd/egl_vendor.d for EGL's icd. With that patch, eglgears is working fine.

Things to do:

  • Understand what is the oldest distro we want/need to support, and check if the conda-forge packaged libglvnd works there
  • Test with a non-mesa driver
  • Understand if the strategy of patching the path to look for EGL's icd to hardcode /usr/share/glvnd/egl_vendor.d make sense
  • Understand if the packages need to be split in different packages for each library, see https://packages.debian.org/source/sid/libglvnd for example for how debian split the package.
  • Sort out the licensing (the library seems to be released under a license that is not registered in SPDX)

Checklist

  • Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
  • License file is packaged (see here for an example).
  • Source is from official source.
  • Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
  • If static libraries are linked in, the license of the static library is packaged.
  • Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
  • Build number is 0.
  • A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
  • GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
  • When in trouble, please check our knowledge base documentation before pinging a team.

@conda-forge-webservices
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/libglvnd) and found it was in an excellent condition.

@h-vetinari
Copy link
Member

Awesome, thank you so much for tackling this!

CC @conda-forge/core, as this is more involved than usual, and corresponds to the recent discussion in the core call about reducing CDTs.

egl_vendor_config_dirs = '@0@/glvnd/egl_vendor.d:@1@/glvnd/egl_vendor.d'.format(
- join_paths(get_option('prefix'),get_option('sysconfdir')),
- join_paths(get_option('prefix'),get_option('datadir')))
+ join_paths('/usr',get_option('sysconfdir')),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This gets resolved at build time to be either lib or lib64 correct? Wont this cause problems between Ubuntu and fedora

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fortunately not, this are not the directory that contains the libraries, but rather the directories that contains the .json configuration files containg ICD information, see https://github.com/NVIDIA/libglvnd/blob/master/src/EGL/icd_enumeration.md .
So by default they should be /usr/share/glvnd/egl_vendor.d and /etc/glvnd/egl_vendor.d/. To be honest, I need to actually check if /etc/glvnd/egl_vendor.d/ is working as intended, as it is not clear how /etc/glvnd/egl_vendor.d/ could emerge if prefix is /usr, but /usr/share/glvnd/egl_vendor.d is working fine and should be the same across Ubuntu and Fedora.

Copy link
Member

@ehfd ehfd Jul 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@traversaro
Copy link
Contributor Author

traversaro commented Apr 2, 2024

Some checks on the location of .json configuration files for EGL's ICD across different distributions:

CentOS

7

/usr/share/glvnd/egl_vendor.d/

traversaro@IITBMP014LW012:~$ docker run -it centos:7 /bin/bash -c "yum provides */egl_vendor.d/*"
[..]
mesa-libEGL-18.3.4-10.el7.i686 : Mesa libEGL runtime libraries
Repo        : base
Matched from:
Filename    : /usr/share/glvnd/egl_vendor.d/50_mesa.json



mesa-libEGL-18.3.4-10.el7.x86_64 : Mesa libEGL runtime libraries
Repo        : base
Matched from:
Filename    : /usr/share/glvnd/egl_vendor.d/50_mesa.json



mesa-libEGL-18.3.4-12.el7_9.i686 : Mesa libEGL runtime libraries
Repo        : updates
Matched from:
Filename    : /usr/share/glvnd/egl_vendor.d/50_mesa.json



mesa-libEGL-18.3.4-12.el7_9.x86_64 : Mesa libEGL runtime libraries
Repo        : updates
Matched from:
Filename    : /usr/share/glvnd/egl_vendor.d/50_mesa.json

Fedora

39

/usr/share/glvnd/egl_vendor.d/

traversaro@IITBMP014LW012:~$ docker run -it fedora:latest /bin/bash -c "dnf provides */egl_vendor.d/*"
Fedora 39 - x86_64                                                                      3.8 MB/s |  89 MB     00:23
Fedora 39 openh264 (From Cisco) - x86_64                                                4.6 kB/s | 2.6 kB     00:00
Fedora 39 - x86_64 - Updates                                                            468 kB/s |  35 MB     01:15
mesa-libEGL-23.2.1-2.fc39.i686 : Mesa libEGL runtime libraries
Repo        : fedora
Matched from:
Filename    : /usr/share/glvnd/egl_vendor.d/50_mesa.json

mesa-libEGL-23.2.1-2.fc39.x86_64 : Mesa libEGL runtime libraries
Repo        : fedora
Matched from:
Filename    : /usr/share/glvnd/egl_vendor.d/50_mesa.json

mesa-libEGL-23.3.6-1.fc39.i686 : Mesa libEGL runtime libraries
Repo        : updates
Matched from:
Filename    : /usr/share/glvnd/egl_vendor.d/50_mesa.json

mesa-libEGL-23.3.6-1.fc39.x86_64 : Mesa libEGL runtime libraries
Repo        : updates
Matched from:
Filename    : /usr/share/glvnd/egl_vendor.d/50_mesa.json

Ubuntu

22.04

/usr/share/glvnd/egl_vendor.d/

traversaro@IITBMP014LW012:~$ docker run -it ubuntu:22.04 /bin/bash -c "apt update && apt install -y apt-file && apt-file update && apt-file search egl_vendor"
[...]
libegl-amber0: /usr/share/glvnd/egl_vendor.d/50_amber.json
libegl-mesa0: /usr/share/glvnd/egl_vendor.d/50_mesa.json
libnvidia-gl-390: /usr/share/glvnd/egl_vendor.d/10_nvidia.json
libnvidia-gl-418-server: /usr/share/glvnd/egl_vendor.d/10_nvidia.json
libnvidia-gl-450-server: /usr/share/glvnd/egl_vendor.d/10_nvidia.json
libnvidia-gl-470: /usr/share/glvnd/egl_vendor.d/10_nvidia.json
libnvidia-gl-470-server: /usr/share/glvnd/egl_vendor.d/10_nvidia.json
libnvidia-gl-510: /usr/share/glvnd/egl_vendor.d/10_nvidia.json
libnvidia-gl-510-server: /usr/share/glvnd/egl_vendor.d/10_nvidia.json
libnvidia-gl-525: /usr/share/glvnd/egl_vendor.d/10_nvidia.json
libnvidia-gl-525-server: /usr/share/glvnd/egl_vendor.d/10_nvidia.json
libnvidia-gl-535: /usr/share/glvnd/egl_vendor.d/10_nvidia.json
libnvidia-gl-535-server: /usr/share/glvnd/egl_vendor.d/10_nvidia.json
libnvidia-gl-545: /usr/share/glvnd/egl_vendor.d/10_nvidia.json
libnvidia-gl-550-server: /usr/share/glvnd/egl_vendor.d/10_nvidia.json

Arch Linux

/usr/share/glvnd/egl_vendor.d/

See https://archlinux.org/packages/extra/x86_64/mesa/ .

@ehfd
Copy link
Member

ehfd commented May 29, 2024

Is there tested support for GLES as well? There's a lack of support for GLES + Mesa, at least in the legacy CDT packages.

@traversaro
Copy link
Contributor Author

Is there tested support for GLES as well? There's a lack of support for GLES + Mesa, at least in the legacy CDT packages.

Do you know if there exists a simple program such as glxgears or eglgears for test for GLES support?

@ehfd
Copy link
Member

ehfd commented May 29, 2024

@traversaro

glmark2 and es2gears (https://packages.debian.org/sid/amd64/mesa-utils-bin/filelist / https://packages.fedoraproject.org/pkgs/mesa-demos/mesa-demos/fedora-40.html#files)

@ehfd
Copy link
Member

ehfd commented May 29, 2024

Moreover, there must be an alternative to the mesa-libEGL(-devel) and mesa-libGL(-devel) CDT packages, as well as having an equivalent to mesa-libGLES(-devel) and mesa-libGLw(-devel) within Conda.

This is needed in order to drop these CDT packages for feedstocks directly needing the CDT Mesa libraries and headers during build without necessarily going through libglvnd.

Not sure if mesalib does all these. @hmaarrfk

If that's not the case, I'm not sure whether the CDTs can be dropped.

Edit: As long as libGLdispatch.so.0, libGL.so.1, libEGL.so.1, libGLESv1_CM.so.1, libGLESv2.so.2, libOpenGL.so.0, libGLX.so.0 (not necessarily exhaustive) are provided here, I see absolutely no issues with removing the CDT packages. Recent versions of Fedora and the newest RHEL provide these libraries through glvnd, not mesa so I've missed it while looking at RHEL 7 and 8.

However, building the mesa-provided libraries in the mesalib feedstock is also fine, and is applicable in certain scenarios.

@ehfd
Copy link
Member

ehfd commented Jul 27, 2024

@hmaarrfk @traversaro No news of merging?

@traversaro
Copy link
Contributor Author

I think the first two points in #25919 (comment) (i.e. test in old glibc 2.17 distributions and test with non-mesa (i.e. nvidia) driver) would benefit from volunteer actually looking into doing the tests.

@ehfd
Copy link
Member

ehfd commented Jul 27, 2024

I'll answer the few things I know:

  1. (I will update the results for COS7 here.)

  2. NVIDIA and AMD drivers work well.

  3. /usr/share/glvnd/egl_vendor.d AND /etc/glvnd/egl_vendor.d should be hardcoded (this is also a valid path, nonetheless not used frequently). I did a few tests based on the recipe for Ubuntu 22.04 and results are consistent.

  4. The following libraries are components for libglvnd and need to be tested for existence (obtained from Fedora 40, ignore /usr/include):

libGLdispatch.so.0
libOpenGL.so.0
libGL.so.1
libGLX.so.0
libGLESv2.so.2
libGLESv1_CM.so.1
libEGL.so.1
pkgconfig/egl.pc
pkgconfig/gl.pc
pkgconfig/glesv1_cm.pc
pkgconfig/glesv2.pc
pkgconfig/glx.pc
pkgconfig/opengl.pc
pkgconfig/libglvnd.pc
/usr/include/EGL/egl.h
/usr/include/EGL/eglext.h
/usr/include/EGL/eglplatform.h
/usr/include/GL/gl.h
/usr/include/GL/glcorearb.h
/usr/include/GL/glext.h
/usr/include/GL/glx.h
/usr/include/GL/glxext.h
/usr/include/GLES/egl.h
/usr/include/GLES/gl.h
/usr/include/GLES/glext.h
/usr/include/GLES/glplatform.h
/usr/include/GLES2/gl2.h
/usr/include/GLES2/gl2ext.h
/usr/include/GLES2/gl2platform.h
/usr/include/GLES3/gl3.h
/usr/include/GLES3/gl31.h
/usr/include/GLES3/gl32.h
/usr/include/GLES3/gl3ext.h
/usr/include/GLES3/gl3platform.h
/usr/include/KHR/khrplatform.h
/usr/include/glvnd/GLdispatchABI.h
/usr/include/glvnd/libeglabi.h
/usr/include/glvnd/libglxabi.h

Personally, I would not bother splitting the libraries into different packages; the mesalib feedstock doesn't do that.

  1. License is BSD-like.

@ehfd
Copy link
Member

ehfd commented Jul 27, 2024

Made my changes in #27107.

@ehfd ehfd mentioned this pull request Jul 27, 2024
10 tasks
@traversaro
Copy link
Contributor Author

Thanks @ehfd, I guess we can continue the discussion in #27107, I think we can close here.

@traversaro traversaro closed this Jul 27, 2024
@hmaarrfk hmaarrfk mentioned this pull request Aug 28, 2024
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants