8 GB cards: the image blocks made at the start (#2438) shrink the texture budget; Market 31-36 fps on main vs 54-56 with RX_VK_IMAGE_PREALLOC=0

github-sync commented

2026-11-12 06:27:10 +00:00

Owner

@blushOFF opened on GitHub · 2026-11-12 06:24 UTC · original

What happened

On an 8 GB card, Castle Town Market on current main (0ec31ff6) runs at about 31-36 fps where v2.1.0 gave 39-46. The image pool's blocks made at the start (#2438) leave the texture budget too small, and the GPU time per frame doubles. RX_VK_IMAGE_PREALLOC=0 brings the Market to 54-56 fps on the same build.

Measured

Windows 11, RTX 3070 8 GB (driver 610.88), i7-14700KF. Game folder built from main 0ec31ff6, no hookshot_env.txt, with HOS_BENCH=1;RX_VK_IMAGE_BLOCK_MB=32;RX_VK_WB_MAX_KB=1024 passed by the bench. Teleport from the Kokiri save, then about 2 minutes standing in each area; arms alternated in one session (D Z Z D Z D).

D = defaults: the log says images from a pool of 32 MB blocks (memory type 1), 24 made at the start.
Z = RX_VK_IMAGE_PREALLOC=0: ..., 0 made at the start.

Castle Town Market:

run	fps	lowest 5 s	GPU a frame	last VRAM line
D1	31.4	28.6	18.9 ms	1226 MB free in the blocks; textures 1996 MB (budget 965 MB)
Z1	56.0	41.7	8.3 ms	517 MB free in the blocks; textures 2389 MB (budget 1445 MB)
Z2	55.3	38.4	9.9 ms	746 MB free in the blocks; textures 2683 MB (budget 1270 MB)
D2	35.7	32.8	15.7 ms	1123 MB free in the blocks; textures 2141 MB (budget 902 MB)
Z3	54.5	45.2	8.0 ms	681 MB free in the blocks; textures 2530 MB (budget 1386 MB)
D3	49.9	31.9	11.1 ms	860 MB free in the blocks; textures 2266 MB (budget 955 MB)

Lake Hylia (55.5-58.5 fps) and the Graveyard (55.4-59.0) show no clear difference between the arms.

With the blocks made at the start, the blocks hold 860-1226 MB free while the texture budget sits at 902-965 MB, under the 2.0-2.3 GB of textures the Market keeps; without them, 517-746 MB free and a budget of 1270-1445 MB. So on this card the up-front blocks seem to sit mostly empty and count against the textures.

For reference, v2.1.0 with the same settings (two zone tours that night): Market 46.3 and 39.2 fps, budget 2241 MB at the last VRAM line.

Not checked

Only with RX_VK_IMAGE_BLOCK_MB=32 (the 8 GB setting from #887), where the rule gives the cap of 24 blocks (768 MB). With the default 128 MB blocks, 15 % of 8 GB is 9 or 10 blocks (about 1.2 GB); I have not run that.
Only one 8 GB NVIDIA card.

A lower share on cards with 8 GB or less (or none, as before #2438) would avoid it; the stall it removes (vkAllocateMemory ~170 ms on AMD's Windows driver) may not need the same number of blocks on NVIDIA.

> [@blushOFF](https://github.com/blushOFF) opened on GitHub · 2026-11-12 06:24 UTC · [original](https://github.com/NotRexed/Hookshot/issues/2690) ### What happened On an 8 GB card, Castle Town Market on current `main` (0ec31ff6) runs at about 31-36 fps where v2.1.0 gave 39-46. The image pool's blocks made at the start (#2438) leave the texture budget too small, and the GPU time per frame doubles. `RX_VK_IMAGE_PREALLOC=0` brings the Market to 54-56 fps on the same build. ### Measured Windows 11, RTX 3070 8 GB (driver 610.88), i7-14700KF. Game folder built from `main` 0ec31ff6, no `hookshot_env.txt`, with `HOS_BENCH=1;RX_VK_IMAGE_BLOCK_MB=32;RX_VK_WB_MAX_KB=1024` passed by the bench. Teleport from the Kokiri save, then about 2 minutes standing in each area; arms alternated in one session (D Z Z D Z D). D = defaults: the log says `images from a pool of 32 MB blocks (memory type 1), 24 made at the start`. Z = `RX_VK_IMAGE_PREALLOC=0`: `..., 0 made at the start`. **Castle Town Market:** | run | fps | lowest 5 s | GPU a frame | last VRAM line | |---|---|---|---|---| | D1 | 31.4 | 28.6 | 18.9 ms | 1226 MB free in the blocks; textures 1996 MB (budget 965 MB) | | Z1 | 56.0 | 41.7 | 8.3 ms | 517 MB free in the blocks; textures 2389 MB (budget 1445 MB) | | Z2 | 55.3 | 38.4 | 9.9 ms | 746 MB free in the blocks; textures 2683 MB (budget 1270 MB) | | D2 | 35.7 | 32.8 | 15.7 ms | 1123 MB free in the blocks; textures 2141 MB (budget 902 MB) | | Z3 | 54.5 | 45.2 | 8.0 ms | 681 MB free in the blocks; textures 2530 MB (budget 1386 MB) | | D3 | 49.9 | 31.9 | 11.1 ms | 860 MB free in the blocks; textures 2266 MB (budget 955 MB) | Lake Hylia (55.5-58.5 fps) and the Graveyard (55.4-59.0) show no clear difference between the arms. With the blocks made at the start, the blocks hold 860-1226 MB free while the texture budget sits at 902-965 MB, under the 2.0-2.3 GB of textures the Market keeps; without them, 517-746 MB free and a budget of 1270-1445 MB. So on this card the up-front blocks seem to sit mostly empty and count against the textures. For reference, v2.1.0 with the same settings (two zone tours that night): Market 46.3 and 39.2 fps, budget 2241 MB at the last VRAM line. ### Not checked - Only with `RX_VK_IMAGE_BLOCK_MB=32` (the 8 GB setting from #887), where the rule gives the cap of 24 blocks (768 MB). With the default 128 MB blocks, 15 % of 8 GB is 9 or 10 blocks (about 1.2 GB); I have not run that. - Only one 8 GB NVIDIA card. A lower share on cards with 8 GB or less (or none, as before #2438) would avoid it; the stall it removes (`vkAllocateMemory` ~170 ms on AMD's Windows driver) may not need the same number of blocks on NVIDIA.

github-sync referenced this issue

2026-11-12 06:27:17 +00:00

perf(vk): make part of the image pool's blocks at the start #2438

github-sync commented

2026-11-12 07:30:29 +00:00

Author

Owner

@blushOFF commented on GitHub · 2026-11-12 07:11 UTC · original

The same with the default 128 MB blocks (no RX_VK_IMAGE_BLOCK_MB), so it is not tied to the 32 MB setting. Same card, build and spot; HOS_BENCH=1;RX_VK_WB_MAX_KB=1024 only; arms alternated D Z Z D Z D. D logs pool of 128 MB blocks (memory type 1), 9 made at the start, Z 0 made at the start.

Castle Town Market:

run	fps	lowest 5 s	GPU a frame	last VRAM line
D1	36.6	23.6	24.7 ms	1438 MB free in the blocks; textures 2078 MB (budget 624 MB)
Z1	56.2	39.3	8.5 ms	945 MB free in the blocks; textures 2455 MB (budget 1227 MB)
Z2	51.7	37.7	9.6 ms	678 MB free in the blocks; textures 2199 MB (budget 1117 MB)
D2	30.5	30.4	17.7 ms	1623 MB free in the blocks; textures 2002 MB (budget 472 MB)
Z3	51.4	49.1	6.3 ms	283 MB free in the blocks; textures 2420 MB (budget 1426 MB)
D3	35.5	32.0	13.7 ms	1501 MB free in the blocks; textures 2013 MB (budget 487 MB)

D averages 34.2 fps, Z 53.1. With 128 MB blocks the 9 up-front blocks (1152 MB) leave 1.4-1.6 GB free in the blocks and a texture budget of 472-624 MB, lower than with the 32 MB blocks.

> [@blushOFF](https://github.com/blushOFF) commented on GitHub · 2026-11-12 07:11 UTC · [original](https://github.com/NotRexed/Hookshot/issues/2690#issuecomment-6817253665) The same with the default 128 MB blocks (no `RX_VK_IMAGE_BLOCK_MB`), so it is not tied to the 32 MB setting. Same card, build and spot; `HOS_BENCH=1;RX_VK_WB_MAX_KB=1024` only; arms alternated D Z Z D Z D. D logs `pool of 128 MB blocks (memory type 1), 9 made at the start`, Z `0 made at the start`. **Castle Town Market:** | run | fps | lowest 5 s | GPU a frame | last VRAM line | |---|---|---|---|---| | D1 | 36.6 | 23.6 | 24.7 ms | 1438 MB free in the blocks; textures 2078 MB (budget 624 MB) | | Z1 | 56.2 | 39.3 | 8.5 ms | 945 MB free in the blocks; textures 2455 MB (budget 1227 MB) | | Z2 | 51.7 | 37.7 | 9.6 ms | 678 MB free in the blocks; textures 2199 MB (budget 1117 MB) | | D2 | 30.5 | 30.4 | 17.7 ms | 1623 MB free in the blocks; textures 2002 MB (budget 472 MB) | | Z3 | 51.4 | 49.1 | 6.3 ms | 283 MB free in the blocks; textures 2420 MB (budget 1426 MB) | | D3 | 35.5 | 32.0 | 13.7 ms | 1501 MB free in the blocks; textures 2013 MB (budget 487 MB) | D averages 34.2 fps, Z 53.1. With 128 MB blocks the 9 up-front blocks (1152 MB) leave 1.4-1.6 GB free in the blocks and a texture budget of 472-624 MB, lower than with the 32 MB blocks.

github-sync commented

2026-11-12 07:30:29 +00:00

Author

Owner

@hckrman101 commented on GitHub · 2026-11-12 07:21 UTC · original

Claiming this: reproducing with a capped VRAM budget on a larger NVIDIA card first, then a fix for the share on 8 GB cards.

> [@hckrman101](https://github.com/hckrman101) commented on GitHub · 2026-11-12 07:21 UTC · [original](https://github.com/NotRexed/Hookshot/issues/2690#issuecomment-6817422757) Claiming this: reproducing with a capped VRAM budget on a larger NVIDIA card first, then a fix for the share on 8 GB cards.

github-sync referenced this issue from a commit

2026-11-12 08:30:51 +00:00

fix(vk): make the blocks at the start in the pool the textures are made in (#2690)

github-sync referenced this issue from a pull request that will close it,

2026-11-12 08:30:55 +00:00

fix(vk): make the blocks at the start in the pool the textures are made in (#2690) #2711

github-sync commented

2026-11-12 08:31:23 +00:00

Author

Owner

@klikso commented on GitHub · 2026-11-12 08:09 UTC · original

Same on a second 8 GB card, in Hyrule Field, and the frame-time spikes are where most of it shows.

Windows 11, RTX 3060 Ti 8 GB (driver 32.0.16.2114), Ryzen 5 5600X, 32 GB, 2560x1440 with DLSS. Game folder built from main 5b96a55a. Hyrule Field child, the camera turning for 40 s after a settle; RX_VK_FRAMEGEN=0, HOS_FPS_MAX=240, HOS_AUDIO=0; arms alternated Z D Z D Z D.

arm	fps median	fps mean	frame p99	frames over 50 ms in 40 s	render targets made new / reused	compactions
D (9 made at the start)	48.7 / 49.8 / 47.9	44.9 / 46.5 / 46.0	78 / 69 / 62 ms	53 / 38 / 30	~9,500 / ~480	13
Z (`RX_VK_IMAGE_PREALLOC=0`)	58.6 / 58.3 / 58.8	56.9 / 57.2 / 57.0	35 / 34 / 36 ms	8 / 3 / 6	~6,250 / ~4,400	5

The pools at the end of a D run and a Z run (the 600-frame lines):

D: image blocks: 9 blocks 1152 MB, 11 images 52 MB; 11 free ranges, the largest 128 MB
   image blocks (render targets): 4 blocks 512 MB, 155 images 342 MB
   image blocks (textures, compacted): 10 blocks 1280 MB, 1218 images 1208 MB
   VRAM: 6782 MB used of 6991 MB allowed (1391 MB of it free in the blocks); textures 2120 MB (budget 1002 MB)
Z: image blocks: 1 blocks 128 MB, 11 images 52 MB
   image blocks (render targets): 5 blocks 640 MB, 285 images 563 MB
   image blocks (textures, compacted): 10 blocks 1280 MB, 1201 images 1188 MB
   VRAM: 6354 MB used of 6957 MB allowed (326 MB of it free in the blocks); textures 2178 MB (budget 1481 MB)

One thing that may help the fix: the blocks are made in images_pool(), which since the textures' pool (RX_VK_COMPACT, on by default) and the render targets' pool (target_images_pool()) holds only DLSS's, the frame interpolation's and the scratch images: 52 MB in both arms here. So on this tree the 1.1 GB made at the start never takes the images whose vkAllocateMemory #2438 measured (it was measured on v2.0.5-v2.0.12, before both pools); it only sits in the count. The texture budget then falls to ~1 GB, and pool_pressed gives the render-target pool back ("VRAM short: given back"), so render targets are made new about 20 times as often as they are reused, against about 1.4 times without the blocks. That churn and the evictions line up with the spikes.

Results and logs are on this PC; happy to run a fix on this card.

> [@klikso](https://github.com/klikso) commented on GitHub · 2026-11-12 08:09 UTC · [original](https://github.com/NotRexed/Hookshot/issues/2690#issuecomment-6818293125) Same on a second 8 GB card, in Hyrule Field, and the frame-time spikes are where most of it shows. Windows 11, RTX 3060 Ti 8 GB (driver 32.0.16.2114), Ryzen 5 5600X, 32 GB, 2560x1440 with DLSS. Game folder built from `main` 5b96a55a. Hyrule Field child, the camera turning for 40 s after a settle; `RX_VK_FRAMEGEN=0`, `HOS_FPS_MAX=240`, `HOS_AUDIO=0`; arms alternated Z D Z D Z D. | arm | fps median | fps mean | frame p99 | frames over 50 ms in 40 s | render targets made new / reused | compactions | |---|---|---|---|---|---|---| | D (9 made at the start) | 48.7 / 49.8 / 47.9 | 44.9 / 46.5 / 46.0 | 78 / 69 / 62 ms | 53 / 38 / 30 | ~9,500 / ~480 | 13 | | Z (`RX_VK_IMAGE_PREALLOC=0`) | 58.6 / 58.3 / 58.8 | 56.9 / 57.2 / 57.0 | 35 / 34 / 36 ms | 8 / 3 / 6 | ~6,250 / ~4,400 | 5 | The pools at the end of a D run and a Z run (the 600-frame lines): ``` D: image blocks: 9 blocks 1152 MB, 11 images 52 MB; 11 free ranges, the largest 128 MB image blocks (render targets): 4 blocks 512 MB, 155 images 342 MB image blocks (textures, compacted): 10 blocks 1280 MB, 1218 images 1208 MB VRAM: 6782 MB used of 6991 MB allowed (1391 MB of it free in the blocks); textures 2120 MB (budget 1002 MB) Z: image blocks: 1 blocks 128 MB, 11 images 52 MB image blocks (render targets): 5 blocks 640 MB, 285 images 563 MB image blocks (textures, compacted): 10 blocks 1280 MB, 1201 images 1188 MB VRAM: 6354 MB used of 6957 MB allowed (326 MB of it free in the blocks); textures 2178 MB (budget 1481 MB) ``` One thing that may help the fix: the blocks are made in `images_pool()`, which since the textures' pool (`RX_VK_COMPACT`, on by default) and the render targets' pool (`target_images_pool()`) holds only DLSS's, the frame interpolation's and the scratch images: 52 MB in both arms here. So on this tree the 1.1 GB made at the start never takes the images whose `vkAllocateMemory` #2438 measured (it was measured on v2.0.5-v2.0.12, before both pools); it only sits in the count. The texture budget then falls to ~1 GB, and `pool_pressed` gives the render-target pool back ("VRAM short: given back"), so render targets are made new about 20 times as often as they are reused, against about 1.4 times without the blocks. That churn and the evictions line up with the spikes. Results and logs are on this PC; happy to run a fix on this card.

github-sync referenced this issue

2026-11-12 09:32:00 +00:00

[Tracking] VRAM and RAM fill up over play time: fps fades, textures degrade or turn rainbow, a restart fixes it (mostly 4-8 GB cards) #993

github-sync referenced this issue

2026-11-12 09:32:28 +00:00

fix(vk): keep the 97% texture squeeze past the driver's allowance (#2… #2585

github-sync referenced this issue

2026-11-12 10:34:12 +00:00

perf(vk): RX_VK_WB_MAX_KB writes large GPU-written bindings back only where the CPU reads or writes them (opt-in) #2731

github-sync referenced this issue

2026-11-12 10:34:38 +00:00

fix(vk): keep the 97% texture squeeze past the driver's allowance (#2… #2585