perf(vk): no bursts at 13 fps with video memory at the driver's limit #2401

2026-11-11T17:22:35Z

msxdan commented

2026-11-11 17:22:35 +00:00

(Migrated from github.com)

In Hyrule Castle Town's market on a 12 GB card the game drops to about 13 fps for seconds at a time. Video memory is at the driver's limit there, the GPU falls a frame or more behind, and every submit then waits 40-60 ms for it.

What changed

Two changes to what happens once video memory is at the driver's limit:

vk_timeline_wait gives up after 8 ms, not 250 (gpu/vk/vk_replay.cpp). The wait is a capture's, for a page the GPU writes back that the CPU wrote too (the exposure meter's). With the GPU behind it was 40-60 ms of the game's main thread or of the presenting one at every submit. Past the timeout the page is copied as it is, which is what already happened after 250 ms.
The texture budget steps down near the limit (gpu/vk/vk_texture.cpp, texture_frame): 55% of what the driver allows from 90% used, 47% from 94%, 40% from 97%, kept until the count is back under 85%. At the limit nothing squeezed while VMA's blocks had room, and the blocks keep what an eviction frees, so the count stayed at the limit and the driver paged. It is not the budget from the start: Hyrule Field fits at 91% with 5.5 GB of textures, and held to 4 GB it made 2000 more uploads in 76 s.

No new switches.

How it was tested

RTX 5070 12 GB, driver 615.78.08, Linux (CachyOS, KDE Wayland), Ryzen 9 9900X, 2560x1440 output, frame generation off. Played by hand, a save loaded in Kokiri Forest, then the market by the Cheats page's teleport and a walk round the plaza with the camera turning. Numbers are from RX_VK_FRAME_TRACE=1, frames outside the loads.

Same options, same code base (49f75dc8), caches already used on both sides:

In the market	main `49f75dc8` (96 s)	with the changes (159 s)
Frames over 50 ms	220	2
Frames with over 20 ms of memory sync	174	1
Worst 15 s window	35.4 fps	54.7 fps
Video memory used, texture budget	95-98%, 7.6 GB	95-99%, 4.1 GB

On main the stalls come as two bursts, 15 s and 25 s long, with nearly every frame at 75-100 ms and ~60 ms of it memory sync.

