richisol commented

(Migrated from github.com)

Hookshot version

2.1.0

What kind of problem

Low fps or stutter

What happened

Slowdown after moving between areas: GPU memory seems to spill into system RAM and write-back copies drop from ~120 GB/s to ~6 GB/s (v2.1.0, RTX 5070 12 GB)

Summary

Right after a fresh start the game runs at 60 fps. After a few minutes of moving between areas it drops to 10–35 fps. Restarting and staying in one area gives 60 fps again.

I returned to the same place with the same draw count and the same frame cost went up about 3x. The game's own GPU timing shows the write-back copies (mirror -> guest memory) running at VRAM speed when fast and at PCIe speed when slow. The game's shared GPU memory (system RAM used by the GPU) grows from 2 GB to 6 GB while VRAM is at the limit.

Environment

Hookshot v2.1.0 (source 633eb435), Windows 11 Pro 26200, fullscreen
GPU: RTX 5070 12 GB, NVIDIA driver 617.14
CPU/RAM: Ryzen 7 5700X3D, 32 GB RAM, pagefile 5 GB (system managed), High performance power plan
PCIe link reads Gen 3 x8 under load (nvidia-smi: pcie.link.gen.max=3, width.max=16, current width=8). I am checking my slot/BIOS. This may make the effect worse on my PC, but the VRAM behaviour below is independent of it.
Settings: quality_preset=0 (Custom), output_res=2048x1152, dlss=2, dlss_model=3, resolution=0 (Auto), anisotropic_filtering=4, frame_generation=0, mesh_shaders=0 (Automatic), robust_buffers=0, descriptor_reuse=1
hookshot_env.txt: only RX_VK_PASS_TIMING=1 (and SLOW_LOG/FRAME_LOG); no other switches. Note: PASS_TIMING waits on the GPU per span, so absolute GPU times in those blocks are inflated, but the pattern is the same as in the normal "GPU time" lines.

Steps (clock times from my notes)

18:15 Kokiri Forest entrance (about 1 minute after starting the game)
18:18 Hyrule Field
18:19:45 Hyrule Castle Town
18:21 back in Hyrule Field
18:23 back in Kokiri Forest
18:24 end, in the menu. (The jumps to 60 fps are me opening the map.)

Evidence 1: same place, same draws, ~3x the cost

Kokiri Forest	18:15 (first visit)	18:23 (after the walk)
Draws per frame	~897	~890–909
fps	60	32–34
GPU time (normal stats line)	7.1 ms	19–23 ms
memory sync	0.4 ms	15–17 ms
VRAM used / allowed (game log)	7.3 / 11.2 GB	11.3 / 10.9 GB
Free in the blocks	0.5 GB	2.7 GB
Game's shared GPU memory (Windows counter)	2.0 GB	5.7–6.2 GB
Imports (game log)	1.6 GB	3.3 GB

Evidence 2: write-back copy speed (GPU pass timing blocks)

"wb" = copies mirror -> guest memory. MB and ms are per frame as the game reports them.

Clock	Where	fps	wb MB	wb ms	wb speed	avg pass span
18:15:16	Kokiri	60	48.5	0.38	129 GB/s	19 µs
18:17:01	Kokiri	60	66.6	0.56	119 GB/s	22 µs
18:18:26	Hyrule Field	40	68.3	9.35	7.3 GB/s	23 µs
18:19:16	Hyrule Field	57	68.5	1.43	48 GB/s	28 µs
18:19:53	Castle Town	23	37.1	2.40	15.5 GB/s	36 µs
18:21:24	Hyrule Field	15	48.0	7.78	6.2 GB/s	255 µs
18:23:13	Kokiri	33	54.8	8.82	6.2 GB/s	52 µs
18:23:36	Kokiri	21	62.9	10.12	6.2 GB/s	68 µs

When fast the copies run at 100+ GB/s (VRAM speed). When slow they run at 6–7 GB/s, which is what a PCIe 3.0 x8 link carries. The draw passes also get slower (19 µs -> up to 255 µs per span), which looks like the GPU reading textures/buffers from system memory.

Evidence 3: VRAM and memory (game log + nvidia-smi + Windows counters)

