MagicBeanDev/Hookshot

Archived

Watch

Fork 0

[AMD / v2.0.7] RX 6600 vs RX 7600: VRAM saturation, persistent low FPS, long stalls and missing geometry #1123

Closed

opened 2026-11-09 13:03:30 +00:00 by notreallyfreddie76-arch · 4 comments

notreallyfreddie76-arch commented

2026-11-09 13:03:30 +00:00

(Migrated from github.com)

Hookshot version

v2.0.7

What kind of problem

Crash, freeze or black screen

What happened

[AMD / v2.0.7] RX 6600 vs RX 7600: VRAM saturation, persistent low FPS, long stalls and missing geometry

Summary

I tested Hookshot v2.0.7 (source 9b541c9c) on two Windows PCs equipped with AMD Radeon GPUs: an RX 6600 (RDNA 2) and an RX 7600 (RDNA 3).

Both configurations show serious performance and rendering problems, although their failure modes differ.

RX 6600:

Severe rendering stalls and eventually a permanent freeze without a Vulkan device-loss error.
A second run after a clean reboot initially worked, then froze when opening the inventory.
VRAM usage reached the reported Vulkan memory budget.

RX 7600:

No permanent freeze, but a very long temporary stall after the Deku Tree boss.
Persistent 20–25 FPS in Kokiri Forest, even after spending time in the same area.
Severe stuttering when loading new textures or animations and during fast camera movements.
Brief black screens when entering houses.
An NPC temporarily lost its visible arms and legs during dialogue; the geometry reappeared afterward.
VRAM usage repeatedly reached the reported memory budget.

Related issues: #995, #996, #1002, #1032.

Test configurations

At 72,000 frames, the renderer reports approximately 2,331 draws per frame.

This is important because the low frame rate persists in samples reporting zero shader/pipeline waits.

Therefore, first-time shader compilation alone cannot explain the sustained performance problems. Rendering workload, GPU time and memory pressure may be contributing factors.

VRAM pressure

The reported Vulkan memory budget was reached in 52 of 130 periodic memory snapshots.

Example:

VRAM: 6647 MB used of 6647 MB allowed (1741 MB of it free in the blocks)

textures 3343 MB (budget 3144 MB), 1328 textures

The maximum reported resident texture memory was approximately 5,078 MB.

These figures indicate allocation/budget pressure, not necessarily that every byte of physical VRAM is occupied by useful data.

Rendering anomalies

In addition to poor performance:

An NPC temporarily lost its visible arms and legs during dialogue.
Short black screens occurred when entering houses.
Rapid movement produced noticeable FPS drops.
Texture and animation loading caused heavy stutters.

The log reports 165 failures during initial shader preparation, increasing to 180 cumulative program failures during gameplay. It is not yet possible to link those failures to the specific visual anomalies.

There are also messages about video buffers being displayed black before decoding completes, but whether these correspond to the house-transition black screens is unknown.

Earlier observation on RX 6600

On an earlier v2.0.2 run using an experimental Vulkan DLL from PR #734, the Deku Tree boss could be completed without a driver crash.

However, the boss arena was missing its visible walls, ceiling and pillars while their collision geometry remained functional.

This occurred on a different build and should not be interpreted as a v2.0.7-specific result.

Preliminary interpretation

The tests suggest several potentially overlapping issues:

Vulkan memory-budget pressure: both AMD GPUs regularly reach their reported budget.
Persistent rendering cost: the RX 7600 remains at approximately 20–25 FPS even after shader/pipeline waits fall to zero.
Silent rendering stalls: the application can stop producing frames for extended periods without Vulkan reporting device loss.
Incorrect or incomplete geometry: some scene elements or character meshes may be omitted temporarily.

These observations do not establish a single root cause.

The VRAM-management changes announced for v2.0.8 appear particularly relevant, but v2.0.8 has not yet been tested on either machine.

Logs

The corresponding complete logs are:

hookshot_log(4).txt — RX 6600, first v2.0.7 freeze
hookshot_log(5).txt — RX 6600, inventory freeze after reboot
hookshot_log(6).txt — RX 7600, long gameplay session

</html> </html>

Where in the game

Kokiri Forest

How often

Every time

Graphics card and driver version

RX 6600, RX7600

CPU, RAM and operating system

Ryzen 5 3600 32GB RAM on both devices

Changes from the defaults

No response

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

hookshot_log(4).txt
hookshot_log(5).txt
hookshot_log(6).txt

Screenshots or video

No response

Before you send it

I'm on the newest release, or the problem is still there on it.
I searched the open issues for this problem.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

