{compiler,lib,vis}[GCCcore/14.3.0] glslang-SPIRV v15.4.0, libclc v20.1.8, OpenGL v2025.09 #23764
Conversation
|
While there was some discussion about if we want to go this route, I think some improvements can be ported to the individual EasyConfigs, if we decide to keep the split, e.g:
|
|
Intel GPU support would probably also be achievable, but requires #23174. Therefore, I didn't look into that yet. |
|
Test report by @Thyre |
|
Test report by @Thyre |
|
AMD GPU shows up in $ which glxinfo
/data/EasyBuild-develop/software/OpenGL/2025b-GCCcore-14.3.0/bin/glxinfo
$ glxinfo | grep radeonsi
Device: AMD Radeon RX 9070 (radeonsi, gfx1201, LLVM 20.1.8, DRM 3.64, 6.16.3-arch1-1) (0x7550)
OpenGL renderer string: AMD Radeon RX 9070 (radeonsi, gfx1201, LLVM 20.1.8, DRM 3.64, 6.16.3-arch1-1)
g: AMD Radeon RX 9070 (radeonsi, gfx1201, LLVM 20.1.8, DRM 3.64, 6.16.3-arch1-1)
$ eglinfo | grep radeonsi
EGL driver name: radeonsi
OpenGL core profile renderer: AMD Radeon Graphics (radeonsi, raphael_mendocino, LLVM 20.1.8, DRM 3.64, 6.16.3-arch1-1)
OpenGL compatibility profile renderer: AMD Radeon Graphics (radeonsi, raphael_mendocino, LLVM 20.1.8, DRM 3.64, 6.16.3-arch1-1)
OpenGL ES profile renderer: AMD Radeon Graphics (radeonsi, raphael_mendocino, LLVM 20.1.8, DRM 3.64, 6.16.3-arch1-1)
[...] |
|
Test report by @Thyre |
|
Test report by @Thyre |
|
From ZAM054 ( NVIDIA GPU ): $ __GLX_VENDOR_LIBRARY_NAME=nvidia glxinfo | grep vendor
server glx vendor string: SGI
client glx vendor string: NVIDIA Corporation
OpenGL vendor string: NVIDIA CorporationAs expected, one also sees warnings due to the Intel driver missing. |
|
Per conventions of our other bundles (like Python-bundle-PyPI), we should probably name the OpenGL version |
|
Test report by @Thyre |
|
@boegelbot please test @ jsc-zen3 |
|
@Thyre: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de PR test command '
Test results coming soon (I hope)... Details- notification for comment with ID 3241736651 processed Message to humans: this is just bookkeeping information for me, |
|
Test report by @boegelbot |
Updated software
|
Thyre
changed the title
|
@boegelbot please test @ jsc-zen3 |
|
@Thyre: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de PR test command '
Test results coming soon (I hope)... Details- notification for comment with ID 3242091992 processed Message to humans: this is just bookkeeping information for me, |
|
Test report by @Thyre |
|
Test report by @Thyre |
|
Test report by @boegelbot |
|
Test report by @Thyre jreuter@Framework ~ module purge --force
jreuter@Framework ~ glxinfo | grep -e "radeonsi" -e "Mesa"
client glx vendor string: Mesa Project and SGI
Device: AMD Radeon 860M Graphics (radeonsi, gfx1152, LLVM 20.1.8, DRM 3.63, 6.15.10-200.fc42.x86_64) (0x1114)
OpenGL renderer string: AMD Radeon 860M Graphics (radeonsi, gfx1152, LLVM 20.1.8, DRM 3.63, 6.15.10-200.fc42.x86_64)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 25.1.7
OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.1.7
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 25.1.7
jreuter@Framework ~ ml GCCcore/14.3.0 OpenGL
jreuter@Framework ~ glxinfo | grep -e "radeonsi" -e "Mesa"
client glx vendor string: Mesa Project and SGI
Device: AMD Radeon 860M Graphics (radeonsi, gfx1152, LLVM 20.1.8, DRM 3.63, 6.15.10-200.fc42.x86_64) (0x1114)
OpenGL renderer string: AMD Radeon 860M Graphics (radeonsi, gfx1152, LLVM 20.1.8, DRM 3.63, 6.15.10-200.fc42.x86_64)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 25.2.1
OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.2.1
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 25.2.1 |
…CCcore-14.3.0.eb, OpenGL-2025b-GCCcore-14.3.0.eb
easybuild/easyconfigs/g/glslang-SPIRV/glslang-SPIRV-15.4.0-GCCcore-14.3.0.eb
Outdated
Show resolved
Hide resolved
Signed-off-by: Jan André Reuter <[email protected]>
|
Test report by @Thyre |
|
@boegelbot please test @ jsc-zen3 |
|
@Thyre: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de PR test command '
Test results coming soon (I hope)... Details- notification for comment with ID 3285055813 processed Message to humans: this is just bookkeeping information for me, |
|
Test report by @boegelbot |
|
Test report by @Thyre |
|
Test report by @Thyre |
Micket
left a comment
Micket
left a comment
There was a problem hiding this comment.
Sorry for being long worded. I'm bad at cutting down my text. I tried to be more direct here than my rambling response in the issue thread.
| # OpenGL Extension Wrangler Library - determines which OpenGL extensions are supported at run-time | ||
| # This is just GLEW for GLX (which requires DISPLAY to be set) and not GLEW for EGL as GLEW selects GLX/EGL at | ||
| # compile-time and not run-time (https://github.com/nigels-com/glew/issues/172#issuecomment-357400019) | ||
| # Compile+Load GLEW-EGL on top to enable GLEW for EGL | ||
| ('glew', '2.2.0', { | ||
| 'easyblock': 'ConfigureMake', | ||
| 'source_urls': ['https://github.com/nigels-com/glew/releases/download/%(name)s-%(version)s/'], | ||
| 'sources': ['%(name)s-%(version)s.tgz'], | ||
| 'patches': [ | ||
| {'name': 'glew-2.2.0-uintptr_t.patch', 'alt_location': 'glew'}, | ||
| ], | ||
| 'checksums': [ | ||
| {'glew-2.2.0.tgz': 'd4fc82893cfb00109578d0a1a2337fb8ca335b3ceccf97b97e5cc7f08e4353e1'}, | ||
| {'glew-2.2.0-uintptr_t.patch': '30fffe5b6606ae840fd5d10d353196c8faf3b88618ab8db03bd1b50dde98a280'}, | ||
| ], | ||
| 'start_dir': '%(namelower)s-%(version)s', | ||
| 'skipsteps': ['configure'], | ||
| 'buildopts': local_glew_buildopts, | ||
| 'installopts': 'GLEW_PREFIX=%(installdir)s GLEW_DEST=%(installdir)s ', | ||
| 'install_cmd': 'make install.all ', | ||
| }), |
There was a problem hiding this comment.
I think we should skip GLEW. It's barely used by anything, but most importantly, shadowing it is not safe at all; the library symbols will conflict, so loading one while a software links to the other would end up with all segfaults. The previous modules ensured that these conflicted.
I'm not sure we have anything anymore that even uses GLEW since ParaView ditched it for GLAD (static generator).
There was a problem hiding this comment.
You have a very good point here, especially since we're now having rpath enabled by default. I'll remove the component.
There was a problem hiding this comment.
I dropped GLEW from this EasyConfig.
There was a problem hiding this comment.
Actually, rpath does help a little bit here (but it's not mandatory, so I don't want to rely on it); if it's just different programs that would have rpath linked to egl vs glx, then they could coexist.
Hopefully, more things switch to GLAD and we don't have to worry about this at all.
| ( | ||
| '{ cat > %(installdir)s/share/glvnd/egl_vendor.d/50_mesa.json; } << \'EOF\'\n' | ||
| '{\n' | ||
| ' \"file_format_version\" : \"1.0.0\",\n' | ||
| ' \"ICD\" : {\n' | ||
| ' \"library_path\" : \"libEGL_mesa.so.0\"\n' | ||
| ' }\n' | ||
| '}\n' | ||
| 'EOF' | ||
| ), |
There was a problem hiding this comment.
Isn't the standard Mesa build already generating this exact file (into this very location)? It certainly did for all my previous Mesa builds, and we never generated this file manually like this before.
It's standard, required file for all EGL stuff these days after all. All library providers would need to provide these themselves.
There was a problem hiding this comment.
I'll cross-check, but I'm totally fine with removing this. I've checked quite a few systems and the only one missing these files was a empty Ubuntu container IIRC. I'd need to check my home server again. That one might not have the system files, but if our Mesa installation already provides them by default, there's no need to generate them again.
There was a problem hiding this comment.
I removed both files. You're correct that Mesa already creates this (I checked the one from 2024a).
| # EGL vendor ICDs | ||
| ( | ||
| '{ cat > %(installdir)s/share/glvnd/egl_vendor.d/10_nvidia.json; } << \'EOF\'\n' | ||
| '{\n' | ||
| ' \"file_format_version\" : \"1.0.0\",\n' | ||
| ' \"ICD\" : {\n' | ||
| ' \"library_path\" : \"libEGL_nvidia.so.0\"\n' | ||
| ' }\n' | ||
| '}\n' | ||
| 'EOF' | ||
| ), |
There was a problem hiding this comment.
I'm really not sure why re-generating this json is done here.
It's a requirement that anything that is providing libEGL_nvidia.so.0 also must be providing the accompanying ICD (10_nvidia_json).
Every EGL vendor would need to supply this.
I don't have any alternative system where there would be anything beyond mesa or nvidia, so I'm not sure there is a single other vendor to compare with here (ARM Mali? broadcome/videocore on raspberry pi maybe?)
The only thing I can think of is maybe a OS installed Intel GPU, and we aren't building that in this Mesa (but we could?) But even in that case, it's would still be libEGL_mesa.so.0., so LD_LIBRARY_PATH would take over.
There was a problem hiding this comment.
I don't have any alternative system where there would be anything beyond mesa or nvidia, so I'm not sure there is a single other vendor to compare with here (ARM Mali? broadcome/videocore on raspberry pi maybe?)
I think handling NVIDIA & Mesa (therefore AMD & potentially Intel) is a good set to target. If there's more, we could try to handle this later. But since the core audience for EasyBuild is HPC, I don't think that other graphic accelerators are common.
The only thing I can think of is maybe a OS installed Intel GPU, and we aren't building that in this Mesa (but we could?) But even in that case, it's would still be libEGL_mesa.so.0., so LD_LIBRARY_PATH would take over.
I'd need to check the requirements for Intel GPUs again, but building that as well might be worthwhile.
At that point we could adapt the EasyBlock for this as well, so that we always build them if the dependencies are given.
| } | ||
|
|
||
| modextravars = { | ||
| 'EGL_PLATFORM': 'surfaceless', |
There was a problem hiding this comment.
Hm. Does this not interfere with interactive applications by forcing some off-screen rendering to happen? I haven't played with this parameter before.
There was a problem hiding this comment.
@jhgoebbert, can you maybe give some information on this? 😄
| performance on NVIDIA GPUs. | ||
|
|
||
| This is a GL vendor neutral dispatch (GLVND) installation with Mesa and NVIDIA in the same lib-directory. Mesa or NVIDIA | ||
| OpenGL is set individually for each XScreen. |
There was a problem hiding this comment.
So, a lot of the text in the description is.. very misleading.
Some strange emphasis on that it's using the same lib-directory? Well, first, they aren't in this easyconfig. Also, if they are, or not makes no difference to GLVND anyway. It looks at your library paths. Standard OS paths, as well as LD_LIBRARY_PATH as far as I know.
This easyconfig does include a duplicate ICD for mesa, but that just fails to load unless the user also provides the nvidia drivers separately (which will also provide them with a secondary ICD json).
This might mislead people into thinking they need to embed the nvidia driver libraries into this easyconfigs singular %(installdir)s, which would be completely unnecessary and convoluted.
GLVND works perfectly well without doing any such thing (i mean, all the previous Mesa ones just did the simple approach, and that has always worked with accelerated 3D support, assuming you have the nvidia driver libs somewhere, which is still a requirement here).
I have no idea what is meant that very last part about XScreens. That you can pick at runtime?
There was a problem hiding this comment.
I haven't really looked at the text, basically copied what we had at JSC in prior stages. I'll rework the text a bit.
There was a problem hiding this comment.
I completely rewrote the description. Hopefully this is a bit better now 😄
Thanks a lot for the detailed review. |
Signed-off-by: Jan André Reuter <[email protected]>
Signed-off-by: Jan André Reuter <[email protected]>
Signed-off-by: Jan André Reuter <[email protected]>
Signed-off-by: Jan André Reuter <[email protected]>
Signed-off-by: Jan André Reuter <[email protected]>
We first need to figure out what we need to do specifically Signed-off-by: Jan André Reuter <[email protected]>
Signed-off-by: Jan André Reuter <[email protected]>
Signed-off-by: Jan André Reuter <[email protected]>
|
Test report by @Thyre |
|
@boegelbot please test @ jsc-zen3 |
|
@Thyre: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de PR test command '
Test results coming soon (I hope)... Details- notification for comment with ID 3323192083 processed Message to humans: this is just bookkeeping information for me, |
|
Test report by @boegelbot |
easybuild/easyconfigs/o/OpenGL/OpenGL-2025.09-GCCcore-14.3.0.eb
Outdated
Show resolved
Hide resolved
|
Test report by @Micket |
Micket
left a comment
Micket
left a comment
There was a problem hiding this comment.
lets merge this as is, though i might discover something down the line that requires tweaking, i just have so many more easyconfigs to build on top of this before i can determine that.
Happy to help out with any fixes if they're required 😄 |
5 participants
(created using
eb --new-pr)This PR implements the changes proposed in #10701, i.e. combining the different parts for OpenGL into one single EasyConfig. The components were mostly copied from the individual EasyConfigs of prior toolchains, with some minor modifications to Mesa:
-Dgles1=enabled-Dgles2=enabled-Dvulkan-drivers='swrast,amd'&-Dgallium-drivers=llvmpipe,radeonsifor AMDGPU supportDue to this, we also have
libclcas a new dependency.TODO:
Requires:
Resolves #10701