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

Add libglvnd recipe #27107

Merged
merged 62 commits into from
Aug 12, 2024
Merged

Add libglvnd recipe #27107

merged 62 commits into from
Aug 12, 2024

Conversation

ehfd
Copy link
Member

@ehfd ehfd commented Jul 27, 2024

Test workflow:

Use glxgears, eglgears (eglgears_x11 - Pure EGL /xeglgears - EGL/X11 interop), es2gears (es2gears_x11 - Dependent to EGL) from https://gitlab.freedesktop.org/mesa/demos and verify the correct library is loaded, for instance using cat /proc/<pid>/maps | grep libGL.so / cat /proc/<pid>/maps | grep libGLX.so / cat /proc/<pid>/maps | grep libEGL.so / cat /proc/<pid>/maps | grep libGLESv2.so

The option -info specifies which driver was used for the gears examples in command-line output. Mesa with glxgears should find /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 (libGLX_nvidia.so.0 for NVIDIA), and eglgears should find the correct system 50_mesa.json ICD JSON file in /usr/share/glvnd/egl_vendor.d or /etc/glvnd/egl_vendor.d (and 10_nvidia.json for NVIDIA).

For x86_64, Intel and AMD GPUs use Mesa for 3D OpenGL/Vulkan applications, and NVIDIA GPUs use their own libglvnd GL library libGLX_nvidia.so.0 or libEGL_nvidia.so.0 bundled with their nvidia-gl drivers.

lrwxrwxrwx 1 ubuntu ubuntu    33 Feb 13 16:40 /usr/bin/eglgears_wayland -> eglgears_wayland.x86_64-linux-gnu
-rwxr-xr-x 1 ubuntu ubuntu 35632 Feb 13 16:40 /usr/bin/eglgears_wayland.x86_64-linux-gnu
lrwxrwxrwx 1 ubuntu ubuntu    29 Feb 13 16:40 /usr/bin/eglgears_x11 -> eglgears_x11.x86_64-linux-gnu
-rwxr-xr-x 1 ubuntu ubuntu 27128 Feb 13 16:40 /usr/bin/eglgears_x11.x86_64-linux-gnu
lrwxrwxrwx 1 ubuntu ubuntu    33 Feb 13 16:40 /usr/bin/es2gears_wayland -> es2gears_wayland.x86_64-linux-gnu
-rwxr-xr-x 1 ubuntu ubuntu 39664 Feb 13 16:40 /usr/bin/es2gears_wayland.x86_64-linux-gnu
lrwxrwxrwx 1 ubuntu ubuntu    29 Feb 13 16:40 /usr/bin/es2gears_x11 -> es2gears_x11.x86_64-linux-gnu
-rwxr-xr-x 1 ubuntu ubuntu 31176 Feb 13 16:40 /usr/bin/es2gears_x11.x86_64-linux-gnu
lrwxrwxrwx 1 ubuntu ubuntu    25 Feb 13 16:40 /usr/bin/glxgears -> glxgears.x86_64-linux-gnu
-rwxr-xr-x 1 ubuntu ubuntu 27032 Feb 13 16:40 /usr/bin/glxgears.x86_64-linux-gnu
lrwxrwxrwx 1 ubuntu ubuntu    26 Feb 13 16:40 /usr/bin/peglgears -> peglgears.x86_64-linux-gnu
-rwxr-xr-x 1 ubuntu ubuntu 22904 Feb 13 16:40 /usr/bin/peglgears.x86_64-linux-gnu
lrwxrwxrwx 1 ubuntu ubuntu    24 Feb 13 16:40 /usr/bin/vkgears -> vkgears.x86_64-linux-gnu
-rwxr-xr-x 1 ubuntu ubuntu 62768 Feb 13 16:40 /usr/bin/vkgears.x86_64-linux-gnu
lrwxrwxrwx 1 ubuntu ubuntu    26 Feb 13 16:40 /usr/bin/xeglgears -> xeglgears.x86_64-linux-gnu
-rwxr-xr-x 1 ubuntu ubuntu 31200 Feb 13 16:40 /usr/bin/xeglgears.x86_64-linux-gnu

glxgears -info/xeglgears -info:

GL_RENDERER   = NVIDIA TITAN Xp/PCIe/SSE2
GL_VERSION    = 4.6.0 NVIDIA 550.76
GL_VENDOR     = NVIDIA Corporation

eglgears_x11 -info/es2gears_x11 -info:

EGL_VERSION = 1.5
EGL_VENDOR = NVIDIA

Expected result for cat /proc/<pid>/maps | grep libGL.so after prepending the conda environment lib directory to LD_LIBRARY_PATH for instance:

