Flashing artifacts in most 3D games

[KiralyCraft]

I'm running the latest version on my Adreno 740. Most 3D games I try have these flashing artifacts. This also happens in Firefox for instance, where elements on the page flash to black. I'm running Arch here.

screen-20260405-094606.mp4

[lfdevs]

The current Freedreno (KGSL) driver under Termux:X11 has incomplete support for vertical synchronization and some advanced graphical features, which requires more work from Mesa upstream. However, you can individually modify the environment variables for launching applications that are significantly affected, changing the value of MESA_LOADER_DRIVER_OVERRIDE from kgsl to zink to use the Turnip + Zink combination, which usually reduces graphical issues such as flickering and tearing.

BTW, if you need to run Windows games, I recommend trying whitebelyash's Turnip driver. He has applied more optimization patches for gaming scenarios to the upstream source code, which might solve some issues.

Regarding browsers, I recommend using Chromium because it has better compatibility in GPU-accelerated scenarios.

chromium --no-sandbox --use-angle=vulkan --enable-features=Vulkan,VulkanFromANGLE

[KiralyCraft]

Will try, thank you for the answer. The games I'm trying to run are all natively compiled, not Wine'd; This one is the source engine from here: https://github.com/nillerusr/source-engine

Similarly, reVC has some glitches in the current KGSL scenario. I will take a look at using Turnip + Zink instead. I've given it a try already and vulkaninfo seems to work correctly at least. I think i still had the driver override set to kgsl unfortunatey, so despite having it installed it was not configured correctly. Will report back asap.

EDIT: This is a plain rooted + chroot scenario, no proot.

[hansm629]

@lfdevs
Interestingly, with Freedreno KGSL, flickering is not very noticeable with the Adreno 840.

It is more noticeable than expected with the Adreno 830, and it is even worse with the Adreno 7xx series.

Could this also be related to the Mesa upstream?

With the Adreno 840, Freedreno KGSL seems stable enough for practical use.

[KiralyCraft]

It seems that using zink instead of kgsl has two effects. Mainly, the artifacts seem to be gone, while performance is lower (though I expected this). However, in hl2, when starting a game like this after loading the map I'll get a Mesa: DEVICE LOST error and the game will be frozen. reVC also behaves normally with zink in the beginning, but crashes/freezes shortly after in-game (with some frame replaying and black flickering across the lower half). OpenXray works correctly, though performance is degraded and there is significant input lag compared to kgsl.

[lfdevs]

@lfdevs Interestingly, with Freedreno KGSL, flickering is not very noticeable with the Adreno 840.

It is more noticeable than expected with the Adreno 830, and it is even worse with the Adreno 7xx series.

Could this also be related to the Mesa upstream?

With the Adreno 840, Freedreno KGSL seems stable enough for practical use.

I believe so. As Rob Clark, who did the core adaptation work for the Adreno Gen 8 open-source drivers, mentioned in some MRs, he initially only had Adreno 840 machines for testing. Therefore, I suspect that the fact that open-source driver adaptation for other GPU models is not as good as for the Adreno 840 might be related to this.

[lfdevs]

It seems that using zink instead of kgsl has two effects. Mainly, the artifacts seem to be gone, while performance is lower (though I expected this). However, in hl2, when starting a game like this after loading the map I'll get a Mesa: DEVICE LOST error and the game will be frozen. reVC also behaves normally with zink in the beginning, but crashes/freezes shortly after in-game (with some frame replaying and black flickering across the lower half). OpenXray works correctly, though performance is degraded and there is significant input lag compared to kgsl.

The Mesa: DEVICE LOST issue might be alleviated by specifying the environment variable TU_DEBUG=sysmem, see the Release notes of whitebelyash's repository: https://github.com/whitebelyash/freedreno_turnip-CI/releases/tag/tu_v24

[KiralyCraft]

That seems to have solved it. Now the things load correctly with zink and sysmem. Although they are rendering correctly (albeit with lower performance than kgsl), there is quite a bunch of screen tearing in all games, despite using things such as VSync. I assume this is better than colorful artifacts anyway, so that's nice. Thanks for the suggestions thus far, it's been great;

[natsumerinchan]

Try add FD_DEV_FEATURES="enable_tp_ubwc_flag_hint=1" to /etc/environment

[KiralyCraft]

Try add FD_DEV_FEATURES="enable_tp_ubwc_flag_hint=1" to /etc/environment

Unfortunately, it does not seem to make a difference as flashing is still asvisbile as before. I did not check for a regression in performance however

[KiralyCraft]

I made some progress here. I found a flag called -gl_disable_arb_buffer_storage trial and error which fixes the artifacts in HL2. A Codex summary of my findings, with the codebase in mind:

• The argument -gl_disable_arb_buffer_storage makes Source pretend that the
  GL_ARB_buffer_storage extension is unavailable, disabling its optimized system of
  permanently mapped, coherent vertex and index buffers that the CPU rewrites while
  the GPU renders from them. Source instead uses older, more explicit upload
  methods such as glBufferSubData or temporary mapping followed by flushing and
  unmapping. Because this eliminates HL2’s flashing without disabling KGSL, GMEM,
  shaders, or hardware acceleration, it suggests that the problem involves
  Freedreno/KGSL handling of frequently rewritten persistent/coherent vertex or
  index buffers—possibly incorrect CPU-to-GPU memory visibility or the GMEM binning
  and rendering passes observing different buffer contents—rather than the final
  X11 presentation path. However, the standalone test did not reproduce it, so the
  exact Source-specific trigger remains unidentified.

[KiralyCraft]

@lfdevs can you please re-open this? I figured out that this issue does not happen with #101 on a leased HDMI display, but it does happen with Termux:X11. I need to investigate it some more, hence I'm not sure this is complete.