### Hookshot version v2.0.7 ### What kind of problem Crash, freeze or black screen ### What happened <html> <body> <html><head></head><body><h1>[AMD / v2.0.7] RX 6600 vs RX 7600: VRAM saturation, persistent low FPS, long stalls and missing geometry</h1><h2>Summary</h2>I tested Hookshot v2.0.7 (source <code>9b541c9c</code>) on two Windows PCs equipped with AMD Radeon GPUs: an RX 6600 (RDNA 2) and an RX 7600 (RDNA 3).Both configurations show serious performance and rendering problems, although their failure modes differ.RX 6600:<ul><li>Severe rendering stalls and eventually a permanent freeze without a Vulkan device-loss error.</li><li>A second run after a clean reboot initially worked, then froze when opening the inventory.</li><li>VRAM usage reached the reported Vulkan memory budget.</li></ul>RX 7600:<ul><li>No permanent freeze, but a very long temporary stall after the Deku Tree boss.</li><li>Persistent 20–25 FPS in Kokiri Forest, even after spending time in the same area.</li><li>Severe stuttering when loading new textures or animations and during fast camera movements.</li><li>Brief black screens when entering houses.</li><li>An NPC temporarily lost its visible arms and legs during dialogue; the geometry reappeared afterward.</li><li>VRAM usage repeatedly reached the reported memory budget.</li></ul>Related issues: #995, #996, #1002, #1032.<h2>Test configurations</h2> | RX 6600 system | RX 7600 system -- | -- | -- GPU | RX 6600 8 GB, RDNA 2 | RX 7600 8 GB, RDNA 3 Vulkan | 1.4 | 1.4 Driver ID | 0x800161 | 0x800184 Hookshot | v2.0.7 | v2.0.7 Source | 9b541c9c | 9b541c9c AMD checkpoints | Enabled | Disabled Frame generation | — | Disabled for sustained-FPS observations At 72,000 frames, the renderer reports approximately 2,331 draws per frame.This is important because the low frame rate persists in samples reporting zero shader/pipeline waits.Therefore, first-time shader compilation alone cannot explain the sustained performance problems. Rendering workload, GPU time and memory pressure may be contributing factors.<h3>VRAM pressure</h3>The reported Vulkan memory budget was reached in 52 of 130 periodic memory snapshots.Example:<code>VRAM: 6647 MB used of 6647 MB allowed (1741 MB of it free in the blocks)</code><code>textures 3343 MB (budget 3144 MB), 1328 textures</code>The maximum reported resident texture memory was approximately 5,078 MB.These figures indicate allocation/budget pressure, not necessarily that every byte of physical VRAM is occupied by useful data.<h3>Rendering anomalies</h3>In addition to poor performance:<ul><li>An NPC temporarily lost its visible arms and legs during dialogue.</li><li>Short black screens occurred when entering houses.</li><li>Rapid movement produced noticeable FPS drops.</li><li>Texture and animation loading caused heavy stutters.</li></ul>The log reports 165 failures during initial shader preparation, increasing to 180 cumulative program failures during gameplay. It is not yet possible to link those failures to the specific visual anomalies.There are also messages about video buffers being displayed black before decoding completes, but whether these correspond to the house-transition black screens is unknown.<h2>Earlier observation on RX 6600</h2>On an earlier v2.0.2 run using an experimental Vulkan DLL from PR #734, the Deku Tree boss could be completed without a driver crash.However, the boss arena was missing its visible walls, ceiling and pillars while their collision geometry remained functional.This occurred on a different build and should not be interpreted as a v2.0.7-specific result.<h2>Preliminary interpretation</h2>The tests suggest several potentially overlapping issues:<ol start="1"><li>Vulkan memory-budget pressure: both AMD GPUs regularly reach their reported budget.</li><li>Persistent rendering cost: the RX 7600 remains at approximately 20–25 FPS even after shader/pipeline waits fall to zero.</li><li>Silent rendering stalls: the application can stop producing frames for extended periods without Vulkan reporting device loss.</li><li>Incorrect or incomplete geometry: some scene elements or character meshes may be omitted temporarily.</li></ol>These observations do not establish a single root cause.The VRAM-management changes announced for v2.0.8 appear particularly relevant, but v2.0.8 has not yet been tested on either machine.<h2>Logs</h2>The corresponding complete logs are:<ul><li><code>hookshot_log(4).txt</code> — RX 6600, first v2.0.7 freeze</li><li><code>hookshot_log(5).txt</code> — RX 6600, inventory freeze after reboot</li><li><code>hookshot_log(6).txt</code> — RX 7600, long gameplay session</li></ul></body></html> </body> </html> ### Where in the game Kokiri Forest ### How often Every time ### Graphics card and driver version RX 6600, RX7600 ### CPU, RAM and operating system Ryzen 5 3600 32GB RAM on both devices ### Changes from the defaults _No response_ ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [hookshot_log(4).txt](https://github.com/user-attachments/files/34579924/hookshot_log.4.txt) [hookshot_log(5).txt](https://github.com/user-attachments/files/34579923/hookshot_log.5.txt) [hookshot_log(6).txt](https://github.com/user-attachments/files/34579922/hookshot_log.6.txt) ### Screenshots or video _No response_ ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