7f6ceba6f000-7f6cebab6000 r--p 00000000 00:215 52970104                  /home/ubuntu/Downloads/conda/envs/libglvnd/lib/libGL.so.1.7.0
7f6cebab6000-7f6cebab9000 r-xp 00047000 00:215 52970104                  /home/ubuntu/Downloads/conda/envs/libglvnd/lib/libGL.so.1.7.0
7f6cebab9000-7f6cebad4000 r-xp 0004a000 00:215 52970104                  /home/ubuntu/Downloads/conda/envs/libglvnd/lib/libGL.so.1.7.0
7f6cebad4000-7f6cebad5000 r-xp 00065000 00:215 52970104                  /home/ubuntu/Downloads/conda/envs/libglvnd/lib/libGL.so.1.7.0
7f6cebad5000-7f6cebaea000 r--p 00066000 00:215 52970104                  /home/ubuntu/Downloads/conda/envs/libglvnd/lib/libGL.so.1.7.0
7f6cebaea000-7f6cebaf8000 r--p 0007a000 00:215 52970104                  /home/ubuntu/Downloads/conda/envs/libglvnd/lib/libGL.so.1.7.0
7f6cebaf8000-7f6cebaf9000 rw-p 00088000 00:215 52970104                  /home/ubuntu/Downloads/conda/envs/libglvnd/lib/libGL.so.1.7.0

Mesa (which includes all sorts of device support including embedded) and NVIDIA should be the ones to test.
https://wiki.archlinux.org/title/OpenGL

Since libglvnd is merely a glue that connects OpenGL applications to Mesa or NVIDIA GL, if one device interface works correctly on Mesa, the rest should also most likely work and if they don't, it's Mesa's problem.
This means that if Mesa llvmpipe works but Mesa AMD gallium doesn't work, it's not libglvnd's problem.

So while it would be more assuring to try on AMD and Intel GPUs, I don't think it's a necessity if nobody has the hardware. The reason this package needs to exist is to eliminate the CDTs during builds, so there is enough breathing space to listen to issues.


Tests:

This is the build I've isolated using conda-pack (feel free to use this to test):
libglvnd-conda.tar.gz

Note that you need a valid X.Org server running and would also be an ideal idea to prepend LD_LIBRARY_PATH.

Ubuntu 24.04 + NVIDIA: All three (GLX, EGL, GLES) work
Ubuntu 24.04 + Mesa llvmpipe (software, use env __GLX_VENDOR_LIBRARY_NAME=mesa __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json my_command): All three work
Ubuntu 22.04 + NVIDIA: All three work
Ubuntu 22.04 + Mesa llvmpipe (software): All three work

CentOS 7 + NVIDIA: All three work when substituting command to eglinfo and es2_info (feel free to use glxinfo in addition to glxgears -info as well)
CentOS 7 + Mesa llvmpipe (software) from latest Mesa and glvnd (install yum install mesa-libGLU*.i686 mesa-libGLU*.x86_64): All three work when substituting command to eglinfo and es2_info (feel free to use glxinfo in addition to glxgears -info as well)

So all glibc >= 2.17 work well.

When using glxinfo, eglinfo or es2_info, use <program> & cat /proc/${!}/maps.


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.

Built upon #25919 by @traversaro, accommodates conda-forge/cdt-builds#66 (comment) and removes the need for OpenGL CDT packages.

@h-vetinari @hmaarrfk Review requested.

@conda-forge-webservices
Copy link

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/libglvnd/meta.yaml) and found some lint.

Here's what I've got...

For recipes/libglvnd/meta.yaml:

For recipes/libglvnd/meta.yaml:

  • License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

@ehfd
Copy link
Member Author

ehfd commented Jul 27, 2024

@conda-forge-admin, please rerender

@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/meta.yaml) and found it was in an excellent condition.

@ehfd
Copy link
Member Author

ehfd commented Jul 27, 2024

@conda-forge-admin, please rerender

@ehfd
Copy link
Member Author

ehfd commented Jul 27, 2024

@conda-forge/staged-recipes, ready for review!

Copy link

To help direct your pull request to the best reviewers, please mention a topic-specifc team if your recipe matches any of the following: conda-forge/help-c-cpp, conda-forge/help-cdts, conda-forge/help-go, conda-forge/help-java, conda-forge/help-julia, conda-forge/help-nodejs, conda-forge/help-perl, conda-forge/help-python, conda-forge/help-python-c, conda-forge/help-r, conda-forge/help-ruby,or conda-forge/help-rust. Thanks!

@ehfd
Copy link
Member Author

ehfd commented Jul 27, 2024

I have had no visible issues with EGL or GLES for CentOS 7 and Ubuntu 22.04.

@hmaarrfk
Copy link
Contributor

Can we have a test table at the top that adds the following lines:

  1. Ubuntu 24.04
  2. Ubuntu XX.04 + Nvidia GPU

How do I check which GPU is being used?

I feel like we should have this table and our test established before asking Isuru for their input.

@ehfd
Copy link
Member Author

ehfd commented Jul 28, 2024

