chrg6 af06160284 Leave lazily armed memory out of the camera-speed search, so a sensitivity change no longer fetches GPU buffers. ...

camera_speed.c rewrite reads the guest's heap and alias regions in 16 MiB pieces under mem_read_hold and skipped only
untouched lazy-heap runs. A piece holding pages the lazy write-back had armed (GPU-written buffers the CPU has not
read since) faulted into memory.c lazy_fault on each armed range, which fetches it from the GPU under frz_lock while
the game runs, disarms those buffers, and keeps the game's mapping calls waiting on the read hold meanwhile. This
happened at every change of the stick sensitivity with the lazy write-back on (the Windows default except on AMD's
driver).

A piece that mem_lazy_touches reports armed is now gone through in 64 KiB steps, and the armed steps are not read;
the camera table never lies in a GPU-written buffer. The step after a piece still starts a little before its end, so
a copy across two steps or two pieces is found as before. The first search that leaves memory out logs how much,
since with NX2NAVI_WB_PROBE every range counts as armed and the search then reports the table "not in memory". A
range armed between the check and the read still costs one fetch, as before.

Not reproduced before the change (no log of a sensitivity change under trace). tests/camera_search_check.py cuts
factor and rewrite from camera_speed.c over a 40 MiB stand-in heap with one armed 64 KiB step: the copies in plain
memory, across two pieces and across two steps are rewritten, the copy in armed memory is left alone and no read
touches it, the left-out memory is logged once, and with every range armed nothing is read. Against the previous
camera_speed.c it fails six of its checks. mouse_stick_check passes, and the compile check adds no warnings.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-11-13 18:41:46 -05:00

15 KiB

Raw Permalink Blame History

View Raw