fix(vk): multi-second freezes and white foliage without mesh shaders: fallback pipelines on a worker and in the precompile #1512
No reviewers
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
1 participant
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot!1512
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/mesh-fallback-freezes-pipelines-on-worker"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
On a GPU without mesh shaders, the fallback compiled its compute pipelines inside the first draw, under one lock. AMD's compiler takes up to 12 s on one, so the game froze, and foliage and the door drew white until each was done. This builds them on a worker, and before play in the precompile.
Independent of the floor-grass and allocator PRs; they merge cleanly in any order. Part of splitting up #1023.
Problem
fallback_compute_pipelinesmade a program's task and mesh compute pipelines in its first draw, holding one global lock. Every recording thread stopped behind it. On an RX 5500M the game froze for seconds in the first room with foliage, and the door at spawn drew white until its pipelines were done.Change
fallback_pipelines_readybuilds them on a worker, exactly asdispatch()builds a compute program's pipeline:compute_state0/1/2 (otherwise only compute programs use it), andRX_VK_COMPUTE_SERIALas there. The draw that starts a build waits up to 50 ms for it, which covers NVIDIA's compiles. A draw while it's still compiling is left out, as a dispatch is.fallback_compute_pipelinesis now the build step. Its lock covers #1317's failure set and the program's pipelines, but not the compiles, so several programs compile at once. A failure is still remembered by key and variant before the return, and never retried.tests/test_mesh_fallback_failed_once.pypasses unchanged.precompile_runbuilds every fallback program's pipelines alongside the compute programs'.program_cache_load_somegets afallbacksflag, set only by the precompile, that loads every program translated for the fallback (kind 4), whatever the compute list from #1417 says. Right after an update is exactly when those are cold. Only a GPU without mesh shaders has kind-4 programs.The first start after a translator change compiles them all: on this laptop, about 15 minutes for 1,300 programs. The precompile's existing stall rule lets the game start while the last ones finish in the background. Later starts take them from the driver's cache in seconds.
Who it affects
Tests
tests/test_mesh_fallback.pychecks the worker, the draw, the lock's scope, the precompile and the program cache's load. The check fails on main without this change.test_precompile_compute_guard.pyextracts the precompile's compute branch, which is byte-for-byte unchanged.Tested on
precompile: ... 1300 mesh fallback programs in 2934 ms(driver cache warm)