NotRexed commented

2026-11-09 13:09:13 +00:00

(Migrated from github.com)

Thanks for the side-by-side comparison. Linking this to the FPS tracker #995; the VRAM saturation on 8 GB cards is collected in #993. The next release keeps large textures compressed on 6-8 GB cards and adds about 5% FPS from CPU-side changes, so a retest then would be very useful.

notreallyfreddie76-arch commented

2026-11-09 17:07:39 +00:00

(Migrated from github.com)

v2.0.8 follow-up — RX 6600: intermittent permanent freezes when opening different menus

Additional testing on Hookshot v2.0.8 (source 24534a6a), RX 6600, Vulkan driver 0x800161, Windows 11.

The game successfully reached Hyrule and remained generally playable. Some textures appeared as bright white halos, and FPS were relatively low, but there was little noticeable stuttering.

However, the application permanently froze when opening the quick item selection menu (Deku Stick / Slingshot / Deku Nut).

This is not limited to that interface. Previous runs froze when opening the main inventory, while another run successfully opened the inventory several times before freezing on a later attempt. The issue is therefore intermittent.

Windows observations during the freeze:

GPU 3D utilization drops to approximately 0%.
Dedicated VRAM usage remains near its previous high level.
CPU and system RAM usage remain stable and consistent with normal activity.
GPU fans slow down or stop a few seconds after the freeze.
Windows Reliability Monitor (perfmon /rel) shows no corresponding hardware failure, LiveKernelEvent or graphics-driver recovery.

Log observations:

RX_VK_CHECKPOINTS=1 was enabled.
No VK_ERROR_DEVICE_LOST is reported.
No useful AMD checkpoint failure diagnosis is emitted.
The renderer was still producing frames before the freeze, with the workload dropping significantly during the menu transition.
The process remains alive, and the log eventually ends with the window being closed.

This suggests that the freeze is not necessarily caused by sustained GPU rendering load or VRAM budget exhaustion alone.

Since multiple menu interfaces can trigger a similar silent freeze, a shared rendering transition or synchronization path may be worth investigating.

This may be related to the existing AMD freeze tracker #996 and earlier RX 6600 menu reports #749 and #872.

Attached: hookshot_log(10).txt — RX 6600, v2.0.8, permanent freeze after opening quick item selection.

hookshot_log(10).txt

### v2.0.8 follow-up — RX 6600: intermittent permanent freezes when opening different menus Additional testing on **Hookshot v2.0.8 (source `24534a6a`)**, RX 6600, Vulkan driver `0x800161`, Windows 11. The game successfully reached Hyrule and remained generally playable. Some textures appeared as bright white halos, and FPS were relatively low, but there was little noticeable stuttering. However, the application permanently froze when opening the **quick item selection menu** (Deku Stick / Slingshot / Deku Nut). This is not limited to that interface. Previous runs froze when opening the main inventory, while another run successfully opened the inventory several times before freezing on a later attempt. The issue is therefore intermittent. **Windows observations during the freeze:** - GPU 3D utilization drops to approximately 0%. - Dedicated VRAM usage remains near its previous high level. - CPU and system RAM usage remain stable and consistent with normal activity. - GPU fans slow down or stop a few seconds after the freeze. - Windows Reliability Monitor (`perfmon /rel`) shows no corresponding hardware failure, LiveKernelEvent or graphics-driver recovery. **Log observations:** - `RX_VK_CHECKPOINTS=1` was enabled. - No `VK_ERROR_DEVICE_LOST` is reported. - No useful AMD checkpoint failure diagnosis is emitted. - The renderer was still producing frames before the freeze, with the workload dropping significantly during the menu transition. - The process remains alive, and the log eventually ends with the window being closed. This suggests that the freeze is not necessarily caused by sustained GPU rendering load or VRAM budget exhaustion alone. Since multiple menu interfaces can trigger a similar silent freeze, a shared rendering transition or synchronization path may be worth investigating. This may be related to the existing AMD freeze tracker **#996** and earlier RX 6600 menu reports **#749** and **#872**. **Attached:** `hookshot_log(10).txt` — RX 6600, v2.0.8, permanent freeze after opening quick item selection. [hookshot_log(10).txt](https://github.com/user-attachments/files/34589937/hookshot_log.10.txt)

