On Thu, 20 Mar 2025 at 15:50:44 +0100, John Paul Adrian Glaubitz wrote:
On Mon, 2024-09-16 at 11:43 +0100, Simon McVittie wrote:
Expected result: either of these:
- llvmpipe exists, is used, and works
- llvmpipe doesn't exist and softpipe is automatically used instead
...
I would suggest special-casing llvmpipe (and anything else requiring LLVM
JIT: lavapipe?) to be built on most of the $(LLVM_ARCHS), but not sparc64.
I just ran into this issue while looking at libadwaita-1.
I'm not 100% sure yet what would need to be done to enable full JIT support on
sparc64. I assume that the missing component is liborc, isn't it?
I don't know, I'm not a compiler or Mesa expert. I know that one blocker
for LLVM JIT on less mainstream architectures in the past has been that
LLVM upstream deprecated their old JIT implementation (MC JIT?) in
favour of a new implementation (ORC JIT?), and as part of that they
would no longer accept patches to expand the old JIT to new
architectures; but for a while Mesa only knew how to use the old JIT,
and could not use the new JIT, which meant no JIT on riscv64 for
example. I believe that limitation has now been resolved, with Mesa
using the new JIT on at least the architectures that are not supported
by the old one.
I don't think LLVM ORC JIT has anything to do with the liborc used by
e.g. GStreamer (src:orc in Debian), but I could be wrong about that.
If it isn't obvious how to make the JIT work on sparc64, the next best
thing (probably considerably easier to achieve) would be for the Mesa
packaging to disable llvmpipe (and any other feature that needs it, like
perhaps lavapipe) on sparc64, so that the only features that are enabled
on each architecture are the ones that we can expect will actually work
in practice. From GTK's point of view, I think that not having llvmpipe
at all would be better than llvmpipe existing but crashing out at
runtime.
If I understand correctly, the result of that would be that in the
absence of a supported GPU, everything that uses OpenGL (such as GTK)
would automatically fall back to softpipe, which is slow and sometimes
misrenders things (so we'd still need architecture-specific workarounds
to ignore known test failures) but does generally work (so GTK apps
would have a reasonably normal level of functionality, even if they're
slow or have visual glitches).
smcv
