Game: GPU reset (device lost) entering Death Mountain Crater on an 8 GB RX 6600, Windows, at the driver's VRAM limit #130

New issue

Open

opened 2026-11-13 05:43:07 +00:00 by llun · 0 comments

llun commented

2026-11-13 05:43:07 +00:00

Member

Longshot version

A player's Hookshot v2.2.0-rc.1 (source 006e7dfe). Longshot main (b9cdc432 and later) has the same texture and mirror budget code, quoted below.

Update track

Release candidate

What kind of problem

Crash, freeze or black screen

What happened

About 15–20 minutes into a session (48,360 presents), the game froze for about 6 seconds right after a debug-menu teleport into Death Mountain Crater (adult). Then the GPU was reset and the game ended:

[hos BaseProcExecutor0] map: DeathMountainCrater_Adult (adult)
...
[hos BaseProcExecutor0] hid: the game read no controller for 5.9 s (lr 0x83489670)
[hos sead::MainThread] vk: submit 339379 failed (-4)
[hos sead::MainThread] vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers)
[hos sead::MainThread] vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, and nothing sent to it runs any more

The AMD Windows driver gives no fault details, so the log can't name the draw. What it does show is that the whole session ran at the driver's VRAM limit:

The allowance shrank. At the start the driver allowed 7,378 MB; for most of the session it allowed 6,060–6,400 MB, so other programs probably held 1 GB or more of the 8 GB card.
The game kept filling it, at 4,800–6,275 MB, and above 5,800 MB from Kokiri Forest on. The at the driver's limit, room in the blocks: not squeezed note appeared in Kokiri Forest and twice in the Lost Woods.
The last status before the crater: VRAM: 6125 MB used of 6317 MB allowed (1061 MB of it free in the blocks); textures 1849 MB (budget 1260 MB), with 1,024 MB of VRAM mirrors and 2.8 GB of system memory imported for the GPU.
The crater then loaded on top of that, at 42–52 fps, with a frame's uploads taking 83 ms. About 6 seconds later the GPU was reset.

That matches the driver paging past the allowance until a GPU job ran past Windows' 2-second timeout (TDR). A GPU fault in one of the crater's own shaders on AMD would look the same in this log; see "To confirm" below.

Where in the game

Death Mountain Crater (adult), arriving from Goron City's side through the debug teleport, after Market, Ganon's Castle, Kokiri Forest, the Lost Woods and Gerudo Valley in the same session.

How often

Once so far

Graphics card and driver version

AMD Radeon RX 6600 8 GB, AMD proprietary driver 26.10.1 (Vulkan driver 0x800161), Windows

CPU, RAM and operating system

14 cores / 20 threads, 32 GB RAM (5 GB swap), Windows

Changes from the defaults

