Skip to content

LSFG: initialize loader data for adopted-device framegen command buffers - #7

Open
butilly wants to merge 1 commit into
releasefrom
fix/dying-light-lsfg-loader-fix
Open

butilly wants to merge 1 commit into
releasefrom
fix/dying-light-lsfg-loader-fix

Conversation

@butilly

@butilly butilly commented Oct 10, 2026

Copy link
Copy Markdown
Collaborator

Game: Dying Light (DyingLightGame.exe). Thread: 1558400197086937158.

Latest Legacy LSFG report on Adreno 840 / Proton 9 arm64ec remains at median 0 FPS and asserts in the Wine vkCreateSwapchainKHR host call. Logcat reaches Adopted-device caps immediately before the assertion, without a completed swapchain context. Shader-worker saturation is transient and ends around 13 seconds, so it is not the persistent failure.

The adopted framegen path allocates Core::CommandBuffer below the loader through Volk but omits the loader-data callback already used by Mini::CommandBuffer. Route the private Volk device resolver through a loader-aware allocation adapter, initialize each dispatchable command buffer, and release all allocated buffers if setup fails. Other calls stay on the next-layer device resolver. Add three startup-only fallback-image markers to identify progress through the exact initialization region.

This is a candidate fix, not a confirmed device result. No present-mode, image-count, shader or game-file changes; the Native app backend is unchanged. Verify the new build stamp, fallback descriptor ready, completed LSFG context and rendering with Legacy x2; compare against median 0 FPS and absence of those markers. If the assertion remains, the last marker narrows the next investigation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant