[thehobbit85]

What and why

The automatic real-time CPU budget was measured on every texture acquire, so multiple acquires split a frame's CPU work and underdeclared its budget. Global sampling and policy state also mixed different threads' CPU clocks: a replacement acquire thread could skip its initial policy and subtract another thread's clock.

Sample the first acquire after a present and keep the CPU samples, declared budget and policy period per thread. Preserve the existing estimation window, margins, cap, fixed-budget mode and disabled mode. A synthetic test exercises the real acquire path while replacing only the operating-system CPU clock and policy submission; CI runs its automatic, fixed and disabled modes without a GPU.

Related to #1985. These are reproduced scheduling defects; whether either explains OoT's Castle Town slowdown remains unverified. Finding: budgets sampled per acquire or across threads, linked from the OoT note.

Checked

• Apple M2 Max, macOS 26.6; synthetic inputs only, no game files and no actual real-time policy granted to tests.
• Full standalone graphics suite: make -j4 -C dm/gfx/tests GAME=0400486024DEC000 run — passed.
• make -C dm/gfx/tests GAME=010015100B514000 -W t_rt_comp.c check_t_rt_comp also passed with CI's Wonder profile.
• New regression: 735 automatic-mode checks, 243 fixed-mode checks and 243 disabled-mode checks passed. Seven assertions failed with the original implementation. A 6 ms frame split across two acquires now declares 7.5 ms instead of 3.75 ms; this is a controlled CPU-clock test, not a gameplay speed measurement.
• Tool/documentation suite: python3 -m unittest discover -s dm/tools/tests — final run: 1,435 tests; 1,411 passed, 23 skipped, one inherited failure. The inherited ABI-literal-ratchet failure in unchanged nvn_mtl.m also reproduces from pristine base revision 976fbd57f5cbee1f374453c2450c92ffd9f20dbc.
• The first full tool run also failed the unchanged test_triage_report.Report.test_main_load stdout assertion; it passed both alone and in the full rerun.
• Independent review completed. Compilation database generated; clang-tidy was unavailable locally. git diff --check passed.
• scripts/regress.py impact BASE..HEAD was run. Usage coverage is unknown; no gameplay regression run was possible without game files. Intended checks: OoT (0400486024DEC000, reported scheduling slowdown), Pokopia (0400A3A01EE4C000, NVN2), Monster Hunter Rise (0100B04011742000, engine frame limiter), Fire Emblem Engage (0100A6301214E000, Unity), and Super Mario Bros. Wonder (010015100B514000, Nintendo NVN). None is claimed gameplay-validated by this PR.
• Remaining estimation limitation: CPU work a thread performs during a handoff can inflate its next sample when it returns, within the existing cap. No speculative reset heuristic is added.

Docs

• Durable reference finding, game-note link, and regenerated symptom index.
• No shader-chain change; no game files, keys, extracted game data or agent work logs in this change.

[seedds]

Thank you: the diagnosis holds and is on main in b06f4e0 (you are credited as co-author), on top of PR #2569 (4c71083), which rewrote this code. Sampling once per presented frame came with #2569. The per-thread part is now a slot per acquiring thread, so each thread's CPU clock and policy are its own, and a thread that stops acquiring for 120 frames goes back to the standard policy. Your acquire-path test is in as dm/gfx/tests/t_rt_comp.c, adapted to the new code: it runs its auto, fixed and off modes in one call and is in CI's CPU-only list. Whether this played a part in #1985's Castle Town slowdown is still open, so that issue stays open.