notreallyfreddie76-arch commented

2026-11-09 18:30:43 +00:00

(Migrated from github.com)

v2.0.8 follow-up — RX 6600: `VK_ERROR_DEVICE_LOST` during Lon Lon Ranch introduction

Another test on Hookshot v2.0.8 (source 24534a6a), using the same RX 6600 system and Vulkan driver 0x800161.

What happened

This session was significantly more stable than previous runs:

Successfully reached Hyrule and continued playing without freezes when opening menus.
Performance was generally acceptable, although FPS remained relatively low in some areas.
No major recurring stuttering was noticeable.
Some rendering artifacts persisted, particularly textures or surfaces appearing as extremely bright white halos.

However, the game crashed during the Lon Lon Ranch introduction cutscene.

Unlike previous silent freezes, this time Hookshot explicitly reported VK_ERROR_DEVICE_LOST (-4).

AMD buffer markers — useful diagnostic information

RX_VK_CHECKPOINTS=1 was enabled, and this time the log successfully captured GPU execution markers.

The device loss occurred at Vulkan submission 576805, around frame 82393.

Relevant log excerpt:

vk: submit 576805 failed (-4) vk: device lost: reading the buffer markers vk: device lost: 90738865 markers set, 62326 reached; the last whose earlier work all finished: 90735651 vk: finished before: marker 90735649 (draw of program b069ca31d98f98f8, frame 82393) vk: finished before: marker 90735650 (dispatch of program 499dbfd0721d2858, frame 82393) vk: RUNNING after: marker 90735651 (draw of program c5d860e370525466, frame 82393) vk: running: marker 90735652 (draw of program 84b96ce39f90a7dc, frame 82393)

vk: reached, earlier work unfinished: marker 90735652 (draw of program 84b96ce39f90a7dc, frame 82393)

The first draw not confirmed as completed is associated with program c5d860e370525466, at marker 90735651.

This is a useful investigation point, but does not establish that the program itself caused the GPU hang. The fault could also involve a resource dependency, synchronization issue or preceding GPU operation.

Rendering statistics immediately before device loss

The last periodic rendering sample reported:

Metric	Value
Presented frames	82,320
FPS	25.0
Draw calls per frame	3,753
Compute dispatches per frame	204
Render passes per frame	181
GPU time per frame	24.7 ms
Replay time	32.72 ms
Shader/pipeline wait	0.0 ms
Draws left out (not ready)	54.7
VRAM usage (latest memory sample)	6,667 / 6,806 MB

The GPU was handling a relatively heavy rendering workload before the crash.

VRAM usage was close to the reported budget, but the sampled memory usage did not reach the budget ceiling. Memory pressure may still contribute, but budget exhaustion alone cannot be established as the cause.

After the device loss, additional Vulkan submissions and graphics pipeline creations failed with -4, as expected.

Comparison with previous RX 6600 freezes

Previous v2.0.7 and v2.0.8 sessions showed intermittent permanent freezes when opening either:

The main inventory.
The quick item-selection menu (Deku Stick / Slingshot / Deku Nut).

Those freezes had a different observable signature:

No VK_ERROR_DEVICE_LOST in the logs.
GPU 3D utilization dropped to approximately 0%.
VRAM remained heavily allocated.
CPU and RAM usage stayed stable.
No corresponding Windows Reliability Monitor error or graphics-driver recovery was recorded.
The application remained running but stopped rendering.

The Lon Lon Ranch crash is different: it occurred during a relatively demanding cutscene and produced a confirmed device loss with usable AMD buffer markers.

These may be related issues, but the available evidence does not establish a common root cause.

Attached log

hookshot_log(20261109-182413).txt

This log contains the complete RX 6600 session, including the device-loss report and AMD execution markers near the end.

Related tracker: #996.

The v2.0.8 texture-memory improvements appear beneficial overall, but intermittent silent freezes and confirmed AMD Vulkan device losses are both still occurring.

</html> </html>

hookshot_log(20261109-182413).txt

