Re: Bug#1081943: libgl1-mesa-dri: llvmpipe exists but does not work on sparc64

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