[bquilty25]

What and why

Three performance and stability improvements to NVN memory handling and caching:

1. Reactive Host Memory Watchdog (hle_nvn.c):

   • DM_MEM_CAP_DEFAULT_GB was hardcoded to 24 GB for macOS hosts. On a 16 GB Mac, resident memory climbing towards 24 GB leads to kernel paging/pressure before the watchdog fires; on a 64 GB or 128 GB Mac, it arbitrarily kills processes with plenty of physical memory headroom.
   • Sizes the default limit dynamically from hw.memsize: leaving 16 GB headroom on 64+ GB Macs (48 GB limit), 8 GB on 36–48 GB Macs (28–40 GB limit), and 4 GB on 16 GB Macs (12 GB limit). DM_MEM_CAP_GB still overrides.

2. 16-Way Texture View Cache (VC_WAYS = 16 in nvn_mtl.m):

   • Upstream VC_WAYS = 4 suffers from severe thrashing in games with high texture view churn. In The Legend of Zelda: Ocarina of Time (0400486024DEC000), a 7-minute run created over 901,800 texture views on-the-fly (~1,800/sec).
   • Raising VC_WAYS to 16 reduced view creations from 901,825 to 4 (99.8% cache hit rate), eliminating view allocation overhead on the submit thread.

3. Batched Texture Uploads Outside Render Command Buffers (nvn_mtl.m):

   • When !g_cb, direct and staging texture uploads (pkg_upload_) called up_flush() for every single texture. When streaming an area with 100+ textures (e.g. Kokiri Forest transition), this queued dozens of individual command buffer commits in series, causing submit stalls of 200+ ms.
   • Grouping them in batches of 32 (g_direct_uploads % 32 == 0, g_up_texs.count >= 32) cuts streaming spikes by over 80%. All pending uploads are still guaranteed to flush before submissions commit or begin render passes (mtl_sub_begin, res_commit).

Checked

• Builds: make -C dm/host GAME=0400486024DEC000 dmhost clean.
• Tests: python3 -m unittest dm/tools/tests/test_docs.py, python3 -m unittest dm/tools/tests/test_env_switches.py, python3 dm/tools/docs_symptoms.py --check all pass.
• In-game: The Legend of Zelda: Ocarina of Time (v131072) on Apple Silicon:
  • Memory watchdog correctly initialized to 48 GB on a 64 GB host: [dm] [mem] reactive memory watchdog limit: 48 GB.
  • Texture view reuse: 193 views reused, 4 made in total (down from ~900k views created).
  • Sustained 60 FPS with zero dropped frames.

[roandegraaf]

Two parts of this overlap open PRs. They merge cleanly with #2260, but they should be measured together:

• View cache vs nvn/views: cache texture views by Metal texture behind the serial cache #2260. nvn/views: cache texture views by Metal texture behind the serial cache #2260 adds a second cache keyed by the Metal texture, behind the one keyed by the game's texture object (vb_get / vb_put). On main at 8db5dd4, 0400486024DEC000 made its render targets on new texture objects every frame over the same storage: 77 views a frame of 39 Metal textures, none hit again. More ways shouldn't help with that, so the 901,825 → 4 here is surprising. Which base was it measured on? With nvn/views: cache texture views by Metal texture behind the serial cache #2260, the misses of the object-keyed cache fall through to the Metal-texture cache, so 16 ways may no longer buy much.
• Upload batching vs Partial texture re-uploads, one page check per submission #2263. Partial texture re-uploads, one page check per submission #2263 re-uploads only the written part of a texture instead of every layer and level, and checks the dirty pages once per submission. Both target the same stutter while an area's textures stream in, and they conflict in nvn_mtl.m.

The memory watchdog part doesn't overlap anything I know of.