MagicBeanDev/Hookshot

Archived

Watch

Fork 0

AMD RX 7800 XT (v2.0.5): sudden stutters and late/wrong textures when something new appears; every first-seen pipeline costs a stall #865

Closed

opened 2026-11-08 23:32:50 +00:00 by lucasmazzoni45-del · 5 comments

lucasmazzoni45-del commented

2026-11-08 23:32:50 +00:00

(Migrated from github.com)

UPDATE (see the comment below): in a longer session most dips were load-related, not new pipelines; the 21-of-26 figure below is from a short session right after an update.

Hookshot version

v2.0.5 (source cd9cebb6)

What kind of problem

Low fps or stutter

What happened

Sudden one-off stutters, and textures that load late or wrong when something new appears (a new character or enemy, its death animation, a new area). The frame rate itself is fine most of the time: ~58 fps average, median 60.0, and 60.0 for minutes when nothing new is on screen.

Numbers from the log (one session, 238 gameplay intervals of 120 presents): 26 dipped below 58 fps. In those intervals there were on average 2.4 new graphics pipelines (~450 ms of compile time) against 0.09 (4 ms) in the normal intervals; GPU time, memory sync, uploads, mirrors and draws were the same in both groups. 21 of the 26 dips had at least one new pipeline or program. One new pipeline in an interval was enough for ~50 fps.

After an update (new translator stamp) the driver cache misses everything: ~1,050 pipelines / 315 s of compile during play on v2.0.3 and 3,469 pipelines / 741 s on v2.0.5. The prepare on the first start of v2.0.5 ended with "precompile: 10107 programs, 0 graphics and 10107 compute pipelines", i.e. no graphics pipeline was built in advance.

User observation without log data: when a character or enemy shows up for the first time its textures appear late or wrong (untextured/neon) for a moment, and a new enemy's death animation freezes the game briefly. This is probably the same first-seen effect, but I have not isolated it.

Suggestion: save the pipeline notes (hookshot_pipelines.bin) more often than only on a clean exit, and let the prepare rebuild the noted pipelines even when the translator stamp changed, so the first session after an update is not the slow one.

Where in the game

Wherever something new appears for the first time (new areas, new enemies and their death animations, new characters), including Goron City.

How often

Every time (once for each new pipeline)

Graphics card and driver version

AMD Radeon RX 7800 XT, Adrenalin 32.0.32015.7029

CPU, RAM and operating system

Ryzen 7 5800X3D, 32 GB, Windows 11, 2560x1440, frame generation 4x

Changes from the defaults

IMPORTANT: this is not a stock build. hookshot_vk.dll is v2.0.5 plus the open PRs #700, #701, #758, #754 and a few local tweaks (texture budget 8 GB, image-pool preallocation, shader-job thread count/priority, bounded waits for pipelines). Sharpness 30. hookshot_env.txt: RX_VK_TAAU_KEYS=fd029a317a9a4b94 (the default on AMD anyway). I have not compared against the stock DLL, so I cannot say yet whether any of this changes the numbers above.

Other software hooked into the game

No, nothing hooked in (but see the modified renderer DLL above)

hookshot_log.txt

Trimmed excerpt (personal paths redacted): https://gist.github.com/lucasmazzoni45-del/aefcf474e138af9a7c68e99b8a345e57
Full hookshot_log.txt on request.

**UPDATE (see the comment below): in a longer session most dips were load-related, not new pipelines; the 21-of-26 figure below is from a short session right after an update.** ### Hookshot version v2.0.5 (source cd9cebb6) ### What kind of problem Low fps or stutter ### What happened Sudden one-off stutters, and textures that load late or wrong when something new appears (a new character or enemy, its death animation, a new area). The frame rate itself is fine most of the time: ~58 fps average, median 60.0, and 60.0 for minutes when nothing new is on screen. Numbers from the log (one session, 238 gameplay intervals of 120 presents): 26 dipped below 58 fps. In those intervals there were on average 2.4 new graphics pipelines (~450 ms of compile time) against 0.09 (4 ms) in the normal intervals; GPU time, memory sync, uploads, mirrors and draws were the same in both groups. 21 of the 26 dips had at least one new pipeline or program. One new pipeline in an interval was enough for ~50 fps. After an update (new translator stamp) the driver cache misses everything: ~1,050 pipelines / 315 s of compile during play on v2.0.3 and 3,469 pipelines / 741 s on v2.0.5. The prepare on the first start of v2.0.5 ended with "precompile: 10107 programs, 0 graphics and 10107 compute pipelines", i.e. no graphics pipeline was built in advance. User observation without log data: when a character or enemy shows up for the first time its textures appear late or wrong (untextured/neon) for a moment, and a new enemy's death animation freezes the game briefly. This is probably the same first-seen effect, but I have not isolated it. Suggestion: save the pipeline notes (hookshot_pipelines.bin) more often than only on a clean exit, and let the prepare rebuild the noted pipelines even when the translator stamp changed, so the first session after an update is not the slow one. ### Where in the game Wherever something new appears for the first time (new areas, new enemies and their death animations, new characters), including Goron City. ### How often Every time (once for each new pipeline) ### Graphics card and driver version AMD Radeon RX 7800 XT, Adrenalin 32.0.32015.7029 ### CPU, RAM and operating system Ryzen 7 5800X3D, 32 GB, Windows 11, 2560x1440, frame generation 4x ### Changes from the defaults IMPORTANT: this is not a stock build. hookshot_vk.dll is v2.0.5 plus the open PRs #700, #701, #758, #754 and a few local tweaks (texture budget 8 GB, image-pool preallocation, shader-job thread count/priority, bounded waits for pipelines). Sharpness 30. hookshot_env.txt: RX_VK_TAAU_KEYS=fd029a317a9a4b94 (the default on AMD anyway). I have not compared against the stock DLL, so I cannot say yet whether any of this changes the numbers above. ### Other software hooked into the game No, nothing hooked in (but see the modified renderer DLL above) ### hookshot_log.txt Trimmed excerpt (personal paths redacted): https://gist.github.com/lucasmazzoni45-del/aefcf474e138af9a7c68e99b8a345e57 Full hookshot_log.txt on request.