<html> <body> <html><head></head><body><h2>v2.0.8 follow-up — RX 6600: <code>VK_ERROR_DEVICE_LOST</code> during Lon Lon Ranch introduction</h2>Another test on Hookshot v2.0.8 (source <code>24534a6a</code>), using the same RX 6600 system and Vulkan driver <code>0x800161</code>.<h3>What happened</h3>This session was significantly more stable than previous runs:<ul><li>Successfully reached Hyrule and continued playing without freezes when opening menus.</li><li>Performance was generally acceptable, although FPS remained relatively low in some areas.</li><li>No major recurring stuttering was noticeable.</li><li>Some rendering artifacts persisted, particularly textures or surfaces appearing as extremely bright white halos.</li></ul>However, the game crashed during the Lon Lon Ranch introduction cutscene.Unlike previous silent freezes, this time Hookshot explicitly reported <code>VK_ERROR_DEVICE_LOST</code> (-4).<h3>AMD buffer markers — useful diagnostic information</h3><code>RX_VK_CHECKPOINTS=1</code> was enabled, and this time the log successfully captured GPU execution markers.The device loss occurred at Vulkan submission <code>576805</code>, around frame 82393.Relevant log excerpt:<pre><code>vk: submit 576805 failed (-4) vk: device lost: reading the buffer markers vk: device lost: 90738865 markers set, 62326 reached; the last whose earlier work all finished: 90735651 vk: finished before: marker 90735649 (draw of program b069ca31d98f98f8, frame 82393) vk: finished before: marker 90735650 (dispatch of program 499dbfd0721d2858, frame 82393) vk: RUNNING after: marker 90735651 (draw of program c5d860e370525466, frame 82393) vk: running: marker 90735652 (draw of program 84b96ce39f90a7dc, frame 82393) vk: reached, earlier work unfinished: marker 90735652 (draw of program 84b96ce39f90a7dc, frame 82393)</code></pre>The first draw not confirmed as completed is associated with program <code>c5d860e370525466</code>, at marker <code>90735651</code>.This is a useful investigation point, but does not establish that the program itself caused the GPU hang. The fault could also involve a resource dependency, synchronization issue or preceding GPU operation.<h3>Rendering statistics immediately before device loss</h3>The last periodic rendering sample reported: Metric | Value -- | -- Presented frames | 82,320 FPS | 25.0 Draw calls per frame | 3,753 Compute dispatches per frame | 204 Render passes per frame | 181 GPU time per frame | 24.7 ms Replay time | 32.72 ms Shader/pipeline wait | 0.0 ms Draws left out (not ready) | 54.7 VRAM usage (latest memory sample) | 6,667 / 6,806 MB The GPU was handling a relatively heavy rendering workload before the crash.VRAM usage was close to the reported budget, but the sampled memory usage did not reach the budget ceiling. Memory pressure may still contribute, but budget exhaustion alone cannot be established as the cause.After the device loss, additional Vulkan submissions and graphics pipeline creations failed with <code>-4</code>, as expected.<h3>Comparison with previous RX 6600 freezes</h3>Previous v2.0.7 and v2.0.8 sessions showed intermittent permanent freezes when opening either:<ul><li>The main inventory.</li><li>The quick item-selection menu (Deku Stick / Slingshot / Deku Nut).</li></ul>Those freezes had a different observable signature:<ul><li>No <code>VK_ERROR_DEVICE_LOST</code> in the logs.</li><li>GPU 3D utilization dropped to approximately 0%.</li><li>VRAM remained heavily allocated.</li><li>CPU and RAM usage stayed stable.</li><li>No corresponding Windows Reliability Monitor error or graphics-driver recovery was recorded.</li><li>The application remained running but stopped rendering.</li></ul>The Lon Lon Ranch crash is different: it occurred during a relatively demanding cutscene and produced a confirmed device loss with usable AMD buffer markers.These may be related issues, but the available evidence does not establish a common root cause.<h3>Attached log</h3><code>hookshot_log(20261109-182413).txt</code>This log contains the complete RX 6600 session, including the device-loss report and AMD execution markers near the end.Related tracker: #996.The v2.0.8 texture-memory improvements appear beneficial overall, but intermittent silent freezes and confirmed AMD Vulkan device losses are both still occurring.</body></html> </body> </html> [hookshot_log(20261109-182413).txt](https://github.com/user-attachments/files/34592996/hookshot_log.20261109-182413.txt)

NotRexed commented

2026-11-09 22:50:37 +00:00

(Migrated from github.com)

Thanks for the report. To keep each problem in one place, this is tracked in #995 (low FPS and stutter), which links your details. Closing this as a duplicate; please follow #995 for updates.

Commenting is not possible because the repository is archived.