Re: Bug#1081943: libgl1-mesa-dri: llvmpipe exists but does not work on sparc64
Hi Simon, On Thu, 2025-03-20 at 16:18 +, 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
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
Re: Bug#1081943: libgl1-mesa-dri: llvmpipe exists but does not work on sparc64
Hello Simon, On Mon, 2024-09-16 at 11:43 +0100, Simon McVittie wrote: > 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. 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 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1081943: libgl1-mesa-dri: llvmpipe exists but does not work on sparc64
Source: libgl1-mesa-dri Version: 24.2.2-1 Severity: normal X-Debbugs-Cc: debian-sparc@lists.debian.org User: debian-sparc@lists.debian.org Usertags: sparc64 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