lucasmazzoni45-del commented

2026-11-08 23:39:19 +00:00

(Migrated from github.com)

https://gist.github.com/lucasmazzoni45-del/06bad1ce4151fa93dadb13c3531d6f22

Every point is marked verified/not verified. Most numbers come from a build that is not stock (11 files in gpu/vk, listed in the gist), and I did not compare against the stock DLL for the current items. Happy to run any A/B you want on RDNA3.

Follow-up with the full write-up of what I saw on this RX 7800 XT and what I changed in my build (including my own mistakes, so nobody repeats them), with the diff against stock v2.0.5 and the commands to rebuild only hookshot_vk.dll: https://gist.github.com/lucasmazzoni45-del/06bad1ce4151fa93dadb13c3531d6f22 Every point is marked verified/not verified. Most numbers come from a build that is not stock (11 files in gpu/vk, listed in the gist), and I did not compare against the stock DLL for the current items. Happy to run any A/B you want on RDNA3.

lucasmazzoni45-del commented

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

(Migrated from github.com)

Gameplay report after a few hours on this RX 7800 XT with my (non-stock) build, and a correction of my own first post.

Setup. RX 7800 XT 16 GB, Ryzen 7 5800X3D, 32 GB, 1440p fullscreen, v2.0.5 with a modified hookshot_vk.dll (the diff against stock is in the gist linked above: 11 files, ~860 lines). In-game options: frame generation 3x on a 180 Hz screen, resolution 100%, Lanczos, sharpness 40, frame pacing on, preset Custom; hookshot_env.txt: RX_VK_ANISO=16 (and the stand-in upscaler, which is the AMD default anyway).

Numbers from one long v2.0.5 session (787 gameplay intervals of 120 presents, i.e. several hours):

fps: median 57.5, mean 53.3, 10th percentile 40.3, minimum 7.1; 47% of the intervals at 58 fps or more.
GPU time ~10 ms on average (8.8 ms in the "normal" intervals, 12.2 ms in the heavy ones). Frame generation output was steady (frames shown on time, no "late" runs).
410 intervals dipped below 58 fps. Splitting them: 138 are heavy scenes (>=1,800 draws a frame, avg 2,256 draws, 42 fps, replay submit 17 ms), 60 have new pipelines built during play (avg 1,113 draws, 44 fps), and 212 have neither (avg 1,259 draws, 52 fps, submit 10.9 ms vs 8.6 ms in the normal intervals).
5,448 graphics pipelines were built during play in that session.

Correction. In my first post I wrote that 21 of 26 dips lined up with new pipelines. That was true for an earlier, shorter session right after an update (cold cache), but over this long session most dips are load-related instead: more draws per frame and a longer replay submit, with no new pipeline. So first-seen pipelines explain the stutter right after an update or in a new area, not the rest. The steady-state cost of heavy scenes (replay thread, CPU side) is a separate effect, which I have not reported on its own.

What I can and cannot say about my build. I never ran the same scenes with the stock DLL, so I cannot say it is faster or smoother than stock. Measured on v2.0.2 only: preallocating the image pool and keeping the capture buffers took a scripted walk from 52.9 to 59.8 fps. Things I added that hurt and removed: a dark/bright frame guard in the frame-generation thread (it hid a game frame 73 times in one session on real fades and flashes), forcing the real upscaling network on the software-multiply path (black blotches in the sky and banded pink bloom around explosions; the stock stand-in default is right), and a float clamp that turned water red.

