Shader compilation stutter? - drops from 60 - 5fps in new areas/scenes #69

Closed

opened 2026-11-07 08:25:02 +00:00 by lozengelover · 3 comments

lozengelover commented

2026-11-07 08:25:02 +00:00

(Migrated from github.com)

Tested on The latest build

I am experiencing stutter similar to shader compilation stutter on emulated versions of the game. Drops from 60 to 5fps when moving, or looking at things in a new area. This stutter makes the game unplayable currently as it is every 2-3 seconds as new assets are being loaded.

tested on an rtx 5070 + ryzen 5 5700x + 32gb ddr4 ram.

Tested on The latest build I am experiencing stutter similar to shader compilation stutter on emulated versions of the game. Drops from 60 to 5fps when moving, or looking at things in a new area. This stutter makes the game unplayable currently as it is every 2-3 seconds as new assets are being loaded. tested on an rtx 5070 + ryzen 5 5700x + 32gb ddr4 ram.

👍 1

NotRexed commented

2026-11-07 14:56:48 +00:00

(Migrated from github.com)

Duplicate of #62: stutter when new shaders are built in new areas. Making pipeline builds not block the frame is on the list.

litechenacc commented

2026-11-07 15:03:01 +00:00

(Migrated from github.com)

Cold start vs second start on AMD (RX 9060 XT): what the precompile actually bought, and the one stall that is not pipeline creation

