Hi Simon, On Thu, 2025-03-20 at 16:18 +0000, Simon McVittie wrote: > 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.
There is actually a patch for SPARC to add support for the old JIT, see: https://reviews.llvm.org/D118450 I will try to add it to all active Debian LLVM packages. Then in the future, we can look into porting the old JIT code to the new one. Apparently, this isn't too difficult according to upstream: https://github.com/llvm/llvm-project/issues/47229#issuecomment-2742515988 > 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. OK, I'll give it a try with the old JIT first. > 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). Yeah, we can consider this as well. But I want to give the JIT patch a try first since it doesn't seem to be too difficult. Would be great if it fixed all testsuite failures in gtk4 and libadawaita on sparc64. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
