Repository navigation
Adreno 740 / kgsl: FD_MESA_DEBUG=sysmem causes rendering corruption under Termux:X11 (glmark2 reproducer) #99
Description
Environment
Retroid Pocket 6, Snapdragon 8 Gen 2 (QCS8550, kalama), Adreno 740, Android 13 (unrooted)
Device kernel 5.15.123-android13-8-g17bf0404b059
Debian trixie under proot-distro (Termux); Termux:X11 with -legacy-drawing
Mesa 26.2.0-devel-20260709 (git-9452d1daec), installed by direct extraction
Also reproduced on 26.2.0-devel-20260610 (git-9c8bdb4f2e)
glmark2 2023.01 (Debian trixie)
Reproducer
Clean:
MESA_LOADER_DRIVER_OVERRIDE=kgsl TU_DEBUG=noconform glmark2 -b build --run-forever
Corrupt — black block-aligned horizontal bands over the scene:
FD_MESA_DEBUG=sysmem MESA_LOADER_DRIVER_OVERRIDE=kgsl TU_DEBUG=noconform glmark2 -b build --run-forever
Frame rate is unchanged between the two (~2,200-2,300 FPS), so only rendering is affected. Not scene-specific.. also reproduces on bump:bump-render=high-poly.
What I've narrowed down here..
Bisected from a sixteen-option set in five runs. These fifteen produce nothing: dclear, ddraw, noscis, nolrz, nolrzfc, nofp16, serialc, noblit, noindirect, nogrow, direct, nobin, notile, noubwc, inorder. Only sysmem does.
gmem is clean at a comparable frame rate (~2,100), so high frame rate alone is not sufficient - the sysmem path is required.
sysmem,gmem behaves as sysmem alone.
sysmem,flush does not help at unchanged frame rate, which argues the race is not at draw submission.
vblank_mode=3, capping presentation at 61fps, renders clean.
zink on Turnip, same device, same Mesa build, same scene: clean.
Note that msm can't be tested here - it falls back to zink silently as there's no accessible DRM render node on unrooted Android.
Filed upstream
I reported this to Mesa as #16189. Rob Clark's assessment was that it's likely an issue with the downstream patches (although he did say he's not familiar with what those are). He also filed #16195 proposing upstream support for Android/proot environments via kopper and said that kopper appears to solve some of these problems.
26.2.0-devel-20260610 already included #69, "Fix Termux:X11 presentation on KGSL", and the fault is present on that build and on 20260709 after two further upstream syncs. So it doesn't appear to be what #69 addressed.
A separate (and possibly related) fault
I also see black band corruption in an OpenGL application on this device under kgsl with no debug flags set. That one has been filed as Mesa #16184. That fault is not sysmem-dependent: it appears with and without the flag. gmem changes its character rather than clearing it - whole-screen flicker at a higher rate, with the band artefacts still present but covering less of the display. Whether the two share a cause, I haven't deduced at the moment. The resemblance is anecdotal only, judged by sight.
Am very happy to run any debug build, environment variable or trace that would help and thanks for your time and effort with this community.
Activity
lfdevs commentedon Aug 28, 2026
This is a known issue unique to the Adreno 740, please try adding the environment variable
FD_DEV_FEATURES=enable_tp_ubwc_flag_hint=1to see if the issue is resolved.If not, please try the build artifacts of these two PRs in sequence:
turnip/gen8branch #94shakeheartbreak commentedon Sep 2, 2026
I need to add a photosensitivity warning to the outputs I saw here.
On the game workload,
FD_DEV_FEATURES=enable_tp_ubwc_flag_hint=1 produces constant full-screen white
flashing with small black pixelated patterns over both 2D and 3D. It is
headache-inducing and in my judgement a seizure risk. So anyone asked to reproduce it should be warned of that.
On the glmark2 reproducer, the flag is inert. One note - the command in your
reply omitted FD_MESA_DEBUG=sysmem, without which glmark2 under kgsl is already
clean here, so it discriminates nothing. Reconstructed:
FD_DEV_FEATURES=enable_tp_ubwc_flag_hint=1 FD_MESA_DEBUG=sysmem
MESA_LOADER_DRIVER_OVERRIDE=kgsl glmark2 -b bump:bump-render=high-poly
FD740, no invalid-feature warning, so the flag did take. I saw 2036fps, with black corruption bands unchanged.
It didn't fix the artefacts either on the game itself.
The fallback does fix it. On PR #96 with KiralyCraft's paired Termux:X11 build fc534e5, this issue's reproducer is clean on bump:high-poly, build, terrain and ideas. The game's artefacts are gone too, along with the allocator crash - 33 scudo OOM aborts and 1,353 scudo lines both to zero.
Since this fault is frame-rate dependent, I checked that the clean result is not just #96 being slower. And it's not:
baseline 9452d1d, 2048x1536: 904 fps, corruption
#96 91f7e8c, 800x600: 815 and 839 fps, clean
The old build corrupts at a rate below where the new one stays clean, same scene, same flag, same boot. The fix is real!
Attribution: rolling Mesa back to 20260709 with fc534e5 still installed brings the bands back, so #96 is necessary and fc534e5 alone is not sufficient.
Whether #96 alone suffices I cannot test - that pairing produces the allocator runaway that kills X11 for mr.
One cost figure, since #96 is unmerged on performance grounds. Same boot, A-B-A, version printed per run: bump:high-poly 2147/2158 baseline against 839/815 on #96, build 2061 against 1078/1069. That is 48-61%.
On my actual workload - a game running at ~50fps - the cost is inside noise: 52.58 silent / 47.38 with audio against 54.4-56.6 and 47.0-47.8 before #96, run-to-run spread 0.70fps.
Adreno 740, Android 13, Debian in proot, Termux:X11 with -legacy-drawing. Anything else that might be useful to you, please just give me the nod.