MagicBeanDev/Longshot

Watch

Fork 98

Game: Hyrule Field on RX 9070 XT — first-use pipeline stalls and Windows commit pressure (AI Assisted) - Worth looking into #770

New issue

Closed

opened 2026-11-15 11:01:23 +00:00 by MasterDenis · 1 comment

MasterDenis commented

2026-11-15 11:01:23 +00:00

Longshot version

3.0.0

Channel

Release

What kind of problem

Crash, freeze or black screen

What happened

Hyrule Field on RX 9070 XT — first-use pipeline stalls and Windows commit pressure (AI Assisted)

I reproduced repeated freezes while moving through Hyrule Field as child Link on Longshot 7315957 (runtime log also reports source cdf3d9d8). The longest stall in the original play session was a single graphics-pipeline build. Replaying a copy of the same save and using the existing load-at-create path with the resulting cache brought the route back to about 59 FPS and eliminated the multi-second stalls on that route.

Test setup

Ryzen 7 5700X3D, 32 GB RAM, Radeon RX 9070 XT, AMD driver reported as 26.10.2 (LLPC), Vulkan 1.4, Windows 11 build 26300.9818.
Fixed 100% render scale at 2560×1440, downsampled to a 1920×1080 borderless window during normal play. Frame generation off, 60 FPS cap, V-Sync off. The benchmark ran headless with audio disabled. The same local foliage-distance and Link skin material mods were enabled in all runs, so a stock-content confirmation would help.
Each run launched a fresh process with a separate copy of the same child Link save. After arriving in HyruleField_Child, the script waited 120 presents and sent eight 540-frame movement and camera inputs through the control bridge. Each route covered about 4,320 presents. The timings below cover movement and exclude the initial area load.
The baseline used RX_VK_LOAD=start with precompilation enabled. The only setting changed for the subsequent runs was RX_VK_LOAD=create. Both setups used RX_VK_PRECOMPILE=1, RX_VK_PRECOMPILE_COMPUTES=learned, RX_VK_NO_STATE_LIST=1, RX_VK_PIPE_SKIP=0 and RX_VK_UPLOAD_BUDGET_MS=0. The shipped state list was bypassed in this local setup.

For a replay, send one exclusive stick input at a time with ly=1 throughout and the following (lx, rx) values in order. Wait 540 presents after each input.

(0, 0), (0, 0.55), (0, -0.35), (0.4, 0),
(-0.4, 0.5), (0, -0.55), (0, 0), (0, 0.35)

Results

Run	Average FPS	p99 frame time	Longest frame	Frames >100 ms	Frames >1 s
Local baseline, load at startup	50.42	29.57 ms	1,840 ms	19	5
First load-at-create pass	58.24	25.42 ms	1,131 ms	3	1
Load-at-create, fresh launch	58.92	24.47 ms	631 ms	1	0
Load-at-create, final fresh launch	59.22	23.34 ms	85 ms	0	0

The play cache carried forward between runs, so the improvement reflects both the load strategy and warming the route. This sequence cannot quantify the contribution of each. The workaround used the same renderer binary throughout. Upstream already uses load-at-create by default on mesh-shader GPUs, as noted in the pipeline coverage measurements in PR #563.

1. Measure the remaining first-use misses on AMD

In the original visible session, the presentation thread reported 6,746.8 ms for a pipeline build with zero other jobs queued or running. The enclosing submit took 6,787.3 ms. The first load-at-create replay still hit a 1,119 ms submit with several pipeline builds in the same frame. The subsequent replay had one new graphics pipeline and a 608.6 ms wait. Longshot wrote that pipeline to a play-cache file on exit. The final fresh launch merged the play-cache files, indexed 11,242 pipeline notes in about 3.0 seconds, and reported zero new graphics pipeline compilations, pipeline waits or draws skipped for being unready during the session.

PR #563 already broadens shipped coverage. A useful follow-up would be to replay this moving child-Link route on current main with the shipped list enabled, on AMD at fixed 1440p. Compare fresh per-install caches with identical starting data for each arm, then repeat after a clean exit to verify persistence. Keep the AMD driver cache state comparable and report the worst frame and counts over 100 ms and one second alongside p99. If a miss remains, a slow-build log with the pipeline key or program variant, cache lookup result, and time from program creation to first use would show whether it needs a shipped state entry or can be queued earlier. The existing pipeline tour and pipeline submission issue provide ways to collect any route-specific entries.

2. Track Windows commit pressure separately from VRAM pressure

