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

SadTransGirl commented

2026-11-12 00:22:14 +00:00

(Migrated from github.com)

On 8 GB cards that run past what the driver allows, the driver pages VRAM out to system memory and the frame rate falls (#2156: an RTX 5050 8 GB at 7,602 MB used of 6,982 allowed ran at 14-25 fps). #1506 made the 97% texture squeeze wait while VMA's blocks hold an eighth of the allowance free. This keeps that wait only while the driver's count is within the allowance, so past it the squeeze runs again, as in v2.0.14.

Cause. #1506's wait stops a ratchet: evicting textures frees space inside blocks the driver still counts, so the count doesn't drop and the squeeze ran again ten frames later (a 4 GB RX 5500M lost 1,700 MB of textures while paused). But the wait held past the allowance too, where the driver pages and room in the blocks doesn't help: #2156's card had 1,649 MB free in its blocks.

Change (gpu/vk/vk_texture.cpp, texture_frame, one condition):

room_in_blocks holds only while used <= allowed: past the allowance, the squeeze runs whatever the blocks hold.
#2711's gate stays: not while the textures' pool is down to its blocks made at the start (kept_only), where no eviction can bring the count down. So past the allowance it squeezes only where an eviction can help, as hckrman101 and Joey-Magnus asked.
With #2826, what the squeeze lets go of is the excess over its line, not an eighth of the cache.
RX_VK_SQUEEZE_ALWAYS=1 still squeezes as before. Ported from Revens2's a4c7cb3.

Measured so far. None of it is yet on a card that really pages, on top of #2711:

RTX 4070 SUPER 12 GB (617.42), Windows 11, DLAA 2560x1440, unattended, held to an 8 GB card's allowance (RX_VK_TEST_ALLOWED_MB=6900), before #2711: the "room in the blocks: not squeezed" lines went (26 to 0), but VRAM stayed past the allowance as much (27 of 29 lines, worst +1,393 MB, against 26 of 28 and +1,641 MB on main), at 58.9 against 58.7 fps. The texture budget was already 0 MB there: the excess was the image pool's blocks made at the start (#2438), which #2711 has since fixed. At a 6 GB allowance, Castle Town to the field: 4 of 6 lines past either way, 51.2 fps both. Rows in docs/tested-configurations.md.
Rogasse, RTX 4050 Laptop 6 GB (621.14), the one line backported to v2.1.0, Kokiri Forest with a 4,300 MB test allowance: 7 of 16 VRAM samples past the allowance on the base, 2 of 16 with this; fps unchanged (one pair each).
Waryxxful, RX 5600 XT 6 GB: at most 4,470 MB against the driver's 4,480 (main: 4,480 of 4,480 throughout); fps within main's noise.

Wanted before merge. A before/after on a card that really pages (an 8 GB one, ideally from #2156's or #2690's reporters), same scene, on current main (which has #2711), with fps and the vk: VRAM: lines. That shows whether this adds anything past #2711.

Tests. tests/test_texture_squeeze.py checks that the wait for room in the blocks holds only within the allowance and that #2711's kept_only gate is still on the squeeze; it fails without the change.

Not tested. A card that pages (every run above is a lower allowance on a larger card, or a card at but not past its limit); Linux; Intel.

Part of #993.
See #2690.

Assisted-by: Claude Opus 5.5, Claude Mythos 5.2

🤖 Generated with Claude Code

On 8 GB cards that run past what the driver allows, the driver pages VRAM out to system memory and the frame rate falls (#2156: an RTX 5050 8 GB at 7,602 MB used of 6,982 allowed ran at 14-25 fps). #1506 made the 97% texture squeeze wait while VMA's blocks hold an eighth of the allowance free. This keeps that wait only while the driver's count is within the allowance, so past it the squeeze runs again, as in v2.0.14. **Cause.** #1506's wait stops a ratchet: evicting textures frees space inside blocks the driver still counts, so the count doesn't drop and the squeeze ran again ten frames later (a 4 GB RX 5500M lost 1,700 MB of textures while paused). But the wait held past the allowance too, where the driver pages and room in the blocks doesn't help: #2156's card had 1,649 MB free in its blocks. **Change** (`gpu/vk/vk_texture.cpp`, `texture_frame`, one condition): - `room_in_blocks` holds only while `used <= allowed`: past the allowance, the squeeze runs whatever the blocks hold. - #2711's gate stays: not while the textures' pool is down to its blocks made at the start (`kept_only`), where no eviction can bring the count down. So past the allowance it squeezes only where an eviction can help, as hckrman101 and Joey-Magnus asked. - With #2826, what the squeeze lets go of is the excess over its line, not an eighth of the cache. - `RX_VK_SQUEEZE_ALWAYS=1` still squeezes as before. Ported from Revens2's a4c7cb3. **Measured so far.** None of it is yet on a card that really pages, on top of #2711: - RTX 4070 SUPER 12 GB (617.42), Windows 11, DLAA 2560x1440, unattended, held to an 8 GB card's allowance (`RX_VK_TEST_ALLOWED_MB=6900`), before #2711: the "room in the blocks: not squeezed" lines went (26 to 0), but VRAM stayed past the allowance as much (27 of 29 lines, worst +1,393 MB, against 26 of 28 and +1,641 MB on main), at 58.9 against 58.7 fps. The texture budget was already 0 MB there: the excess was the image pool's blocks made at the start (#2438), which #2711 has since fixed. At a 6 GB allowance, Castle Town to the field: 4 of 6 lines past either way, 51.2 fps both. Rows in `docs/tested-configurations.md`. - Rogasse, RTX 4050 Laptop 6 GB (621.14), the one line backported to v2.1.0, Kokiri Forest with a 4,300 MB test allowance: 7 of 16 VRAM samples past the allowance on the base, 2 of 16 with this; fps unchanged (one pair each). - Waryxxful, RX 5600 XT 6 GB: at most 4,470 MB against the driver's 4,480 (main: 4,480 of 4,480 throughout); fps within main's noise. **Wanted before merge.** A before/after on a card that really pages (an 8 GB one, ideally from #2156's or #2690's reporters), same scene, on current main (which has #2711), with fps and the `vk: VRAM:` lines. That shows whether this adds anything past #2711. **Tests.** `tests/test_texture_squeeze.py` checks that the wait for room in the blocks holds only within the allowance and that #2711's `kept_only` gate is still on the squeeze; it fails without the change. **Not tested.** A card that pages (every run above is a lower allowance on a larger card, or a card at but not past its limit); Linux; Intel. Part of #993. See #2690. Assisted-by: Claude Opus 5.5, Claude Mythos 5.2 🤖 Generated with [Claude Code](https://claude.com/claude-code)

github-sync changed title from ~~WIP: fix(vk): keep the 97% texture squeeze past the driver's allowance (#2…~~ to fix(vk): keep the 97% texture squeeze past the driver's allowance (#2…

2026-11-12 06:23:23 +00:00

github-sync commented

2026-11-12 07:28:01 +00:00

Owner

@hckrman101 commented on GitHub · 2026-11-12 06:56 UTC · original

Please test

> [@hckrman101](https://github.com/hckrman101) commented on GitHub · 2026-11-12 06:56 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2585#issuecomment-6816989412) Please test

github-sync commented

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

Owner

@SadTransGirl commented on GitHub · 2026-11-12 09:10 UTC · original

Tested #2585 on my RTX 4070 SUPER (12 GB), Windows 11, DLAA 1440p, main c544828f, default settings, as an 8 GB card (RX_VK_TEST_ALLOWED_MB=6900, 5 min Hyrule Field walk) and a 6 GB one (6144, Castle Town to the field):

•	It does what it says: the "(at the driver's limit, room in the blocks: not squeezed)" lines are gone (26 → 0).
•	But VRAM stays over the allowance just as much: 26-27 of 28 checks over, by up to 1.4-2.0 GB (main: 26 of 28, up to 1.6 GB). The texture budget is already 0 MB on main there, so the squeeze has nothing left to take.
•	What holds the VRAM is the image pool's blocks made at the start (#2438): 14 blocks, 1,792 MB, with 102 MB of images in them. minBlockCount keeps them for good.
•	Main with RX_VK_IMAGE_PREALLOC=0: over the allowance in 0 of 29 checks, VRAM mean 6,316 MB against 7,641, peak 6,845 against 8,541, 59.4 against 58.7 fps. As a 6 GB card: at most 799 MB over, against 2,333.
•	On a real 8 GB card #2438 would keep 9 blocks (1.15 GB) that way. Caveats: here the 15% is of a 12 GB card, and this card can't page, so the fps drop itself can't be reproduced.

That's the same thing #2690 / #2711 found, so #2711 looks like the bigger fix for 8 GB cards; this run is a Windows data point for it. #2585 touches the same room_in_blocks line as #2711 (a small text conflict, no conflict in meaning: past the allowance it squeezes, unless #2711's kept_only says an eviction can't lower the count). I'll rebase #2585 on #2711 once it lands; there's also a follow-up ready that makes the squeeze count only the textures' own free space (#2412).

> [@SadTransGirl](https://github.com/SadTransGirl) commented on GitHub · 2026-11-12 09:10 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2585#issuecomment-6819499044) Tested #2585 on my RTX 4070 SUPER (12 GB), Windows 11, DLAA 1440p, main c544828f, default settings, as an 8 GB card (RX_VK_TEST_ALLOWED_MB=6900, 5 min Hyrule Field walk) and a 6 GB one (6144, Castle Town to the field): • It does what it says: the "(at the driver's limit, room in the blocks: not squeezed)" lines are gone (26 → 0). • But VRAM stays over the allowance just as much: 26-27 of 28 checks over, by up to 1.4-2.0 GB (main: 26 of 28, up to 1.6 GB). The texture budget is already 0 MB on main there, so the squeeze has nothing left to take. • What holds the VRAM is the image pool's blocks made at the start (#2438): 14 blocks, 1,792 MB, with 102 MB of images in them. minBlockCount keeps them for good. • Main with RX_VK_IMAGE_PREALLOC=0: over the allowance in 0 of 29 checks, VRAM mean 6,316 MB against 7,641, peak 6,845 against 8,541, 59.4 against 58.7 fps. As a 6 GB card: at most 799 MB over, against 2,333. • On a real 8 GB card #2438 would keep 9 blocks (1.15 GB) that way. Caveats: here the 15% is of a 12 GB card, and this card can't page, so the fps drop itself can't be reproduced. That's the same thing #2690 / #2711 found, so #2711 looks like the bigger fix for 8 GB cards; this run is a Windows data point for it. #2585 touches the same room_in_blocks line as #2711 (a small text conflict, no conflict in meaning: past the allowance it squeezes, unless #2711's kept_only says an eviction can't lower the count). I'll rebase #2585 on #2711 once it lands; there's also a follow-up ready that makes the squeeze count only the textures' own free space (#2412).

github-sync commented

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

Owner

@hckrman101 commented on gpu/vk/vk_texture.cpp line 4329 on GitHub · 2026-11-12 09:37 UTC · original

Past the allowance this squeezes even with an eighth of the allowance free in the blocks. Evicting there frees space inside blocks the driver still counts, so used stays put and the budget shrinks again on the next pass: #1506's ratchet, now past the allowance. In your 4070 SUPER run the excess was the image pool's preallocated blocks, which no texture eviction can release. Gating this on #2711's kept_only (squeeze only when an eviction can lower the count) after the rebase would avoid draining the cache for nothing.

> [@hckrman101](https://github.com/hckrman101) commented on `gpu/vk/vk_texture.cpp` line 4329 on GitHub · 2026-11-12 09:37 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2585#discussion_r4548679828) Past the allowance this squeezes even with an eighth of the allowance free in the blocks. Evicting there frees space inside blocks the driver still counts, so `used` stays put and the budget shrinks again on the next pass: #1506's ratchet, now past the allowance. In your 4070 SUPER run the excess was the image pool's preallocated blocks, which no texture eviction can release. Gating this on #2711's `kept_only` (squeeze only when an eviction can lower the count) after the rebase would avoid draining the cache for nothing.

github-sync commented

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

Owner

@hckrman101 reviewed on GitHub · 2026-11-12 09:37 UTC · original

Thanks for this, and for testing it yourself straight away. The change does what the description says: the used <= allowed term only lifts #1506's wait once the driver's count is past the allowance, the RX 5500M case (3337 of 3337) keeps waiting, RX_VK_SQUEEZE_ALWAYS=1 is unchanged, and the test pins the new term in the right expression.

What holds me back is your own run: the "not squeezed" lines go away (26 to 0), but VRAM stays over the allowance just as much as on main, because the texture budget is already 0 MB there and what holds the memory is the image pool's blocks made at the start (#2438, kept by minBlockCount). So on this data the PR changes the log but not the count, and the fix for #2156 / #2690 is #2711. I agree with your plan: let #2711 land first, rebase this on it (with its kept_only check, so that past the allowance it only squeezes when an eviction can actually lower the count), and then measure again.

One thing to keep in mind for that rebase (inline): past the allowance with room in the blocks, evicting textures frees space inside blocks the driver still counts, so the count doesn't drop and the squeeze runs again ten frames later. That's the ratchet #1506 stopped, now allowed once the count passes the allowance. When the excess isn't textures, it can drain the cache to nothing and have it re-made, on exactly the 8 GB cards this is for.

For merging (the maintainer's rule from #2712): a fix needs to be shown in the game with numbers in the description. Here that's a before/after on a card that really pages (an 8 GB one, ideally from the #2156 / #2690 reporters, same scene, fps and the VRAM log lines), on top of #2711, showing this adds something past what #2711 does. The 4070 SUPER run is a useful data point, but as you say it can't page, so it can't show the fps side.

CI: the two red jobs fail only tests/test_env_on.py on HOS_FPS_LOG in host/oot_high_fps.c, which this PR doesn't touch; main has since fixed it (latest main runs are green), so a rebase clears it.

> [@hckrman101](https://github.com/hckrman101) reviewed on GitHub · 2026-11-12 09:37 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2585#pullrequestreview-5872179971) Thanks for this, and for testing it yourself straight away. The change does what the description says: the `used <= allowed` term only lifts #1506's wait once the driver's count is past the allowance, the RX 5500M case (3337 of 3337) keeps waiting, `RX_VK_SQUEEZE_ALWAYS=1` is unchanged, and the test pins the new term in the right expression. What holds me back is your own run: the "not squeezed" lines go away (26 to 0), but VRAM stays over the allowance just as much as on main, because the texture budget is already 0 MB there and what holds the memory is the image pool's blocks made at the start (#2438, kept by minBlockCount). So on this data the PR changes the log but not the count, and the fix for #2156 / #2690 is #2711. I agree with your plan: let #2711 land first, rebase this on it (with its `kept_only` check, so that past the allowance it only squeezes when an eviction can actually lower the count), and then measure again. One thing to keep in mind for that rebase (inline): past the allowance with room in the blocks, evicting textures frees space inside blocks the driver still counts, so the count doesn't drop and the squeeze runs again ten frames later. That's the ratchet #1506 stopped, now allowed once the count passes the allowance. When the excess isn't textures, it can drain the cache to nothing and have it re-made, on exactly the 8 GB cards this is for. For merging (the maintainer's rule from #2712): a fix needs to be shown in the game with numbers in the description. Here that's a before/after on a card that really pages (an 8 GB one, ideally from the #2156 / #2690 reporters, same scene, fps and the VRAM log lines), on top of #2711, showing this adds something past what #2711 does. The 4070 SUPER run is a useful data point, but as you say it can't page, so it can't show the fps side. CI: the two red jobs fail only `tests/test_env_on.py` on `HOS_FPS_LOG` in `host/oot_high_fps.c`, which this PR doesn't touch; main has since fixed it (latest main runs are green), so a rebase clears it.

github-sync referenced this pull request

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

fix(vk): bound the wait for shaders still translating, then leave the… #2586

github-sync commented

2026-11-12 11:36:02 +00:00

Owner

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

Setup: RX 5600 XT 6 GB (RDNA1, no mesh shaders), Adrenalin 26.10.1, Windows 11, Ryzen 5 5600X, 24 GB, 1920x1080, frame generation off. Every run starts from the same copied save and follows a scripted route through the control bridge (Kokiri Forest and Hyrule Field: settle 15 s, then 60 s standing); fps are the medians of the log's N presents lines. Run-to-run noise on main de866017 (4 runs): Kokiri 31.5-34.6 fps, Hyrule Field 32.1-34.8.

A real 6 GB card, to go with the emulated ones above. Merged on main de866017:

fps: Kokiri 33.9, Hyrule Field 33.7, within main's noise.
VRAM: 4,470 MB at most, against the driver's 4,480 MB allowance. Main sits at 4,480 of 4,480 at every sample in both places.

So on this card too, the squeeze changes nothing visible at these two spots. On main the texture budget there is 300-390 MB with ~1,100 MB of textures held, and the buffer pools' mirror budget is full as well (pool ... (160 MB) stays in system memory: the mirrors have 688 MB of 734), so the textures are not the only thing at the allowance.

> [@Waryxxful](https://github.com/Waryxxful) commented on GitHub · 2026-11-12 11:21 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2585#issuecomment-6822205001) **Setup:** RX 5600 XT 6 GB (RDNA1, no mesh shaders), Adrenalin 26.10.1, Windows 11, Ryzen 5 5600X, 24 GB, 1920x1080, frame generation off. Every run starts from the same copied save and follows a scripted route through the control bridge (Kokiri Forest and Hyrule Field: settle 15 s, then 60 s standing); fps are the medians of the log's `N presents` lines. Run-to-run noise on main `de866017` (4 runs): Kokiri 31.5-34.6 fps, Hyrule Field 32.1-34.8. A real 6 GB card, to go with the emulated ones above. Merged on main `de866017`: - **fps:** Kokiri 33.9, Hyrule Field 33.7, within main's noise. - **VRAM:** 4,470 MB at most, against the driver's 4,480 MB allowance. Main sits at 4,480 of 4,480 at every sample in both places. So on this card too, the squeeze changes nothing visible at these two spots. On main the texture budget there is 300-390 MB with ~1,100 MB of textures held, and the buffer pools' mirror budget is full as well (`pool ... (160 MB) stays in system memory: the mirrors have 688 MB of 734`), so the textures are not the only thing at the allowance.

github-sync commented

2026-11-12 14:43:10 +00:00

Owner

@Joey-Magnus reviewed on GitHub · 2026-11-12 14:33 UTC · original

I merged this into current main and tests/test_texture_squeeze.py passes. The change at gpu/vk/vk_texture.cpp:4302 does what it says: past the allowance it no longer waits for room in the blocks.

hckrman101's points still stand at this head, and you agreed with them. Both your 4070 SUPER run and Waryxxful's RX 5600 XT run show the log lines going away but VRAM staying where it was. So on the data so far this changes the log, not the count. The inline point is also still open: past the allowance, evicting textures frees space inside blocks the driver still counts, so used doesn't move and the squeeze runs again ten frames later. That is #1506's ratchet, now allowed above the allowance.

#2711 is still open. The plan in the thread looks right to me: rebase on #2711 once it lands, gate the squeeze on its kept_only, and add a before/after from a card that really pages (same scene, fps and VRAM lines) to the description. The red CI is test_env_on on HOS_FPS_LOG, which main fixed since, so the rebase clears it as well.

> [@Joey-Magnus](https://github.com/Joey-Magnus) reviewed on GitHub · 2026-11-12 14:33 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2585#pullrequestreview-5876218187) I merged this into current main and tests/test_texture_squeeze.py passes. The change at gpu/vk/vk_texture.cpp:4302 does what it says: past the allowance it no longer waits for room in the blocks. hckrman101's points still stand at this head, and you agreed with them. Both your 4070 SUPER run and Waryxxful's RX 5600 XT run show the log lines going away but VRAM staying where it was. So on the data so far this changes the log, not the count. The inline point is also still open: past the allowance, evicting textures frees space inside blocks the driver still counts, so `used` doesn't move and the squeeze runs again ten frames later. That is #1506's ratchet, now allowed above the allowance. #2711 is still open. The plan in the thread looks right to me: rebase on #2711 once it lands, gate the squeeze on its `kept_only`, and add a before/after from a card that really pages (same scene, fps and VRAM lines) to the description. The red CI is test_env_on on HOS_FPS_LOG, which main fixed since, so the rebase clears it as well.

github-sync commented

2026-11-12 15:50:49 +00:00

Owner

@Rogasse commented on GitHub · 2026-11-12 15:37 UTC · original

Tested the one-line #2585 condition on a real RTX 4050 Laptop GPU (6 GB), Windows 11, NVIDIA 621.14, i5-13420H, 32 GB RAM. I backported only that line to the v2.1.0 renderer source (633eb435, API 14) so it could run with my installed v2.1.0 game. Base and patched Vulkan DLLs were built the same way. The game executable, graphics options, and manual Kokiri Forest save were the same; caches were left warm across runs. Output 2048x1152, 50% render resolution, handheld profile on, DLSS and frame generation off.

For each arm, I loaded the same save, let the scene settle, sent the same eight timed stick inputs (LRIGHT, LLEFT, LUP, LDOWN, repeated), then left Link standing. These are one A/B pair per condition, not repeat-range measurements. FPS below comes from RX_VK_FRAME_LOG: the 24 s scripted route and the following 45 s standing window.

Driver allowance	Base route / standing	#2585 route / standing	VRAM and squeeze result
Normal (~5.1 GB)	28.58 / 29.87 fps	28.79 / 29.53 fps	Neither run went above the allowance (0 over-limit samples); the changed condition was not reached.
`RX_VK_TEST_ALLOWED_MB=4300`	27.46 / 28.49 fps	27.38 / 29.00 fps	Base: 7/16 VRAM samples over the test allowance, 5 `room in the blocks: not squeezed` lines. Patched: 2/16 over, with the sole `not squeezed` line at 4257/4300 MB (within allowance). During gameplay, base stayed around 4369/4300 MB; patched was mostly 4209/4300 MB after squeezing.

The lower allowance exercises this PR's condition on this card: it reduces the renderer's over-limit samples in this scene. I cannot infer a real FPS gain from one pair; route FPS is effectively unchanged here. The 4300 MB cap is a renderer test switch, not a real 4.3 GB Windows VRAM budget, so this does not test WDDM paging. No game files or derived assets are attached.

> [@Rogasse](https://github.com/Rogasse) commented on GitHub · 2026-11-12 15:37 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2585#issuecomment-6828095123) Tested the one-line #2585 condition on a real RTX 4050 Laptop GPU (6 GB), Windows 11, NVIDIA 621.14, i5-13420H, 32 GB RAM. I backported only that line to the v2.1.0 renderer source (`633eb435`, API 14) so it could run with my installed v2.1.0 game. Base and patched Vulkan DLLs were built the same way. The game executable, graphics options, and manual Kokiri Forest save were the same; caches were left warm across runs. Output 2048x1152, 50% render resolution, handheld profile on, DLSS and frame generation off. For each arm, I loaded the same save, let the scene settle, sent the same eight timed stick inputs (`LRIGHT`, `LLEFT`, `LUP`, `LDOWN`, repeated), then left Link standing. These are **one A/B pair per condition**, not repeat-range measurements. FPS below comes from `RX_VK_FRAME_LOG`: the 24 s scripted route and the following 45 s standing window. | Driver allowance | Base route / standing | #2585 route / standing | VRAM and squeeze result | |---|---:|---:|---| | Normal (~5.1 GB) | 28.58 / 29.87 fps | 28.79 / 29.53 fps | Neither run went above the allowance (0 over-limit samples); the changed condition was not reached. | | `RX_VK_TEST_ALLOWED_MB=4300` | 27.46 / 28.49 fps | 27.38 / 29.00 fps | Base: 7/16 VRAM samples over the test allowance, 5 `room in the blocks: not squeezed` lines. Patched: 2/16 over, with the sole `not squeezed` line at 4257/4300 MB (within allowance). During gameplay, base stayed around 4369/4300 MB; patched was mostly 4209/4300 MB after squeezing. | The lower allowance exercises this PR's condition on this card: it reduces the renderer's over-limit samples in this scene. I cannot infer a real FPS gain from one pair; route FPS is effectively unchanged here. The 4300 MB cap is a renderer test switch, **not** a real 4.3 GB Windows VRAM budget, so this does not test WDDM paging. No game files or derived assets are attached.

github-sync referenced this pull request

2026-11-12 16:55:10 +00:00

fix(vk): bound the wait for shaders still translating, then leave the… #2586

github-sync referenced this pull request from a commit

2026-11-12 17:57:25 +00:00

fix(vk): bound the wait for shaders still translating, then leave the… (#2586)

github-sync commented

2026-11-12 17:58:09 +00:00

Owner

@Joey-Magnus reviewed on GitHub · 2026-11-12 17:02 UTC · original

#2711 merged at 16:50 today, so this can move to the plan from the thread. As it stands, it conflicts with main in gpu/vk/vk_texture.cpp, at the same squeeze condition #2711 changed.

What I'd want in the update:

Merge main, and gate the squeeze past the allowance on #2711's kept_only, so it only runs when evicting can actually lower the driver's count. That closes hckrman101's ratchet point: evicting inside blocks the driver still counts doesn't move used, so the squeeze comes back ten frames later.
Rogasse's RTX 4050 run is useful. With RX_VK_TEST_ALLOWED_MB=4300, the over-allowance samples went from 7/16 to 2/16, fps didn't change, and only one pair per arm was run. As Rogasse says, the 4300 MB cap is a renderer test switch, so it doesn't test real paging. A before/after on this head, after the merge, from a card that really pages (same scene, fps and VRAM lines) is still what the description needs.

The red test_env_on was main's HOS_FPS_LOG failure, so the merge clears it too.

> [@Joey-Magnus](https://github.com/Joey-Magnus) reviewed on GitHub · 2026-11-12 17:02 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2585#pullrequestreview-5878654906) #2711 merged at 16:50 today, so this can move to the plan from the thread. As it stands, it conflicts with main in gpu/vk/vk_texture.cpp, at the same squeeze condition #2711 changed. What I'd want in the update: - Merge main, and gate the squeeze past the allowance on #2711's kept_only, so it only runs when evicting can actually lower the driver's count. That closes hckrman101's ratchet point: evicting inside blocks the driver still counts doesn't move `used`, so the squeeze comes back ten frames later. - Rogasse's RTX 4050 run is useful. With RX_VK_TEST_ALLOWED_MB=4300, the over-allowance samples went from 7/16 to 2/16, fps didn't change, and only one pair per arm was run. As Rogasse says, the 4300 MB cap is a renderer test switch, so it doesn't test real paging. A before/after on this head, after the merge, from a card that really pages (same scene, fps and VRAM lines) is still what the description needs. The red test_env_on was main's HOS_FPS_LOG failure, so the merge clears it too.

github-sync commented

2026-11-12 17:58:09 +00:00

Owner

@SadTransGirl commented on GitHub · 2026-11-12 17:09 UTC · original

Merged main in ca082cd1 now that #2711 has landed (#2826 came with it), and added the tested-configurations rows in f385fe47. As you both suggested:

Past the allowance, the wait for room in the blocks no longer holds.
#2711's kept_only gate stays on the squeeze, so past the allowance it squeezes only where an eviction can lower the count.
With #2826 it lets go of the excess, not an eighth of the cache.

The test checks both the allowance term and the kept_only gate. The description now has the runs so far (mine at an emulated 8 GB allowance, Rogasse's RTX 4050 6 GB, Waryxxful's RX 5600 XT) and what's still wanted: a before/after on a card that really pages, on current main. My card can't page, so that has to come from someone with an 8 GB card.

> [@SadTransGirl](https://github.com/SadTransGirl) commented on GitHub · 2026-11-12 17:09 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2585#issuecomment-6830479939) Merged main in ca082cd1 now that #2711 has landed (#2826 came with it), and added the tested-configurations rows in f385fe47. As you both suggested: - Past the allowance, the wait for room in the blocks no longer holds. - #2711's `kept_only` gate stays on the squeeze, so past the allowance it squeezes only where an eviction can lower the count. - With #2826 it lets go of the excess, not an eighth of the cache. The test checks both the allowance term and the `kept_only` gate. The description now has the runs so far (mine at an emulated 8 GB allowance, Rogasse's RTX 4050 6 GB, Waryxxful's RX 5600 XT) and what's still wanted: a before/after on a card that really pages, on current main. My card can't page, so that has to come from someone with an 8 GB card.

github-sync referenced this pull request from a commit

2026-11-12 19:00:50 +00:00

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

github-sync closed this pull request

2026-11-12 19:01:40 +00:00

Rows
Columns

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