[alfalfa-star]

What

#2096 keeps a copy of a storage image's guest bytes so that Refresh can compare memory the write watch doesn't cover. Its host-import upload path takes that copy only when the range is unwatched (GuestMemory::Watched). The DCC fast-clear path, however, takes it on every upload: originalValid = false became an unconditional captureGuestBytes(nullptr).

Reading the whole surface goes through the flush hook. For a surface a unit shadow covers, every 64 KiB block records a publish and waits for the GPU (FlushForAccess → PublishShadowsOnly → SyncThrough). Stack from PPSA14632, sampled at those waits: Driver::dispatch → ShaderResources::Revalidate → cachedStorageTexture → StorageTexture::Refresh → upload → captureGuestBytes → ReadCommitted → FlushForAccess.

The clear path now resolves the surface's host import first, because creating it can unwatch the range (a compared host-pointer import does). It takes the copy only when the range is unwatched after that, like the import path. Write-watched memory, such as Linux direct memory behind a dma-buf import (which keeps write protection), skips the read. A range that becomes unwatched only later re-uploads instead of comparing, as it did before #2096.

agc_driver_dcc_keys_first_write now checks that a fast-cleared upload keeps the copy exactly when its range is unwatched at that point. In the default run, the test block's host-pointer import is compared, so it covers the case #2096 needs. With APS5_WRITE_WATCH_IMPORTS=watch the check fails without this change ("a fast-cleared upload of write-watched memory read its guest bytes"). That mode then stops at the existing "an unchanged pending image was uploaded again" check, on main as well, so it isn't a ctest variant.

Tested

Linux (Arch), RX 9070 XT, RADV, Release:

• Full ctest: 695/695.
• PPSA14632 (LEGO Horizon Adventures), main b5f5362 plus fix(guest-arena): place guest address space in the PS5 window on Linux #861 (Linux guest arena, needed to boot it), udmabuf size_limit_mb 1024. Values per 10 s, steady state:

	presents	flush-hook recorded-store waits	waited
main	~24	~60,000, all "publish only"	~6.4 s
with this PR	~100	~3,500	~4.4 s

How I narrowed it down: on that setup, the merge right before #639 (2b29784) has about 230 such waits per 10 s, and #2347, the first later merge that boots the title, has about 61,900. Reverting #425, #1309's backing write, #1310, #1410/#1411 or #2575 on main didn't change the count. The stack above leads to this line.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• AI-assisted: yes

🤖 Generated with Claude Code

[popcoder565]

Native Windows run, since no Windows results were posted. Setup: Windows 10 (19045), RTX 3060 Laptop (NVIDIA 616.92), MinGW-w64 GCC 15.2.0 (WinLibs r7), Release. Head 4f9ddffc, merged onto main 57f96fd in one build with 4 other new PRs.

• This PR's test passes: agc_driver_dcc_keys_first_write.
• Full ctest in that build: 711 of 711.

No title was run.

🤖 Addressed by Claude Code

[alfalfa-star]

The one failing job, write-watch (macos-15-intel), is a 30 s timeout in write_watch_threads. This PR only changes libSceAgcDriver (Texture.cpp/.hpp and its test), which that job does not build, and the same job passed on the 10 other recent runs I checked. Could someone with rights rerun it?

[orbz22]

Tested on Windows with a second title, Hollow Knight: Silksong (PPSA12544).

Setup: Windows 11 Pro (26300), i7-11800H, RTX 3060 Laptop (driver 617.42), WinLibs GCC 15.2.0 r7, Release. main de5e541 + #846 (Silksong needs it for its plugins), with and without this PR merged on top. Each run used the same scripted input for 250 s (title menu, New Game, the opening, into Moss Grotto) with APS5_PROFILE_DRAW=1.

Guest memory reads ([guestmem] read, cumulative at about 180 s):

Build	Calls	MiB	Time
main, run 1	2.03 M	68,665	9.7 s
main, run 2	2.03 M	68,191	9.8 s
main + #2791 (control)	2.03 M	68,728	9.9 s
main + #2792 (control)	2.03 M	68,353	9.6 s
main + this PR	1.11 M	11,342	2.0 s

Over the whole 250 s, reads went from 99,548 MiB in 14.7 s to 14,470 MiB in 3.3 s.

• GPU waits: unchanged, about 13,100 to 13,900 syncs and 9 s by 180 s in every build. Almost all of them come from WaitForKeyWriters (DCC keys), not from this path.
• Frame rate: unchanged. Here the game is paced at 30 or 60 FPS by vsync. At 180 s every build had presented 7,418 to 7,424 frames.
• Picture: unchanged. Frames dumped every 600 presents (menu, profile select, opening, Moss Grotto) match the runs without the PR, apart from animation timing. No new log lines.

🤖 Generated with Claude Code

[adriadam10]

Checked the diff, the build and ctest of libSceAgcDriver on Linux (agc_driver_dcc_keys_first_write passes), and the Windows runs from @popcoder565 and @orbz22. The only red job is write-watch (macos-15-intel), a timeout in a job that doesn't build this code; I re-ran it. Merging once it is green.