vk: VRAM: 12343 MB used of 10889 MB allowed (2792 MB of it free in the blocks); textures 5184 MB (budget 6144 MB), 2451 textures (at the driver's limit, room in the blocks: not squeezed)
vk: image blocks: 49 blocks 6272 MB, 2533 images 4316 MB; 1504 free ranges, the largest 62 MB

"used" exceeds "allowed" at times (12343 vs 10889). At the end of the run: 10784 used, 2995 MB free in the blocks.
nvidia-smi: 11.2–11.6 GB used of 12.2 GB while slow; the game's dedicated usage ~10.4–10.8 GB; dwm 0.65–1.05 GB.
Game's shared GPU memory (Windows GPU Process Memory counter): 2.0 GB at 18:15 -> 3.2 GB (18:18) -> 5.4 GB (18:19:52) -> 6.3 GB (18:21:28). Imports in the log only grow 1.6 -> 3.3 GB, so about 2.5 GB more of the game's GPU memory sits in system memory than at the start.
GPU power is only 58–65 W at 92–96% utilisation in the slow stretches (84–88 W at 60 fps), so the GPU looks busy but stalled.

Ruled out

Windows paging: pagefile used 25–402 MB (of 5 GB), disk reads small outside loads, free RAM 2.4–2.9 GB at the lowest.
Shaders: "0.00 waits for shaders or pipelines" in slow stretches.
Throttling: clocks 2.9 GHz, power 60–88 W of 250 W, 41–63 °C, throttle bit constant.
Other programs: next biggest VRAM users are dwm (~1 GB) and small apps.
Not related: dips to 40–44 fps in Kokiri at 3,500–4,000 draws (18:15:25–18:16:06) are CPU-side limited, memory numbers are normal there.

Hypotheses (not confirmed)

When VRAM reaches the allowance, part of the game's allocations are placed in system memory (shared GPU memory), and write-back copies and draws that touch them then run at PCIe speed. On my PCIe 3.0 x8 link this is about 6 GB/s.
#1506 makes the texture squeeze wait while VMA's blocks have room. The free space is in 1,300–1,800 small ranges (largest 62–94 MB), so it may not be usable and nothing is evicted.

Questions

Is this known? Is there a recommended preset or setting for 12 GB cards (RX_VK_MIRROR_MB, RX_VK_VRAM_MB, the VRAM compaction from #1821)?
Is the README's "about 10 GB" for a run still accurate? I see ~23 GB working set and ~35 GB private memory.

Not done yet

Testing RX_VK_MIRROR_MB / RX_VK_VRAM_MB caps.
Checking the same run on a full x16 PCIe link.

Attachments

hookshot_issue_log_excerpt_v2.txt: trimmed log with clock annotations (full log available).
hookshot_monitor.csv: nvidia-smi / memory / Windows counters every 5 s, including the size of hookshot_log.txt so log lines can be matched to clock time.

hookshot_issue_log_excerpt_v2.txt

Where in the game

Kokiri Forest, Hyrule Field and Castle Town, walking back and forth between them

How often

Every time

Graphics card and driver version

RTX 5070 12GB, NVIDIA 617.14

CPU, RAM and operating system

Ryzen 7 5700X3D, 32 GB, Windows 11 Pro 26200

Changes from the defaults

quality_preset=0, output_res=2048x1152, dlss=2, dlss_model=3, anisotropic_filtering=4, and the env line RX_VK_PASS_TIMING=1

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

Screenshots or video

No response

Before you send it

I'm on the newest release, or the problem is still there on it.
I searched the open issues for this problem.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

### Hookshot version 2.1.0 ### What kind of problem Low fps or stutter ### What happened # Slowdown after moving between areas: GPU memory seems to spill into system RAM and write-back copies drop from ~120 GB/s to ~6 GB/s (v2.1.0, RTX 5070 12 GB) ## Summary Right after a fresh start the game runs at 60 fps. After a few minutes of moving between areas it drops to 10–35 fps. Restarting and staying in one area gives 60 fps again. I returned to the same place with the same draw count and the same frame cost went up about 3x. The game's own GPU timing shows the write-back copies (mirror -> guest memory) running at VRAM speed when fast and at PCIe speed when slow. The game's shared GPU memory (system RAM used by the GPU) grows from 2 GB to 6 GB while VRAM is at the limit. ## Environment - Hookshot v2.1.0 (source 633eb435), Windows 11 Pro 26200, fullscreen - GPU: RTX 5070 12 GB, NVIDIA driver 617.14 - CPU/RAM: Ryzen 7 5700X3D, 32 GB RAM, pagefile 5 GB (system managed), High performance power plan - **PCIe link reads Gen 3 x8 under load** (nvidia-smi: pcie.link.gen.max=3, width.max=16, current width=8). I am checking my slot/BIOS. This may make the effect worse on my PC, but the VRAM behaviour below is independent of it. - Settings: quality_preset=0 (Custom), output_res=2048x1152, dlss=2, dlss_model=3, resolution=0 (Auto), anisotropic_filtering=4, frame_generation=0, mesh_shaders=0 (Automatic), robust_buffers=0, descriptor_reuse=1 - `hookshot_env.txt`: only `RX_VK_PASS_TIMING=1` (and SLOW_LOG/FRAME_LOG); no other switches. Note: PASS_TIMING waits on the GPU per span, so absolute GPU times in those blocks are inflated, but the pattern is the same as in the normal "GPU time" lines. ## Steps (clock times from my notes) 1. 18:15 Kokiri Forest entrance (about 1 minute after starting the game) 2. 18:18 Hyrule Field 3. 18:19:45 Hyrule Castle Town 4. 18:21 back in Hyrule Field 5. 18:23 back in Kokiri Forest 6. 18:24 end, in the menu. (The jumps to 60 fps are me opening the map.) ## Evidence 1: same place, same draws, ~3x the cost | Kokiri Forest | 18:15 (first visit) | 18:23 (after the walk) | |---|---|---| | Draws per frame | ~897 | ~890–909 | | fps | 60 | 32–34 | | GPU time (normal stats line) | 7.1 ms | 19–23 ms | | memory sync | 0.4 ms | 15–17 ms | | VRAM used / allowed (game log) | 7.3 / 11.2 GB | 11.3 / 10.9 GB | | Free in the blocks | 0.5 GB | 2.7 GB | | Game's shared GPU memory (Windows counter) | 2.0 GB | 5.7–6.2 GB | | Imports (game log) | 1.6 GB | 3.3 GB | ## Evidence 2: write-back copy speed (GPU pass timing blocks) "wb" = copies mirror -> guest memory. MB and ms are per frame as the game reports them. | Clock | Where | fps | wb MB | wb ms | wb speed | avg pass span | |---|---|---|---|---|---|---| | 18:15:16 | Kokiri | 60 | 48.5 | 0.38 | **129 GB/s** | 19 µs | | 18:17:01 | Kokiri | 60 | 66.6 | 0.56 | **119 GB/s** | 22 µs | | 18:18:26 | Hyrule Field | 40 | 68.3 | 9.35 | **7.3 GB/s** | 23 µs | | 18:19:16 | Hyrule Field | 57 | 68.5 | 1.43 | 48 GB/s | 28 µs | | 18:19:53 | Castle Town | 23 | 37.1 | 2.40 | 15.5 GB/s | 36 µs | | 18:21:24 | Hyrule Field | 15 | 48.0 | 7.78 | **6.2 GB/s** | **255 µs** | | 18:23:13 | Kokiri | 33 | 54.8 | 8.82 | **6.2 GB/s** | 52 µs | | 18:23:36 | Kokiri | 21 | 62.9 | 10.12 | **6.2 GB/s** | 68 µs | When fast the copies run at 100+ GB/s (VRAM speed). When slow they run at 6–7 GB/s, which is what a PCIe 3.0 x8 link carries. The draw passes also get slower (19 µs -> up to 255 µs per span), which looks like the GPU reading textures/buffers from system memory. ## Evidence 3: VRAM and memory (game log + nvidia-smi + Windows counters) ``` vk: VRAM: 12343 MB used of 10889 MB allowed (2792 MB of it free in the blocks); textures 5184 MB (budget 6144 MB), 2451 textures (at the driver's limit, room in the blocks: not squeezed) vk: image blocks: 49 blocks 6272 MB, 2533 images 4316 MB; 1504 free ranges, the largest 62 MB ``` - "used" exceeds "allowed" at times (12343 vs 10889). At the end of the run: 10784 used, 2995 MB free in the blocks. - nvidia-smi: 11.2–11.6 GB used of 12.2 GB while slow; the game's dedicated usage ~10.4–10.8 GB; dwm 0.65–1.05 GB. - Game's shared GPU memory (Windows GPU Process Memory counter): 2.0 GB at 18:15 -> 3.2 GB (18:18) -> 5.4 GB (18:19:52) -> 6.3 GB (18:21:28). Imports in the log only grow 1.6 -> 3.3 GB, so about 2.5 GB more of the game's GPU memory sits in system memory than at the start. - GPU power is only 58–65 W at 92–96% utilisation in the slow stretches (84–88 W at 60 fps), so the GPU looks busy but stalled. ## Ruled out - Windows paging: pagefile used 25–402 MB (of 5 GB), disk reads small outside loads, free RAM 2.4–2.9 GB at the lowest. - Shaders: "0.00 waits for shaders or pipelines" in slow stretches. - Throttling: clocks 2.9 GHz, power 60–88 W of 250 W, 41–63 °C, throttle bit constant. - Other programs: next biggest VRAM users are dwm (~1 GB) and small apps. - Not related: dips to 40–44 fps in Kokiri at 3,500–4,000 draws (18:15:25–18:16:06) are CPU-side limited, memory numbers are normal there. ## Hypotheses (not confirmed) 1. When VRAM reaches the allowance, part of the game's allocations are placed in system memory (shared GPU memory), and write-back copies and draws that touch them then run at PCIe speed. On my PCIe 3.0 x8 link this is about 6 GB/s. 2. #1506 makes the texture squeeze wait while VMA's blocks have room. The free space is in 1,300–1,800 small ranges (largest 62–94 MB), so it may not be usable and nothing is evicted. ## Questions - Is this known? Is there a recommended preset or setting for 12 GB cards (`RX_VK_MIRROR_MB`, `RX_VK_VRAM_MB`, the VRAM compaction from #1821)? - Is the README's "about 10 GB" for a run still accurate? I see ~23 GB working set and ~35 GB private memory. ## Not done yet - Testing `RX_VK_MIRROR_MB` / `RX_VK_VRAM_MB` caps. - Checking the same run on a full x16 PCIe link. ## Attachments - `hookshot_issue_log_excerpt_v2.txt`: trimmed log with clock annotations (full log available). - `hookshot_monitor.csv`: nvidia-smi / memory / Windows counters every 5 s, including the size of hookshot_log.txt so log lines can be matched to clock time. [hookshot_issue_log_excerpt_v2.txt](https://github.com/user-attachments/files/34699431/hookshot_issue_log_excerpt_v2.txt) ### Where in the game Kokiri Forest, Hyrule Field and Castle Town, walking back and forth between them ### How often Every time ### Graphics card and driver version RTX 5070 12GB, NVIDIA 617.14 ### CPU, RAM and operating system Ryzen 7 5700X3D, 32 GB, Windows 11 Pro 26200 ### Changes from the defaults quality_preset=0, output_res=2048x1152, dlss=2, dlss_model=3, anisotropic_filtering=4, and the env line RX_VK_PASS_TIMING=1 ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [hookshot_log.txt](https://github.com/user-attachments/files/34699767/hookshot_log.txt) ### Screenshots or video _No response_ ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

JustScorpionn commented

2026-11-11 18:14:57 +00:00

(Migrated from github.com)

Same for me. Intel Core Ultra 9 275HX, 32GB DDR5 RAM (6400MT/s), RTX 5070TI Laptop GPU (12GB)
Also my logs.
hookshot_log.3.txt
hookshot_log.4.txt
hookshot_log.txt
hookshot_log.1.txt
hookshot_log.2.txt

Same for me. Intel Core Ultra 9 275HX, 32GB DDR5 RAM (6400MT/s), RTX 5070TI Laptop GPU (12GB) Also my logs. [hookshot_log.3.txt](https://github.com/user-attachments/files/34700431/hookshot_log.3.txt) [hookshot_log.4.txt](https://github.com/user-attachments/files/34700430/hookshot_log.4.txt) [hookshot_log.txt](https://github.com/user-attachments/files/34700433/hookshot_log.txt) [hookshot_log.1.txt](https://github.com/user-attachments/files/34700434/hookshot_log.1.txt) [hookshot_log.2.txt](https://github.com/user-attachments/files/34700432/hookshot_log.2.txt)

kennmaskin commented

2026-11-11 19:21:01 +00:00

(Migrated from github.com)

It's been happening to me for a couple of versions now i have the same laptop specs and I still have issues with the game overflowing into system ram and using up all 12 GB of VRAM.

GeekyGami commented

2026-11-11 19:57:54 +00:00

(Migrated from github.com)

Can confirm.

felipefl142 commented

2026-11-11 20:55:21 +00:00

(Migrated from github.com)

Same slowdown on an 8 GB card under Linux. The log also shows pools left in system memory for good after one short VRAM shortage, which #2482 addresses.

Setup: RTX 3070 Laptop 8 GB, NVIDIA 620.70.06, CachyOS (kernel 7.3), main at 7759a6f (v2.1.0-rc.3-86-g7759a6f). DLSS (built with the SDK), output 1920x1080, RX_VK_VRAM_MB=3072, RX_VK_IMAGE_BLOCK_MB=64, RX_VK_COMPACT=1, RX_VK_FSR_FG=0. Mirror budget is the default for 8 GB: 2048 MB.

Two sessions of about an hour each on the same build:

	Session 1	Session 2
Game fps (mean of the `vi:` lines)	44	35 (200 of 852 five-second windows at 20-28)
GPU time a frame	10.8 ms	16.1 ms
Replay `submit` a frame	9.6 ms	15.7 ms
`memory sync` a frame	2.1 ms	4.5 ms
"bound in guest memory" summaries with more than 100 MB	20	2956

Session 1 reached the mirror budget only near its end. Session 2 reached it about 10 minutes in. VRAM was at its limit then, and image allocations started failing:

vk: VRAM: 6503 MB used of 7559 MB allowed (1254 MB of it free in the blocks); textures 2447 MB (budget 3072 MB), 1520 textures
vk: pool 0x1178000000 (160 MB) stays in system memory: the mirrors have 1920 MB of 2048
vk: pool 0x1140000000 (80 MB) stays in system memory: the mirrors have 2048 MB of 2048
vk: pool 0x7fd3000000 (160 MB) stays in system memory: the mirrors have 2032 MB of 2048
vk: image over budget, retrying without WITHIN_BUDGET   (x10)

From then until the session ended (53,000 log lines later), the per-600-submit summaries show the same pools in state 3 (MIRROR_REFUSED), with 200-560 MB read over PCIe in each window:

vk:   bound in guest memory, by pool (... 561.9 MB in all ...):  0x7f64000000 (32 MB, state 3): 1161 binds, 347 MB; ...

Pool (state 3)	Summaries it appears in
0x7f64000000 (32 MB)	3017
0x1165000000 (32 MB)	2582
0x7f4f000000 (32 MB)	2042
0x1167000000 (32 MB)	1983
0x7f97000000 (160 MB)	1344
0x7fd3000000 (160 MB)	1127

None of these pools went back to state 0 or 2. That includes a stretch about 25 minutes in when VRAM dropped to 4.3 of 7.5 GB. In mirror_make (gpu/vk/vk_memory.cpp), a failed create_device_buffer sets MIRROR_REFUSED, and only mirror_free sets the state back, which a refused pool never reaches. So a short allocation failure leaves the pool in system memory until its import is given back. #2482 (retry after VRAM pressure) changes exactly this, so I've linked it here.

The retry alone may not fix everything. In session 2 the mirrors stayed at 2016-2048 of the 2048 MB budget for the rest of the session, so a retried pool still has to compete for that budget (#1377 would choose which pools get it). For now I lowered RX_VK_VRAM_MB from 3072 to 2560 to leave VRAM for the mirrors. I'll report back after I've played on that setting.

Same slowdown on an 8 GB card under Linux. The log also shows pools left in system memory for good after one short VRAM shortage, which #2482 addresses. **Setup:** RTX 3070 Laptop 8 GB, NVIDIA 620.70.06, CachyOS (kernel 7.3), main at 7759a6f (`v2.1.0-rc.3-86-g7759a6f`). DLSS (built with the SDK), output 1920x1080, `RX_VK_VRAM_MB=3072`, `RX_VK_IMAGE_BLOCK_MB=64`, `RX_VK_COMPACT=1`, `RX_VK_FSR_FG=0`. Mirror budget is the default for 8 GB: 2048 MB. **Two sessions of about an hour each on the same build:** | | Session 1 | Session 2 | |---|---|---| | Game fps (mean of the `vi:` lines) | 44 | 35 (200 of 852 five-second windows at 20-28) | | GPU time a frame | 10.8 ms | 16.1 ms | | Replay `submit` a frame | 9.6 ms | 15.7 ms | | `memory sync` a frame | 2.1 ms | 4.5 ms | | "bound in guest memory" summaries with more than 100 MB | 20 | 2956 | Session 1 reached the mirror budget only near its end. Session 2 reached it about 10 minutes in. VRAM was at its limit then, and image allocations started failing: ``` vk: VRAM: 6503 MB used of 7559 MB allowed (1254 MB of it free in the blocks); textures 2447 MB (budget 3072 MB), 1520 textures vk: pool 0x1178000000 (160 MB) stays in system memory: the mirrors have 1920 MB of 2048 vk: pool 0x1140000000 (80 MB) stays in system memory: the mirrors have 2048 MB of 2048 vk: pool 0x7fd3000000 (160 MB) stays in system memory: the mirrors have 2032 MB of 2048 vk: image over budget, retrying without WITHIN_BUDGET (x10) ``` From then until the session ended (53,000 log lines later), the per-600-submit summaries show the same pools in **state 3** (`MIRROR_REFUSED`), with 200-560 MB read over PCIe in each window: ``` vk: bound in guest memory, by pool (... 561.9 MB in all ...): 0x7f64000000 (32 MB, state 3): 1161 binds, 347 MB; ... ``` | Pool (state 3) | Summaries it appears in | |---|---| | 0x7f64000000 (32 MB) | 3017 | | 0x1165000000 (32 MB) | 2582 | | 0x7f4f000000 (32 MB) | 2042 | | 0x1167000000 (32 MB) | 1983 | | 0x7f97000000 (160 MB) | 1344 | | 0x7fd3000000 (160 MB) | 1127 | None of these pools went back to state 0 or 2. That includes a stretch about 25 minutes in when VRAM dropped to 4.3 of 7.5 GB. In `mirror_make` (`gpu/vk/vk_memory.cpp`), a failed `create_device_buffer` sets `MIRROR_REFUSED`, and only `mirror_free` sets the state back, which a refused pool never reaches. So a short allocation failure leaves the pool in system memory until its import is given back. #2482 (retry after VRAM pressure) changes exactly this, so I've linked it here. The retry alone may not fix everything. In session 2 the mirrors stayed at 2016-2048 of the 2048 MB budget for the rest of the session, so a retried pool still has to compete for that budget (#1377 would choose which pools get it). For now I lowered `RX_VK_VRAM_MB` from 3072 to 2560 to leave VRAM for the mirrors. I'll report back after I've played on that setting.

NotRexed commented

2026-11-11 21:30:14 +00:00

(Migrated from github.com)

Thanks for the report. Reports of the same problem are now collected in #993, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #993 for the fix, and add new details there (or here). If this turns out to be a separate problem it will be reopened.

felipefl142 commented

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

(Migrated from github.com)

Follow-up to my comment above. I tested #2482 (retry refused mirrors) merged into main at 57ed3aa on the same 8 GB card, and it fixes the part where pools stayed refused for good. VRAM still filled up when I left the Water Temple for Lake Hylia, but the pools got their mirrors back within about 3 minutes. Pools appeared in state 3 in 4 summaries, against 23,649 in the bad session. memory sync stayed at 0.7-0.9 ms the whole session. Numbers by scene size are in #2482.

An update to what I wrote above: lowering RX_VK_VRAM_MB to 2560 did not help. VRAM still filled up, textures were missing or blurry, and fps was lower. I went back to 3072.

Follow-up to my comment above. I tested #2482 (retry refused mirrors) merged into main at 57ed3aa on the same 8 GB card, and it fixes the part where pools stayed refused for good. VRAM still filled up when I left the Water Temple for Lake Hylia, but the pools got their mirrors back within about 3 minutes. Pools appeared in state 3 in 4 summaries, against 23,649 in the bad session. `memory sync` stayed at 0.7-0.9 ms the whole session. Numbers by scene size are in #2482. An update to what I wrote above: lowering `RX_VK_VRAM_MB` to 2560 did not help. VRAM still filled up, textures were missing or blurry, and fps was lower. I went back to 3072.