feat(memory): track changes to mapped address ranges

[TibixDev]

Status after review

Do not land range history without its first consumer.

Audited the actual compare commits: this head contains the two targeted-lease/range-update commits from #1324 and the history commit. Its new validation API is used by its tests, with no production history consumer in this PR. That remains a valid blocker.

Main now has a range invalidator for page states and a GPU-map observer for imports. These are not automatically equivalent to retained-history queries, but a proposed import consumer must show why the existing notifications are insufficient before adding another 1,024-entry mechanism. #1366 was rebuilt without this API, so it is no longer a reason to land it. If #1361 is revived with measured benefit, its first real history consumer should be developed and reviewed together with the history implementation. No mechanical adoption of the suggested rebase or standalone API push.

What

Record a bounded history of changed guest address ranges. A cache can keep an unchanged range across unrelated mapping changes. Overlapping changes and expired history reject the proof. Record changes during main-image registration too.

Tested

Earlier branch-specific tests and measurements remain in the discussion. They have not been rerun on a redesigned current-main version of this PR. The review audit and shared NGS-assisted title exploration do not establish that this head is merge-ready. No full Linux/Windows platform CI was dispatched in this pass.

Checklist

• Current-main implementation and outstanding review requirements complete.
• Isolated title benefit / reference validation established where required.
• Depends on: perf(memory): restrict registry work to affected ranges #1324; must be reviewed together with a real consumer such as perf(agc): reuse import decisions across mapping changes #1361.
• AI-assisted: yes.

[TibixDev]

Rebased on 58a1bd66. Kept both mapping-history and upstream time-conversion test registration, including Windows paths. The upstream mprotect tests are also retained.

Fedora 44 Release: guest_memory_tests, guest_mapping_history_tests, guest_time_conversion_tests build; the targeted tests and contribution checks pass. Windows CI is pending.

[rmz-24]

Windows run: Windows 11 Pro 25H2 (10.0.26200.9457), RTX 5060 Ti (NVIDIA 617.42), MinGW-w64 GCC 15.2.0 (WinLibs r7), Release, -DANYPS5_ENABLE_SPIRV_TOOLS=ON, full build plus libs. 7fe5e9c cherry-picked onto current main d70b899 (applies cleanly).

• guest_mapping_history and agc_driver_graphics (which carries the GuestAllocations.cpp cases) pass.
• Full ctest: 511/511.

AI-assisted: yes

[blawesom]

Hi! This PR currently conflicts with main, so I rebased its 3 commits onto the latest main. This one interleaved heavily with main's newer GuestAllocations work, so the rebased branch combines both:

• replaceRange: this PR's RangeReplacement/fragments machinery is kept, with main's newer gpu parameter threaded through the insert lambda and Range literals.
• GuestAllocationsAcquireRange: renamed to _nid_no_patch as in the PR, alongside main's AcquireAll.
• UploadFinish import lookup: the PR's targeted-lease logic is kept, with its importAllocation call adapted to main's current 4-argument signature.
• GuestAllocationsEnd: the PR's publishChanges (which now bumps the generation itself) replaces main's raw fetch_add, with ended loaded after it for main's gpu-map observer.
• registerImage: main's newer multi-image refactor is kept — it supersedes this PR's main-image-only registration export.
• The tests were updated for main's gpu parameter on Mutation::Add/Protect.

It builds, and guest_mapping_history_tests plus the affected agc suites (bda_device, graphics, mesh, shader_memory, write_tracking) all pass locally.

The rebased branch is available to pull:

git fetch https://github.com/blawesom/AnyPS5 rebase/pr-1360
git reset --hard FETCH_HEAD

Feel free to ignore this if you'd rather rebase yourself.

[adriadam10]

Thanks for the work here. This can't be merged as is:

• It is stacked on #1324, #1357 and #1359. All three are still open and conflict with main, so nothing here can land before them.
• This head also conflicts with main (GuestBufferMemory.cpp, libc/CMakeLists.txt, GuestAllocations.hpp, GuestAllocations.cpp). The conflicts are in replaceRange and the host-import lookup, so they need the author, not a mechanical rebase (the rebase suggested in the thread merges both versions of that logic and hasn't been pushed here).
• GuestAllocationsValidateMapping_nid_no_patch and the 1024-entry history have no caller in this PR; only the new test uses them. Please land it together with its first consumer (#1361/#1364/#1366), or say which existing code uses it.
• GuestAllocationsAcquireRange_nid_no_patch is wired into GuestBufferMemory.cpp as a perf change. Please name a title/scene where it helps: on #1324 @oneandonlydean measured no frame-time change and the question is still unanswered.

Please rebase once the base PRs are merged (or fold the stack so each PR keeps one topic) and we will review it again.

[TibixDev]

Review-pass update:

Audited the actual compare commits: this head contains the two targeted-lease/range-update commits from #1324 and the history commit. Its new validation API is used by its tests, with no production history consumer in this PR. That remains a valid blocker.

Main now has a range invalidator for page states and a GPU-map observer for imports. These are not automatically equivalent to retained-history queries, but a proposed import consumer must show why the existing notifications are insufficient before adding another 1,024-entry mechanism. #1366 was rebuilt without this API, so it is no longer a reason to land it. If #1361 is revived with measured benefit, its first real history consumer should be developed and reviewed together with the history implementation. No mechanical adoption of the suggested rebase or standalone API push.

I have updated the PR description to match this status. The PR remains open; the outstanding review requirements are not being marked resolved. AI-assisted audit.

[oneandonlydean]

Closing for now: no title is known to need it. With the queue this large we're closing stalled perf PRs that don't show a gain in a title; reopen it with before/after numbers from a title scene (the summary lines from the performance report form) if you pick it up again.