Files
nxnative-easy/docs
seedds 9b7cb76104 Compute dispatches share the copy encoder; texture views are cached by texture (Age of Calamity after its first cutscene)
An iPhone log of Hyrule Warriors: Age of Calamity went from about 57 to 17 fps after the first
battle's first cutscene, at thermal state 0 and with no frame held: the same ~1,400 draws a frame,
but NVN calls from 82,000 to 287,000, GPU 15 -> 51 ms and the replay 12 -> 24 ms. The battle then
runs many more small compute dispatches (on the Mac about 280 -> 900-1,500 a frame, each after a
game barrier, about 17 texture binds each), and two host costs grew with them:

- Every dispatch had a compute encoder of its own with full queue barriers on both sides, a GPU
  drain per dispatch (about 10 us each on the Mac). Dispatches now go into the open copy encoder
  (dispatch_enc), each after a barrier inside it as texture copies are, with the compute argument
  table set once per encoder: about 1.3 us each. DM_NVN_DISPATCH_OWN=1 (and DM_NVN_PASSGPU)
  gives each its own encoder again.
- KTGL registers a texture into the next ID of a ring before every bind, so the per-ID view was
  rebuilt for half of all binds (newTextureViewWithPixelFormat, 45% of the replay thread). Views
  are now also kept by texture serial and view parameters (vc_get: 4 per texture, checked against
  the current base texture, dropped when the texture or its pool is finalized, live textures
  only), and a registration identical to what the ID holds keeps its view and the registration
  generation. 2,036 views made in a 15-minute battle run, 211 million reused.

Mac (M4 Pro), original and fixed hosts side by side on the same route: frame p50 19.4 -> 16.7 ms
before the cutscene and 34 -> 17.3 ms after it, GPU after it 17 -> 6.6 ms. Screenshots every 500
frames: the dark platform in some is a cloud shadow, as often in the original (8 of 51 vs 8 of 63).

The earlier reading of the iPhone battle's GPU going from 10 to 41 ms as its GPU clock following
the frame step's hold was wrong: the same rise comes with no hold, with the same growth in calls.
The profile comment, the fps_hold row and the development notes now say so; fps_hold stays off.
2026-10-21 15:44:58 +08:00
..