[DotDebian]

Follow-up to discussion boykopovar#357: materializeRegisterClear only exists on this branch, so the PR targets astrobot.

Problem

When a color target's DCC keys read as the register clear code, materializeRegisterClear clears the resident image to CB_COLOR_CLEAR_WORD. In Astro Bot those keys usually come from a key store the driver recorded itself (NoteKeysFillOnGpu) that the GPU has not run yet. FillClear then refuses with "keys pending", and the fallback waits for that store (SyncThrough) before clearing. That wait happens on the queue worker, every frame.

Change

The wait is not needed when the newest recorded writer of the whole key range is that noted store. ProvedCurrentDccKeys has already answered from the same memo (PendingStoreKeys), so the keys the GPU will hold are known, and they are the code this clear stands for. The image clear and the "uncompressed" key store that follows are recorded into the same queue behind the store, so they land after it. That is the same order the wait gave.

• KnownPendingDccKeys(meta, bytes) exposes that proof: it returns the keys of a pending noted store covering the range, and nullopt otherwise. It needs GpuMutex and never waits.
• FillClear takes pendingKeysKnown, which skips only the "keys pending" refusal. Its scan of the keys in memory still runs.
• Any other pending writer keeps the wait: a title kernel, a later partial or wider write, or a shadowed range. So do keys in memory (still from before the store) that the scan refuses.

APS5_NO_REGISTER_CLEAR_KNOWN_KEYS=1 restores the wait.

Measurement

Host: Windows 11, Core Ultra 9 285K, RTX 5080. Astro Bot (PPSA21564), -lvl hub_crashsite, 150 s runs. The CPU wait of this path dropped from about 145 ms to 4 ms per frame, and the image did not change.

That number comes from the same change on an older base of this branch: b58df66c plus my local stack, including boykopovar#637 for the Windows red-zone crash. I could not re-measure on 88d7bb62. On Windows that head needs a write-watch fix to get past SceSndzAudioOutMain (issue boykopovar#361). With boykopovar#637's commit cherry-picked, the old executable shows black frames, and a fresh relink crashes in RoomLoad_ATQT before the level. With the change on, [recorder] (APS5_PROFILE_DRAW=1) still shows the "recorded store" sync count dropping, but I would not quote those runs.

Tests

• agc_driver_recorder_tests (not part of the default ctest run):
  • pendingKeyStoreTests: the proof answers only for a pending noted store that covers the range. It returns nullopt when a later writer is over it or when nothing is pending, and asking never waits.
  • metadataPassTests: a register clear recorded behind a pending register-clear key store is refused without the proof and accepted with it, without waiting. After submission, memory holds the clear word and the keys are uncompressed.
  • The suite passes when drawInputReuseTests is skipped. That test already fails on 88d7bb62 without this change ("a shorter vertex read did not reuse the longer snapshot").
• ctest (Windows, MinGW g++ from WinLibs, Release): 297/299 pass. The two failures are recompiler ALU tests: agc_driver_f32_output_modifier (div:2 overflow) and agc_driver_scalar_sop1 (s_movrelsd_2_b32). This change does not touch the code they test.

Tested and written with AI assistance (Claude Code).

🤖 Generated with Claude Code

[oneandonlydean]

The astrobot branch is frozen and the work has moved to upstream main, where materializeRegisterClear and the noted key stores exist too (boykopovar#132, boykopovar#458). On Linux with an RTX 4090 the recorder tests pass and the waits from this path go away with the same frames: 101 to none at the Crash Site and 1,393 (3.2 s) to none through the title, menu and first level; the frame rate doesn't move here, because the wait is small on this host. I've ported it to main with you as the commit author (carry/fork3-register-clear-known-keys: the off switch and the comments are removed, and the tests run in ctest as agc_pending_dcc_keys). May I open it upstream with your commit, or would you rather open it yourself?

[oneandonlydean]

Thanks @DotDebian. This change is on boykopovar/AnyPS5 main now as a61c70f (via boykopovar#6247), so I'm closing it here. The astrobot branch is frozen; anything new is best opened against main directly.