[jordanella]

Two pieces of bookkeeping in vk_memory.cpp that run at every write-back, and so at every recording split (~20 a frame in Kokiri Forest), cost ~4-6% of the replay thread in the sampling profiler (HOS_SAMPLE=Presentation). Both now keep exactly the same contents and answers, at less cost:

1. cpu_words (the words the replay writes on the CPU, cut out of mirror write-backs). Each merge appended every new word to the sorted vector, ran inplace_merge over all of it (up to 65536 words), then de-duplicated the whole thing again. Report words arrive at new addresses all the time, so this ran in full at most write-backs. Now words already kept are skipped first, and new ones go into a second, small sorted set. That set is merged into the big one only once it reaches an eighth of the big one's size (at least 4096 words), and the write-back cut walks both sets in order. Same words, same 65536 limit.
2. wb_pages (each guest page a write-back covers, with the timeline value a CPU read or a capture waits for) was an unordered_map with one insert per page of every write-back. It's now a map of 2 MB regions, each with a 512-entry page array, and the last region is cached for the next page: one lookup per 512 pages instead of a hash insert per page. Same values (0: none; 1: written back long ago, which the pruning sets), same pruning at 200000 pages.

Measured on a Ryzen 9 3900X with an RTX 3080 on Windows 11. Kokiri Forest, standing still after loading a save, headless, input timed in game frames (HOS_INPUT_FRAME_CLOCK=1), live numbers over presents 3120-5520:

build	runs	fps	replay per frame
main	2	34.7 / 35.1	23.6 / 23.4 ms
this branch	2	35.7 / 35.6	22.9 / 22.9 ms

How much this saves depends on the scene: on how much GPU-written memory goes back each frame, and how many counter reports the game makes. I expect more where GPU-driven effects and occlusion queries are heavier, and little in simple interiors.

The numbers were measured on v2.0.5 (232eecb). The branch is rebased onto main 3b4347d; the rebase did not change the patches (git range-diff), and vk_memory.cpp has no upstream changes since. python -I -B tests/run_all.py: 104 passed, 3 failed, 13 skipped on Windows. The three failures (test_changelog.py, test_fps_overlay_order.py, test_precompile_compute_guard.py) fail the same way on main 3b4347d on this machine. This PR also updates tests/test_report_words.py, which compiles cpu_words_merge and cut_cpu_words out of the source into a fixture: it now takes sorted_merge and the second set, and adds cases where kept and new words are cut together. With the cut's walk over the recent set removed, the fixture fails.

🤖 Generated with Claude Code

[jordanella]

Thanks for the careful review. Three commits address it: cd70a0a, bca9997 and 6f66a61; details inline. I re-measured on the same setup (Ryzen 9 3900X, Kokiri Forest, standing still, two runs): 35.8 / 36.0 fps, against 35.7 / 35.6 for the previous version and 34.7 / 35.1 for main. tests/run_all.py gives the same result as main: 104 passed, plus the same three failures that main also has on this machine.

[jordanella]

Thanks for the approval. I took all five nits:

• WbPages comment (44208c9): it now says what the table holds and why values are never lowered, and names the three readers: memory_writeback_value's ever and its value against the GPU's progress, and the capture's wait.
• Skipping null chunks (44208c9): memory_writeback_value reads its range through WbPages::max_in, which steps over a whole chunk that was never made. The new tests/test_wb_pages.py builds WbPages from the source with small chunks and checks values per page, ranges over missing chunks, both chunk edges, the table's end and the ever flag. A range read that stops short of a chunk's or the range's last page fails it, through a timeout, since such a loop never moves on.
• The dead clear in memory_cpu_owned (30f2b01): removed. It couldn't fire on main either.
• Repeats (9baca70): check_repeats merges a batch containing the same word twice, then a word that's already in the recent set. Taking out either the unique or the recent set's binary_search now makes the fixture fail.
• RX_VK_WB_REPORTS (9baca70): the fixture now runs with it removed from the environment, so check_clear passes even when the caller has it set.

tests/run_all.py: 105 passed (the new test included), plus the same three failures main has on this machine. One run in game on the same setup showed nothing different: readbacks behaved as before, and fps was within the earlier runs' range.

[jordanella]

Main is merged in. Meanwhile main took narrower versions of both changes: 4ca115a leaves report words already kept out of the merge, and da44bd4 hashes the write-back page map by page number. I kept this branch's versions, since the recent set already includes 4ca115a's filter and the chunks need no hash at all. The capture's wait takes main's new late-page list (ab68f35) with the chunks' lookup. test_report_words.py keeps both sets of tests: main's randomized merge test now checks both sets together over 800 rounds, enough that the recent set is promoted along the way.

Re-measured on main 8b2e1d3 (v2.0.8-rc.1), Ryzen 9 3900X, Kokiri Forest, two runs each in two rounds: 38.6 / 37.8 fps standing against main's 36.8 / 36.3 (+4.5%, replay 21.3 against 22.5 ms a frame), and 35.5 / 34.1 panning against 33.9 / 34.9 (+1.2%). tests/run_all.py: the same 12 failures as main on this machine (missing tools and an older g++), and everything else passes. Main moved again after the measurement and is merged in too (016d582). Its write-back diff (55036ef) has memory_cpu_owned call shadow_written, so the report-word fixture, which builds that function for check_clear, stubs it.