Repository navigation
Release stale app timing data and deferred frame-type presents - #702
Merged
markgalvan-intel merged 1 commit intoOct 16, 2026
Merged
markgalvan-intel merged 1 commit into
markgalvan-intel merged 1 commit into
Conversation
| // last one stays deferred forever once the runtime stops typing frames (e.g., XeSS-FG | ||
| // switched off or replaced by another frame generation), blocking every process until | ||
| // the completed ring overflows. | ||
| deferredPresent->WaitingForFrameId = false; |
Collaborator
There was a problem hiding this comment.
This works for the stall in #695, but this block only runs when mReadyCount == 0, which depends on how far the output thread has dequeued, not on the trace. So the same ETL can release a typed present in one run and keep it in the next. If it's released before its partner completes, the partner no longer finds it in the merge loop and loses its AppPropagated* data. We saw this as intermittent gold failures on internal XeSS-FG captures. We're accepting it as is and will replace it in a follow-up PR with a release driven by the trace: the next later-started present from the same process, plus a 2 s backstop based on trace time.
markgalvan-intel
approved these changes
Oct 16, 2026
markgalvan-intel
left a comment
markgalvan-intel
left a comment
Collaborator
There was a problem hiding this comment.
Thank you for the PR. Code looks good. Appreciate the contribution!
markgalvan-intel
added a commit
that referenced
this pull request
Oct 16, 2026
Replace the WaitingForFrameId reset added to the stale-deferral block in #702 with a deterministic release rule. That reset only ran when mReadyCount was 0, so it depended on how fast the output thread dequeued presents. This made ETL results vary between runs and could release a generated frame before its partner merged the propagated data. A present waiting for a PresentFrameType partner is now released when: - a later-started present from the same process completes, whether or not it has a PresentFrameType (e.g., frame generation was turned off), or - any present that started more than mDeferralTimeLimit later completes (e.g., the process stopped presenting). A limit of 0 releases on the next later-started present, matching the documented meaning of 0. An earlier-started present that completes late does not release a waiting present. Only a typed successor with the same FrameId takes the propagated data from an Intel_XEFG present. Add PresentFrameTypeDeferralTests to the CMake and Visual Studio unit test projects. Update the AuxData lock to the regenerated gold CSVs for test_case_7, 8, 9, 11 and 12 (default and _v2), which reflect the app timing pruning from #702 and the new release rule.
planetchili
pushed a commit
that referenced
this pull request
Oct 21, 2026
Replace the WaitingForFrameId reset added to the stale-deferral block in #702 with a deterministic release rule. That reset only ran when mReadyCount was 0, so it depended on how fast the output thread dequeued presents. This made ETL results vary between runs and could release a generated frame before its partner merged the propagated data. A present waiting for a PresentFrameType partner is now released when: - a later-started present from the same process completes, whether or not it has a PresentFrameType (e.g., frame generation was turned off), or - any present that started more than mDeferralTimeLimit later completes (e.g., the process stopped presenting). A limit of 0 releases on the next later-started present, matching the documented meaning of 0. An earlier-started present that completes late does not release a waiting present. Only a typed successor with the same FrameId takes the propagated data from an Intel_XEFG present. Add PresentFrameTypeDeferralTests to the CMake and Visual Studio unit test projects. Update the AuxData lock to the regenerated gold CSVs for test_case_7, 8, 9, 11 and 12 (default and _v2), which reflect the app timing pruning from #702 and the new release rule.
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.
Fixes #695.
App timing data now expires based on its newest timestamp, even when AppPresentStart is missing. This also removes stale PC latency data from other processes. WaitingForFrameId is cleared at the deferral limit, so the last typed frame cannot block output after frame generation is switched off.
In the original Bodycam retest, memory stayed around 8 MB and CPU at 0.1% over 86 minutes. The Assassin's Creed Shadows retest had no ring overflow after disabling XeSS-FG; the previous stall lasted about 60 seconds.
Built with VS2022, Debug x64. All 18 checked-in Gold ETL/CSV comparisons and 7 local regression tests passed. Three of those regression tests fail against the unpatched upstream consumer.