dri3: add an option to disable the Present wait-fence bridge

[lfdevs]

Summary

Add MESA_DRI3_DISABLE_PRESENT_WAIT_FENCE as an opt-in workaround for Android/Xwayland sessions affected by the Present wait-fence bridge introduced in PR #96.

Change

Setting the following environment variable skips initialization of the XSync Present wait-fence bridge and uses the existing flush path:

MESA_DRI3_DISABLE_PRESENT_WAIT_FENCE=1 glmark2

The variable defaults to false, so existing behavior is preserved unless the workaround is explicitly enabled.

This PR only adds the fallback switch. It does not change swap-interval handling or claim to fix the underlying compatibility issue.

[lfdevs]

@KiralyCraft Could you please help test on your devices whether this PR affects the fix in PR #96?

[KiralyCraft]

Of course, I don't have a wayland setup, but I can test on my current xorg-based setup. I'll give it a shot with wayland as well;

[lfdevs]

Of course, I don't have a wayland setup, but I can test on my current xorg-based setup. I'll give it a shot with wayland as well;

Testing with Termux:X11 is fine. I mainly want to confirm whether this PR reintroduces previously fixed issues such as screen flickering in X11 applications or games.

[KiralyCraft]

So I'm back. I tested 5f25a63d2c against its actual base, 11b5503fa2; This was on my Adreno 740 device with the paired Termux:X11 build, using separate private Mesa directories so that the installed packages and APK stayed unchanged from the Termux:X11 Choreographer-supporting variant.

So far, I have not reproduced the old OpenGL flickering in this test. The cube, horse, cat and moving-window scenes looked clean in the matched glmark2 recordings on both builds. I ran my Minecraft 26.1.1 instance also showed no visible flashes, so that's fine.

However, there is a substantial performance regression with swap_interval=0:

Test	Base containing #96	With #105
Uncapped glxgears, 640x480	about 3044 FPS	about 707 FPS
Full glmark2, 640x480	2193	638

I found a Redmi Pad Pro in my drawer, the 2405CRPFDC version (which unfortunately I cannot unlock, since I'm in Europe. No root here I'm afraid). This has the Adreno 710, but I will run the tests on this one as well to see if it behaves similarly to your 730.

It seems that with your fix, the ordinary KGSL flush waits for GPU completion on the CPU, whereas with PR96 Mesa submits rendering and then gives back a fence to overlap GPU and CPU.

I would not merge this yet, I'm studying this a bit more to see if I can come up with anything

EDIT: I am now replicating your setup on the 710 device with proot. Hope it crashes!

[KiralyCraft]

I managed to reproduce your freeze without this PR by using Anland’s KDE Plasma Wayland setup on my Adreno 710 device. The setup is:

• Redmi Pad Pro 5G, Snapdragon SM7435 / Adreno 710, stock Android 14, kernel 5.10.209.
• F-Droid Termux 0.118.3, running Debian 13 through PRoot, without root.
• Anland 5.13.3-compatible.
• KDE Plasma 6.3.6-2, patched KWin 6.3.6-95, and patched XWayland 24.1.6-91.
• Mesa 26.3.0-devel, build a1a9ac6cac. Its source tree is identical to 11b5503fa2, so it includes the merged Fix/kgsl present wait fence #96 changes but not dri3: add an option to disable the Present wait-fence bridge #105.

glxinfo confirms direct, accelerated rendering with FD710; XWayland reports its KGSL surfaceless EGL backend.

With vblank_mode=1, windowed glmark2 at 800x600 displays a frame and then stalls on the first scene. A scene configured to last three seconds does not complete before the 22-second timeout. I reproduced this repeatedly.

Keeping KWin and XWayland unchanged and switching only the client’s Mesa to this PR’s 5f25a63d2c makes the same tests complete. Keeping the baseline Mesa but forcing vblank_mode=3 also lets them complete. The async baseline still stalls, while both controls complete. This looks consistent with your reported failure, although I haven’t established whether the underlying cause is exactly the same.

[KiralyCraft]

I found an issue in xwayland where it waits on a frame’s fence again after it has already copied the frame and told the application that the buffer is free to reuse. By then, the application may have reset that fence for its next frame, so xwayland ends up waiting for the wrong frame and can get stuck.

Fixing this resolved the freeze on my Adreno 710 without any performance hit. I'll reference the PR for your xwayland repo here in a bit, putting things together now;

[KiralyCraft]

Done! I also added the fix we pushed to Termux:X11 with the wait-fence retrigger. My advice here would be to not merge this PR (#105) but instead to test the PR for xwayland. If that works, then the current status of Mesa can stay as is, without any further changes