[WIP] mesa: add egl variant#45570
Conversation
Signed-off-by: Teague Sterling <[email protected]>
spackbot-app
bot
added
dependencies
new-variant
update-package
virtual-dependencies
labels
Signed-off-by: Teague Sterling <[email protected]>
| # Provides | ||
| provides("libglx", when="+glx") | ||
| # provides('[email protected]', when='+egl') | ||
| provides("[email protected]", when="+egl") |
There was a problem hiding this comment.
The virtual should be renamed libegl as there is already an egl package that this will conflict with.
The EGL package should also be updated here to provide libegl and gl to reflect the current hack there that detects both for system EGL. It is also possible that we could just drop the hack completely with the libegl virtual.
Then we also need to update the references in the packages that are currently EGL aware.
- GLEW
- ParaView
|
To test I would like to see paraview configured/built like this Additionally we should add this to our CI that is testing the GL stack The file here: Add the following to the ParaView matrix: - paraview_specs:
- matrix:
- - paraview +raytracing
- - +qt ^[virtuals=gl] glx # GUI Support w/ GLX Rendering
- ~qt ^[virtuals=gl] glx # GLX Rendering
- ^[virtuals=gl] osmesa # OSMesa Rendering
+ - ^[virtuals=libegl,libglx] mesa +egl +glx ^[virtuals=gl] glx # EGL Rendering |
Signed-off-by: Teague Sterling <[email protected]>
Signed-off-by: Teague Sterling <[email protected]>
…ings Signed-off-by: Teague Sterling <[email protected]>
|
@kwryankrattiger I should have an opportunity to test/troubleshoot this over the weekend. Thanks a bunch for providing a great test case. |
|
This is not yet ready to go. I ran into issues testing the paraview packages that @kwryankrattiger. From what I could gather there was a conflict showing up in concretization, but the concretizer was reporting a general internal error. I'll investigate further. |
|
Feel free to upload logs/messages here along with the commands you ran. |
| ] | ||
|
|
||
| if spec.satisfies("^[virtuals=gl] egl"): | ||
| if spec.satisfies("^[virtuals=gl] libegl"): |
There was a problem hiding this comment.
Does this work? You have a virtual edge provided by a virtual edge here.
There was a problem hiding this comment.
That may be why i broke the concretizer the last time I was trying to sort this out.
There was a problem hiding this comment.
I think working on modeling this after how we handle GLX and OSMesa may be a good start. We have a BundlePackage that sits between the libglx provider and is the gl provider from glx.
mesa +glx <- [virtual=libglx] <- glx <- [virtuals=gl] <- consuming package
we could so something similar then wtih EGL, where
mesa+egl <- [virtuals=libegl]
and introduce a egl-external/egl-system to take the place of the existing egl package
egl-system <- [virtuals=libegl]
egl would then consume libegl and provide a gl as defined by the libegl provider.
I think this should more or less act as a drop in replacement for the existing layout and we could do..
paraview ^[virtuals=gl] egl ^[virtuals=libegl] mesa +egl`
--
It is kind of strange since egl isn't really a gl "provider". I am still unsure how best to describe a gl provider that is compatible with egl. We would probably need something along the lines of a glvnd package the consumed a libopengl and then provided a gl. This would require a fair amount more work in the packages to correctly constrain the spec strings.
|
Closing, since we moved the package repository. Feel free to reopen at / migrate to https://github.com/spack/spack-packages if you want to continue working on this. |
I have a ton of old PRs that need to be cleaned up and (where still relevant) moved to the spack-packages repo. Hopefully will have those reviewed in the next few weeks. |
|
There is a migration tool, if it works for your PRs https://github.com/spack/migrate-package-prs |
5 participants
FYI @v-dobrev
Breaking this out from #44722 to capture discussions around the EGL variant in a more focused PR.