Output resolution 2048x1152 (the game's own). Nothing else is visible in the log.

longshot_log.txt

Not attached: the log holds a personal folder path. The lines above are from it.

https://github.com/NotRexed/Hookshot/issues/993: tracking VRAM and RAM filling up over play time, mostly on 4–8 GB cards (open)
https://github.com/NotRexed/Hookshot/issues/2749: Windows crashes after VRAM goes over the driver's allowance (open)
https://github.com/NotRexed/Hookshot/issues/1465 and https://github.com/NotRexed/Hookshot/issues/1891: earlier device losses (TDR) on RDNA 2 under Windows (closed)
#89: lower performance after area changes (open)

Proposal: what could fix it

Make room before an area loads. The squeeze in texture_frame() (gpu/vk/vk_texture.cpp, room_in_blocks) waits while the count is within the allowance and the textures' blocks hold an eighth of it free.
- That wait is right for a paused game: it stops a ratchet that evicts textures for nothing.
- At an area change it backfires. The free space sits in the textures' own 128 MB blocks, and the next area's render targets, buffers and mirrors can't use it, so their new allocations push the count past the allowance.
- The proposal: within 3–5% of the allowance, or as a map change starts, give the textures' empty blocks back (compaction already tracks them) and evict to the textures' budget, without waiting on room_in_blocks.
- Here that is about 1 GB of empty block space, plus 590 MB of textures over their 1,260 MB budget, freed before the crater loaded.
Port https://github.com/NotRexed/Hookshot/pull/3020 (a large excess over the 90% rule or the driver's limit is cut to 7/8 again). It brings the count down faster once it is over.
Smaller VRAM mirrors on 8 GB cards near the limit. mirror_budget() (gpu/vk/vk_memory.cpp) gives 1,024 MB here.
- https://github.com/NotRexed/Hookshot/pull/2794 (sparse mirrors, memory only where a game pool is) and https://github.com/NotRexed/Hookshot/pull/2834 (a smaller budget on 6 GB cards) are open on Hookshot.
- A run with RX_VK_MIRROR_MB=512 on an 8 GB AMD card would show whether the same frame rate holds with half the mirrors.
A Texture detail setting, as https://github.com/NotRexed/Hookshot/pull/2557 proposes, for cards that stay at the limit.

Open PRs on Longshot: none targets this. #77 (merged) is about Windows' system commit limit, not VRAM, and #65 only adds memory counters (HOS_COUNTERS), which would help measure the fix.

To confirm

Teleport straight to Death Mountain Crater after a fresh start, with nothing else using the GPU. If the GPU still resets with plenty of free VRAM, it's more likely a shader problem than memory. In that case a run with RX_VK_CHECKPOINTS=1 names the work the GPU was on.

Workarounds for players now

Close other programs that use the GPU (browsers, Discord with hardware acceleration, recorders, overlays): the allowance here was 1–1.3 GB below its start.
Set the Output resolution to 1920x1080.
RX_VK_MIRROR_MB=512 in longshot_env.txt frees 512 MB of the mirrors.

### Longshot version A player's Hookshot v2.2.0-rc.1 (source 006e7dfe). Longshot main (b9cdc432 and later) has the same texture and mirror budget code, quoted below. ### Update track Release candidate ### What kind of problem Crash, freeze or black screen ### What happened About 15–20 minutes into a session (48,360 presents), the game froze for about 6 seconds right after a debug-menu teleport into Death Mountain Crater (adult). Then the GPU was reset and the game ended: ``` [hos BaseProcExecutor0] map: DeathMountainCrater_Adult (adult) ... [hos BaseProcExecutor0] hid: the game read no controller for 5.9 s (lr 0x83489670) [hos sead::MainThread] vk: submit 339379 failed (-4) [hos sead::MainThread] vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers) [hos sead::MainThread] vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, and nothing sent to it runs any more ``` The AMD Windows driver gives no fault details, so the log can't name the draw. What it does show is that the whole session ran at the driver's VRAM limit: - **The allowance shrank.** At the start the driver allowed 7,378 MB; for most of the session it allowed 6,060–6,400 MB, so other programs probably held 1 GB or more of the 8 GB card. - **The game kept filling it**, at 4,800–6,275 MB, and above 5,800 MB from Kokiri Forest on. The `at the driver's limit, room in the blocks: not squeezed` note appeared in Kokiri Forest and twice in the Lost Woods. - **The last status before the crater:** `VRAM: 6125 MB used of 6317 MB allowed (1061 MB of it free in the blocks); textures 1849 MB (budget 1260 MB)`, with 1,024 MB of VRAM mirrors and 2.8 GB of system memory imported for the GPU. - **The crater then loaded on top of that**, at 42–52 fps, with a frame's uploads taking 83 ms. About 6 seconds later the GPU was reset. That matches the driver paging past the allowance until a GPU job ran past Windows' 2-second timeout (TDR). A GPU fault in one of the crater's own shaders on AMD would look the same in this log; see "To confirm" below. ### Where in the game Death Mountain Crater (adult), arriving from Goron City's side through the debug teleport, after Market, Ganon's Castle, Kokiri Forest, the Lost Woods and Gerudo Valley in the same session. ### How often Once so far ### Graphics card and driver version AMD Radeon RX 6600 8 GB, AMD proprietary driver 26.10.1 (Vulkan driver 0x800161), Windows ### CPU, RAM and operating system 14 cores / 20 threads, 32 GB RAM (5 GB swap), Windows ### Changes from the defaults Output resolution 2048x1152 (the game's own). Nothing else is visible in the log. ### longshot_log.txt Not attached: the log holds a personal folder path. The lines above are from it. ### Related - https://github.com/NotRexed/Hookshot/issues/993: tracking VRAM and RAM filling up over play time, mostly on 4–8 GB cards (open) - https://github.com/NotRexed/Hookshot/issues/2749: Windows crashes after VRAM goes over the driver's allowance (open) - https://github.com/NotRexed/Hookshot/issues/1465 and https://github.com/NotRexed/Hookshot/issues/1891: earlier device losses (TDR) on RDNA 2 under Windows (closed) - https://git.magicbean.dev/MagicBeanDev/Longshot/issues/89: lower performance after area changes (open) ### Proposal: what could fix it 1. **Make room before an area loads.** The squeeze in `texture_frame()` (`gpu/vk/vk_texture.cpp`, `room_in_blocks`) waits while the count is within the allowance and the textures' blocks hold an eighth of it free. - That wait is right for a paused game: it stops a ratchet that evicts textures for nothing. - At an area change it backfires. The free space sits in the textures' own 128 MB blocks, and the next area's render targets, buffers and mirrors can't use it, so their new allocations push the count past the allowance. - The proposal: within 3–5% of the allowance, or as a map change starts, give the textures' empty blocks back (compaction already tracks them) and evict to the textures' budget, without waiting on `room_in_blocks`. - Here that is about 1 GB of empty block space, plus 590 MB of textures over their 1,260 MB budget, freed before the crater loaded. 2. **Port https://github.com/NotRexed/Hookshot/pull/3020** (a large excess over the 90% rule or the driver's limit is cut to 7/8 again). It brings the count down faster once it is over. 3. **Smaller VRAM mirrors on 8 GB cards near the limit.** `mirror_budget()` (`gpu/vk/vk_memory.cpp`) gives 1,024 MB here. - https://github.com/NotRexed/Hookshot/pull/2794 (sparse mirrors, memory only where a game pool is) and https://github.com/NotRexed/Hookshot/pull/2834 (a smaller budget on 6 GB cards) are open on Hookshot. - A run with `RX_VK_MIRROR_MB=512` on an 8 GB AMD card would show whether the same frame rate holds with half the mirrors. 4. **A Texture detail setting**, as https://github.com/NotRexed/Hookshot/pull/2557 proposes, for cards that stay at the limit. Open PRs on Longshot: none targets this. #77 (merged) is about Windows' system commit limit, not VRAM, and #65 only adds memory counters (`HOS_COUNTERS`), which would help measure the fix. ### To confirm - Teleport straight to Death Mountain Crater after a fresh start, with nothing else using the GPU. If the GPU still resets with plenty of free VRAM, it's more likely a shader problem than memory. In that case a run with `RX_VK_CHECKPOINTS=1` names the work the GPU was on. ### Workarounds for players now - Close other programs that use the GPU (browsers, Discord with hardware acceleration, recorders, overlays): the allowance here was 1–1.3 GB below its start. - Set the Output resolution to 1920x1080. - `RX_VK_MIRROR_MB=512` in `longshot_env.txt` frees 512 MB of the mirrors.