Still seen on this build (v2.0.5): some flowers/stems glow neon (see #875; the log lines are in the gist), late or wrong textures when a new character or enemy appears for the first time, and the stutter described above. Not seen: the black faces / wrong lighting of v2.0.3, the terrain grid, the leaf-less plants.

Happy to run any A/B on RDNA3 (stock DLL vs mine, same scene) if that helps; the gist has the exact diff and the commands to rebuild only hookshot_vk.dll.

Gameplay report after a few hours on this RX 7800 XT with my (non-stock) build, and a correction of my own first post. **Setup.** RX 7800 XT 16 GB, Ryzen 7 5800X3D, 32 GB, 1440p fullscreen, v2.0.5 with a modified `hookshot_vk.dll` (the diff against stock is in the gist linked above: 11 files, ~860 lines). In-game options: frame generation 3x on a 180 Hz screen, resolution 100%, Lanczos, sharpness 40, frame pacing on, preset Custom; `hookshot_env.txt`: `RX_VK_ANISO=16` (and the stand-in upscaler, which is the AMD default anyway). **Numbers from one long v2.0.5 session (787 gameplay intervals of 120 presents, i.e. several hours):** - fps: median 57.5, mean 53.3, 10th percentile 40.3, minimum 7.1; 47% of the intervals at 58 fps or more. - GPU time ~10 ms on average (8.8 ms in the "normal" intervals, 12.2 ms in the heavy ones). Frame generation output was steady (frames shown on time, no "late" runs). - 410 intervals dipped below 58 fps. Splitting them: 138 are heavy scenes (>=1,800 draws a frame, avg 2,256 draws, 42 fps, replay submit 17 ms), 60 have new pipelines built during play (avg 1,113 draws, 44 fps), and 212 have neither (avg 1,259 draws, 52 fps, submit 10.9 ms vs 8.6 ms in the normal intervals). - 5,448 graphics pipelines were built during play in that session. **Correction.** In my first post I wrote that 21 of 26 dips lined up with new pipelines. That was true for an earlier, shorter session right after an update (cold cache), but over this long session most dips are load-related instead: more draws per frame and a longer replay submit, with no new pipeline. So first-seen pipelines explain the stutter right after an update or in a new area, not the rest. The steady-state cost of heavy scenes (replay thread, CPU side) is a separate effect, which I have not reported on its own. **What I can and cannot say about my build.** I never ran the same scenes with the stock DLL, so I cannot say it is faster or smoother than stock. Measured on v2.0.2 only: preallocating the image pool and keeping the capture buffers took a scripted walk from 52.9 to 59.8 fps. Things I added that hurt and removed: a dark/bright frame guard in the frame-generation thread (it hid a game frame 73 times in one session on real fades and flashes), forcing the real upscaling network on the software-multiply path (black blotches in the sky and banded pink bloom around explosions; the stock stand-in default is right), and a float clamp that turned water red. **Still seen on this build (v2.0.5):** some flowers/stems glow neon (see #875; the log lines are in the gist), late or wrong textures when a new character or enemy appears for the first time, and the stutter described above. Not seen: the black faces / wrong lighting of v2.0.3, the terrain grid, the leaf-less plants. Happy to run any A/B on RDNA3 (stock DLL vs mine, same scene) if that helps; the gist has the exact diff and the commands to rebuild only `hookshot_vk.dll`.

lucasmazzoni45-del commented

2026-11-09 00:12:55 +00:00

(Migrated from github.com)

Conclusion of my play session (v2.0.5, RX 7800 XT, my non-stock DLL): playable, mostly at 50-60 fps. What is still wrong, in my own words as the player:

some flowers (and some plants) glow neon (see #875);
frame-rate drops and a brief hitch when new enemies or new characters appear and their textures have to be loaded (first sight of them, including their death animations);
while those textures are loading they show up neon (bright wrong colours) before they settle to the right ones.

Nothing else stood out as a blocker: no crashes, no black faces, no missing terrain. I did not compare against the stock DLL, so I cannot say how much of this is specific to my build.

**Conclusion of my play session (v2.0.5, RX 7800 XT, my non-stock DLL):** playable, mostly at 50-60 fps. What is still wrong, in my own words as the player: - some flowers (and some plants) glow neon (see #875); - frame-rate drops and a brief hitch when new enemies or new characters appear and their textures have to be loaded (first sight of them, including their death animations); - while those textures are loading they show up neon (bright wrong colours) before they settle to the right ones. Nothing else stood out as a blocker: no crashes, no black faces, no missing terrain. I did not compare against the stock DLL, so I cannot say how much of this is specific to my build.

neochiken commented

2026-11-09 04:44:59 +00:00

(Migrated from github.com)

I'd love to know what I'm doing wrong, I'm getting 20-30fps on a 7800 XTX

NotRexed commented

2026-11-09 05:59:29 +00:00

(Migrated from github.com)

Tracked in #995, follow there. That issue collects every report of low FPS while the GPU is not fully used, and shader stutter, and this one is linked from it with its GPU, version and log details. If it still happens on v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher), please add a comment there with your hookshot_log.txt.

Commenting is not possible because the repository is archived.