[Romen-Adama-Dev]

What

With tex_dirty_upload, a registered texture that the CPU writes after its first use is uploaded from guest memory by nvn_ft_poll, unless its host texture "is the GPU's" (mtl_tex_gpu_owned), so that a CPU write to pages it shares does not replace what the GPU drew. That test was the texture's usage: render-target or shader-writable. But NVN has no flag for a render target, so tex_desc gives every uncompressed texture made without a CPU fill render-target use from the start, and the test held for every such texture whether or not the GPU had ever written it. A texture bound before the CPU filled it, then filled, was never uploaded; only block-compressed textures (no render-target use) came through, which is why the poll worked for Tears of the Kingdom's BC4 atlas and ASTC arrays.

Ocarina of Time's terrain tiles (260×260, one CPU_CACHED | GPU_CACHED pool: R32F height, RGBA8 and 2-layer RGBA8 blend and hole maps, block-compressed detail, RG8 normals with 9 levels) are bound at creation and written from the CPU as tile slots are reused while the player moves. Every uncompressed one was dropped, and after about an hour the ground opened flat blue holes with grass and rocks floating over them (Kokiri Forest, the village floor, the Deku Tree), the same look the profile's keys had fixed for tiles written before their first use.

Fix

• nvn_mtl.m: mtl_tex_storage_gpu_owned: whether the GPU wrote the texture's storage and the CPU has not rewritten it since, through the storage spans tex_cpu_content keeps since e2b76d4 (gws_owned, stamped when a GPU write is recorded).
• nvn_ft_poll asks it instead of the host texture's usage: a texture the GPU never wrote, or wrote before the CPU's write, is uploaded; one the GPU wrote after the CPU's write stays the GPU's. mtl_tex_gpu_owned (usage) stays for tex_storage_dst, so packaged textures keep their render-pass readbacks.
• The poll logs the first four uploads and the first four textures kept.
• t_cpu_storage: storage the GPU never wrote is the CPU's; the GPU's once it writes it; the CPU's again once it rewrites it.
• Reference entry Textures made for GPU use kept from their CPU rewrites, the game note, the symptom index.

Measured

Mac (M3 Pro, 18 GB), loading a Kokiri Forest save and turning the camera, two runs:

	before	after
CPU-rewritten textures the poll uploaded	0 (every one dropped)	263 in 6,600 frames; 127 in 10,600 frames
kept as the GPU's	all	4 (RG8 normal tiles the GPU had drawn)

The 4 kept are right: the diagnostic showed the CPU zeroing their level 0 (every byte 0 at the poll) before the GPU draws every level. The uploaded ones are the tiles' height, blend and hole maps and a few small lookup textures (4×1 RGBA8, 32×32 RGBA8, 4×4×6 R32F, 64³ BC4) that had the same fate. Frame time unchanged on this walk (p50 16.9–18.9 ms); the uploads happen as tiles stream in.

Not yet eye-checked at the exact spots of the reported holes (they appeared after an hour of play on the previous host); the mechanism and the textures match the profile note's description of the symptom, and the fixed host is now in the play build for that check.

Tests

• t_cpu_storage (45 → 48 checks), t_cpu_tex (68), t_clear_tex (51), t_readback (153): pass.
• dm/tools/tests/test_docs.py: pass.
• regress.py check --games cannot run on this Mac: Ocarina of Time is the only local game. Reach: every profile with tex_dirty_upload (Tears of the Kingdom, FINAL FANTASY TACTICS, The Great Ace Attorney Chronicles, Kirby Air Riders, Ocarina of Time), whose block-compressed cases are unchanged; uncompressed textures in those games that were bound before the CPU filled them now upload too.

[dderiso1]

Independent corroboration of the CPU-upload ownership problem on Ocarina of Time v131072, macOS 27.0, Apple M5 Ultra. In Kokiri Forest we captured two sampled 260×260 R32Float height maps whose Metal backing contained 67,600 zeros while the corresponding guest storage held nonzero heights around 0.134–0.175.

Our downstream fix tracks actual GPU writes and lets unrelated textures sharing a GPU-written pool retain CPU upload ownership. Afterward the two captured streamed height maps matched the deswizzled guest storage byte-for-byte. This tested a separate implementation; direct validation of #1558 and #1447 remains pending.

Two regression cases proved useful beyond usage-flag classification:

• Start with a CPU-filled texture, write an unrelated resource in the same pool, then make another CPU fill and verify the texture receives it. Both tex_cpu_content and the later cpu_unc_drop transition need the per-texture rule.
• Create another texture object over an already GPU-written Metal backing, then make a CPU write. The alias must preserve the backing's GPU ownership so the poll cannot overwrite the GPU result through that second serial. We also preserve that state across texture-view or format upgrades.

Those cases may be useful alongside this PR's coverage of a texture bound before its first CPU fill. Our 106-check storage suite includes real GPU readback for these transitions.

[seedds]

Landed as b547f1e, with you as co-author: thank you for the diagnosis. The usage test could never answer the question, and your log lines and reference entry are kept.

The commit reworks the poll in three places:

• Block-compressed textures upload as before. A GPU copy into a registered BC texture is also written into its storage (tex_storage_dst). So a GPU-written span over one doesn't make its storage stale, and asking the span would have kept a CPU rewrite followed by a copy from being uploaded. The poll now applies tex_cpu_content's own rule (mtl_tex_cpu_rewritten, sharing tex_storage_ok): the span question only for uncompressed 2D textures, and the usage test for the textures that rule leaves out (depth, display, video decode, compressible, multisample).
• An uncompressed texture the poll uploads joins g_cpu_unc, so cpu_unc_drop makes it a GPU texture again when the GPU draws into it. Otherwise it stayed CPU-written for good, and a later CPU write nearby would re-upload stale storage over the drawing.
• A texture left to the GPU stays registered with a new stamp, so the CPU's next rewrite is still asked about. Once the decision depends on time rather than on usage, leaving the list for good would miss it.

On an M4 Pro (Kokiri autosave and a walk onto the village floor, 160 s): about 250 textures were uploaded by the poll against none before, and 17 of them became GPU textures again when drawn into. The picture was whole at 60 fps. t_cpu_storage has the span cases, and t_cpu_tex now drives the poll itself with a tex_dirty_upload profile.

@dderiso1, thanks for the independent check. Both of your cases hold, because the spans are by address: an unrelated GPU write in the same pool doesn't take a texture away from the CPU, and a second texture object over GPU-written storage is the GPU's too. The second one is now a test.

Still open: an eye check at the exact spots where the holes appeared after an hour of play.