Fix/kgsl present wait fence

[KiralyCraft]

A Codex assisted patch which attempts to fix reading buffers too early and causing flash-to-black issues in scenarios like Firefox GPU-enabled rendering, Minecraft, reVC and others.

I am not 100% sure what is going on here, but I can confirm this works on my Adreno 740 with KGSL with no significant performance drawbacks (-20% on glxgears compared to unfixed version: 1757 fps original vs 1337 with this patch).

This is accompanied by a fix to Termux:X11 where it does not correctly handle some callback disarming: KiralyCraft/termux-x11@fc534e5

EDIT: I do not completely trust what is going on here, but I can confirm it is reliable on my device. It might be better to rework this for better integration and style adaptation.

[lfdevs]

In my testing with an Adreno 730 device, when the graphics API of Minecraft Java Edition is OpenGL, the version built by this PR fixes the game screen flickering issue compared to the version before modification. However, the scores of glmark2 and vkmark dropped significantly, so I will not merge this PR for the time being.

It is recommended to keep the PR status as "draft" so that people with similar needs can obtain the build artifacts more easily.

[KiralyCraft]

Should I investigate a solution which doesn't plummet the performance of glmark2 and vkmark ? Currently, correctness was a greater importance at the cost of performance

EDIT: This does not fix the artifacts in #44

[lfdevs]

EDIT: This does not fix the artifacts in #44

Currently, it seems that the flickering issue is particularly severe on the Adreno 740, and I am unable to reproduce this issue on either Adreno 730 or 830.

[KiralyCraft]

Just some more updates about the 740 situation. It seems he following now render correctly: Firefox with GPU acceleration, OpenXray, OpenMW, OpenJK, reVC and etLegacy (alongside of Minecraft). No more flickering, albeit performance is reduced. However, it seems to be better than the zink variant. I'll run some numbers when I get some more time.

[shakeheartbreak]

So I tried the #96 build artifact on an Adreno 740 (Termux:X11, Debian trixie proot)..

With it installed, my 32-bit OpenGL application running under box64 kills Termux:X11 within a few seconds under kgsl. logcat shows Scudo exhausting 33 size classes in sequence, from 48 bytes up to 131088, over about 7.4 seconds, in the LorieNative process - popped counts in the hundreds of thousands with pushed at zero, and rss 0K on every region.

Controls: the same application under zink is fine, glxgears and glmark2 under kgsl are also fine and the same application under kgsl on the unpatched 20260709 release produces no scudo output at all.

IIt' might be worth noting that 'm running stock Termux:X11, not the fc534e5 build. Is that commit required for #96 or should the Mesa half work standalone? Appreciate your help.

[KiralyCraft]

Yes, build fc534e5 in Termux:x11 fixes the issue where a Present wait fence callback remains registered after it fires. It is not simply an allocation leak. When the X server restarts its Sync trigger list scan, it can invoke the same callback repeatedly. Because that callback reexecutes and may requeue the same Present request for a future vblank while its fence remains alive, the request can be processed multiple times and eventually crash the X server. The patch unregisters the callback before reexecuting the Present request, making the callback execute only once.

I may be able to upload the necessary APK here if it would be easier for you; EDIT: Here it is, of a different commit but it contains the fix:
termux-x11-universal-debug.zip

[shakeheartbreak]

Superb reply and thank you. Your post explains the log better than a plain leak would - the allocation growth accelerated across 33 size classes in about 7 seconds rather than climbing steadily in one and every region reported rss 0K, which fits requests being duplicated rather than filled.

It also fits my controls: glxgears and glmark2 under kgsl were both fine on the same build and they presented at a steady cadence.

The APK is super helpful as I have no Android toolchain set up here. I'll reinstall the #96 Mesa build alongside it and report back on whether the crash goes away and what the artefacts do. Thanks again!