[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
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
2 participants
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot#993
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This issue collects every open report of garbled or rainbow textures that get worse over play time, so there is one place to follow it. The individual reports were closed pointing here; their logs, screenshots and discussion stay in each linked issue.
Summary
Textures turn into multicoloured blocks, rainbow or checkerboard patterns, see-through characters with thin stripes, or black terrain. It usually starts after some minutes of play and gets worse the longer the game runs. Saving and reloading, or restarting, clears it for a while. The v2.0.6 release notes list it as a known issue that is being worked on; it is not fixed yet.
Affected GPUs and versions
Evidence from the logs
Every v2.0.5 log attached to these reports shows the same three things:
Working hypothesis: a texture that is evicted and later re-created comes back with the wrong contents. #933 decodes ASTC on upload (not the BC3 path), so it is not only the BC3 re-encode. #1015 (kept open; #988 closed into it) is a freeze or device lost every time on the walk from Kakariko to Death Mountain Trail, on v2.0.5 and v2.0.6. "A capture's wait for write-back ... timed out" there, on a GPU-written 1600x1600 texture that is uploaded again, which may be related.
Texture problems that do not show this pattern are listed in the table too (for example #736, stretched floor textures on a 16 GB RTX 5080, and #107, ground streaks after a long walk from Castle Town).
Workarounds
Reports merged here (25 issues, about 46 people)
b234b43): Deck textures stay at budget, paging stops, no device lost…Adding a report
Please update to v2.0.6 first (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher). Please add: GPU and its VRAM size, preset and Resolution, the area, how many minutes until it starts, and the
hookshot_log.txtfrom that session (the VRAM / budget / "textures retired" lines are what matter).All tracking issues
RX_VK_BC_IDLE_S=0 stops the garbled textures here (RTX 3050 Laptop 4 GB, v2.0.5)
Following up on #898 with more testing. The garbage seems tied to the BC3 scratch being given back when it goes idle.
Setup: RTX 3050 Laptop 4 GB, driver 32.0.16.1742. The driver allows 3367 MB, so every large ASTC texture goes through the BC3 re-encode.
Preset: Custom (Resolution 50%, handheld profile on, frame generation off). Still on v2.0.5, but the scratch give-back code (
bc_scratch_idleingpu/vk/vk_texture.cpp) is unchanged in v2.0.6 and v2.0.7, so this should still apply there.What I saw in the logs:
vk: the BC3 scratch (160 MB) unused for N s: given backline. That includes a session on default settings, where the scratch is given back after 20 s.RX_VK_NO_EVICT=1did not help. The textures still turned to noise, so eviction and re-creation are not the cause.RX_VK_ASTC_RGBA8=1together withRX_VK_NO_EVICT=1gave no garbage across Kakariko, Hyrule Field, Lake Hylia and Castle Town. The BC3 scratch is never used in that mode, but RAM filled up and loading was very slow.RX_VK_ASTC_BC_ALL=0did not help. UI and character textures stayed out of BC3, and the garbage still came back.With
RX_VK_BC_IDLE_S=0(scratch kept for good, at a cost of 160 MB of VRAM): Kokiri Forest, Hyrule Castle, Castle Town and Hyrule Field were all clean, in a session of about 20 minutes. No give-back line in the log. VRAM was still over the allowance (3.5–3.9 GB of 3367 MB), so being over budget alone does not cause it.Local changes in this build. To be transparent, these two logs come from a build with changes of mine:
The default-settings session with the garbage, attached to #898, had none of them. The two logs below differ only in
RX_VK_BC_IDLE_S(5 in the garbage one, 0 in the clean one) andRX_VK_ASTC_BC_ALL(0 in the garbage one, default in the clean one). I'm open to going into these changes in more depth if that helps.For anyone with a 4–8 GB card: add
RX_VK_BC_IDLE_S=0tohookshot_env.txtnext to the game (or set it as an environment variable) and see whether the garbage stops.Logs:
RX_VK_BC_IDLE_S=0, no give-back, clean: https://gist.githubusercontent.com/hallygtree/8d7d0dbe8e00982aa5ab3d95d16765ca/raw/v2.0.5_bc_idle0_clean.txthookshot_log.txt
After the latest update the game now runs at like 20-25 fps and some weird shaders.
Fixed in the v2.0.12 branch, closing when it ships. (the rainbow and garbled textures on 6-8 GB cards). Please retest when it's out and comment here if they come back.
Also in the v2.0.12 branch: a lower texture budget on cards with 8 GB or less, aimed at the slowdowns and garbling when VRAM fills.
Data point for 4 GB cards: a preset that turns into Custom falls back to #1485's 45% default (1551 MB on a 4 GB card), and a pause evicted ~580 textures (resume at 8.6 fps). Numbers in #1358: #1358
Three open PRs address parts of this on 4 GB cards, tested on an RX 5500M:
Another 16 GB card, v2.0.13: Dodongo's Cavern floor garbles after a while (logs attached)
Setup
hookshot v2.0.13 (source cfc565a2)What happens
After a while in Dodongo's Cavern the floor texture turns into stretched streaks (screenshot attached). Restarting brings it back to normal.
From the logs (
hookshot_log_dodongo.txt, about 53,000 presents)hookshot_log_previous.txt, also v2.0.13): at most 10280 MB VRAM, textures 5100 of 6144 MB, 1356 retire events, 24,944 textures.This matches the worklist's 16 GB case (2.1). Since textures get retired even far below the budget, it might fit your next test: whether a retired and re-made texture comes back with stale or wrong contents. Happy to try test switches.
Two more players on Discord: ground textures go wrong near Lon Lon Ranch after long sessions, and one says big stutters come first. With the floor reports in #1006 / #1717 (cleared by reloading the save) and #1710 (VRAM growing over play time), this points at memory growing until textures are evicted or fail.
One more on v2.0.14 (Discord, RTX 4070): Hyrule Field terrain textures going wrong.
hookshot_log.txt
Running pretty good but still fps drops is this just a skill issue?
bcs of 4gb vram?
One more (Discord, Linux, RTX 2060 Super): the ground breaks after the Lon Lon Ranch cutscene; see #1000.
Two more from Discord on v2.0.14: an RTX 5060 Ti 16 GB with the smeared floor in the graveyard, and an RX 9070 XT getting it at random places (Kokiri Forest, Hyrule Field, Death Mountain). It happens on NVIDIA too and on a 16 GB card, so it isn't only VRAM pressure on small cards; see #1006.
A log for the NVIDIA side of this: RTX 4070 12 GB, Hyrule Field terrain (with screenshots).
Setup: Ubuntu 26.04.1, GNOME 50 Wayland, driver 615.71.09, Ryzen 7 5800X3D, 64 GB. 2560x1440, DLSS DLAA, frame generation off, Balanced preset (texture budget 6144 MB). Build: the nightly
v2.1.0-rc.3-46-gddafc1fwith #2314'svk_memory.cppswapped in, run withRX_VK_SHADOW_STAGE=0, so the shadow copies took the same path as without #2314.What: large flat, sharp-edged dark green and brown patches over the Hyrule Field ground, where the grass and terrain texture should be (screenshots). I noticed it about 14 minutes after launch, after leaving Kokiri Forest for the field (around log line 16005, present 58,560). The patches stayed while I moved around Hyrule Field, and were gone once I was back in Kokiri Forest.
What the log shows around it:
docs/worklist.md(under the budget, VRAM at the driver's limit), not the case that runs into the budget.upload over a drawn imagelines, including a 2560x1440 one (NVN 0x25) and a 640x360 one, both witha GPU buffer wrote it. There were 122 of these lines in the session.RX_VK_LOG_REMADEwas not set in this run.More reports of this, collected here:
After around 2.5 hours of gameplay:
hookshot_log.txt
RTX 4080 SUPER (16 GB VRAM)
For #2412's slowdown: reproduced on Linux on a 12 GB card, and in these runs the VRAM compaction that is now on by default (#2198) prevented it. Same route as #2412, with RX_VK_PASS_TIMING=1.
Setup: RTX 4070 12 GB, NVIDIA 615.71.09, Ryzen 7 5800X3D, 64 GB, Ubuntu 26.04.1, GNOME 50 Wayland. 2560x1440, DLSS DLAA, frame generation off, RX_VK_PARALLEL=4, same options file in every session.
Route: a fixed Kokiri Forest view (60 s standing), Hyrule Field, Castle Town (about 3 minutes), Hyrule Field, then the same Kokiri view again (60 s). About 12 minutes a session (23 for the older one, including a pause).
Builds:
Same Kokiri view, start -> end of each session:
RX_VK_COMPACT=0What we saw:
For Windows: compaction is in v2.1.0 but off unless RX_VK_COMPACT=1, and v2.1.0 does not have #2198's fix for the compaction's hold evicting textures in use. I haven't tested Windows.
These were short sessions (about 12 minutes of play each) on a 12 GB card. felipefl142's hour-long sessions on an 8 GB card still slowed down with RX_VK_COMPACT=1, on rc.3-86, which is before #2198. So I can't say whether compaction as it is now holds up for smaller cards or longer play; #2482 targets the pools that stay in system memory.
Logs:
Another data point, from a 24 GB card with 32 GB of RAM: here it is not the VRAM that runs out but the system commit.
Setup: v2.1.0 (source 633eb435), RTX 4090 24 GB, 32 GB RAM + 13 GB page file, Windows 11. Output 3440x1440 (ultrawide on),
resolution=3, DLSS on, frame generation off, HDR off,quality_preset=0.One 66-minute session (389
vk: memory/vk: VRAMreports):So it is not an endless leak: everything plateaus, and textures stay at the 6144 MB budget. But private memory settles about 20 GB above start-up, which is more than the 32 GB of RAM, so Windows pages most of the process out (working set down to 1.7 GB while 39 GB are committed). In play that feels like a leak: hitching that a restart clears.
Other numbers from the same log: up to 480 MB of write-back shadows, and "live" NVN recording copies peaking at 31,031 (66,864 in a shorter session).
Caveat: this session had ReShade 6.8.0 (Vulkan layer) and one add-on loaded; the add-on reports about 1.4 GB of VRAM of its own. I can repeat the run without them and attach
hookshot_log.txtif that helps.Question: is ~20 GB of private memory above start-up expected at these settings (CPU-side copies of the 6 GB of textures plus the reserved guest heap), or should it stay closer to the texture budget?
PC Specs: RX 7600 8GB, 32GB DDR5
Issue: : 20GB RAM (Total RAM in my pc: 32gb DDR5)
When it happens: Areas with lots of detail, mainly in areas recent discoveries
hookshot_log.txt
Another data point for this one, Windows on a 12 GB card. RX_VK_COMPACT=1 fixed it for me on v2.1.0.
Setup: v2.1.0, RTX 4070 12 GB, Ryzen 7 9800X3D, 32 GB RAM, Windows 11. Output 2560x1440, game's own upscaler, frame gen off, 120 fps cap, fullscreen, Reflex on + boost.
What happened: in Castle Town fps kept fading the longer I stayed, down to 5-15. Leaving town brought it right back to 100+.
From the log while it was bad:
So it was over the driver's allowance with 3.5 GB sitting free inside the blocks.
PresentMon, per minute in Castle Town (before):
After adding
RX_VK_COMPACT=1to hookshot_env.txt and restarting, same area, 4 min:GPU time stays flat now instead of climbing. Overall 83.9 fps avg, 1.2% of frames over 2x the median. Wallpaper Engine was also running on the same GPU during the bad run, which ate some of the allowance, but the free-in-blocks number was the big part.
Might be worth making compaction the default on Windows too, or at least mentioning it in the readme for people hitting Castle Town drops.
(Tracked down and benchmarked with Claude Code: it read the log, ran the PresentMon captures and found the compaction switch.)
I did what I asked, VRAM decreased but the use of RAM memory is jumping from 17gb to 20gb RAM much more easily after leaving the forest at the beginning of the game
A 24 GB AMD data point on stock v2.1.0, with the same-view method as my earlier comment. Compaction was off, the v2.1.0 default. In one 10-minute session the fps did not fade.
Setup: RX 7900 XTX 24 GB, RADV (Mesa 26.2.6), Ryzen 7 5800X3D, 32 GB, Ubuntu 24.04. v2.1.0 (source e561602e), output 2560x1440, render 100%, game's own upscaler, frame generation off, no
RX_VK_variables, udmabuf on.Route: Kokiri Forest stream view (standing, then a camera spin), then about 10 minutes through Hyrule Field and Castle Town at night, then back to the same view.
vk: memoryline: private 2.2 GB at the fresh stand, 2.8 GB at the return. No runaway growth on Linux in this session.More reports of this, collected here:
Follow-up to my report in #1072 (closed into this one): v2.1.0 still grows on NVIDIA in a long fullscreen session, and it gets choppy at the end the same way.
Setup: v2.1.0 (source e561602e) native Linux AppImage build. Arch (Omarchy, Hyprland). RTX 5080 16 GB, NVIDIA 615.78.08, kernel 7.2.15, 32 GB RAM. Fullscreen on a 4K TV (swapchain 3840x2160, mailbox), output resolution 3840x2160, no
RX_VK_variables.Session: 1 h 40 min of normal play.
On v2.0.11 I saw 18-18.7 GB and swapping after 34-74 min, so this looks like the same growth, just a longer session.
The log's own counters stay flat or grow much less than RAM, so most of the growth is somewhere they don't report:
vk: malloc: 8.6 GB -> 9.9 GB in arenas (7.3 -> 8.1 GB in use) over the whole session@mooki000's 44-minute RTX 4090 run on the same driver showed no growth, but that was headless. This run was fullscreen, so the growth may be in the swapchain or the scaling to the screen, which a headless run skips.
I can attach the full game.log (25 MB) if that helps.
hookshot_log.txt
AMD Radeon RX 5600 XT, 6013 MB VRAM.
Happens with new areas.
I also get this same problem. RTX 5070, i5 14600k, 32 GB ddr4 3600
Specs in picture
Os: Linux mint
build: Hookshot-v2.1.0-rc.3-250-g46780503-x86_64.AppImage
Ram leaks have been getting worse for me every new update, i cant even join the game anymore, in comparison to older builds
Logs:
hookshot_log.1.txt
hookshot_log.txt
A 2-hour data point on an 8 GB card, on current
main, where it held up.Setup: Windows 11, RTX 3070 8 GB, i7-14700KF, 32 GB RAM.
mainat0ec31ff6, built from source. Output 2048x1152, presented at 2560x1440, mailbox. Variables:RX_VK_IMAGE_BLOCK_MB=32,RX_VK_WB_MAX_KB=1024,RX_VK_IMAGE_PREALLOC=0(because of #2690). Save: a copy of a Kokiri Forest save.Session: 120 min. A script teleports every 4 min through Hyrule Field, Kakariko, the Market, the castle, the Lost Woods, Sacred Forest Meadow, Lake Hylia and the graveyard (29 teleports done). Between teleports it taps A/B to get through dialogs. It is not real play: little combat, no dungeons.
So on this card and build, two hours of moving between zones did not reproduce the fade. Free space inside the blocks rising while the budget falls looks like the slow part of it. A longer run, or a run with more dungeons, might go further. I can share the CSV or the log if it helps.
A 6 GB card at the driver's allowance in plain play: RX 5600 XT, Windows 11, main
de866017.4480 MB used of 4480 MB allowed. The texture budget falls to 300-390 MB while the textures hold ~1,100 MB. The 6 GB card reports 5,872 MB, and Windows lets the game have ~4.4 GB of it.pool 0x7fd3000000 (160 MB) stays in system memory: the mirrors have 688 MB of 734.RX_VK_PRECOMPILE=0it is 20.0-20.9 GB. During the first start's noted pipelines it peaked at 29.4-30.6 GB, twice, with 0.3-0.4 GB of RAM left free.VRAM short: given back), so render targets are made and destroyed all the time:10 reused from the pool, 1418 made new, 1249 destroyedwithin a few minutes of the two places (see #2180 / #2484).A longer Linux result alongside the reports here: 11 repeated-area laps, about 2 h 26 min in one process, on RTX 4090/NVIDIA 615.78.08, main
09aac439plus #2292's read-only state stream, headless at 2048×1152 with DLAA, a 60 cap and frame generation off. It used debug area transitions and fixed entry views, not a walking playthrough. The tour did not reproduce sustained revisit slowdown, and the 77 inspected standing captures showed no persistent texture corruption. Other work shared the machine, so this is not a performance comparison or coverage of the fullscreen path @zeeboguy reported.The rising target-image count is now accounted for: all 77 samples satisfy images made minus images destroyed equals live allocations. At the first forest entry, live allocations rose 128→410 across the tour; finalized textures deliberately retained rose 33→343, mostly terrain tiles, while the other-image remainder fell 95→67. This is retained content, not orphaned target images: 7b774bae introduced that retention before v2.1.0 to prevent texture corruption when the game samples the tiles again. It explains this counter, not every memory-growth report, and is not a reason to discard the protected textures.
Separately, #2615's two v2.1.0 logs show memory pressure at 3840×2160, 3× interpolation and an 11,000 MB texture budget:
hookshot_log.txthookshot_log.1.txtThose are the logger's MB units; they support a pressure lead, not proof of a leak or of the cause of a particular revisit. My 24 GB card never exceeded its allowance in this tour, so the negative result does not settle those pressured sessions or the newer reports here.
Additional v2.1.0 data from a real 6 GB laptop GPU (for #993 and the related CPU-bound/stutter tracker #995):
source 633eb435; Windows 11 Home build 26200; Core i5-13420H, 32 GB RAM; NVIDIA RTX 4050 Laptop 6 GB. The Vulkan driver value in this session's log is0x9a170000(NVIDIA 616.92). The driver has since been updated to 621.14, but these numbers are from 616.92.hookshot_log.3.txt, 122 of 729 VRAM status samples are above the driver's allowance. The largest excess I found is 5,976 MB used / 4,920 MB allowed (+1,056 MB); that same line has 3,115 MB of textures / 2,249 MB texture budget. There are 6,841textures retiredlog entries. Another late sample is 5,111 / 4,825 MB with 2,290 / 2,318 MB of textures; the renderer saysat the driver's limit, room in the blocks: not squeezed.hookshot_log.1.txt) has samples around 16–23 FPS with ~1,500–2,500 draws/frame. In its slower samples, replay submit is 29–37 ms/frame, including 17–26 ms inmemory sync; reported GPU time is about 36–40 ms/frame. This suggests both replay/memory-sync and GPU work matter here. The logs alone do not establish that VRAM pressure caused the 20 FPS.This is a baseline for the 6 GB changes in #2557, #2759, and #2794. I have not run those PRs yet: my installed v2.1.0 game uses renderer API v14 while current
mainuses v19, and the PC currently lacks the ~60 GB free needed to rebuild the game for a valid comparison. No game files or derived assets are attached.Rtx 5080 laptop having the leaking I have DDR5 64gbs and as I play and load into new areas doesnt dump the leaks leading up to 45gbs of ram being used needing to restart every 2-3mins due to leaking degrading graphics and FPS
Tracker upkeep note (merged pull requests and code checked against main
51da0464; no new test run was made for it).This tracker can mark several specific mechanisms as fixed in main: #1505 retries failed BC3 uploads, #1514 provides a smaller staging allocation when the usual arena cannot be pinned, #2198 prevents compaction from evicting recently used textures, and #2545 writes GPU-drawn terrain tiles back before the game copies their memory. The last change is present in
gpu/vk/vk_texture.cpp's drawn-writeback path on51da0464; it does not establish that every long-session slowdown is fixed. BC texture accounting still has the separate #2624 follow-up, and the remaining reports need session-specific memory and termination evidence. Please keep this aggregate open; this is source/history confirmation, not a new game run.Data point (8 GB):
RX_VK_COMPACT=1on the v2.1.0 release cuts VRAM pressure a lot (RTX 5050 Laptop 8 GB, Pop!_OS, driver 595.104.02, 2048x1152, DLSS off,hookshot_env.txtwithRX_VK_COMPACT=1)status:lines with VRAM past 95% of the allowanceThe VRAM and stutter numbers repeated in all three sessions with the switch. The fps is not a controlled A/B: the "without" run was one ~100 min session of mixed content, and the three "with" sessions covered different areas (the latest, 55.7 fps, went through Hyrule Field). So I would not claim a throughput change either way, only less VRAM pressure and fewer slow windows.
This is a real 8 GB card in normal play, not an emulated allowance, so it may help with the 8 GB side of this issue. Compaction is opt-in on v2.1.0 and already on by default on main, so this supports keeping it on.
Rows for the page are in #2889. Full logs for both runs available on request.