VRAM use higher on v2.0.13 than v2.0.11 on an 8 GB card: dedicated memory full, 3+ GB spilled to shared system memory #1710
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
1 participant
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot#1710
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?
Reported on Discord (8 GB card, Windows; v2.0.13).
What changed: on v2.0.11 the game used about 5.9 of 8 GB. On v2.0.13 it fills the card and spills into shared system memory. The player's Task Manager screenshot (GPU page, during play) shows:
Memory spilled to shared system RAM is read over PCIe, which is the kind of overcommit that makes the frame rate drop and stay low on 8 GB cards (see #993 and #1400).
Why it's unexpected: v2.0.12 lowered the texture budget on cards with 8 GB or less to 45% of what the driver allows (#1485), so texture memory should be lower than on v2.0.11, not higher. Other pools changed since v2.0.11 too (render-target image pool #1416/#1436, upload budget, descriptor/mirror pools), so something other than textures may be growing.
What would help: a hookshot_log.txt from v2.0.13 after a few minutes in the same place, with its
vk: VRAM: ... used of ... allowed,textures ... (budget ...)andmemory heapslines, the GPU model and driver, and if possible the same lines from v2.0.11.Related: #993 (VRAM over budget on 4-8 GB cards), #1072 (memory growth), #1400.
Update from the reporter: VRAM keeps growing the longer they play and spills into shared memory, and v2.0.11 did that too. So this looks like a leak over play time rather than only a higher starting level on v2.0.13. A log from a long session (its
vk: VRAM: ... used of ... allowed,textures ... (budget ...)andmemory heapslines, early and late) would show what grows. Related: #1072.Possibly related: floor and ground textures that go wrong after playing for a while and come back after reloading the save are now reported by two players on v2.0.14 (an RX 9070 XT, and Dodongo's Cavern 2F; see #1006 and #1717). If VRAM keeps growing until textures are evicted or fail, that would fit this issue's leak.
+1 as well as the ground textures going wrong after a longer play session and vram limit being reached. are there any options that help alleviate the issue a bit in the settings?
I am on rtx 5060 8 gb.
2.0.14
.14
I ran some tests following a specific route using various presets: Forest Temple > Kokori Forest > Hyrule Field > Kakariko Village > Teleport back to the Forest Temple, I repeat the route once more.
The issue I’ve described in some detail below causes frame drops and a 30%–40% reduction in frame-per-second (FPS) performance after a short period of gameplay.
One thing to note is that, whether using the minimum or the balanced preset, the system's power consumption appears to be the same.
(1) "minimum" (4GB) preset, the game starts after the loading screen using about 5GB of the 8GB of dedicated VRAM and 2GB of the 8GB of shared memory. By the end of the route, dedicated VRAM usage reaches around 7.2GB (out of 8GB), while shared memory jumps from 2GB to 4.5GB—occasionally hitting 5GB at certain points.
(2) "balanced" (8GB) preset (without Frame Generation), the figures are surprisingly similar—nearly identical, in fact. After loading, it starts with 5GB of the 8GB of dedicated video memory and 2GB of the 8GB of shared memory; by the end of the test, following the teleport back to the Forest Temple, it finishes with 7.2GB of the 8GB of dedicated video memory and 4.2GB of shared video memory (slightly less than with the "minimum" preset).
(3) with the "balanced" (8GB) preset (without Frame Generation) and the "Handheld" profile enabled, the results match the previous test, showing almost no difference compared to "Docked" mode at a higher resolution.
(4) When using the "balanced" preset with DLAA enabled, the results are the same as the "balanced" (8GB) preset without it, the only difference being a slightly lower frame rate.
1.PRESET MINIMUM (4GB) NO FG
FULLSCREEN: OFF
FRAME PACING: ON
FRAME CAP: 60
NVIDIA RÉFLEX: OFF
OUTPUT RESOLUTION: 1920x1080p
UPSCALER: GAME'S OWN
RENDER RESOLUTION: 50%
WINDOW SCALING FILTER: LANCZOS
HANDHELD PROFILE: ON
REBURST BUFFS: AUTO
Start of route >
Video memory: 5gb (8b)
shared memory: 2gb (8gb)
End of route >
Video memory: 7.3gb (8gb)
shared memory: 4.3gb (8gb)
2.PRESET BALANCED (8GB) NO FG
FULLSCREEN: OFF
FRAME PACING: ON
FRAME CAP: 60
NVIDIA RÉFLEX: OFF
OUTPUT RESOLUTION: 1920x1080p
UPSCALER: GAME'S OWN
RENDER RESOLUTION: 50%
WINDOW SCALING FILTER: LANCZOS
HANDHELD PROFILE: OFF
REBURST BUFFS: AUTO
Start of route >
Video memory: 5gb (8b)
shared memory: 2gb (8gb)
End of route >
Video memory: 7.4gb (8gb)
shared memory: 4.1gb (8gb)
3.PRESET BALANCED (8GB) NO FG
FULLSCREEN: OFF
FRAME PACING: ON
FRAME CAP: 60
NVIDIA RÉFLEX: OFF
OUTPUT RESOLUTION: 1920x1080p
UPSCALER: GAME'S OWN
RENDER RESOLUTION: 100%
WINDOW SCALING FILTER: LANCZOS
HANDHELD PROFILE: OFF
REBURST BUFFS: AUTO
Start of route >
Video memory: 5gb (8b)
shared memory: 2gb (8gb)
End of route >
Video memory: 7.5gb (8gb)
shared memory: 4.3gb (8gb)
4.PRESET BALANCED (8GB) NO FG
FULLSCREEN: OFF
FRAME PACING: ON
FRAME CAP: 60
NVIDIA RÉFLEX: OFF
OUTPUT RESOLUTION: 1920x1080p
UPSCALER: DLAA
RENDER RESOLUTION: NATIVE DLAA
WINDOW SCALING FILTER: LANCZOS
HANDHELD PROFILE: OFF
REBURST BUFFS: AUTO
Start of route >
Video memory: 5gb (8b)
shared memory: 2gb (8gb)
End of route >
Video memory: 7.3gb (8gb)
shared memory: 4.4gb (8gb)
Configuration: CPU RYZEN 7 5700G + RTX 3060TI + 16GB RAM 3200MHZ + SSD NVME 4.0 - WINDOWS 11 PRO 26H2 - NVIDIA GPU DRIVER 621.14
hookshot_log - MINIMUM (4GB) NO FG.txt
hookshot_log - BALANCED (8GB) NO FG + HANDLED PROFILE ON.txt
hookshot_log - BALANCED (8GB) NO FG.txt
hookshot_log - DLAA 1080p NO FG.txt
v2.0.14 log attached (from #1925). RTX 5060 Laptop 8 GB, driver allows 7131 MB, driver 621.14.
Output 1920x1080, Render resolution Auto, Frame generation Off, preset Custom, no hookshot_env.txt.
v2.0.13: 3 times over, peak 8059 MB with 2359 MB free in the blocks (render target blocks 1024 MB for 379 MB).
An earlier v2.0.13 session (Frame generation 3x, Render resolution 100%) ended in VK_ERROR_DEVICE_LOST
entering Sacred Forest Meadow.
hookshot_log_v2.0.14.txt
Adding a Windows data point on v2.0.14. In my case the growth over a long session ended in a crash: Windows ran out of commit (RAM + page file), and then
ParallelDecompThreadwrote to memory it had failed to commit. Related to #1072 as well.System
What happened
The Windows Error Reporting entry matches it: APPCRASH in hookshot.exe, exception c0000005, offset 0x394d4c8.
A side note: after a commit fails, the decompression thread seems to write into the range anyway instead of handling the failure.
The log lines you asked for, early and late in the session
Early (first minute):
Late (seconds before the crash):
A counter that only grows
vk: releases kept for stopped workrose steadily over the whole session and never went down: 6001 → 50001 → 100001 → 148001 → 194001 → 238001 → 286001, the last value just before the crash. I don't know whether that counter matters here, but it is the one thing in the log that climbs without ever falling back.Retired pools are being given back ("0 retired still imported"), so this doesn't look like the #1057 retired-pool case.
I can attach the full log (47 MB) or test an env var or build if that would help.
A reproduction with numbers, on a 16 GB card: the mirrored game memory ("imports") grows with every new area and is never given back. On a scripted tour that revisits Castle Town's market, the market goes from 53 fps on the first visit to 30 fps (lows of 15) after Lake Hylia, once VRAM passes the driver's allowance. Places that don't need the extra memory are unaffected: the open field and Kokiri hold 59-60 fps on the same build.
Over one tour the imports went from 43 pools (1.6 GB) to 109 (4.0 GB), with
0 retired still importedthe whole time. So this isn't the retired-pool case #1906 handles. I'm checking whether the renderer drops a pool's import when the game finalizes it, and will follow up.Per-visit numbers
Teleport tour (Debug tab teleports), 20 s camera spin at each stop: Market → Kakariko → Market → Lake Hylia → Market → Hyrule Field (Lost Woods bridge tunnel) → Market. Values from the log's
VRAM:,memory heaps:andimports:lines at the end of each market visit.The Hyrule Field stop in between went back to a flat 60 fps once the market's memory was out of use. So it's memory pressure, not the area itself.
The same tour without Lake Hylia (Market → Kakariko → Market → Kakariko → Market → field → Market) grew more slowly (39 → 101 pools, 1.6 → 3.9 GB). It stayed just under the allowance, and the market only went 52.8 → 48-49 fps.
What fills VRAM
RX_VK_COMPACT=1loses the device at its first compaction pass in this scene here, with or without other switches.The textures and render targets do go back down between areas (4-6 GB, cycling). The imports are the part that only goes up.
Setup
RX_VK_PARALLEL=3; it changes nothing here, the baseline holds 60 fps with it.0ffc004plus #1944 (DLSS Frame Gen row off) and uncommitted local changes, all switched off.Correction to the above: the imports are in the system-memory heap, not VRAM (
vram_usagecounts only device-local heaps), and only ~100-180 MB of them belong to pools the game has finalized. Their growth isn't what pushes VRAM over. What tracks the collapse is the texture cache going over its budget at the market (7.1-7.2 GB of 6144 MB) while 2.6-2.8 GB sits free inside VMA's blocks. The log saysat the driver's limit, room in the blocks: not squeezedat those peaks, so the driver's count reaches its allowance and pages while the renderer sees room. The per-visit numbers above still stand.Correction: the
RX_VK_COMPACT=1device loss mentioned above was caused by a local change in my build (a cached-view shortcut that didn't know about moved textures), not by #1821. With that fixed, compaction runs cleanly here.8 GB card (RTX 3060 Ti): the upscaler's own render targets are a large part of the overcommit
Adding data to this issue rather than opening a new one, since a
vk: VRAM:reportfrom an 8 GB card was asked for.
v2.1.0, Windows 11 build 22621, NVIDIA 32.0.16.2101. Output resolution 2560x1440,
borderless. Same route for all three runs (Castle Town, Hyrule Field, the Castle
fountain).
Finding: on this card the game's own upscaler accounts for a large share of the
video-memory overcommit, and turning it off does more for VRAM and for frame time
than any render-resolution change.
Setting VRAM over-allowance GPU ms/frame textures made/frame
1440p, render 100%, Upscaler game's own 7.2 - 8.4 of 7.0 GB 20 17 - 33 14 - 17
1440p, render 75%, Upscaler game's own 7.0 - 7.6 of 7.0 GB 7 3.4 - 4.8 28 - 35
1440p, render 75%, Upscaler Off 5.9 - 6.8 of 7.0 GB 0 2.8 - 11.4 7 - 9.8
With the upscaler off (plain linear stretch) the game stops overshooting the
allowance entirely, texture churn drops about 70%, and the worst frame in the
vk: status:lines went from 149 ms to 25-69 ms. Image also stops lookingoversharpened, since the reconstruction network is what sharpens at 75%.
Caveat for anyone reading: Upscaler Off also removes the temporal AA that comes
with that network, so this is a mitigation for memory-constrained cards rather
than a recommendation for everyone.
Relevant log lines at the first two settings:
vk: VRAM: 7606 MB used of 7129 MB allowed (1903 MB of it free in the blocks);
textures 2607 MB (budget 3...
vk: over the driver's video-memory allowance (7.0 of 7.0 GB)
vk: VRAM: 7068 MB used of 7115 MB allowed; textures 3557 MB (budget 3286 MB)
In the second one the textures ask for 3557 MB against a 3286 MB budget, so the
game evicts and remakes 28-35 textures every frame. That is where the stutter is.
It is not shader compilation:
waits for shaders or pipelinesstays at0.0 - 1.0 ms for the whole run.
Two questions if useful:
Is the upscaler's render-target allocation counted inside the same texture
budget, or outside it? The numbers above suggest one shared pool, so enabling
the upscaler effectively shrinks the texture budget available to the scene.
memory_budget=3(the Balanced 8GB caps) lowered the overshoot but raisedchurn, because the derived texture budget landed below demand. Is there a
value intended to leave headroom for the upscaler on an 8 GB card?
Happy to attach the full hookshot_log.txt for any of the three runs, or to run
a specific setting and route and post that log instead.
Same problem on a 6 GB laptop card, v2.1.0.
Setup: RTX 4050 Laptop (5152 MB allowed), Core 5 210H, 16 GB RAM (single-channel), Windows 11, 1080p, DLSS, Low (6GB) preset, frame generation off.
What happens:
What I tried:
RX_VK_SQUEEZE_ALWAYS=1: the budget dropped, but textures stayed (in use), and fps got worse.RX_VK_COMPACT=1alone: VRAM stayed under the limit, but the mirrors dropped to 512 MB and fps fell to 19-23.Best workaround so far (in
hookshot_env.txt):This gives 33-46 fps, memory-sync slow frames went from 45 to 7, and camera turning is much smoother. VRAM is still slightly over (5.1-5.5 GB). More details on the compaction tests in #1821. Log attached.
hookshot_log_async_flicker.txt
hookshot_log_compact_mirror1300.txt
One more detail from the same log: the textures used in the last 8 presents total only about 145 MB, while the cache holds about 1.5 GB. The largest ones (47 MB each, 3072x3072 ASTC) were last used 100+ presents ago and still not evicted ("room in the blocks: not squeezed"). Evicting textures unused for a few seconds would leave room for the mirrors, so no pools would have to stay in system memory.
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.