MagicBeanDev/Longshot

Watch

Fork 99

Game: [RX 6600 / rc.4] Severe FPS collapse in Hyrule Field (~1–2 FPS), prolonged GPU timeline waits, no device loss #869

New issue

Open

opened 2026-11-15 18:10:13 +00:00 by Uki · 2 comments

Uki commented

2026-11-15 18:10:13 +00:00

Longshot version

v3.0.0-rc.4

Channel

Release

What kind of problem

Low fps or stutter

What happened

Description

Longshot v3.0.0-rc.4 no longer produces the VK_ERROR_DEVICE_LOST crashes I experienced with previous Hookshot/Longshot builds on my AMD RX 6600.

However, after extended gameplay, severe performance degradation still occurs, apparently concentrated in Hyrule Field, an extensive area with substantial geometry and resource loading.

Performance remains generally acceptable in other areas. In Hyrule Field, framerate can progressively collapse to approximately 1–2 FPS, eventually making the game nearly unresponsive.

This has now been reproduced in two long sessions using the same rc.4 build.

System configuration

Longshot: v3.0.0-rc.4, source b784a40c
GPU: AMD Radeon RX 6600, 8 GB
Driver: AMD Adrenalin 26.8.1
CPU: AMD Ryzen 5 3600
RAM: 32 GB
OS: Windows 11
Output resolution: 1920×1080
Renderer: Vulkan
Task + mesh compute fallback: Automatically enabled
Sparse VRAM mirrors: Enabled
Threaded rendering: Auto / enabled

Reproduction and observed behavior

Launch the game using the rc.4 build.
Play normally for an extended period.
Visit Hyrule Field and move around the area.
Observe increasingly severe framerate degradation, eventually reaching approximately 1–2 FPS.

The issue appears particularly pronounced in Hyrule Field. Other areas remained generally playable during the second session.

Important clarification: The occasional returns to approximately 60 FPS in the logs correspond primarily to opening the pause menu/inventory. They should not be interpreted as the outdoor scene recovering its performance.

Exiting the menu also sometimes produces a graphical glitch, apparently a separately known issue.

No GPU device loss or application crash occurred during either rc.4 test. Both sessions were terminated manually.

Two test sessions: Windows pagefile comparison

Session 1 — 2 GB pagefile

Windows system-managed pagefile, currently allocated at 2048 MB
144,411 frames presented
Severe degradation, reaching approximately 0.9–1.0 FPS
228 commit limit near warnings

Session 2 — 8 GB initial pagefile

Windows pagefile changed to 8192 MB initial / 16384 MB maximum
Same Longshot build, GPU driver and renderer configuration
324,662 frames presented
Severe degradation reproduced, reaching approximately 1–2 FPS
515 commit limit near warnings

Increasing the initial pagefile allocation did not eliminate the problem.

These warning counts cover sessions of different lengths and should not be compared directly as evidence of increasing memory pressure.

Relevant observations from the second session

Near frame 324,120, during severe degradation:

Metric	Recorded value
Framerate	1.9 FPS
Draw calls/frame	2,360
GPU time/frame	49.4 ms
Replay time/frame	529.46 ms
Host GPU resource waits/frame	513.77 ms
Timeline waits/frame	513.73 ms
Shader/pipeline waits	0.00 ms
Pending translation jobs	0

The GPU resource wait metric is a sum across host threads and should not be interpreted as a direct per-frame GPU execution duration.

An excerpt from the log:

vk: a frame's replay time (ms): submit 529.46
vk: 324120 presents, 1.9 fps
vk: host time in GPU resource waits: 513.77 ms a frame
(fences 0.04, timelines 513.73, idle 0.00, queries 0.00)
vk: GPU time 49.4 ms a frame

At frame 324,000, the log instead reports approximately 60 FPS, 233 draws/frame and 0.16 ms/frame in host GPU resource waits. This corresponds to a much lighter workload, consistent with menu/inventory rendering.

The magnitude of the timeline waits suggests that the slowdown cannot be explained by raw GPU rendering cost alone.

Memory observations

Both sessions repeatedly report commit limit near, sometimes reducing the texture budget substantially.

The second session also reports approximately 30 GB of private committed memory and periods where the device-local VRAM budget is effectively exhausted.

Sparse VRAM mirrors remain enabled, but the available evidence does not establish them as the cause of the slowdown.

Similarly, shader/pipeline compilation does not appear to explain the severe slowdown in the captured interval.

Possible investigation areas

The logs may help investigate:

GPU timeline synchronization and resource waits under heavy scene workloads
Resource allocation, texture eviction and memory-budget pressure
Potential interactions with sparse VRAM mirrors and threaded rendering
Scene-specific behavior in Hyrule Field

