fix(vk): preserve pending screenshots before readback slot reuse #1519
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!1519
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/capture-slot-ownership"
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?
A delayed normal screenshot can remain pending until another shot reuses its parity-selected readback buffer. The newer GPU copy is submitted before the old capture is read; waiting for the old timeline value can then attach newer pixels to the older frame's filename and flash analysis.
Snapshot the pending pixels before recording another write into their slot, then move that CPU-owned snapshot into the existing consumer. Another slot keeps its asynchronous path, and no pending capture adds no wait. Re-arming clears the saved snapshot. Capture format, generated-shot handling and game rendering stay unchanged; there is no global wait-every-frame policy.
Validation at
88bfc18on main60b0c9b:Host-cache visibility is separate in #1502. A private composition keeps its normal invalidation inside the new
shot_pixelshelper, after the wait and before copying; all six normal/generated/log coherent/noncoherent cases pass, including overwriting GPU bytes after the pending snapshot. Removing normal invalidation fails. This PR does not duplicate1502's changes. #1025's request path still needs the same ownership rule when integrated. Seedocs/capture-slot-ownership.md.Exact-head fork workflows follow. No game data, screenshots, captures, generated C or binaries are included.
Current-head validation
Current head
675367e, based on main7d1562d. Earlier local/runtime results describe their recorded source hashes.The standalone contribution patch is unchanged after the audited main refresh; exact-head build/source checks are refreshed below. Earlier runtime evidence remains tied to its recorded hash.
Fork runs are separate from upstream Actions approval; no maintainer approval gate is bypassed.