On Wed, 4 Sep 2024 18:25:17 +0100 Simon McVittie <s...@debian.org> wrote:
Source: mesa
Severity: important
Justification: causes FTBFS in at least src:gtk4
Tags: ftbfs
X-Debbugs-Cc: g...@packages.debian.org, debian-ri...@packages.debian.org,
debian-loonga...@packages.debian.org, debian-m...@packages.debian.org
User: debian-m...@packages.debian.org
Usertags: mips64el
User: debian-ri...@packages.debian.org
Usertags: riscv64
Historically, Mesa's llvmpipe used LLVM MCJIT, which supports a limited
range of architectures and will not add more, and this resulted in
several architectures having either a broken llvmpipe or no llvmpipe
support at all.
With the recent upload of Mesa 24.2.x to unstable, llvmpipe now uses
ORCJIT for architectures where MCJIT is unavailable. However, the ORCJIT
version of llvmpipe doesn't seem to be particularly mature yet (perhaps
unsurprisingly, it's very new!) and is crashing under some circumstances
on at least riscv64: #1080435.
Hello Simon,
Well, riscv64 wasn't well supported by MCJIT what I understood [1].
If softpipe was still enabled on at least the affected architectures,
then packages' test suites would be able to force its use via
GALLIUM_DRIVER=softpipe in the environment if necessary. At the
moment src:gtk4 does this on mips*, plus the powerpc and sparc* -ports
architectures, to avoid #1010838; the removal of the softpipe driver
means that this makes GL initialization fail, causing test failures and
a FTBFS (I'll report this as a separate RC bug in src:gtk4). I had hoped
to do the same for riscv64 to work around #1080435, but in fact this is
not possible for the same reason.
For slightly less supported architectures it definitely make it sense to
keep softpipe around.
For the MIPS bug, I haven't found any report in upstream issues [2], is
it reported?
While it's more important on the ORCJIT architectures, also enabling
softpipe on more mainstream architectures like x86 would make it easier
for maintainers to compare llvmpipe with softpipe (without having to
build their package on porterboxes that are often very slow), and easier
to get a consistent test result for all architectures.
On mainstream architectures, regular users won't likely need run against
softpipe and for developers building Mesa isn't very hard task.
My argument here, is softpipe is unused in 99.999999% scenarios and just
occupy space.
For what it's worth, the upstream default (with -Dgallium-drivers=auto)
is to enable softpipe on all architectures. In the Debian
packaging, I believe this would be most easily done by reverting
1ba4b2499e875266f6fbd7ba20068fb569986286 "rules: Build softpipe or
llvmpipe depending on the arch, not both.".
Sure, the change is new in 24.2, so the default is conservative.
I would like to propose then to drop softpipe on 1st tier archs (at
least x86, aarch64). At least with 24.3 release.
What do you think?
David
[1]
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30343/diffs?commit_id=62143a4b21ddf9399031feab4898420ed53154f8
[2] https://gitlab.freedesktop.org/mesa/mesa/-/issues
Thanks,
smcv
--
David Heidelberg
