MagicBeanDev/Longshot

Watch

Fork 104

Game: on a 6 GB card VRAM goes over the driver's allowance after a few area changes, Hyrule Field falls from 31 to 14 fps until a restart (GTX 1060, nightly-189) #939

New issue

Open

opened 2026-11-15 22:08:39 +00:00 by fireblast327 · 2 comments

fireblast327 commented

2026-11-15 22:08:39 +00:00

Longshot version

nightly-189-aa95d35f (source 719431ac); the same on nightly-171-b80a68f1 in a 75-minute play session

Channel

Nightly

What kind of problem

Low fps or stutter

What happened

On a 6 GB card the game's VRAM goes past what the driver allows within a few area changes. From then on Windows keeps
part of it in system memory (the game's "shared" GPU memory grows to 3-4 GB), and the frame rate falls. It does not come
back until the game is restarted.

Measured on nightly-189, a fresh start of the same save, one scripted tour through the control bridge. Hyrule Field at
noon (debug Set time) was measured at the start and again at the end, the same teleport spot, uncapped, 15 one-second
samples. In between came Forest Temple, Kokiri Forest, Lost Woods, Zora's River, Zora's Domain, Hyrule Field, Market,
Kakariko and Death Mountain Trail, 2.5 minutes each with the camera turning. About 31 minutes in all.

	Hyrule Field, fresh	Hyrule Field, after the tour
fps (median)	31.2	13.8
`vk: VRAM:` used / allowed	5138 / 5201 MB	6128 / 5231 MB
... of it free in the blocks	1076 MB	1255 MB
textures / their budget	1431 / 818 MB	1606 / 200 MB
render-target images	111 (373 MB, 6 blocks)	232 (445 MB, 7 blocks, 89 free ranges)
GPU shared memory of the process (Windows counter)	-	3262 MB
private memory	22.8 GB	24.7 GB

Along the tour (after each area; VRAM used / allowed, textures / budget, the process's shared GPU memory):

after	VRAM used / allowed	textures / budget	shared GPU memory
Forest Temple	4715 / 5201 MB	1094 / 689 MB	1990 MB
Kokiri Forest	5989 / 5231 MB	1885 / 473 MB	2826 MB
Lost Woods	5531 / 5231 MB	1616 / 701 MB	2466 MB
Zora's River	5586 / 5231 MB	1995 / 707 MB	2582 MB
Zora's Domain	5736 / 5231 MB	1777 / 673 MB	2506 MB
Hyrule Field	6069 / 5231 MB	1973 / 136 MB	3186 MB
Market	5706 / 5231 MB	1660 / 230 MB	2852 MB
Kakariko	6210 / 5231 MB	2584 / 584 MB	3339 MB
Death Mountain Trail	6346 / 5231 MB	2945 / 969 MB	3704 MB

It is the GPU side: vk: GPU time in the Field goes from 26.3 ms a frame fresh to 55.8 ms after the tour (the longest
submission 8.3 to 22.0 ms), and the readbacks that wait for their write-back from 0.74 to 26.47 ms each.
The render-target pool holds nothing the whole time ("it holds 0 (0 MB), VRAM short: given back"), so targets are made
and destroyed every frame: 527 made new at the first Field measurement, 72,228 made new and 71,996 destroyed by the
last one (about 2,300 a minute).
Imports and system memory grow too: imports: 93 live (1584 MB) to 97 live (1980 MB), 21 to 154 retired (992 to
5116 MB given back); heap 1 (system) used 1948 to 2702 MB.
The texture budget is the allowance minus everything else, so it falls to 136-200 MB, but the textures stay at
1.6-2.9 GB. Most of them were used in the last frames (the 171 session's log: "used in the last 8 presents 1668 MB" of
2358 MB), so the eviction has little it may let go of.
Up to 1.2-1.4 GB of the used VRAM is free space inside blocks (free in the blocks). The compaction is on (the default).
Render-target images double over the tour (111 to 232; 80-90 to 368 in the 171 session).
Below 60 fps the eviction's waits, counted in presents, get longer. That is #771's case, which asks for measurements from
a card under 60 fps near its VRAM limit: this is one.

The 171 session (normal play, 75 minutes: Forest Temple for an hour, then 8 outdoor areas) ended at 6-10 fps in
Hyrule Field, with VRAM at 6.3-6.6 GB of 5.2 allowed, textures 2.3 GB against a 42 MB budget, and 368 render-target
images. Closing and starting the game again gives ~31 fps there.

The same tour with other settings (Hyrule Field at noon, fresh / after the tour; one start each):

	fps	VRAM used / allowed at the end	shared GPU memory at the end	private memory at the end
Defaults	31.2 / 13.8	6128/5231 MB	3262 MB	24.7 GB
`RX_VK_LOAD=create`	30.5 / 15.6	5751/5231 MB	3005 MB	21.0 GB
`RX_VK_LOAD=create` + Render resolution 50%	41.1 / 34.2	5440/5204 MB	2649 MB	20.3 GB
`RX_VK_MIRROR_MB=1024`	24.4 / 10.9	5052/5175 MB	2990 MB	24.6 GB

With RX_VK_MIRROR_MB=1024 the VRAM stays inside the allowance after the tour, but the textures are squeezed to 353 MB
(budget 276 MB, 217 textures) and it is slower from the start, so a smaller mirror only moves the problem.
At Render resolution 50% the same tour still ends over the allowance (5440 of 5204 MB) and the render-target churn is
the same (92,962 made new), but the Field only drops from 41.1 to 34.2 fps (GPU time 17.6 to 22.3 ms a frame). So on
this card the drop scales with how much the frame needs from VRAM; 50% is the workaround used here for now.

Where in the game

Anywhere outdoors after a few area changes. Measured in Hyrule Field (adult).

How often

Every time

Graphics card and driver version

NVIDIA GeForce GTX 1060 6GB, NVIDIA 582.28 (Vulkan; no mesh shaders, the compute fallback)

CPU, RAM and operating system

Intel Core i7-8700 (12 threads), 32 GB, Windows 11 Pro (build 26300)

Changes from the defaults

Docked, windowed, Output 2560x1440, Render resolution 75% with the game's own upscaler, Anisotropic filtering 16x,
Frame generation off, Threaded rendering Auto, frame rate cap Uncapped for the measurements (60 in play). No
longshot_env.txt.

longshot_log.txt

The status lines of the tour (nightly-189), at the start and the end:

[hos host] vk: memory: working set 17381 MB (peak 17710), private 22812 MB, staging 64 MB in 1 arenas
[hos host] vk: image blocks: 1 blocks 128 MB, 4 images 23 MB; 2 free ranges, the largest 97 MB
[hos host] vk: image blocks (render targets): 6 blocks 768 MB, 111 images 373 MB; 31 free ranges, the largest 95 MB
[hos host] vk: image blocks (textures, compacted): 7 blocks 896 MB, 633 images 532 MB; 195 free ranges, the largest 128 MB
[hos host] vk: VRAM: 5138 MB used of 5201 MB allowed (1076 MB of it free in the blocks); textures 1431 MB (budget 818 MB), 746 textures (at the driver's limit, room in the blocks: not squeezed)
...
[hos host] vk: memory: working set 18440 MB (peak 18937), private 24766 MB, staging 64 MB in 1 arenas
[hos host] vk: image blocks (render targets): 7 blocks 896 MB, 232 images 445 MB; 89 free ranges, the largest 63 MB
[hos host] vk: image blocks (textures, compacted): 8 blocks 1024 MB, 432 images 486 MB; 185 free ranges, the largest 67 MB
[hos host] vk: VRAM: 6128 MB used of 5231 MB allowed (1255 MB of it free in the blocks); textures 1606 MB (budget 200 MB), 933 textures

Screenshots or video

None.

Before you send it

The problem is still there on the newest release or nightly.
I searched the open issues for it.
I'm not attaching game files, keys or saves.

Related: #771 (eviction waits by time), #637 (under-8 GB VRAM management, the same 5,233 MB allowance), #813 (RTX 4050 6 GB on
nightly-189), #388 (memory growth by area), #805 (programs loaded before the title on the compute fallback).

Measured by an AI agent (Claude Code) on the reporter's PC.

### Longshot version nightly-189-aa95d35f (source 719431ac); the same on nightly-171-b80a68f1 in a 75-minute play session ### Channel Nightly ### What kind of problem Low fps or stutter ### What happened On a 6 GB card the game's VRAM goes past what the driver allows within a few area changes. From then on Windows keeps part of it in system memory (the game's "shared" GPU memory grows to 3-4 GB), and the frame rate falls. It does not come back until the game is restarted. **Measured on nightly-189**, a fresh start of the same save, one scripted tour through the control bridge. Hyrule Field at noon (debug Set time) was measured at the start and again at the end, the same teleport spot, uncapped, 15 one-second samples. In between came Forest Temple, Kokiri Forest, Lost Woods, Zora's River, Zora's Domain, Hyrule Field, Market, Kakariko and Death Mountain Trail, 2.5 minutes each with the camera turning. About 31 minutes in all. | | Hyrule Field, fresh | Hyrule Field, after the tour | |---|---:|---:| | fps (median) | **31.2** | **13.8** | | `vk: VRAM:` used / allowed | 5138 / 5201 MB | 6128 / 5231 MB | | ... of it free in the blocks | 1076 MB | 1255 MB | | textures / their budget | 1431 / 818 MB | 1606 / 200 MB | | render-target images | 111 (373 MB, 6 blocks) | 232 (445 MB, 7 blocks, 89 free ranges) | | GPU shared memory of the process (Windows counter) | - | 3262 MB | | private memory | 22.8 GB | 24.7 GB | Along the tour (after each area; VRAM used / allowed, textures / budget, the process's shared GPU memory): | after | VRAM used / allowed | textures / budget | shared GPU memory | |---|---:|---:|---:| | Forest Temple | 4715 / 5201 MB | 1094 / 689 MB | 1990 MB | | Kokiri Forest | 5989 / 5231 MB | 1885 / 473 MB | 2826 MB | | Lost Woods | 5531 / 5231 MB | 1616 / 701 MB | 2466 MB | | Zora's River | 5586 / 5231 MB | 1995 / 707 MB | 2582 MB | | Zora's Domain | 5736 / 5231 MB | 1777 / 673 MB | 2506 MB | | Hyrule Field | 6069 / 5231 MB | 1973 / 136 MB | 3186 MB | | Market | 5706 / 5231 MB | 1660 / 230 MB | 2852 MB | | Kakariko | 6210 / 5231 MB | 2584 / 584 MB | 3339 MB | | Death Mountain Trail | 6346 / 5231 MB | 2945 / 969 MB | 3704 MB | - It is the GPU side: `vk: GPU time` in the Field goes from 26.3 ms a frame fresh to 55.8 ms after the tour (the longest submission 8.3 to 22.0 ms), and the readbacks that wait for their write-back from 0.74 to 26.47 ms each. - The render-target pool holds nothing the whole time ("it holds 0 (0 MB), VRAM short: given back"), so targets are made and destroyed every frame: 527 made new at the first Field measurement, 72,228 made new and 71,996 destroyed by the last one (about 2,300 a minute). - Imports and system memory grow too: `imports:` 93 live (1584 MB) to 97 live (1980 MB), 21 to 154 retired (992 to 5116 MB given back); heap 1 (system) used 1948 to 2702 MB. - The texture budget is the allowance minus everything else, so it falls to 136-200 MB, but the textures stay at 1.6-2.9 GB. Most of them were used in the last frames (the 171 session's log: "used in the last 8 presents 1668 MB" of 2358 MB), so the eviction has little it may let go of. - Up to 1.2-1.4 GB of the used VRAM is free space inside blocks (`free in the blocks`). The compaction is on (the default). - Render-target images double over the tour (111 to 232; 80-90 to 368 in the 171 session). - Below 60 fps the eviction's waits, counted in presents, get longer. That is #771's case, which asks for measurements from a card under 60 fps near its VRAM limit: this is one. The 171 session (normal play, 75 minutes: Forest Temple for an hour, then 8 outdoor areas) ended at 6-10 fps in Hyrule Field, with VRAM at 6.3-6.6 GB of 5.2 allowed, textures 2.3 GB against a 42 MB budget, and 368 render-target images. Closing and starting the game again gives ~31 fps there. **The same tour with other settings** (Hyrule Field at noon, fresh / after the tour; one start each): | | fps | VRAM used / allowed at the end | shared GPU memory at the end | private memory at the end | |---|---:|---:|---:|---:| | Defaults | 31.2 / 13.8 | 6128/5231 MB | 3262 MB | 24.7 GB | | `RX_VK_LOAD=create` | 30.5 / 15.6 | 5751/5231 MB | 3005 MB | 21.0 GB | | `RX_VK_LOAD=create` + Render resolution 50% | 41.1 / 34.2 | 5440/5204 MB | 2649 MB | 20.3 GB | | `RX_VK_MIRROR_MB=1024` | 24.4 / 10.9 | 5052/5175 MB | 2990 MB | 24.6 GB | With `RX_VK_MIRROR_MB=1024` the VRAM stays inside the allowance after the tour, but the textures are squeezed to 353 MB (budget 276 MB, 217 textures) and it is slower from the start, so a smaller mirror only moves the problem. At Render resolution 50% the same tour still ends over the allowance (5440 of 5204 MB) and the render-target churn is the same (92,962 made new), but the Field only drops from 41.1 to 34.2 fps (GPU time 17.6 to 22.3 ms a frame). So on this card the drop scales with how much the frame needs from VRAM; 50% is the workaround used here for now. ### Where in the game Anywhere outdoors after a few area changes. Measured in Hyrule Field (adult). ### How often Every time ### Graphics card and driver version NVIDIA GeForce GTX 1060 6GB, NVIDIA 582.28 (Vulkan; no mesh shaders, the compute fallback) ### CPU, RAM and operating system Intel Core i7-8700 (12 threads), 32 GB, Windows 11 Pro (build 26300) ### Changes from the defaults Docked, windowed, Output 2560x1440, Render resolution 75% with the game's own upscaler, Anisotropic filtering 16x, Frame generation off, Threaded rendering Auto, frame rate cap Uncapped for the measurements (60 in play). No `longshot_env.txt`. ### longshot_log.txt The status lines of the tour (nightly-189), at the start and the end: ``` [hos host] vk: memory: working set 17381 MB (peak 17710), private 22812 MB, staging 64 MB in 1 arenas [hos host] vk: image blocks: 1 blocks 128 MB, 4 images 23 MB; 2 free ranges, the largest 97 MB [hos host] vk: image blocks (render targets): 6 blocks 768 MB, 111 images 373 MB; 31 free ranges, the largest 95 MB [hos host] vk: image blocks (textures, compacted): 7 blocks 896 MB, 633 images 532 MB; 195 free ranges, the largest 128 MB [hos host] vk: VRAM: 5138 MB used of 5201 MB allowed (1076 MB of it free in the blocks); textures 1431 MB (budget 818 MB), 746 textures (at the driver's limit, room in the blocks: not squeezed) ... [hos host] vk: memory: working set 18440 MB (peak 18937), private 24766 MB, staging 64 MB in 1 arenas [hos host] vk: image blocks (render targets): 7 blocks 896 MB, 232 images 445 MB; 89 free ranges, the largest 63 MB [hos host] vk: image blocks (textures, compacted): 8 blocks 1024 MB, 432 images 486 MB; 185 free ranges, the largest 67 MB [hos host] vk: VRAM: 6128 MB used of 5231 MB allowed (1255 MB of it free in the blocks); textures 1606 MB (budget 200 MB), 933 textures ``` ### Screenshots or video None. ### Before you send it - [x] The problem is still there on the newest release or nightly. - [x] I searched the open issues for it. - [x] I'm not attaching game files, keys or saves. Related: #771 (eviction waits by time), #637 (under-8 GB VRAM management, the same 5,233 MB allowance), #813 (RTX 4050 6 GB on nightly-189), #388 (memory growth by area), #805 (programs loaded before the title on the compute fallback). *Measured by an AI agent (Claude Code) on the reporter's PC.*

👀 1

fireblast327 referenced this issue

2026-11-15 22:08:56 +00:00

Idea: on the compute fallback, loading every program before the title costs 5 GB and puts a 24 GB PC at its commit limit; RX_VK_LOAD=create measured on a second such card (RX 5600 XT): same fps or better, loads of 50 ms at worst #805

BeanIssues added the

labels

2026-11-15 22:09:03 +00:00

BeanIssues commented

2026-11-15 22:09:03 +00:00

Collaborator

Possibly related, for context:

#89 Game: performance stays lower after changing areas until a restart or DLSS toggle — Same persistent FPS drop after changing areas, though this new report provides a more specific measured VRAM-pressure mechanism and GTX 1060 results.
#813 Game: 13-25 real FPS in Castle Town Market on Nightly 189 with RTX 4050 6 GB — Related VRAM pressure and low FPS on a 6 GB NVIDIA GPU; different symptom conditions and hardware.

Possibly related, for context: - #89 Game: performance stays lower after changing areas until a restart or DLSS toggle — Same persistent FPS drop after changing areas, though this new report provides a more specific measured VRAM-pressure mechanism and GTX 1060 results. - #813 Game: 13-25 real FPS in Castle Town Market on Nightly 189 with RTX 4050 6 GB — Related VRAM pressure and low FPS on a 6 GB NVIDIA GPU; different symptom conditions and hardware.

BeanIssues referenced this issue

2026-11-15 22:12:34 +00:00

WIP: fix(vk): let render targets go as newer ones together cover them, and pool their images at once #943

Amateurwizrd referenced this issue

2026-11-15 22:14:19 +00:00

WIP: fix(vk): let render targets go as newer ones together cover them, and pool their images at once #943

Amateurwizrd commented

2026-11-15 22:14:35 +00:00

Contributor

Two open PRs aim at parts of this, both WIP and not yet run on a 6 GB card: #943 lets old render targets go once several newer ones together cover them (the render-target images here grow 111 to 232), and #518 caps the target image pool and counts it in the texture budget. A run of either on this tour would tell whether they help.

Two open PRs aim at parts of this, both WIP and not yet run on a 6 GB card: https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/943 lets old render targets go once several newer ones together cover them (the render-target images here grow 111 to 232), and https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/518 caps the target image pool and counts it in the texture budget. A run of either on this tour would tell whether they help.

Amateurwizrd referenced this issue

2026-11-15 22:46:45 +00:00

WIP: fix(vk): let render targets go as newer ones together cover them, and pool their images at once #943