Closed scopatz closed 1 year ago
Thanks for raising this, @scopatz.
Was also wondering about this as well. Particularly after seeing libGL.so
on the list of installed libraries in LFS.
Is this as simple as adding a missing flag? Or is there a bit more complexity to it?
It's worth noting that we also install libGL
from yum
in the legacy Docker image and the new Docker image. IDK if that causes issues building this library or not.
Hi @scopatz and @jakirkham, it seems that the most recent mesalib
package now does provide libGL.so
. This is actually causing problems for a package of mine, which depends on mesalib
purely for off-screen rendering via OSMesa, and assumes that libGL.so
is provided by the system for on-screen rendering.
Now that libGL.so
is being installed, this seems to have the effect that a software GL renderer (softpipe
) is getting used for on-screen rendering.
I'm not intimately familiar with how OpenGL works at the shared-lib level, so don't know what the solution is here. Any thoughts?
Hmm. This might be what I was seeing yesterday as well. I would have to investigate.
It is likely because we are building with swrast
https://docs.mesa3d.org/faq.html?highlight=swrast#rendering-is-slow-why-isn-t-my-graphics-hardware-being-used
Maybe the gallium driver needs to be disabled? https://github.com/conda-forge/mesalib-feedstock/blob/master/recipe/build.sh#L16
Meson options.txt file for reference: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/meson_options.txt
I'm really stumped. The current recipe follows:
https://docs.mesa3d.org/osmesa.html#off-screen-rendering
I tried to manually disable things, but I get stuck on some undefined reference: https://github.com/conda-forge/mesalib-feedstock/pull/40
Your help there would be greatly appreciated. Otherwise, we might have to pull the latest mesa package and revert back to version 18.
@jakirkham do you have time to help with rebuilding 21 without GL.so? Should we mark the 21 package as broken?
Sorry I haven't been following this issue in some time. So am not really sure what is going on or being asked (maybe we should be using a new issue?).
Should add am not actually a maintainer on this feedstock and probably don't have the time to pick up that role.
That all being said, what is the issue? What options are you proposing to address this (and how will they help)? If possible, what is the level of effort for these options? Finally what are the tradeoffs between these options? If you don't know the answers to all of these that is fine, the more info that you can provide the better.
A few builds back in for mesa 21, we accidentally added software rending feature in GL.so. I think we should revert them to allow uesrs to fallback on their system installed GL.so files.
I think I finally got things going to disable software GL. It does remove the GL.so files that we added a few builds back. https://github.com/conda-forge/mesalib-feedstock/pull/40
I hope that it won't do too much damage, but I can't really be sure.
Should remove the software rendering issues for people when it finishes building. I would like to suggest moving forward with #40 and then focusing if people want, on specific builds that add GL.so with the caveat that we only have software rendering (for now).
So for those following this issue, the current status is that there is no libGL.so file in the latest build and we have added tests to ensure that it doesn't pop up randomly by accident.
cc: @kmuehlbauer maybe the most recent package will solve your build issues?
@hmaarrfk Thank you for the heads up. I'll have a look into this.
I think we can close this 1 year later. Let me know if i should reopen.
Issue:
This package does not seem to actually supply the OpenGL library or its pkg-config file. This is blocking the deployment of other packages that rely on OpenGL.
Environment (
conda list
):Details about
conda
and system (conda info
):