@hmaarrfk I have added a test table and test methodology that @traversaro established.

@isuruf Please review this PR together with @hmaarrfk and @h-vetinari.

@ehfd ehfd requested a review from hmaarrfk July 28, 2024 05:51
@ehfd
Copy link
Member Author

ehfd commented Jul 28, 2024

How do I check which GPU is being used?

Either (whatever_gears_command) -info, or by looking at cat /proc/<pid>/maps and seeing if there is libGLX_nvidia.so.0/libEGL_nvidia.so.0 or not, and that the correct libglvnd library is used.

Comment on lines 35 to 41
- test -f $PREFIX/lib/libEGL.so.1
- test -f $PREFIX/lib/libGL.so.1
- test -f $PREFIX/lib/libGLESv1_CM.so.1
- test -f $PREFIX/lib/libGLESv2.so.2
- test -f $PREFIX/lib/libGLX.so.0
- test -f $PREFIX/lib/libOpenGL.so.0
- test -f $PREFIX/lib/libGLdispatch.so.0
Copy link
Member

Choose a reason for hiding this comment

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

I'd prefer these to be in libglvnd and the rest to be in libgl-devel. I can make that change if you prefer

Copy link
Member Author

@ehfd ehfd Jul 29, 2024

Choose a reason for hiding this comment

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

Please go ahead with that. I gave you write access to the repository.

Copy link
Member Author

@ehfd ehfd Jul 29, 2024

Choose a reason for hiding this comment

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

For the headers, xorg-glproto (mandatory headers in conjunction) should also be a runtime dependency (as meson states), if I'm not wrong.

@ehfd ehfd requested a review from isuruf July 29, 2024 04:27
@ehfd
Copy link
Member Author

ehfd commented Jul 29, 2024

@isuruf I would prefer this to be merged quickly as soon as possible because I have my own build pipeline waiting for this.

@hmaarrfk
Copy link
Contributor

@isuruf I would prefer this to be merged quickly as soon as possible because I have my own build pipeline waiting for this.

This isn’t how conda-forge, a volunteer maintained project, works. You have many options to move forward with your projects that do not rely on Isuru’s immediate contributions to this.

You may choose to either upload this package to your own channel or continue to use CDTs as we have done before across conda-forge.

Finally the fastest thing for you to do would be to attempt to write the code to address Isuru’s requests.

@ehfd
Copy link
Member Author

ehfd commented Jul 31, 2024

@hmaarrfk What would be the safest way to split the package into files that end with .so* and files that aren't .so* while building from one source, where one of the output specifies the other as a dependency?
If this is answered, it shouldn't be too much work.

@ehfd
Copy link
Member Author

ehfd commented Aug 2, 2024

@traversaro It appears that you created the Vulkan headers and loaders feedstock. Could you possibly provide directions here?

@traversaro
Copy link
Contributor

@traversaro It appears that you created the Vulkan headers and loaders feedstock. Could you possibly provide directions here?

The situation is a bit different there as the two packages are separate at the repo level (see https://github.com/KhronosGroup/Vulkan-Headers and https://github.com/KhronosGroup/Vulkan-Loader), so nothing specific was required to package them separately.

@traversaro
Copy link
Contributor

@hmaarrfk What would be the safest way to split the package into files that end with .so* and files that aren't .so* while building from one source, where one of the output specifies the other as a dependency? If this is answered, it shouldn't be too much work.

There is some docs in https://conda-forge.org/docs/maintainer/knowledge_base/#multi-output-recipes, not sure if they are enough for what you are looking for.

@ehfd
Copy link
Member Author

ehfd commented Aug 2, 2024

Yeah, the multi-output-recipes section ought to do it. I'll just barge in with it and ask for review later on.

@conda-forge-webservices
Copy link

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/libglvnd/meta.yaml) and found some lint.

Here's what I've got...

For recipes/libglvnd/meta.yaml:

  • Failed to even lint the recipe, probably because of a conda-smithy bug 😢. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint . from the recipe directory.

recipes/libglvnd/meta.yaml Outdated Show resolved Hide resolved
@isuruf isuruf merged commit 2b07001 into conda-forge:main Aug 12, 2024
4 of 5 checks passed
@isuruf
Copy link
Member

isuruf commented Aug 12, 2024

Thanks

@ehfd
Copy link
Member Author

ehfd commented Aug 12, 2024

I will add the recipes for arm64 and ppc64 immediately.

@ehfd ehfd deleted the libglvnd branch August 12, 2024 14:18
@hmaarrfk
Copy link
Contributor

Huge milestone! Congrats everybody and thank you @ehfd for your perseverance through this!

@ehfd
Copy link
Member Author

ehfd commented Aug 12, 2024

@hmaarrfk Yeah, this will be my last feedstock for a long while... Thanks for helping along the way.

@hmaarrfk
Copy link
Contributor

Famous last words!!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

5 participants