Use gamescope payload 20261023.4: shim thunks keyed by target, LSFG latch-grid pacing

Merged
UT
18d ago
+1-1

Description

Payload 20261023.4: 20261023.3 with the ICD shim built from gamenative-drm master e1f4474, and the bundled libgamenative_drm.so is the daemon from the same commit. The pair carries GameNative/gamenative-drm#15 (thunks keyed by target) and #14 (LSFG frames paced on the panel's latch grid; the daemon sends vsync notes to a shim that subscribes with the new capability bit, so shim and daemon ship together). The archive is live on both CDN URLs.

Dishonored DE (Epic, D3D9 through DXVK 1.10.3, Proton 11.0-2-x86_64-7, AYN Thor on Turnip) died ~11 s into a gamescope session at its first query reset: vkResetQueryPoolEXT Exception 0xc0000005 in Unix call, a branch to PC 0. The game's process creates two Vulkan devices: zink's first (API 1.2+, no host-query-reset extension, so that name resolved through the alias to Android's exported core vkResetQueryPool trampoline, valid for that device), then DXVK's (API 1.1, extension enabled, correct answer Turnip's own function). The shim kept one thunk per function name per process, so DXVK's device reused zink's thunk and jumped through an Android dispatch slot that is empty for a 1.1 device. The shim now keys thunks by target address, and its diagnostic logs are per device and uncapped (the old per-process caps had hidden the decisive line in two user logs).

Recording

Odin 3 (Adreno 830, Turnip Gen8 V37, gamescope) with the #15 shim before #14 landed: Vampire Survivors (64-bit DXVK, two devices in one process) 60 fps, Blazing Chrome (32-bit) 60 fps, Balatro (zink) ~277 fps; splash hides within 20 ms of the first-map note; no exceptions; no thunk retargets. Not run on the Thor; BrainBeat's next log should show thunk retarget vkResetQueryPoolEXT followed by a second thunk into libvulkan_freedreno.so.

Type of Change

  • Bug fix
  • Performance / stability improvement
  • Compatibility improvements
  • Other (requires prior approval)

Checklist

  • If I have access to #code-changes, I have discussed this change there and it has been green-lighted. If I do not have access, I have still provided clear context in this PR. If I skip both, I accept that this change may face delays in review, may not be reviewed at all, or may be closed.
  • This change aligns with the current project scope (core functionality, stability, or performance). If not, it has been explicitly approved beforehand.
  • I have attached a recording of the change.
  • I have read and agree to the contribution guidelines in CONTRIBUTING.md.