Repository navigation
fix(vulkan): remove pending shader variants when job submission fails - #130
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Graphics and mesh program selection cache a not-ready Program before preparing its background job. If state/code copying, capture allocation or enqueueing throws, the cached Program has no job to complete it: subsequent selection returns that pending entry and a draw can wait indefinitely. Roll back that new entry on submission failure so later attempts can retry.
Wrap each asynchronous preparation/submission block in a catch-all that removes its just-added variant and rethrows the original exception. Both callers retain shader_mu for the entire operation, so another selector cannot observe the entry before successful submission. If jobs_push returns, ownership remains in the cache for the accepted callback; it is not removed. The queue either inserts successfully or throws before acceptance, and has no throwing operation after insertion. Unwinding destroys temporary captures before the catch removes the Program. Synchronous compute/forced-sync translation and successfully submitted job execution retain their existing behavior.
The regression compiles actual production Program creation, Job metadata/copies, captures, submission and rollback statements. Authored state/code structures and a small queue use real C++ allocation failures. On unchanged main a failed preparation leaves the extra variant and fails the regression. With the fix, 48 cases (44 allocation failures) cover graphics/mesh with optional stages present/absent, preserving an earlier cached variant, retrying every rejected attempt, and executing accepted callbacks to completion. The callback only models readiness, not translation or Vulkan; no game data, driver, real OOM or gameplay stall measurement is involved. The existing real-worker/wait-stealing regression passes too.
Found during #18's lifetime audit; this is a reproduced orphaned-pending-state bug, not proof of the reported gameplay RSS growth. #129 corrects enqueue counters separately and is not required for this cache rollback. Published tree def1c1c3066518ef57659b2c989badb3b7abe816 matches the local staged tree; full local suite finished with 285 passed, the same 12 known host/tool-dependent failure paths, and 56 skipped. Fresh hosted Windows/Linux source/packaging checks are pending. Keep draft until validation completes.