mirror of
https://github.com/boykopovar/AnyPS5.git
synced 2026-10-22 08:33:12 -05:00
raghav314andClaude Opus 5.5
be1f501525
The registry calls an observer on the mapping thread, after the registry lock is released, with the ranges a kernel mapping gave GPU access: direct and flexible maps with it, and fixed remaps with it over a registered range (a reservation). The mutation looks them up while it still holds the lock and hands them over weakly, with the registry generation it ended at, so the observer does not keep a range alive. The driver imports those ranges on its current device, so an address-based build finds the import instead of pinning the memory on the queue that first uses it. A range that gains GPU access through sceKernelMprotect, and AnyPS5's own libc heap, are still imported on first use. The import at map does not reconcile the other imports with the registry, so its cost does not grow with the number of imports. It skips a range that is gone, and any range when the imports were reconciled with a newer registry since; the next lookup imports those as before. It installs the pin waiter as the other import paths do, so unmapping a range imported at map retires its import. The live import bytes are kept as a running total instead of being summed over every import. Once the import table belongs to the current device the import takes only the table's lock; the first import on a device (which runs the write-watch probe) and a device that was just replaced go through the GPU lock. Clearing the observer waits for calls already running. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>