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: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

Reply via email to