What that table does not isolate: the build on the right also carried other changes of mine that are not in this pull request (upload bytes written by their own threads, the executable's code kept in memory on Linux, program cache reads on a worker, and RX_VK_GPL=1). The two timings this pull request is about are the ones that moved, but I have not measured these two commits alone against main.

Later sessions, same PC and options:

Without RX_VK_GPL and on main at 1ceaa2ba, with these two commits plus the upload threads and the Linux one: 52-61 fps in the market, the 8 ms timeout hit once in the session.
Reaching the market from Kakariko Village instead of Kokiri Forest: one stretch of 6 s with 18 frames over 50 ms (worst 88 ms), the count at 99.5% on arrival. Kakariko sits just under 85%, so the step had been let go and came back late. Much shorter than main's bursts, not gone.
One session out of eight played with these changes went badly, and I have not reproduced it: the first start after a rebuild, in the process that had just prepared every shader, with the driver allowing 9.6 GB instead of 10.2. The market ran at 27-30 fps for that visit, the count at 99.8%. A restart of the same build gave the 52-61 fps above. Nothing ties it to these commits, and I have not checked whether main does the same on such a start.

python -I -B tests/run_all.py: 329 pass here; the 6 that fail fail the same way on main at 1ceaa2ba on this PC (no zstandard, no libtk, the local clang on two fixtures).

Not tested on Windows, on AMD or Intel cards, or on cards with less than 12 GB.

What could go wrong

With the GPU behind, a capture now goes on without the write-back after 8 ms where it used to get it within 250 ms: the exposure meter's page can be a frame stale. I did not see the exposure step in play, and did not look for it frame by frame.
A card whose working set in an area is above 40% of what the driver allows would evict and upload again in a loop. I have not seen that on this card outside the one session above, where it may have been the case.

None of these was tested on its reporter's PC, so this does not claim to fix them.

#2398: the same card (RTX 5070 12 GB, Windows 11, v2.1.0), "significant FPS drop when entering Hyrule Town". Its attached log shows the same picture as here: VRAM: 10250 MB used of 10616 MB allowed with the texture budget at 6144 MB, memory sync at 15-35 ms of a frame's replay time, and 10-23 fps in the town.
#2392: frames of ~250 ms with a capture's wait for write-back ... timed out each time. That is the wait this pull request cuts to 8 ms; the GPU time there is long for other reasons, which this does not touch.
#2058 and #2180: video memory at the allowed limit, then a stall or a freeze, on AMD cards.
#995: the tracking issue for the drops in Castle Town.

Assisted-by: Claude Fable 5.2
Co-Authored-By: Claude Fable 5.2 [email protected]

In Hyrule Castle Town's market on a 12 GB card the game drops to about 13 fps for seconds at a time. Video memory is at the driver's limit there, the GPU falls a frame or more behind, and every submit then waits 40-60 ms for it. ## What changed Two changes to what happens once video memory is at the driver's limit: - **`vk_timeline_wait` gives up after 8 ms, not 250** (`gpu/vk/vk_replay.cpp`). The wait is a capture's, for a page the GPU writes back that the CPU wrote too (the exposure meter's). With the GPU behind it was 40-60 ms of the game's main thread or of the presenting one at every submit. Past the timeout the page is copied as it is, which is what already happened after 250 ms. - **The texture budget steps down near the limit** (`gpu/vk/vk_texture.cpp`, `texture_frame`): 55% of what the driver allows from 90% used, 47% from 94%, 40% from 97%, kept until the count is back under 85%. At the limit nothing squeezed while VMA's blocks had room, and the blocks keep what an eviction frees, so the count stayed at the limit and the driver paged. It is not the budget from the start: Hyrule Field fits at 91% with 5.5 GB of textures, and held to 4 GB it made 2000 more uploads in 76 s. No new switches. ## How it was tested RTX 5070 12 GB, driver 615.78.08, Linux (CachyOS, KDE Wayland), Ryzen 9 9900X, 2560x1440 output, frame generation off. Played by hand, a save loaded in Kokiri Forest, then the market by the Cheats page's teleport and a walk round the plaza with the camera turning. Numbers are from `RX_VK_FRAME_TRACE=1`, frames outside the loads. Same options, same code base (49f75dc8), caches already used on both sides: | In the market | main 49f75dc8 (96 s) | with the changes (159 s) | |---|---|---| | Frames over 50 ms | 220 | 2 | | Frames with over 20 ms of memory sync | 174 | 1 | | Worst 15 s window | 35.4 fps | 54.7 fps | | Video memory used, texture budget | 95-98%, 7.6 GB | 95-99%, 4.1 GB | On main the stalls come as two bursts, 15 s and 25 s long, with nearly every frame at 75-100 ms and ~60 ms of it memory sync. **What that table does not isolate:** the build on the right also carried other changes of mine that are not in this pull request (upload bytes written by their own threads, the executable's code kept in memory on Linux, program cache reads on a worker, and `RX_VK_GPL=1`). The two timings this pull request is about are the ones that moved, but I have not measured these two commits alone against main. Later sessions, same PC and options: - Without `RX_VK_GPL` and on main at 1ceaa2ba, with these two commits plus the upload threads and the Linux one: 52-61 fps in the market, the 8 ms timeout hit once in the session. - Reaching the market from Kakariko Village instead of Kokiri Forest: one stretch of 6 s with 18 frames over 50 ms (worst 88 ms), the count at 99.5% on arrival. Kakariko sits just under 85%, so the step had been let go and came back late. Much shorter than main's bursts, not gone. - One session out of eight played with these changes went badly, and I have not reproduced it: the first start after a rebuild, in the process that had just prepared every shader, with the driver allowing 9.6 GB instead of 10.2. The market ran at 27-30 fps for that visit, the count at 99.8%. A restart of the same build gave the 52-61 fps above. Nothing ties it to these commits, and I have not checked whether main does the same on such a start. `python -I -B tests/run_all.py`: 329 pass here; the 6 that fail fail the same way on main at 1ceaa2ba on this PC (no `zstandard`, no `libtk`, the local clang on two fixtures). Not tested on Windows, on AMD or Intel cards, or on cards with less than 12 GB. ## What could go wrong - With the GPU behind, a capture now goes on without the write-back after 8 ms where it used to get it within 250 ms: the exposure meter's page can be a frame stale. I did not see the exposure step in play, and did not look for it frame by frame. - A card whose working set in an area is above 40% of what the driver allows would evict and upload again in a loop. I have not seen that on this card outside the one session above, where it may have been the case. ## Related issues None of these was tested on its reporter's PC, so this does not claim to fix them. - #2398: the same card (RTX 5070 12 GB, Windows 11, v2.1.0), "significant FPS drop when entering Hyrule Town". Its attached log shows the same picture as here: `VRAM: 10250 MB used of 10616 MB allowed` with the texture budget at 6144 MB, `memory sync` at 15-35 ms of a frame's replay time, and 10-23 fps in the town. - #2392: frames of ~250 ms with `a capture's wait for write-back ... timed out` each time. That is the wait this pull request cuts to 8 ms; the GPU time there is long for other reasons, which this does not touch. - #2058 and #2180: video memory at the allowed limit, then a stall or a freeze, on AMD cards. - #995: the tracking issue for the drops in Castle Town. Assisted-by: Claude Fable 5.2 Co-Authored-By: Claude Fable 5.2 <[email protected]>

hckrman101 (Migrated from github.com) reviewed

2026-11-11 17:36:17 +00:00

hckrman101 (Migrated from github.com) left a comment

Thanks, this is a careful write-up, and the honesty about what the table doesn't isolate helps a lot. The problem is real (#2398's log matches yours). I have two concerns before this goes in, and one question about how it fits with the other VRAM work.