Build / hardware: AMD RX 9060 XT 16 GB, Vulkan 1.4, driver 0x8001a0, Windows 11 build 26300, built with HookshotBuilder on 2026-11-07 around 20:50 local (hookshot.exe timestamp 20:58, so it predates #166 — no RX_VK_NOOPT string in hookshot_vk.dll). Language zh-Hant. Insert menu: frame generation 3x, frame pacing on, resolution Auto, upscaling Catmull-Rom, sharpness 60, game speed Real time.

Symptoms match this issue and #34's guess: it stutters when the sky/lighting changes and when entering a new area. So instead of just adding "+1", here are the numbers from two consecutive sessions on the same save.

Session 1 — cold (≈1 h, 51,898 log lines)

	start	end
pipelines	335 (439 ms)	4,929 (995,944 ms)
programs	0	1,905 (15 failed to translate)

boot: precompile: 360 programs, 335 graphics and 87 compute pipelines in 495 ms; pipeline cache 8.7 MB, program cache 21,811 keys.
translation 17390 ms in all — shader translation is not where the time goes.
one stall, broken down by the log itself: slow submit: 1556.3 ms: draw 1481.3 descriptors 1346.6 texture lookups 806.2 uploads 746.7 programs 12.4.
80 slow submit lines (several 1.7–10 s at area changes), 51 slow dispatch (max 81.6 ms).

Session 2 — same save, same area, restart (1.2 MB log so far)

boot: precompile: 3892 programs, 4515 graphics and 513 compute pipelines in 4605 ms. In other words the notes went 43 MB → 121 MB, the driver pipeline cache 8.7 MB → 132 MB and the program cache 21,811 → 23,602 keys, and 4,515 pipelines are now built before the game starts.
during play only 304 new pipelines (4,515 → 4,819), median 60 fps, and the area that stuttered before is smooth. The notes → precompile loop does exactly what the commit says; the price is 4.6 s at start.
those 304 still cost 52.7 s of driver compilation (≈173 ms each), so what is left is the expensive tail.

The one stall that looks different (session 2):

slow dispatch 3098.9 ms: program 0000000000000000 (picked at 3098.8), pipeline at -1.0, descriptors at -1.0
slow dispatch   81.0 ms: program 0000000000000000 (picked at 2.0),    pipeline at -1.0, descriptors at -1.0

The 3.1 s is in picked and the program key is 0, so it is not vkCreateGraphicsPipelines — the presentation thread waited on program selection/translation. translation 3626 ms in all in that session. If in-play translation can block for seconds like this, that may be a separate thing to look at.

VRAM (session 2): VRAM: 12448 MB used of 12448 MB allowed (5392 MB of it free in the blocks); textures 3281 MB (budget 2907 MB) — the allowance walked down from 15,419 MB to 12,290 MB over the session and textures reached ~6.5 GB. Nothing I can call a leak from 20 minutes, but it ends up pinned at the cap.

Crash entering Hyrule Castle — end of session 1, 2026-11-07 22:48 local:

[hos OptimizeChangeBanc] CRASH: exception 0xc0000005 (read 0x100000000004, guest 0x4) at hookshot.exe+0x191033bd
[hos OptimizeChangeBanc] CRASH: host backtrace: hookshot.exe+0x191033bd
[hos OptimizeChangeBanc] CRASH: thread OptimizeChangeBanc, sp 0x105a69eae0
[hos OptimizeChangeBanc] CRASH: guest backtrace: lr 0x809051ec 0x814f2a3c 0x800ac780 0x800ac614 0x80456fb4 0x80455a70 0x83bb5a14 0x80387b00 0x80383d8c 0x801a2268 0x80034bd4 0x80df26c0 0x834a2ec8 0

Windows Error Reporting agrees: fault offset 0x191033bd, fault bucket 1397831994556267451. x0–x31, the stack window and the surrounding frames are in the attachment.

Caveats, so nobody chases the wrong thing: the full session-1 log (8.8 MB) was overwritten when the game was started again — only the excerpt and the WER record survive, and I have not reproduced the crash yet. I will walk into the castle again now that the caches are warm and post the full log if it repeats.

Two side notes from the same logs: 10 programs are left out on this card (the neural-network passes, see #52/#73) and this card still reports matrix multiplies in software (the cooperative matrices lack 16x8x16 f16).

Attachments (secret gist — readable by link, not listed): https://gist.github.com/litechenacc/a191c51eeda99daf62b70c7445112fab

hookshot_log_excerpt_hyrule-castle-crash.txt — verbatim crash block, full register/stack window, WER fields, session-1 figures.
hookshot_log_warm-session_2026-11-07.txt — the warm session (1.2 MB), including the precompile: 3892 programs, 4515 graphics and 513 compute pipelines in 4605 ms line.
hookshot_options.ini.

### Cold start vs second start on AMD (RX 9060 XT): what the precompile actually bought, and the one stall that is not pipeline creation **Build / hardware:** AMD RX 9060 XT 16 GB, Vulkan 1.4, driver `0x8001a0`, Windows 11 build 26300, built with HookshotBuilder on 2026-11-07 around 20:50 local (`hookshot.exe` timestamp 20:58, so it predates #166 — no `RX_VK_NOOPT` string in `hookshot_vk.dll`). Language `zh-Hant`. Insert menu: frame generation **3x**, frame pacing on, resolution **Auto**, upscaling Catmull-Rom, sharpness 60, game speed Real time. Symptoms match this issue and #34's guess: it stutters when the sky/lighting changes and when entering a new area. So instead of just adding "+1", here are the numbers from two consecutive sessions on the same save. **Session 1 — cold (≈1 h, 51,898 log lines)** | | start | end | |---|---|---| | pipelines | 335 (439 ms) | **4,929 (995,944 ms)** | | programs | 0 | 1,905 (**15 failed to translate**) | - boot: `precompile: 360 programs, 335 graphics and 87 compute pipelines in 495 ms`; pipeline cache 8.7 MB, program cache 21,811 keys. - `translation 17390 ms in all` — shader translation is not where the time goes. - one stall, broken down by the log itself: `slow submit: 1556.3 ms: draw 1481.3 descriptors 1346.6 texture lookups 806.2 uploads 746.7 programs 12.4`. - 80 `slow submit` lines (several 1.7–10 s at area changes), 51 `slow dispatch` (max 81.6 ms). **Session 2 — same save, same area, restart (1.2 MB log so far)** - boot: `precompile: 3892 programs, 4515 graphics and 513 compute pipelines in 4605 ms`. In other words the notes went 43 MB → 121 MB, the driver pipeline cache 8.7 MB → 132 MB and the program cache 21,811 → 23,602 keys, and **4,515 pipelines are now built before the game starts**. - during play only **304** new pipelines (4,515 → 4,819), median **60 fps**, and the area that stuttered before is smooth. The notes → precompile loop does exactly what the commit says; the price is 4.6 s at start. - those 304 still cost 52.7 s of driver compilation (≈173 ms each), so what is left is the expensive tail. **The one stall that looks different** (session 2): ``` slow dispatch 3098.9 ms: program 0000000000000000 (picked at 3098.8), pipeline at -1.0, descriptors at -1.0 slow dispatch 81.0 ms: program 0000000000000000 (picked at 2.0), pipeline at -1.0, descriptors at -1.0 ``` The 3.1 s is in `picked` and the program key is `0`, so it is not `vkCreateGraphicsPipelines` — the presentation thread waited on program selection/translation. `translation 3626 ms in all` in that session. If in-play translation can block for seconds like this, that may be a separate thing to look at. **VRAM (session 2):** `VRAM: 12448 MB used of 12448 MB allowed (5392 MB of it free in the blocks); textures 3281 MB (budget 2907 MB)` — the allowance walked down from 15,419 MB to 12,290 MB over the session and textures reached ~6.5 GB. Nothing I can call a leak from 20 minutes, but it ends up pinned at the cap. **Crash entering Hyrule Castle** — end of session 1, 2026-11-07 22:48 local: ``` [hos OptimizeChangeBanc] CRASH: exception 0xc0000005 (read 0x100000000004, guest 0x4) at hookshot.exe+0x191033bd [hos OptimizeChangeBanc] CRASH: host backtrace: hookshot.exe+0x191033bd [hos OptimizeChangeBanc] CRASH: thread OptimizeChangeBanc, sp 0x105a69eae0 [hos OptimizeChangeBanc] CRASH: guest backtrace: lr 0x809051ec 0x814f2a3c 0x800ac780 0x800ac614 0x80456fb4 0x80455a70 0x83bb5a14 0x80387b00 0x80383d8c 0x801a2268 0x80034bd4 0x80df26c0 0x834a2ec8 0 ``` Windows Error Reporting agrees: fault offset `0x191033bd`, fault bucket `1397831994556267451`. x0–x31, the stack window and the surrounding frames are in the attachment. Caveats, so nobody chases the wrong thing: the full session-1 log (8.8 MB) was overwritten when the game was started again — only the excerpt and the WER record survive, and I have not reproduced the crash yet. I will walk into the castle again now that the caches are warm and post the full log if it repeats. Two side notes from the same logs: 10 programs are `left out on this card` (the neural-network passes, see #52/#73) and this card still reports `matrix multiplies in software (the cooperative matrices lack 16x8x16 f16)`. **Attachments** (secret gist — readable by link, not listed): https://gist.github.com/litechenacc/a191c51eeda99daf62b70c7445112fab - `hookshot_log_excerpt_hyrule-castle-crash.txt` — verbatim crash block, full register/stack window, WER fields, session-1 figures. - `hookshot_log_warm-session_2026-11-07.txt` — the warm session (1.2 MB), including the `precompile: 3892 programs, 4515 graphics and 513 compute pipelines in 4605 ms` line. - `hookshot_options.ini`.

MultiKoopa commented

2026-11-07 17:49:33 +00:00

(Migrated from github.com)

Duplicate of #62: stutter when new shaders are built in new areas. Making pipeline builds not block the frame is on the list.

What about precompiling? Is that on the list, or not planned?

> Duplicate of [#62](https://git.magicbean.dev/MagicBeanDev/Hookshot/issues/62): stutter when new shaders are built in new areas. Making pipeline builds not block the frame is on the list. What about precompiling? Is that on the list, or not planned?

Commenting is not possible because the repository is archived.