Bug#1080435: mesa: 24.2.x regression on riscv64: JIT session error, Failed to materialize symbols
Simon McVittie
smcv at debian.org
Wed Sep 4 00:36:05 BST 2024
Source: mesa
Version: 24.2.1-3
Severity: important
Justification: FTBFS in previously working package
User: debian-riscv at lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-riscv at lists.debian.org, gtk4 at packages.debian.org, llvm-toolchain-18 at packages.debian.org
Control: affects -1 + src:gtk4
gtk4 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.
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.
I'm also seeing test failures in testsuite/gsk/scaling, and in several
"reftests" (which render the same content two ways, one simple/hard-coded
and one more complicated, and assert that the rendering is the same).
Exact commands can be found in the build log.
Note that on a porterbox with no graphical desktop session running,
any command that includes "GDK_BACKEND=x11" will need to be run wrapped
in `xvfb-run -a`, and any command that includes "GDK_BACKEND=wayland"
will need to be run wrapped in `debian/tests/run-with-display wayland`,
and commands that do not set GDK_BACKEND should be runnable with either
sort of display.
riscv64 users: With the new Mesa, does GL software rendering work in
practice on riscv64 machines that have a real GUI? It's difficult for me
to assess the severity of this problem from a build log.
If the ORCJIT-based llvmpipe isn't reliable, a possible workaround would
be for riscv64 Mesa builds to provide softpipe instead, or to provide both
so that it can be switched at runtime with e.g. GALLIUM_DRIVER=softpipe.
smcv
-- Package-specific info:
glxinfo:
--------
glxinfo is not available (missing mesa-utils package).
/usr/share/bug/xserver-xorg-core/script not available
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: riscv64
Kernel: Linux 6.10.6-riscv64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Versions of packages mesa-libgallium depends on:
ii libc6 2.40-2
ii libdrm-amdgpu1 2.4.122-1
ii libdrm-radeon1 2.4.122-1
ii libdrm2 2.4.122-1
ii libelf1t64 0.191-2
ii libexpat1 2.6.2-2
ii libgcc-s1 14.2.0-3
ii libglapi-mesa 24.2.1-3
ii libllvm18 1:18.1.8-9
ii libsensors5 1:3.6.0-10
ii libstdc++6 14.2.0-3
ii libxcb-dri3-0 1.17.0-2
ii libzstd1 1.5.6+dfsg-1
ii zlib1g 1:1.3.dfsg+really1.3.1-1
mesa-libgallium recommends no packages.
mesa-libgallium suggests no packages.
-- no debconf information
More information about the Pkg-llvm-team
mailing list