On Fri, 31 Oct 2025 at 13:07:07 +0100, John Paul Adrian Glaubitz wrote:
similar to gtk4, libadwaita-1 needs to runs its tests with softpipe to
make the testsuite pass which currently fails due to missing JIT support
in LLVM on these targets [1].
Do the relevant Mesa features work on these architectures at all?
If not, it seems to me that instead of tracking down and updating all
the packages whose test suites happen to depend on OpenGL and/or Vulkan
(there will be increasingly many of these as upstreams start to rely on
working GPU acceleration, or add unit tests to existing software), and
then updating them all when new LLVM-based features require additional
workarounds like setting DRAW_USE_LLVM, it would be better to disable
llvmpipe (or perhaps all of the LLVM features) in src:mesa, so that
tests running on the buildds have no choice but to use softpipe.
Going that route would also mean that applications that use libadwaita
(which are presumably the only purpose of having it) will run
successfully on powerpc and sparc64 machines that don't have a supported
GPU, without needing their users to apply the same workarounds locally.
At the moment, powerpc and sparc64 are listed in LLVM_ARCHS in mesa's
debian/rules, indicating that they are believed to have working
LLVM-related features. If that's no longer true then mesa seems like the
place to address it.
It's unfortunate that Mesa doesn't currently have build-time tests that
detect whether its software renderer works on a particular architecture,
resulting in a non-functional llvmpipe being detected further down the
dependency stack when packages like GTK and libadwaita run their test
suites. Adding a smoke-test to mesa, so that it fails to build if
llvmpipe is enabled-but-broken, would probably also be useful.
Thanks,
smcv