1. The 8 ms timeout applies on every GPU, not just at the VRAM limit. By default (RX_VK_CAPTURE_WAIT=2) this wait is the replay thread's, in take_capture, for the exposure meter's late pages. That wait is what fixed the one-frame exposure flashes (40-120 a minute in Kokiri Forest, see the comment in capture_make). On any GPU-bound card the GPU sits a frame behind as a matter of course, with no memory pressure at all. A 3060 Ti or 4050 at 30-40 fps will often be more than 8 ms behind, so the stale copy would become the normal path there and bring the flashes back. Under 250 ms it was a rare fallback. Details inline.

2. The step down near the limit hasn't been tried on small cards, and it bypasses the guards just below it. On an 8 GB card the default budget is already 45% of the allowance, so the 40% step is what bites there. Once a card reaches 97% it's held at 40% until the count is under 85%. With compaction off, the blocks keep what an eviction frees, so on 4-8 GB cards that may never happen: a cap 11% under the default for the rest of the session. The step also ignores room_in_blocks, which was added because squeezing at 97% while the blocks had 1.2 GB free emptied a paused game's textures on a 4 GB RX 5500M. A fixed cap doesn't ratchet the way the old one did, so it's milder, but it's the same situation. This is the same open point we raised on #2198: fixed 90%/97% rules that now apply to 8 GB cards by default, with no test below 12 GB. A run on an 8 GB card (Hyrule Field, then the market) would settle it.

3. Overlap with #2198. Both PRs go after the same thing: the count stuck at the limit because freed texture memory stays inside VMA's blocks. #2198 turns compaction on by default, which gives that space back and holds the count at 85% (80% reserve), and it evicts only long-unused textures. The camera-turn thrash it fixes (2.3-2.6 GB of live textures let go every 600 presents) is exactly what a cruder cap would bring back. If both land, this step runs before the hold. When it sets the lower budget, held < budget is false, evict_to stays 0, and the plain 7/8 eviction runs in place of #2198's long-unused-only pass. So this PR wouldn't fix #2198's open point, and it would partly override #2198. Could you try the market on main with RX_VK_COMPACT=1 (or on #2198's branch) without the step? If compaction alone gets the count off the limit, the step may not be needed. If it doesn't, the step should probably defer to the hold when compaction is on. Both PRs touch the same lines of texture_frame, so whichever lands second needs a rebase.

