Control: retitle -1 gtk4 memorytexture test-case regresses with Mesa 22.1
Control: reassign -1 src:gtk4,src:mesa
Control: found -1 gtk4/4.6.6+ds-1
Control: found -1 mesa/22.1.3-1
On Sat, 16 Jul 2022 at 15:49:25 +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> > ▶ 11/681
> > ERROR:../../../testsuite/gdk/memorytexture.c:389:compare_textures:
> > assertion failed (expected_data[y * width + x] == test_data[y * width +
> > x]): (0x55441155 == 0x00000000) ERROR
> > 11/681 gtk:gdk / memorytexture
> > ERROR 0.98s killed by signal 6 SIGABRT
Context for Mesa maintainers: gtk4 fails one of its build-time tests
when built in a current sid environment. In this test, it fills a local
memory buffer with a random colour, uploads it to a GL texture, downloads
it using glReadPixels and compares each pixel with a matching in-memory
texture. The good result is that the colour is the same; the failing
result observed is that the texture is transparent black, rgba(0,0,0,0).
I can reproduce this test failure with sid's mesa 22.1.3-1, but not with
bookworm's mesa, so it seems like this is probably a mesa regression (or
possibly a mesa behaviour change that means what gtk4 is doing no longer
works).
I can also reproduce this test failure without needing to rebuild gtk4,
by using the installed-tests provided in the gtk-4-tests package. Steps
to reproduce:
# apt build-dep gtk4
# apt install gtk-4-tests xvfb xauth dbus
# adduser --disabled-password user
# runuser -u user -- xvfb-run dbus-run-session -- \
/usr/libexec/installed-tests/gtk-4.0/gdk/memorytexture \
|| echo "failed with status $?"
In a debian:bookworm-slim podman container, this test succeeds.
With all packages except for src:mesa upgraded from bookworm to sid, this
test still succeeds (see attached working-packages.gz).
With all packages *including* those from src:mesa upgraded from bookworm
to sid, the test starts to fail (see attached not-working-packages.gz).
The test has a lot of versions of the scenario that I described, for
different texture sizes, pixel encodings and upload/download pairs: you
can run it as
/usr/libexec/installed-tests/gtk-4.0/gdk/memorytexture -l
to list them, and then run with arguments like
/usr/libexec/installed-tests/gtk-4.0/gdk/memorytexture -p
/memorytexture/download_4x4/b8g8r8/gl
to run just one version.
>From a bit of experimenting, it seems like the pattern is:
* 1x1/*/gl: fails
* 4x4/*/gl: fails
* 192x192/*/gl: succeeds
* 1x1/*/gl-released: fails
* 4x4/*/gl-released: fails
* 192x192/*/gl-released: fails
The 1x1 or whatever refers to the pixel size of the test texture.
/gl is the sub-test that uploads the texture to GL and then downloads it
again. /gl-released is the same, but it also calls gdk_gl_texture_release(),
documented as:
Releases the GL resources held by a GdkGLTexture.
The texture contents are still available via the
gdk_texture_download() function, after this function has been called.
which seems to be implemented by downloading the GL texture into an
in-memory buffer which will be used as a source for subsequent downloads,
then discarding the actual GL resources. (I don't know why this makes a
difference to whether the 192x192 case succeeds.)
smcv
