[DUDUYG]

What

Render target images are reused from a pool instead of being made and destroyed for each of OoT's shifting transient targets.

OoT makes a frame's transient targets in a scratch heap, and their offsets shift with what came before them in the frame. So each shifted target is a texture with a new image. Every 60 presents, the dead-target sweep (#899) lets go of the dead ones, and the next present destroys them all at once. In Kokiri Forest that is 300-700 images per sweep, at about 0.07 ms each: a 20-65 ms stall on the replaying thread, about once a second while the camera moves.

In one 4.5-minute run, 10,500 images (17 GB) were made and destroyed this way. The sweep's choice is cheap (under 1 ms). All of the stall is the destruction.

Change (gpu/vk/vk_texture.cpp, vk_texture.h)

• Into the pool: when a render target's texture goes, its image and views wait in a pool, keyed by the whole VkImageCreateInfo (pool_key_of). The dead list puts them there once the GPU is done with them, instead of destroying them.
• Out of the pool: a new texture with the same create info takes a pooled image before create_image is asked. It is still put into GENERAL from UNDEFINED and cleared exactly as a new image is, so nothing it held shows.
• What is pooled: only uncompressed colour and depth targets. Sparse, BC and ASTC images are destroyed as before.
• Bounds:
  • RX_VK_TARGET_POOL_MB (default 1024; 0 turns the pool off and every image is destroyed as before).
  • The pool is given back while VRAM is near what the driver allows, using the budget's existing pressure check.
  • An image unused in the pool for 120 presents is destroyed.
  • pool_trim destroys at most 16 images a present (64 while VRAM is short), so there is never a burst.
• Log: every 600 presents: vk: render target images: N reused from the pool, M made new, K destroyed from it; it holds X (Y MB).

Measured

• Setup: RTX 5070 12 GB, Ryzen 7 9800X3D, Windows 11, NVIDIA 621.01, 1080p output.
• Runs: headless (HOS_HEADLESS, HOS_AUDIO=0), a Kokiri Forest save, the same scripted 36 s walk with camera turns each run. The numbers are the in-play part only (presents 3300 and on, after the save's load).
• Build: main 0828863 with Keep the CPU's newer pages when a remade pool's mirror inherits a retired one #1127, fix(vk): render BC targets through raw views, and stop leaving out OoT's noise volume pass #1338 and local timing logs (not in this PR). The A/B is the same build with RX_VK_TARGET_POOL_MB=0, alternated.

	pool off (2 runs)	pool on (2 runs)
housekeeping presents over 8 ms (worst)	27 / 28 (60.0 / 65.7 ms)	0 / 0
slow submits/presents over 30 ms	9 / 10	1 / 2
time in slow submits/presents over 15 ms	815 / 742 ms	250 / 345 ms
fps	58.5 / 58.8	58.4 / 59.0
images reused / made new / destroyed from the pool	-	7076 / 6422 / 5448, 6091 / 6422 / 5609

• The remaining long stalls with the pool on are the first new pipeline in play (151 ms: opening the pipeline notes file, a separate PR) and texture lookups (57-74 ms).
• With both changes: 3 runs had no stall over 30 ms in play. The worst was 15.7-19.9 ms, at 59.5-60.0 fps.
• The picture: screenshots taken during the runs look the same with the pool on and off (fog, bloom, lighting, HUD).

Not covered

• One GPU (NVIDIA, Windows) and one scene, headless runs. AMD, Intel and Linux are untested.
• Small cards: the pool held up to 835 MB at its peak here. On 6-8 GB cards it relies on the existing VRAM pressure check (pressure > allowed / 10 * 9) to be given back. I could not test that on a small card.
• Screenshots only, no per-frame brightness log (the headless frame log stays empty).

Tests

• tests/test_target_image_pool.py (source checks, 7 cases):
  • the key covers the whole create info;
  • only uncompressed attachment images are pooled, and 0 turns the pool off;
  • a pooled image is taken before create_image and still goes UNDEFINED→GENERAL and is cleared;
  • a gone texture's views go with its image;
  • the dead list pools before it destroys, and the trim runs every present;
  • the trim is bounded and gives back idle and excess images;
  • the numbers are logged.
• These pass on Windows: tests/run_all.py on every test that reads vk_texture.cpp, plus test_vulkan_clear_mip.py and test_parallel_init_order.py with the Vulkan headers.
• The renderer builds with llvm-mingw (RX_VK_ONLY=1 nx2/build.py --standalone).

🤖 Generated with Claude Code

[NotRexed]

This landed in the v2.0.12 branch (merged there for testing; it reaches main with that release), so closing. Thanks!

[NotRexed]

Reopened: closing this was a mistake on my side. It was tested in the v2.0.12 branch, and it will be merged into main here, so it shows as merged. Sorry for the noise.