Related: #2368 (keep GPU-drawn textures) and #2154 (keep mirrors) don't touch these paths. #2288's ASTC counting is merged and this branch already has it.

Smaller things:

Nit: the comment on vk_timeline_wait's signature line (vk_replay.cpp:266) still says "at most 250 ms".
Nit: the 8 ms change and the budget step are independent. Each of them, measured alone against main, would make this much easier to judge, since the table also carries the upload threads, the Linux one and RX_VK_GPL=1.

CI: only the title check is showing, and it's still pending. The build and test workflows haven't run on this branch yet, and it's 19 commits behind main.

Holding off on approving until there's a run on an 8 GB card and an answer on the compaction question.

Thanks, this is a careful write-up, and the honesty about what the table doesn't isolate helps a lot. The problem is real (#2398's log matches yours). I have two concerns before this goes in, and one question about how it fits with the other VRAM work. **1. The 8 ms timeout applies on every GPU, not just at the VRAM limit.** By default (`RX_VK_CAPTURE_WAIT=2`) this wait is the replay thread's, in `take_capture`, for the exposure meter's late pages. That wait is what fixed the one-frame exposure flashes (40-120 a minute in Kokiri Forest, see the comment in `capture_make`). On any GPU-bound card the GPU sits a frame behind as a matter of course, with no memory pressure at all. A 3060 Ti or 4050 at 30-40 fps will often be more than 8 ms behind, so the stale copy would become the normal path there and bring the flashes back. Under 250 ms it was a rare fallback. Details inline. **2. The step down near the limit hasn't been tried on small cards, and it bypasses the guards just below it.** On an 8 GB card the default budget is already 45% of the allowance, so the 40% step is what bites there. Once a card reaches 97% it's held at 40% until the count is under 85%. With compaction off, the blocks keep what an eviction frees, so on 4-8 GB cards that may never happen: a cap 11% under the default for the rest of the session. The step also ignores `room_in_blocks`, which was added because squeezing at 97% while the blocks had 1.2 GB free emptied a paused game's textures on a 4 GB RX 5500M. A fixed cap doesn't ratchet the way the old one did, so it's milder, but it's the same situation. This is the same open point we raised on #2198: fixed 90%/97% rules that now apply to 8 GB cards by default, with no test below 12 GB. A run on an 8 GB card (Hyrule Field, then the market) would settle it. **3. Overlap with #2198.** Both PRs go after the same thing: the count stuck at the limit because freed texture memory stays inside VMA's blocks. #2198 turns compaction on by default, which gives that space back and holds the count at 85% (80% reserve), and it evicts only long-unused textures. The camera-turn thrash it fixes (2.3-2.6 GB of live textures let go every 600 presents) is exactly what a cruder cap would bring back. If both land, this step runs before the hold. When it sets the lower budget, `held < budget` is false, `evict_to` stays 0, and the plain 7/8 eviction runs in place of #2198's long-unused-only pass. So this PR wouldn't fix #2198's open point, and it would partly override #2198. Could you try the market on main with `RX_VK_COMPACT=1` (or on #2198's branch) without the step? If compaction alone gets the count off the limit, the step may not be needed. If it doesn't, the step should probably defer to the hold when compaction is on. Both PRs touch the same lines of `texture_frame`, so whichever lands second needs a rebase. Related: #2368 (keep GPU-drawn textures) and #2154 (keep mirrors) don't touch these paths. #2288's ASTC counting is merged and this branch already has it. Smaller things: - Nit: the comment on `vk_timeline_wait`'s signature line (vk_replay.cpp:266) still says "at most 250 ms". - Nit: the 8 ms change and the budget step are independent. Each of them, measured alone against main, would make this much easier to judge, since the table also carries the upload threads, the Linux one and `RX_VK_GPL=1`. CI: only the title check is showing, and it's still pending. The build and test workflows haven't run on this branch yet, and it's 19 commits behind main. Holding off on approving until there's a run on an 8 GB card and an answer on the compaction question.

