To reproduce:
- install gtk4 build-dependencies on sparc64 porterbox with no access to a
  real GPU
- get gtk4 source
- edit debian/rules to remove the special case that forces use of softpipe
  on sparc64
- build and run tests

Expected result: either of these:
- llvmpipe exists, is used, and works
- llvmpipe doesn't exist and softpipe is automatically used instead

Actual result:
- all tests that use OpenGL fail with message "Target has no JIT support"

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.

    smcv

Hello Simon,

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?

Looking at the LLVM upstream sources, I see no obvious reason why liborc should
not be supported on sparc64. But I'm not an expert on liborc, so I might be missing
something.

Adrian

...

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

Hi Simon,

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

OK, I'll give it a try with the old JIT first.

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

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.