These are investigation suggestions, not confirmed root causes.

Issues #805 and #812 may be related, but I have not confirmed that they describe the same underlying problem.

Expected behavior

Stable, playable performance in Hyrule Field during extended gameplay, without progressively degrading to near-zero FPS.

Attachments

Full logs from both rc.4 sessions are available:

longshot_log.1.txt — 2 GB pagefile session
longshot_log.txt — 8 GB initial pagefile session

Both runs used build b784a40c.

Summary: The automatic task + mesh compute fallback appears to have prevented the previous device-loss crashes in these two sessions, but severe Hyrule Field performance degradation persists, with prolonged GPU timeline waits and significant memory pressure.

Where in the game

Hyrule Field

How often

Every time

Graphics card and driver version

RX6600 v26.8.1

CPU, RAM and operating system

R5 3600, 32GB, Win11

Changes from the defaults

No response

longshot_log.txt

End of longshot_log.txt because upload fails :

[hos host] vk: VRAM: 6846 MB used of 6846 MB allowed (2558 MB of it free in the blocks); textures 608 MB (budget 198 MB), 932 textures (at the driver's limit, room in the blocks: not squeezed)
[hos host] vk: textures: decoded ASTC 45 MB, rendered 534 MB (120 drawn in one frame, kept: 37430 KB), other 7 MB; used in the last 8 presents 133 MB
[hos host] vk: 64 MB: 0x113b7bd000 512x512x64 x1 levels 1 NVN 0x3d rendered, last used 476 presents ago
[hos host] vk: 64 MB: 0x11361ac000 4096x4096x1 x1 levels 1 NVN 0x34 rendered, last used 476 presents ago
[hos host] vk: 34 MB: 0x7fc78f3a00 6133x1467x1 x1 levels 1 NVN 0x87 ASTC, last used 225 presents ago
[hos host] vk: 32 MB: 0x100010e0400 4096x4096x1 x1 levels 1 NVN 0x32 rendered, last used 1 presents ago
[hos host] vk: 32 MB: 0x115882b000 4096x4096x1 x1 levels 1 NVN 0x32 rendered, last used 3614 presents ago
[hos host] vk: 12 MB: 0x1141388000 800x1000x1 x8 levels 1 NVN 0x6 rendered, last used 3614 presents ago
[hos host] vk: 7 MB: 0x100011e5600 1920x1080x1 x1 levels 1 NVN 0x3f rendered, last used 1 presents ago
[hos host] vk: 7 MB: 0x1001f0ffe00 1920x1080x1 x1 levels 1 NVN 0x3f rendered, last used 1 presents ago
[hos host] vk: finalized textures the GPU drew once, kept for being made again: 621 (148857 KB): 8x8x1 NVN 0x3f: 1 (2 KB); 42x41x1 NVN 0x25: 2 (13 KB); 46x66x1 NVN 0x25: 1 (11 KB); 54x46x1 NVN 0x25: 1 (9 KB); 73x49x1 NVN 0x25: 1 (13 KB); 74x30x1 NVN 0x25: 1 (8 KB); 77x77x1 NVN 0x1: 3 (17 KB); 80x72x1 NVN 0x25: 1 (22 KB); 90x64x1 NVN 0x25: 1 (22 KB); 90x86x1 NVN 0x25: 1 (30 KB); 96x77x1 NVN 0x25: 1 (28 KB); 105x76x1 NVN 0x25: 1 (31 KB); 106x30x1 NVN 0x25: 1 (12 KB); 106x105x1 NVN 0x1: 2 (21 KB); 110x130x1 NVN 0x1: 1 (13 KB); 118x110x1 NVN 0x1: 1 (12 KB);
[hos Presentation Thread] vk: presents after the CPU's signal (600): 155 waited for it, 421.29 ms each, 1 let go after RX_VK_FRAME_GATE_MS
[hos host] vk: status: 600 frames, the slowest 1265.1 ms; VRAM 6.7 of 6.7 GB
[hos host] vk: a frame: 2 draws kept their neighbour's descriptors (0 of them through other slots' registrations)
[hos host] vk: a frame: 0.0 draws left out (not ready), 0.00 waits for shaders or pipelines (0.0 ms); translation 155 ms in all, 0 jobs queued
[hos host] vk: a frame's replay time (ms): submit 2.30, present 0.14, draw 0.88, descriptors 0.48, texture lookups 0.04, uploads 0.00, pipelines 0.04, programs 0.07, commands 0.22, dispatch 0.10, memory sync 0.45, queue submit 0.28, slot wait 0.03
[hos host] vk: a frame: mirrors 4276 (1012 MB): 3.84 MB synced in 714.3 copies, 7.08 MB written back
[hos host] vk: 324600 presents, 59.3 fps; a frame: 150 draws (0 skipped), 2 dispatches, 129 passes, 77 barriers, 6 submits, 0.1 uploads (0.0 MB), 459 ub updates (198 overlays), GPU-bound wait 0.0 ms (recording slots only); 32902 pipelines (58673 ms), 1 programs (11 failed), 932 textures (608 MB)
[hos host] vk: host time in GPU resource waits: 1.37 ms a frame (fences 0.01, timelines 1.36, idle 0.00, queries 0.00; sum across threads, not frame time; excludes pacing and driver submit/present blocking)
[hos host] vk: a frame: 628.7 full barriers recorded, 96.2 left out (nothing recorded since the one before), 0.0 pass starts ordered in their fragment stages only (RX_VK_PASS_BARRIER=game)
[hos host] vk: a frame: the game's barriers by their NVN flags: 0x1: 0.0; 0x10: 0.0; 0x11: 1.0; 0x12: 69.0; 0x13: 1.0; 0x21: 2.0; 0x92: 4.0;
[hos host] vk: GPU time 7.2 ms a frame (the longest submission 37.9 ms); 0.1 textures made a frame
[hos host] vk: a frame: 0.00 MB unswizzled on the CPU in 0.00 ms
[hos host] vk: the render thread's whole frames (600 presents): 1 jobs went on before their present after 1000 ms, 8 times a game's thread waited for the work handed over, 0 times for a fence of the frame in the making
[hos host] vk: the render thread (600 presents, 125.70 ms a frame): its jobs 114.21 ms a frame (submits 2.66, presents 1.05, others 110.50), idle 11.48; the game waited for room at 76 presents, 1.89 ms each (0.24 a frame; 85.82 jobs queued at a present); 8 catch-ups (a finish, a texture read back, a write-back not recorded yet: 0), 2.27 ms each; 1 presents held for the CPU's signal, 673.74 ms each (0 let go by RX_VK_HOLD_MS); 158 captures at a CPU signal; the submits' waits read in 0.016 ms a frame; readbacks: 470 next to a texture's storage (no catch-up), 0 in one, 0 read exactly (after the work handed over: among the catch-ups); a present made 114.46 ms after its hand-over (1150.53 at most)
[hos host] vk: 28 textures retired (971 left, 627 MB): budget 0, drawn over 2, dead targets 26
[hos host] vk: sparse mirrors: 89, 1011 MB with memory of 1516 MB (504 MB spared); blocks given memory later 170792, given back 198579; bindings served from guest memory meanwhile 6969 (243 reaching blocks with memory too), from the mirror past every game pool 1385854; 11957 binds (3925.7 ms); 0 made whole for want of memory
[hos host] vk: mirror syncs (600 submits): 543 dirty pages from their submits' captures, 70707 from earlier ones', 0 from guest memory as it was at the replay; 25 captures kept; 0 pages the GPU wrote copied over (0 live); 0 kept for the GPU (RX_VK_PROTECT_BARE)
[hos host] vk: read live, by pool:
[hos host] vk: imports: 187 live (2952 MB), 2 retired still imported (28 MB), 253 retired given back (7208 MB)
[hos Presentation Thread] vk: capture: a submit 0.21 ms (lock 0.01, scan 0.05 over 365 ranges, 4259 MB), 460 pages written, 460 copied (1.8 MB)
[hos host] vk: a capture taken (ms): all 0.009; GPU wait for late pages 0.000 (0 of 600 takes), pools lock 0.000, retires and stamps 0.005, bytes copied 0.000; 25 kept (298 MB), 8 spare buffers, 1749 texture pages copied (6 MB)
[hos host] vk: texture 0x10a0efa600 1365x1365x1 x90 levels 11 NVN 0x8e -> vk 137 (ASTC decoded) (990 textures, 907 MB)
[hos host] vk: recorder: 1317953 packets run in 10.0 s (busy 0.42 s, spun idle 1.30 s, slept 5157 times, 771 of them under 200 us), 0 calls made directly (no room); the replay waited for it 13904 times, 75.14 ms in all, the longest 0.18 ms; replay_mu unlock 4367/33.29 ms (max 0.12), vkResetDescriptorPool 4668/23.87 ms (max 0.15), vkEndCommandBuffer 4668/16.68 ms (max 0.18), vkDestroyBuffer 199/1.21 ms (max 0.03), vmaDestroyBuffer 1/0.05 ms (max 0.05), vkQueueBindSparse 1/0.04 ms (max 0.04)
[hos host] vk: texture 0x10a4772c00 1365x1365x1 x90 levels 11 NVN 0x80 -> vk 137 (ASTC decoded) (991 textures, 1124 MB)
[hos host] vk: texture 0x10feebac00 1024x1024x1 x1 levels 11 NVN 0x7b -> vk 137 (ASTC decoded) (1000 textures, 1130 MB)
[hos host] vk: 4199 mirrors given back (18778 MB in all); 871 MB of mirrors now, 308 MB of them idle and kept for what the GPU wrote there alone
[hos host] vk: texture 0x10f3d4f000 512x512x1 x1 levels 10 NVN 0x8c -> vk 37 (ASTC decoded) (1500 textures, 1657 MB)
[hos host] vk: pool 0x1010000000 remade larger (256 retired)
[hos host] vk: texture 0x7fff44d400 192x128x1 x1 levels 1 NVN 0xd -> vk 16 (2000 textures, 2085 MB)
[hos host] vk: a frame's uploads took 135 ms: ASTC on the GPU 53 (144.5 MB, 34 ms); unswizzled on the GPU 2 (47.0 MB, 3 ms); on the CPU 519 (350.3 MB, 99 ms); [1365x1365 x90 NVN 0x80 ASTC on the GPU 56.5 MB 21 ms] [260x260 x1 NVN 0xa on the CPU 0.4 MB 13 ms] [256x256 x42 NVN 0x4b on the CPU 3.6 MB 10 ms]
[hos host] vk: 454 new ASTC textures left for a later frame (this frame's uploads took their budget; 8292 so far)
[hos Presentation Thread] vi: 324654 frames presented (48.9 fps over the last 5.5 s, interval 1)
[hos Presentation Thread] vi: present intervals: <15.5 ms 17, 15.5-17.8 243, 17.8-22 4, 22-30 1, 30-40 2, over 40 3
[hos host] vk: a frame's uploads took 61 ms: ASTC on the GPU 287 (127.5 MB, 47 ms); on the CPU 9 (11.5 MB, 14 ms); [1024x1024 x1 NVN 0x7b ASTC on the GPU 0.9 MB 23 ms] [640x360 x1 NVN 0x1 on the CPU 0.2 MB 13 ms] [768x768 x1 NVN 0x7b ASTC on the GPU 0.5 MB 7 ms]
[hos rmbl::VibrationThread] vcores: 75277 takes, 10125 waits (mean 28 us, longest 14.6 ms), 5039 kicks, 4979 yields, 0 escapes in 5 s
[hos sead::MainThread] nvn: GPU waits in 5 s: 19 sync waits (3076 ms), 0 polls timed out (0 ms), 0 queue finishes (0 ms)
[hos host] vk: commit limit near: 1523 MB of commit left (reserve 2560 MB); the textures' budget down to 854 MB of their 2099 MB (RX_VK_COMMIT_RESERVE_MB)
[hos host] vk: 57 textures retired (2000 left, 2072 MB): budget 30, drawn over 0, dead targets 27
[hos Presentation Thread] vi: 324662 frames presented (1.6 fps over the last 5.1 s, interval 1)
[hos Presentation Thread] vi: present intervals: <15.5 ms 0, 15.5-17.8 0, 17.8-22 0, 22-30 0, 30-40 0, over 40 8
[hos host] vk: shadow staging (600 takes): 0 shadow copies from staging, 269 from the capture buffer; capture buffers: 600 host-cached, 0 not (write-combined: staged)
[hos host] vk: replay reads of guest memory as submitted: 157400000 (98789477 pages from the captures)
[hos host] vk: pipeline cache: play file 5 saved (1911 KB): 47 pipelines, 42 from the driver's cache, 5 compiled; 0 more from the start's cache
[hos host] display: window closed, exiting

Screenshots or video

No response

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, the game's executable, its .bin caches or saves.

### Longshot version v3.0.0-rc.4 ### Channel Release ### What kind of problem Low fps or stutter ### What happened ## Description Longshot v3.0.0-rc.4 no longer produces the `VK_ERROR_DEVICE_LOST` crashes I experienced with previous Hookshot/Longshot builds on my AMD RX 6600. However, after extended gameplay, severe performance degradation still occurs, apparently concentrated in **Hyrule Field**, an extensive area with substantial geometry and resource loading. Performance remains generally acceptable in other areas. In Hyrule Field, framerate can progressively collapse to approximately **1–2 FPS**, eventually making the game nearly unresponsive. This has now been reproduced in two long sessions using the same rc.4 build. ## System configuration - **Longshot:** v3.0.0-rc.4, source `b784a40c` - **GPU:** AMD Radeon RX 6600, 8 GB - **Driver:** AMD Adrenalin 26.8.1 - **CPU:** AMD Ryzen 5 3600 - **RAM:** 32 GB - **OS:** Windows 11 - **Output resolution:** 1920×1080 - **Renderer:** Vulkan - **Task + mesh compute fallback:** Automatically enabled - **Sparse VRAM mirrors:** Enabled - **Threaded rendering:** Auto / enabled ## Reproduction and observed behavior 1. Launch the game using the rc.4 build. 2. Play normally for an extended period. 3. Visit Hyrule Field and move around the area. 4. Observe increasingly severe framerate degradation, eventually reaching approximately 1–2 FPS. The issue appears particularly pronounced in Hyrule Field. Other areas remained generally playable during the second session. **Important clarification:** The occasional returns to approximately 60 FPS in the logs correspond primarily to opening the pause menu/inventory. They should **not** be interpreted as the outdoor scene recovering its performance. Exiting the menu also sometimes produces a graphical glitch, apparently a separately known issue. No GPU device loss or application crash occurred during either rc.4 test. Both sessions were terminated manually. ## Two test sessions: Windows pagefile comparison **Session 1 — 2 GB pagefile** - Windows system-managed pagefile, currently allocated at 2048 MB - 144,411 frames presented - Severe degradation, reaching approximately 0.9–1.0 FPS - 228 `commit limit near` warnings **Session 2 — 8 GB initial pagefile** - Windows pagefile changed to 8192 MB initial / 16384 MB maximum - Same Longshot build, GPU driver and renderer configuration - 324,662 frames presented - Severe degradation reproduced, reaching approximately 1–2 FPS - 515 `commit limit near` warnings Increasing the initial pagefile allocation did **not** eliminate the problem. These warning counts cover sessions of different lengths and should not be compared directly as evidence of increasing memory pressure. ## Relevant observations from the second session Near frame 324,120, during severe degradation: | Metric | Recorded value | |---|---:| | Framerate | 1.9 FPS | | Draw calls/frame | 2,360 | | GPU time/frame | 49.4 ms | | Replay time/frame | 529.46 ms | | Host GPU resource waits/frame | 513.77 ms | | Timeline waits/frame | 513.73 ms | | Shader/pipeline waits | 0.00 ms | | Pending translation jobs | 0 | The GPU resource wait metric is a sum across host threads and should not be interpreted as a direct per-frame GPU execution duration. An excerpt from the log: ```text vk: a frame's replay time (ms): submit 529.46 vk: 324120 presents, 1.9 fps vk: host time in GPU resource waits: 513.77 ms a frame (fences 0.04, timelines 513.73, idle 0.00, queries 0.00) vk: GPU time 49.4 ms a frame ``` At frame 324,000, the log instead reports approximately 60 FPS, 233 draws/frame and 0.16 ms/frame in host GPU resource waits. This corresponds to a much lighter workload, consistent with menu/inventory rendering. The magnitude of the timeline waits suggests that the slowdown cannot be explained by raw GPU rendering cost alone. ## Memory observations Both sessions repeatedly report `commit limit near`, sometimes reducing the texture budget substantially. The second session also reports approximately 30 GB of private committed memory and periods where the device-local VRAM budget is effectively exhausted. Sparse VRAM mirrors remain enabled, but the available evidence does not establish them as the cause of the slowdown. Similarly, shader/pipeline compilation does not appear to explain the severe slowdown in the captured interval. ## Possible investigation areas The logs may help investigate: - GPU timeline synchronization and resource waits under heavy scene workloads - Resource allocation, texture eviction and memory-budget pressure - Potential interactions with sparse VRAM mirrors and threaded rendering - Scene-specific behavior in Hyrule Field These are investigation suggestions, **not confirmed root causes**. Issues #805 and #812 may be related, but I have not confirmed that they describe the same underlying problem. ## Expected behavior Stable, playable performance in Hyrule Field during extended gameplay, without progressively degrading to near-zero FPS. ## Attachments Full logs from both rc.4 sessions are available: - `longshot_log.1.txt` — 2 GB pagefile session - `longshot_log.txt` — 8 GB initial pagefile session Both runs used build `b784a40c`. **Summary:** The automatic task + mesh compute fallback appears to have prevented the previous device-loss crashes in these two sessions, but severe Hyrule Field performance degradation persists, with prolonged GPU timeline waits and significant memory pressure. ### Where in the game Hyrule Field ### How often Every time ### Graphics card and driver version RX6600 v26.8.1 ### CPU, RAM and operating system R5 3600, 32GB, Win11 ### Changes from the defaults _No response_ ### longshot_log.txt End of longshot_log.txt because upload fails : [hos host] vk: VRAM: 6846 MB used of 6846 MB allowed (2558 MB of it free in the blocks); textures 608 MB (budget 198 MB), 932 textures (at the driver's limit, room in the blocks: not squeezed) [hos host] vk: textures: decoded ASTC 45 MB, rendered 534 MB (120 drawn in one frame, kept: 37430 KB), other 7 MB; used in the last 8 presents 133 MB [hos host] vk: 64 MB: 0x113b7bd000 512x512x64 x1 levels 1 NVN 0x3d rendered, last used 476 presents ago [hos host] vk: 64 MB: 0x11361ac000 4096x4096x1 x1 levels 1 NVN 0x34 rendered, last used 476 presents ago [hos host] vk: 34 MB: 0x7fc78f3a00 6133x1467x1 x1 levels 1 NVN 0x87 ASTC, last used 225 presents ago [hos host] vk: 32 MB: 0x100010e0400 4096x4096x1 x1 levels 1 NVN 0x32 rendered, last used 1 presents ago [hos host] vk: 32 MB: 0x115882b000 4096x4096x1 x1 levels 1 NVN 0x32 rendered, last used 3614 presents ago [hos host] vk: 12 MB: 0x1141388000 800x1000x1 x8 levels 1 NVN 0x6 rendered, last used 3614 presents ago [hos host] vk: 7 MB: 0x100011e5600 1920x1080x1 x1 levels 1 NVN 0x3f rendered, last used 1 presents ago [hos host] vk: 7 MB: 0x1001f0ffe00 1920x1080x1 x1 levels 1 NVN 0x3f rendered, last used 1 presents ago [hos host] vk: finalized textures the GPU drew once, kept for being made again: 621 (148857 KB): 8x8x1 NVN 0x3f: 1 (2 KB); 42x41x1 NVN 0x25: 2 (13 KB); 46x66x1 NVN 0x25: 1 (11 KB); 54x46x1 NVN 0x25: 1 (9 KB); 73x49x1 NVN 0x25: 1 (13 KB); 74x30x1 NVN 0x25: 1 (8 KB); 77x77x1 NVN 0x1: 3 (17 KB); 80x72x1 NVN 0x25: 1 (22 KB); 90x64x1 NVN 0x25: 1 (22 KB); 90x86x1 NVN 0x25: 1 (30 KB); 96x77x1 NVN 0x25: 1 (28 KB); 105x76x1 NVN 0x25: 1 (31 KB); 106x30x1 NVN 0x25: 1 (12 KB); 106x105x1 NVN 0x1: 2 (21 KB); 110x130x1 NVN 0x1: 1 (13 KB); 118x110x1 NVN 0x1: 1 (12 KB); [hos Presentation Thread] vk: presents after the CPU's signal (600): 155 waited for it, 421.29 ms each, 1 let go after RX_VK_FRAME_GATE_MS [hos host] vk: status: 600 frames, the slowest 1265.1 ms; VRAM 6.7 of 6.7 GB [hos host] vk: a frame: 2 draws kept their neighbour's descriptors (0 of them through other slots' registrations) [hos host] vk: a frame: 0.0 draws left out (not ready), 0.00 waits for shaders or pipelines (0.0 ms); translation 155 ms in all, 0 jobs queued [hos host] vk: a frame's replay time (ms): submit 2.30, present 0.14, draw 0.88, descriptors 0.48, texture lookups 0.04, uploads 0.00, pipelines 0.04, programs 0.07, commands 0.22, dispatch 0.10, memory sync 0.45, queue submit 0.28, slot wait 0.03 [hos host] vk: a frame: mirrors 4276 (1012 MB): 3.84 MB synced in 714.3 copies, 7.08 MB written back [hos host] vk: 324600 presents, 59.3 fps; a frame: 150 draws (0 skipped), 2 dispatches, 129 passes, 77 barriers, 6 submits, 0.1 uploads (0.0 MB), 459 ub updates (198 overlays), GPU-bound wait 0.0 ms (recording slots only); 32902 pipelines (58673 ms), 1 programs (11 failed), 932 textures (608 MB) [hos host] vk: host time in GPU resource waits: 1.37 ms a frame (fences 0.01, timelines 1.36, idle 0.00, queries 0.00; sum across threads, not frame time; excludes pacing and driver submit/present blocking) [hos host] vk: a frame: 628.7 full barriers recorded, 96.2 left out (nothing recorded since the one before), 0.0 pass starts ordered in their fragment stages only (RX_VK_PASS_BARRIER=game) [hos host] vk: a frame: the game's barriers by their NVN flags: 0x1: 0.0; 0x10: 0.0; 0x11: 1.0; 0x12: 69.0; 0x13: 1.0; 0x21: 2.0; 0x92: 4.0; [hos host] vk: GPU time 7.2 ms a frame (the longest submission 37.9 ms); 0.1 textures made a frame [hos host] vk: a frame: 0.00 MB unswizzled on the CPU in 0.00 ms [hos host] vk: the render thread's whole frames (600 presents): 1 jobs went on before their present after 1000 ms, 8 times a game's thread waited for the work handed over, 0 times for a fence of the frame in the making [hos host] vk: the render thread (600 presents, 125.70 ms a frame): its jobs 114.21 ms a frame (submits 2.66, presents 1.05, others 110.50), idle 11.48; the game waited for room at 76 presents, 1.89 ms each (0.24 a frame; 85.82 jobs queued at a present); 8 catch-ups (a finish, a texture read back, a write-back not recorded yet: 0), 2.27 ms each; 1 presents held for the CPU's signal, 673.74 ms each (0 let go by RX_VK_HOLD_MS); 158 captures at a CPU signal; the submits' waits read in 0.016 ms a frame; readbacks: 470 next to a texture's storage (no catch-up), 0 in one, 0 read exactly (after the work handed over: among the catch-ups); a present made 114.46 ms after its hand-over (1150.53 at most) [hos host] vk: 28 textures retired (971 left, 627 MB): budget 0, drawn over 2, dead targets 26 [hos host] vk: sparse mirrors: 89, 1011 MB with memory of 1516 MB (504 MB spared); blocks given memory later 170792, given back 198579; bindings served from guest memory meanwhile 6969 (243 reaching blocks with memory too), from the mirror past every game pool 1385854; 11957 binds (3925.7 ms); 0 made whole for want of memory [hos host] vk: mirror syncs (600 submits): 543 dirty pages from their submits' captures, 70707 from earlier ones', 0 from guest memory as it was at the replay; 25 captures kept; 0 pages the GPU wrote copied over (0 live); 0 kept for the GPU (RX_VK_PROTECT_BARE) [hos host] vk: read live, by pool: [hos host] vk: imports: 187 live (2952 MB), 2 retired still imported (28 MB), 253 retired given back (7208 MB) [hos Presentation Thread] vk: capture: a submit 0.21 ms (lock 0.01, scan 0.05 over 365 ranges, 4259 MB), 460 pages written, 460 copied (1.8 MB) [hos host] vk: a capture taken (ms): all 0.009; GPU wait for late pages 0.000 (0 of 600 takes), pools lock 0.000, retires and stamps 0.005, bytes copied 0.000; 25 kept (298 MB), 8 spare buffers, 1749 texture pages copied (6 MB) [hos host] vk: texture 0x10a0efa600 1365x1365x1 x90 levels 11 NVN 0x8e -> vk 137 (ASTC decoded) (990 textures, 907 MB) [hos host] vk: recorder: 1317953 packets run in 10.0 s (busy 0.42 s, spun idle 1.30 s, slept 5157 times, 771 of them under 200 us), 0 calls made directly (no room); the replay waited for it 13904 times, 75.14 ms in all, the longest 0.18 ms; replay_mu unlock 4367/33.29 ms (max 0.12), vkResetDescriptorPool 4668/23.87 ms (max 0.15), vkEndCommandBuffer 4668/16.68 ms (max 0.18), vkDestroyBuffer 199/1.21 ms (max 0.03), vmaDestroyBuffer 1/0.05 ms (max 0.05), vkQueueBindSparse 1/0.04 ms (max 0.04) [hos host] vk: texture 0x10a4772c00 1365x1365x1 x90 levels 11 NVN 0x80 -> vk 137 (ASTC decoded) (991 textures, 1124 MB) [hos host] vk: texture 0x10feebac00 1024x1024x1 x1 levels 11 NVN 0x7b -> vk 137 (ASTC decoded) (1000 textures, 1130 MB) [hos host] vk: 4199 mirrors given back (18778 MB in all); 871 MB of mirrors now, 308 MB of them idle and kept for what the GPU wrote there alone [hos host] vk: texture 0x10f3d4f000 512x512x1 x1 levels 10 NVN 0x8c -> vk 37 (ASTC decoded) (1500 textures, 1657 MB) [hos host] vk: pool 0x1010000000 remade larger (256 retired) [hos host] vk: texture 0x7fff44d400 192x128x1 x1 levels 1 NVN 0xd -> vk 16 (2000 textures, 2085 MB) [hos host] vk: a frame's uploads took 135 ms: ASTC on the GPU 53 (144.5 MB, 34 ms); unswizzled on the GPU 2 (47.0 MB, 3 ms); on the CPU 519 (350.3 MB, 99 ms); [1365x1365 x90 NVN 0x80 ASTC on the GPU 56.5 MB 21 ms] [260x260 x1 NVN 0xa on the CPU 0.4 MB 13 ms] [256x256 x42 NVN 0x4b on the CPU 3.6 MB 10 ms] [hos host] vk: 454 new ASTC textures left for a later frame (this frame's uploads took their budget; 8292 so far) [hos Presentation Thread] vi: 324654 frames presented (48.9 fps over the last 5.5 s, interval 1) [hos Presentation Thread] vi: present intervals: <15.5 ms 17, 15.5-17.8 243, 17.8-22 4, 22-30 1, 30-40 2, over 40 3 [hos host] vk: a frame's uploads took 61 ms: ASTC on the GPU 287 (127.5 MB, 47 ms); on the CPU 9 (11.5 MB, 14 ms); [1024x1024 x1 NVN 0x7b ASTC on the GPU 0.9 MB 23 ms] [640x360 x1 NVN 0x1 on the CPU 0.2 MB 13 ms] [768x768 x1 NVN 0x7b ASTC on the GPU 0.5 MB 7 ms] [hos rmbl::VibrationThread] vcores: 75277 takes, 10125 waits (mean 28 us, longest 14.6 ms), 5039 kicks, 4979 yields, 0 escapes in 5 s [hos sead::MainThread] nvn: GPU waits in 5 s: 19 sync waits (3076 ms), 0 polls timed out (0 ms), 0 queue finishes (0 ms) [hos host] vk: commit limit near: 1523 MB of commit left (reserve 2560 MB); the textures' budget down to 854 MB of their 2099 MB (RX_VK_COMMIT_RESERVE_MB) [hos host] vk: 57 textures retired (2000 left, 2072 MB): budget 30, drawn over 0, dead targets 27 [hos Presentation Thread] vi: 324662 frames presented (1.6 fps over the last 5.1 s, interval 1) [hos Presentation Thread] vi: present intervals: <15.5 ms 0, 15.5-17.8 0, 17.8-22 0, 22-30 0, 30-40 0, over 40 8 [hos host] vk: shadow staging (600 takes): 0 shadow copies from staging, 269 from the capture buffer; capture buffers: 600 host-cached, 0 not (write-combined: staged) [hos host] vk: replay reads of guest memory as submitted: 157400000 (98789477 pages from the captures) [hos host] vk: pipeline cache: play file 5 saved (1911 KB): 47 pipelines, 42 from the driver's cache, 5 compiled; 0 more from the start's cache [hos host] display: window closed, exiting ### Screenshots or video _No response_ ### 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, the game's executable, its .bin caches or saves.

longshot_log.1.txt

9.3 MiB

👀 1

Uki added the

kind

bug

label

2026-11-15 18:10:13 +00:00

BeanIssues added

and removed

labels

2026-11-15 18:10:29 +00:00

BeanIssues commented

2026-11-15 18:10:30 +00:00

Collaborator

Possibly related, for context:

#805 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 — Related compute-fallback behavior and Windows commit pressure; reports different symptom and no severe persistent timeline waits.
#770 Game: Hyrule Field on RX 9070 XT — first-use pipeline stalls and Windows commit pressure (AI Assisted) - Worth looking into — Hyrule Field performance and commit-pressure investigation, but focuses on first-use pipeline stalls on another GPU.

Possibly related, for context: - #805 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 — Related compute-fallback behavior and Windows commit pressure; reports different symptom and no severe persistent timeline waits. - #770 Game: Hyrule Field on RX 9070 XT — first-use pipeline stalls and Windows commit pressure (AI Assisted) - Worth looking into — Hyrule Field performance and commit-pressure investigation, but focuses on first-use pipeline stalls on another GPU.

Uki commented

2026-11-15 18:40:14 +00:00

Author

Additional finding: camera orientation strongly affects the slowdown in Hyrule Field.

I found a simple workaround: when moving through problematic areas, positioning the camera above Link and pointing it almost straight down toward the ground significantly improves performance.

Pointing the camera toward the distant landscape causes much more severe slowdown, especially in Hyrule Field where the visible environment extends over a large distance.

This suggests the issue may be strongly related to visible scene complexity, draw-call processing, culling, or associated GPU resource synchronization rather than simply the total duration of the session.

It may also provide a useful way to reproduce and profile the problem by comparing different camera orientations at the same location.

**Additional finding: camera orientation strongly affects the slowdown in Hyrule Field.** I found a simple workaround: when moving through problematic areas, positioning the camera above Link and pointing it almost straight down toward the ground significantly improves performance. Pointing the camera toward the distant landscape causes much more severe slowdown, especially in Hyrule Field where the visible environment extends over a large distance. This suggests the issue may be strongly related to visible scene complexity, draw-call processing, culling, or associated GPU resource synchronization rather than simply the total duration of the session. It may also provide a useful way to reproduce and profile the problem by comparing different camera orientations at the same location.