gpu/vk/vk_replay.cpp

					
				@ -276,0 +277,4 @@

				    if (vkWaitSemaphores(dev.device, &wi, 8000000ull) == VK_TIMEOUT) {

				        static std::atomic<int64_t> n{0};

				        if (const int64_t k = ++n; k == 1 || k % 100 == 0)

				            logf("vk: a capture's wait for write-back %llu went on without it after 8 ms (done %llu): %lld so far", (unsigned long long)v,

On every GPU-bound system, not only at the VRAM limit, the GPU is regularly more than 8 ms behind the last submission that writes the exposure page back. When that happens, take_capture copies the late pages without their write-back, and the mirror sync puts the GPU's older words back over the newer ones. That brings back the one-frame exposure flash that this wait exists to prevent (see capture_make). Could the short timeout be used only while VRAM is pressed (compact.pressed / the step below is active), with 250 ms kept otherwise? Or could you show with a frame-by-frame check on a slower card that the flashes don't come back?

On every GPU-bound system, not only at the VRAM limit, the GPU is regularly more than 8 ms behind the last submission that writes the exposure page back. When that happens, `take_capture` copies the late pages without their write-back, and the mirror sync puts the GPU's older words back over the newer ones. That brings back the one-frame exposure flash that this wait exists to prevent (see `capture_make`). Could the short timeout be used only while VRAM is pressed (`compact.pressed` / the step below is active), with 250 ms kept otherwise? Or could you show with a frame-by-frame check on a slower card that the flashes don't come back?

gpu/vk/vk_texture.cpp

					
				@ -3898,0 +3890,4 @@

				    // kept until the count is back under 85%. At the limit nothing below squeezes while the blocks have room, and the blocks keep

				    // what an eviction frees, so the count stayed there: the driver paged and the replay waited for the GPU in bursts of seconds

				    // (Hyrule Castle Town's market on a 12 GB card). Not from the start: Hyrule Field fits at 91%, and uploads more with less

				    if (known && !vram_env) {

This runs before the compaction's hold and before the room_in_blocks guard, and it ignores both. With #2198's compaction on by default, a 40-55% cap set here makes held < budget false, so the hold's long-unused-only pass gives way to a plain 7/8 eviction. With compaction off, it squeezes even when the blocks hold an eighth of the allowance free (the 4 GB RX 5500M case). Maybe skip it when compact_on(), and respect room_in_blocks?

This runs before the compaction's hold and before the `room_in_blocks` guard, and it ignores both. With #2198's compaction on by default, a 40-55% cap set here makes `held < budget` false, so the hold's long-unused-only pass gives way to a plain 7/8 eviction. With compaction off, it squeezes even when the blocks hold an eighth of the allowance free (the 4 GB RX 5500M case). Maybe skip it when `compact_on()`, and respect `room_in_blocks`?

gpu/vk/vk_texture.cpp

					
				@ -3898,0 +3902,4 @@

				        } else if (used < allowed / 100 * 85) {

				            tight = 0;

				        }

				        if (tight) budget = std::min(budget, allowed / 100 * (tight == 3 ? tight_pct : tight == 2 ? tight_pct + 7 : tight_pct + 15));

On an 8 GB card the default own is 45% of the allowance, so step 3 (40%) cuts about 11% for as long as the count stays over 85%. With compaction off, that's probably the rest of the session on small cards. A run on an 8 GB card would show whether the scene's working set fits under 35% (7/8 of 40%), or whether this turns into the evict-and-upload loop that the description's last risk mentions.

On an 8 GB card the default `own` is 45% of the allowance, so step 3 (40%) cuts about 11% for as long as the count stays over 85%. With compaction off, that's probably the rest of the session on small cards. A run on an 8 GB card would show whether the scene's working set fits under 35% (7/8 of 40%), or whether this turns into the evict-and-upload loop that the description's last risk mentions.

msxdan commented

2026-11-11 18:36:56 +00:00

(Migrated from github.com)

Thanks for the review. I ran what you asked for, and you are right on the main point: compaction alone gets the count off the limit here, so I am closing this in favour of #2198.

Same PC as in the description (RTX 5070 12 GB, driver 615.78.08, Linux, 2560x1440, frame generation off), main at 1ceaa2ba plus test-only switches to turn each part on and off in one build. An input script loads a save in Kokiri Forest, teleports to the market and walks round the plaza with the camera turning for 83 s; frames counted from the arrival, RX_VK_FRAME_TRACE=1. Two runs each unless said.

	frames over 50 ms	frames with over 20 ms of memory sync	uploads	count at the end
main	214 / 100	155 / 85	~18,000	99%
main with `RX_VK_COMPACT=1`	2 / 1	0 / 0	~37,000	93% / 87%
this PR (8 ms + step)	3 / 4	0 / 0	~39,000	95-96%
the step alone	8 / 14	2 / 3	~40,000	97%
the 8 ms alone (one run)	137	102	~17,000	99.5%, 400 waits given up
the step, 8 ms only above 90% (one run)	2	0	~41,000	96%
`RX_VK_COMPACT=1` with the step (one run)	3	0	~38,500	96%

What I take from it:

Compaction alone does what this PR does, and brings the count lower. Played by hand on main with RX_VK_COMPACT=1 afterwards: 48-65 fps in the market, no frame with over 20 ms of memory sync, the count at 88%.
The 8 ms timeout is not worth its risk. Alone it does not fix the market, and beside the step or compaction it is hit 0-1 times a run. I did not run the flash check you asked for, since I am dropping the change.
The step works but adds nothing over compaction, and with compaction on it changes nothing I could measure.
Both the step and compaction about double the uploads against main on this route (the camera turning the whole time). That is the thrash you describe; I have not measured #2198's branch yet, only main with the switch.
8 GB cards: I have no card to test on. I tried reading the allowance as 8 GB on this one and it told me nothing (my options pin the 6 GB preset budget, and real use stayed above the pretended limit), so I have no data for your second point.

I will try #2198's branch on this card and the same route and post the numbers there.

Thanks for the review. I ran what you asked for, and you are right on the main point: compaction alone gets the count off the limit here, so I am closing this in favour of #2198. Same PC as in the description (RTX 5070 12 GB, driver 615.78.08, Linux, 2560x1440, frame generation off), main at 1ceaa2ba plus test-only switches to turn each part on and off in one build. An input script loads a save in Kokiri Forest, teleports to the market and walks round the plaza with the camera turning for 83 s; frames counted from the arrival, `RX_VK_FRAME_TRACE=1`. Two runs each unless said. | | frames over 50 ms | frames with over 20 ms of memory sync | uploads | count at the end | |---|---|---|---|---| | main | 214 / 100 | 155 / 85 | ~18,000 | 99% | | main with `RX_VK_COMPACT=1` | 2 / 1 | 0 / 0 | ~37,000 | 93% / 87% | | this PR (8 ms + step) | 3 / 4 | 0 / 0 | ~39,000 | 95-96% | | the step alone | 8 / 14 | 2 / 3 | ~40,000 | 97% | | the 8 ms alone (one run) | 137 | 102 | ~17,000 | 99.5%, 400 waits given up | | the step, 8 ms only above 90% (one run) | 2 | 0 | ~41,000 | 96% | | `RX_VK_COMPACT=1` with the step (one run) | 3 | 0 | ~38,500 | 96% | What I take from it: - **Compaction alone does what this PR does**, and brings the count lower. Played by hand on main with `RX_VK_COMPACT=1` afterwards: 48-65 fps in the market, no frame with over 20 ms of memory sync, the count at 88%. - **The 8 ms timeout is not worth its risk.** Alone it does not fix the market, and beside the step or compaction it is hit 0-1 times a run. I did not run the flash check you asked for, since I am dropping the change. - **The step works but adds nothing over compaction**, and with compaction on it changes nothing I could measure. - **Both the step and compaction about double the uploads** against main on this route (the camera turning the whole time). That is the thrash you describe; I have not measured #2198's branch yet, only main with the switch. - **8 GB cards:** I have no card to test on. I tried reading the allowance as 8 GB on this one and it told me nothing (my options pin the 6 GB preset budget, and real use stayed above the pretended limit), so I have no data for your second point. I will try #2198's branch on this card and the same route and post the numbers there.

Commenting is not possible because the repository is archived.

No reviewers