Hi Simon, On Wed, 4 Sep 2024 00:36:05 +0100 Simon McVittie <s...@debian.org> wrote:
Source: mesa Version: 24.2.1-3 Severity: important Justification: FTBFS in previously working package User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org, g...@packages.debian.org, llvm-toolchain...@packages.debian.org Control: affects -1 + src:gtk4gtk4 previously passed most of its build-time tests on riscv64, but it's now failing on the riscv64 porterbox ricci. I initially thought this was a regression in 4.15.x (in experimental) but in fact I can reproduce the failure in the previously-working version in unstable. I think this might be related to the addition of ORC JIT support in the new Mesa. Steps to reproduce: * set up a chroot with gtk4 build-dependencies * build gtk4 (it will fail build-time tests) * To run one of the affected tests: schroot -c $chroot -r -- \ env GDK_DEBUG=opengl,vulkan,gl-debug GDK_BACKEND=x11 \ xvfb-run -a \ debian/build/deb/testsuite/gdk/memorytexture --tap -k Expected result: test passes Actual result: > JIT session error: No HI20 PCREL relocation type be found for LO12 PCREL relocation type > Failed to materialize symbols: { (fs681_variant0_14, { fs_variant_linear2, fs_variant_partial }) } and the program exits with status 1.
AFAIK we need to backport a commit [1] to LLVM to fix the issue. Moreover, a small memory leak related to ORCJIT can be fixed by another one [2].
[1]: https://github.com/llvm/llvm-project/commit/78f39dc70c1feaea5130b90ea3fb7b3ddd62446b [2]: https://github.com/llvm/llvm-project/commit/3d67cf681a728e4cf0ab9947c0dd07539dda8b74
You can run the same command and add "-l" to get a list of test-cases, then run with e.g. "-p /memorytexture/download_1x1/b8g8r8a8-premultiplied/local" to run a single test-case. On a riscv64 machine with no access to a GPU, or with LIBGL_ALWAYS_SOFTWARE=1, you should see that: * /memorytexture/download_1x1/b8g8r8a8-premultiplied/local succeeds (this is a trivial case that doesn't touch OpenGL/Vulkan) * /memorytexture/download_1x1/b8g8r8a8-premultiplied/gl, the "old GL" renderer, fails. This can use either OpenGL ES (default) or "desktop" OpenGL (add gl-prefer-gl to GDK_DEBUG). * /memorytexture/download_1x1/b8g8r8a8-premultiplied/gl-released and /memorytexture/download_1x1/b8g8r8a8-premultiplied/gl-native, variations on the "old GL" renderer with different call patterns (I don't know the specifics), also fail. * /memorytexture/download_1x1/b8g8r8a8-premultiplied/ngl, the "new GL" renderer, succeeds when using OpenGL ES, but fails when using "desktop" OpenGL (GDK_DEBUG="...,gl-prefer-gl") * /memorytexture/download_1x1/b8g8r8a8-premultiplied/vulkan is skipped because GTK recognises that there is no real GPU. Sorry, I don't know the specifics of what is "new" about the ngl renderer, or really much about GL at all: please consult the gtk4 source code for details. testsuite/gdk/memorytexture is probably a good simple test to work with: it copies textures to and from (the software emulation of) GPU memory, and doesn't need many special environment variables set.
Cheers, Eric
