Windows ARM64 / NVIDIA RTX Spark N1X: Gameplay at 3–4 FPS — Vulkan dispatch barriers and 250 ms memory sync stalls #2392

Closed

opened 2026-11-11 17:05:46 +00:00 by 3mbrava · 1 comment

3mbrava commented

2026-11-11 17:05:46 +00:00

(Migrated from github.com)

Hookshot version

v2.1.0 (source 633eb435)

What kind of problem

Low fps or stutter

What happened

Hookshot starts normally and menus, videos and lightweight scenes run at approximately 60 FPS. However, actual 3D gameplay consistently drops to around 3–4 FPS, making the game unplayable.

This has been reproduced across multiple launches, including a clean test after stopping other GPU-intensive local AI workloads. Reducing graphics settings does not meaningfully improve performance. The problem persists with shader caches already populated; it is not a first-run shader-compilation stutter.

I collected multiple logs and used RX_VK_PASS_TIMING=1 to investigate.

Findings from the latest log:

Gameplay: 3.4–4.3 FPS.

GPU execution: approximately 228–266 ms per frame.

CPU-side Vulkan memory synchronization: approximately 202–233 ms per frame.

Repeated a capture's wait for write-back ... timed out messages, with synchronization waits around 250–256 ms.

During a 600-present profiling interval containing slow gameplay and faster scenes, 89% of measured GPU time was attributed to barriers.

The largest profiled operation was barrier (dispatch), averaging 82.45 ms per frame across that interval.

Graphics passes accounted for only 5.8% of measured GPU time during the same interval.

No shader or pipeline waits were reported during the slow gameplay samples.

The Vulkan renderer correctly detects the native NVIDIA GPU. Texture usage is within the configured budget.

I also tested increasing the Vulkan texture budget to 24 GB and the documented mesh-culling workaround. Neither improved gameplay performance.

The main question is whether this is caused by Vulkan compute-dispatch synchronization, GPU write-back handling, or an NVIDIA Windows ARM64 driver compatibility issue. The profiler identifies where time is being charged, but doesn't establish whether the barriers themselves or preceding GPU work are responsible.

I found related reports in #995 and #1400, but neither appears to describe the same hardware and synchronization pattern.

Expected: Playable gameplay at a reasonable frame rate rather than persistent 3–4 FPS.

Where in the game

Kokiri forest

How often

Every time

Graphics card and driver version

NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU). NVIDIA Vulkan 1.4 driver reports 0x9b438000, corresponding to driver version 621.14. Native NVIDIA Vulkan device selected, not the Microsoft Direct3D12 Vulkan device.

CPU, RAM and operating system

CPU/platform: NVIDIA N1X ARM64 RAM: 128 GB unified memory OS: Windows 11 ARM64 Device: ASUS ProArt P16

Changes from the defaults

The latest diagnostic log had these environment settings active:

RX_VK_VRAM_MB=24576
RX_VK_PASS_TIMING=1

Earlier experiments included:

RX_VK_MESH_NOCULL=2c56dc1006942f74
RX_VK_FRAMEGEN=0

Other software hooked into the game

No, nothing hooked in

hookshot_log.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.1.0 (source 633eb435) ### What kind of problem Low fps or stutter ### What happened Hookshot starts normally and menus, videos and lightweight scenes run at approximately 60 FPS. However, actual 3D gameplay consistently drops to around 3–4 FPS, making the game unplayable. This has been reproduced across multiple launches, including a clean test after stopping other GPU-intensive local AI workloads. Reducing graphics settings does not meaningfully improve performance. The problem persists with shader caches already populated; it is not a first-run shader-compilation stutter. I collected multiple logs and used RX_VK_PASS_TIMING=1 to investigate. Findings from the latest log: Gameplay: 3.4–4.3 FPS. GPU execution: approximately 228–266 ms per frame. CPU-side Vulkan memory synchronization: approximately 202–233 ms per frame. Repeated a capture's wait for write-back ... timed out messages, with synchronization waits around 250–256 ms. During a 600-present profiling interval containing slow gameplay and faster scenes, 89% of measured GPU time was attributed to barriers. The largest profiled operation was barrier (dispatch), averaging 82.45 ms per frame across that interval. Graphics passes accounted for only 5.8% of measured GPU time during the same interval. No shader or pipeline waits were reported during the slow gameplay samples. The Vulkan renderer correctly detects the native NVIDIA GPU. Texture usage is within the configured budget. I also tested increasing the Vulkan texture budget to 24 GB and the documented mesh-culling workaround. Neither improved gameplay performance. The main question is whether this is caused by Vulkan compute-dispatch synchronization, GPU write-back handling, or an NVIDIA Windows ARM64 driver compatibility issue. The profiler identifies where time is being charged, but doesn't establish whether the barriers themselves or preceding GPU work are responsible. I found related reports in #995 and #1400, but neither appears to describe the same hardware and synchronization pattern. Expected: Playable gameplay at a reasonable frame rate rather than persistent 3–4 FPS. ### Where in the game Kokiri forest ### How often Every time ### Graphics card and driver version NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU). NVIDIA Vulkan 1.4 driver reports 0x9b438000, corresponding to driver version 621.14. Native NVIDIA Vulkan device selected, not the Microsoft Direct3D12 Vulkan device. ### CPU, RAM and operating system CPU/platform: NVIDIA N1X ARM64 RAM: 128 GB unified memory OS: Windows 11 ARM64 Device: ASUS ProArt P16 ### Changes from the defaults The latest diagnostic log had these environment settings active: RX_VK_VRAM_MB=24576 RX_VK_PASS_TIMING=1 Earlier experiments included: RX_VK_MESH_NOCULL=2c56dc1006942f74 RX_VK_FRAMEGEN=0 ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [hookshot_log.txt](https://github.com/user-attachments/files/34698225/hookshot_log.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-11 21:29:44 +00:00

(Migrated from github.com)

Thanks for the report. Reports of the same problem are now collected in #1007, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #1007 for the fix, and add new details there (or here). If this turns out to be a separate problem it will be reopened.

Commenting is not possible because the repository is archived.