The original session reported 415–965 MB of commit headroom in several Hyrule Field samples. The texture cache held roughly 2.2–2.8 GB, while the commit guard sometimes reduced its eviction target to 132–1,053 MB. One interval showed about 7.8 GB of device memory used against roughly 15 GB allowed. Commit warnings persisted on the final run even after graphics pipeline compilation fell to zero. The data ties the seconds-long freezes to pipeline builds and shows a separate source of texture churn under Windows commit pressure.

For this case, log the commit headroom, texture budget before and after the clamp, amount evicted and re-uploaded, and time spent doing that work alongside the frame-time spike. If smaller hitches correlate with repeated trims as the system-managed pagefile grows, test whether a short hysteresis window for noncritical trims or reclaiming unused allocation blocks first reduces churn. Keep an immediate path for critically low headroom. This is a follow-up to measure, and the local workaround leaves the commit guard enabled.

Suggested regression check

Replay about 4,320 presents from a child save with forward movement, camera sweeps, and a restart between passes. For the warm pass, check for zero new graphics pipeline compilations, zero draws skipped because a pipeline was still pending, and zero frames over 100 ms in the measured movement window. Record area-entry timing separately. The confirmed result is for this route and hardware, with the existing visual settings preserved and the live saves untouched.

Where in the game

Hyrule Field

How often

Every time

Graphics card and driver version

RX 9070XT, Latest Optional

CPU, RAM and operating system

Ryzen 5700X3D, 32 gb, Windows 11

Changes from the defaults

No response

longshot_log.txt

Attached logs cover the original play session, the Hyrule Field freeze reproduced on a copy of the save, and the verification run after applying the workaround. Key log lines.txt lists the relevant lines.

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 3.0.0 ### Channel Release ### What kind of problem Crash, freeze or black screen ### What happened # Hyrule Field on RX 9070 XT — first-use pipeline stalls and Windows commit pressure (AI Assisted) I reproduced repeated freezes while moving through Hyrule Field as child Link on Longshot `7315957` (runtime log also reports source `cdf3d9d8`). The longest stall in the original play session was a single graphics-pipeline build. Replaying a copy of the same save and using the existing load-at-create path with the resulting cache brought the route back to about 59 FPS and eliminated the multi-second stalls on that route. ## Test setup - Ryzen 7 5700X3D, 32 GB RAM, Radeon RX 9070 XT, AMD driver reported as 26.10.2 (LLPC), Vulkan 1.4, Windows 11 build 26300.9818. - Fixed 100% render scale at 2560×1440, downsampled to a 1920×1080 borderless window during normal play. Frame generation off, 60 FPS cap, V-Sync off. The benchmark ran headless with audio disabled. The same local foliage-distance and Link skin material mods were enabled in all runs, so a stock-content confirmation would help. - Each run launched a fresh process with a separate copy of the same child Link save. After arriving in `HyruleField_Child`, the script waited 120 presents and sent eight 540-frame movement and camera inputs through the control bridge. Each route covered about 4,320 presents. The timings below cover movement and exclude the initial area load. - The baseline used `RX_VK_LOAD=start` with precompilation enabled. The only setting changed for the subsequent runs was `RX_VK_LOAD=create`. Both setups used `RX_VK_PRECOMPILE=1`, `RX_VK_PRECOMPILE_COMPUTES=learned`, `RX_VK_NO_STATE_LIST=1`, `RX_VK_PIPE_SKIP=0` and `RX_VK_UPLOAD_BUDGET_MS=0`. The shipped state list was bypassed in this local setup. For a replay, send one exclusive stick input at a time with `ly=1` throughout and the following `(lx, rx)` values in order. Wait 540 presents after each input. ```text (0, 0), (0, 0.55), (0, -0.35), (0.4, 0), (-0.4, 0.5), (0, -0.55), (0, 0), (0, 0.35) ``` ## Results | Run | Average FPS | p99 frame time | Longest frame | Frames >100 ms | Frames >1 s | | --- | ---: | ---: | ---: | ---: | ---: | | Local baseline, load at startup | 50.42 | 29.57 ms | 1,840 ms | 19 | 5 | | First load-at-create pass | 58.24 | 25.42 ms | 1,131 ms | 3 | 1 | | Load-at-create, fresh launch | 58.92 | 24.47 ms | 631 ms | 1 | 0 | | Load-at-create, final fresh launch | 59.22 | 23.34 ms | 85 ms | 0 | 0 | The play cache carried forward between runs, so the improvement reflects **both** the load strategy and warming the route. This sequence cannot quantify the contribution of each. The workaround used the same renderer binary throughout. Upstream already uses load-at-create by default on mesh-shader GPUs, as noted in the [pipeline coverage measurements in PR #563](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/563). ### 1. Measure the remaining first-use misses on AMD In the original visible session, the presentation thread reported **6,746.8 ms** for a pipeline build with zero other jobs queued or running. The enclosing submit took **6,787.3 ms**. The first load-at-create replay still hit a **1,119 ms** submit with several pipeline builds in the same frame. The subsequent replay had one new graphics pipeline and a **608.6 ms** wait. Longshot wrote that pipeline to a play-cache file on exit. The final fresh launch merged the play-cache files, indexed **11,242** pipeline notes in about **3.0 seconds**, and reported **zero** new graphics pipeline compilations, pipeline waits or draws skipped for being unready during the session. PR #563 already broadens shipped coverage. A useful follow-up would be to replay this moving child-Link route on current main with the shipped list enabled, on AMD at fixed 1440p. Compare fresh per-install caches with identical starting data for each arm, then repeat after a clean exit to verify persistence. Keep the AMD driver cache state comparable and report the worst frame and counts over 100 ms and one second alongside p99. If a miss remains, a slow-build log with the pipeline key or program variant, cache lookup result, and time from program creation to first use would show whether it needs a shipped state entry or can be queued earlier. The existing [pipeline tour](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/111) and [pipeline submission issue](https://git.magicbean.dev/MagicBeanDev/Longshot/issues/14) provide ways to collect any route-specific entries. ### 2. Track Windows commit pressure separately from VRAM pressure The original session reported **415–965 MB** of commit headroom in several Hyrule Field samples. The texture cache held roughly **2.2–2.8 GB**, while the commit guard sometimes reduced its eviction target to **132–1,053 MB**. One interval showed about **7.8 GB** of device memory used against roughly **15 GB** allowed. Commit warnings persisted on the final run even after graphics pipeline compilation fell to zero. The data ties the seconds-long freezes to pipeline builds and shows a separate source of texture churn under Windows commit pressure. For this case, log the commit headroom, texture budget before and after the clamp, amount evicted and re-uploaded, and time spent doing that work alongside the frame-time spike. If smaller hitches correlate with repeated trims as the system-managed pagefile grows, test whether a short hysteresis window for noncritical trims or reclaiming unused allocation blocks first reduces churn. Keep an immediate path for critically low headroom. This is a follow-up to measure, and the local workaround leaves the commit guard enabled. ## Suggested regression check Replay about 4,320 presents from a child save with forward movement, camera sweeps, and a restart between passes. For the warm pass, check for zero new graphics pipeline compilations, zero draws skipped because a pipeline was still pending, and zero frames over 100 ms in the measured movement window. Record area-entry timing separately. The confirmed result is for this route and hardware, with the existing visual settings preserved and the live saves untouched. ### Where in the game Hyrule Field ### How often Every time ### Graphics card and driver version RX 9070XT, Latest Optional ### CPU, RAM and operating system Ryzen 5700X3D, 32 gb, Windows 11 ### Changes from the defaults _No response_ ### longshot_log.txt Attached logs cover the original play session, the Hyrule Field freeze reproduced on a copy of the save, and the verification run after applying the workaround. Key log lines.txt lists the relevant lines. ### 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.

03 After fix verification.log

558 KiB

01 Original gameplay.log

640 KiB

02 Baseline reproduction.log

552 KiB

Key log lines.txt

3.1 KiB

👀 1

MasterDenis added the

kind

bug

label

2026-11-15 11:01:23 +00:00

BeanIssues added

and removed

labels

2026-11-15 11:01:40 +00:00

BeanIssues commented

2026-11-15 11:01:40 +00:00

Collaborator

Possibly related, for context:

#539 Game: freeze requiring hard reboot — Related Hyrule Field transition freeze on AMD/Windows; the reported symptom and suspected cause differ.
#333 Game: at Windows' commit limit the NVN layer's own allocations end the game ("recording handle set") with no wait and no out-of-memory notice — Related Windows commit-pressure behavior, but that issue concerns allocation failure at the commit limit, not measured texture churn or pipeline stalls.

Possibly related, for context: - #539 Game: freeze requiring hard reboot — Related Hyrule Field transition freeze on AMD/Windows; the reported symptom and suspected cause differ. - #333 Game: at Windows' commit limit the NVN layer's own allocations end the game ("recording handle set") with no wait and no out-of-memory notice — Related Windows commit-pressure behavior, but that issue concerns allocation failure at the commit limit, not measured texture churn or pipeline stalls.

MasterDenis closed this issue

2026-11-15 11:04:53 +00:00

BeanIssues referenced this issue

2026-11-15 13:13:45 +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 referenced this issue

2026-11-15 13:19:37 +00:00

Game: The Legend of Zelda: Ocarina of Time #808

BeanIssues referenced this issue

2026-11-15 13:27:47 +00:00

Game: Crash in Hyrule field after opening and closing map #809