Intel GPU Issues

GPU: Intel arc b580
CPU: Ryzen 7 5700X3D
RAM: 32GB ddr4

Game renders fine when opening until the point where the title screen flashes. I am still able to start at new game and hear the audio for the intro cut-scene, but I believe after as soon as the game tries to render the in-game graphics, I get a complete Hookshot crash.

I looked for a looked for a log or a crash report in the file structure but couldn't find any. If there is one and I missed it gladly share it here.

I also tried importing my save from lichii which worked just fine, but I had the same issue. As soon as the game loads the save and tries to render the in-game graphics, Hookshot crashes.

GPU: Intel arc b580 CPU: Ryzen 7 5700X3D RAM: 32GB ddr4

Game renders fine when opening until the point where the title screen flashes. I am still able to start at new game and hear the audio for the intro cut-scene, but I believe after as soon as the game tries to render the in-game graphics, I get a complete Hookshot crash.

I looked for a looked for a log or a crash report in the file structure but couldn't find any. If there is one and I missed it gladly share it here.

I also tried importing my save from lichii which worked just fine, but I had the same issue. As soon as the game loads the save and tries to render the in-game graphics, Hookshot crashes.

Hey man! I saw you were talking about the Intel Arc support for the port. I actually opened an issue on GitHub about my case and one of the main collaborators replied to me. He basically said he’d love to add support but doesn't have an Intel Arc GPU on hand to test the code, so he needs someone from the community to open a PR.

Since you're into this kind of stuff, I wanted to reach out and see if you’d be interested in helping out or if you know how to tinker with the code to get Intel Arc support working. It would be awesome! Here's the link to my post if you want to check out what the dev said:

#165

GPU: Intel arc b580 CPU: Ryzen 7 5700X3D RAM: 32GB ddr4
Game renders fine when opening until the point where the title screen flashes. I am still able to start at new game and hear the audio for the intro cut-scene, but I believe after as soon as the game tries to render the in-game graphics, I get a complete Hookshot crash.
I looked for a looked for a log or a crash report in the file structure but couldn't find any. If there is one and I missed it gladly share it here.
I also tried importing my save from lichii which worked just fine, but I had the same issue. As soon as the game loads the save and tries to render the in-game graphics, Hookshot crashes.

Hey man! I saw you were talking about the Intel Arc support for the port. I actually opened an issue on GitHub about my case and one of the main collaborators replied to me. He basically said he’d love to add support but doesn't have an Intel Arc GPU on hand to test the code, so he needs someone from the community to open a PR.

Since you're into this kind of stuff, I wanted to reach out and see if you’d be interested in helping out or if you know how to tinker with the code to get Intel Arc support working. It would be awesome! Here's the link to my post if you want to check out what the dev said:

#165

Yo thanks for reaching out,

I'm actually fairly new to github and don't have much coding knowledge. I'd definitely want to help but I'm not sure exactly how to do so outside of testing and sending diagnostic logs if possible. I'll check your post out though, maybe I can be of some help!

Okay so I actually got the game to load past the initial cut-scene on the latest build, but game rendering still freezes as soon as the menus/title screen is meant to appear on the screen:

I am able to hear the kokiri forest theme, hear the waterfall in the background, control green hat kid, and open menus but game isn't rendering. I can even tell shader compilation is taking place due to stuttery gameplay which mirrors what i expereinced on my lichii testing yesterday.

Here is the log for the few tests I've done:
hookshot_log.txt

I installed the latest version and now Zelda actually works on an Intel Arc card. It only has issues like flickering and sometimes the background goes black, but then it goes back to normal. It no longer freezes or closes on its own. I'll share the hookshot_log.txt file in case it could help you fix those small problems :D

hookshot_log.txt

A few minutes ago I mentioned that the beginning and the introduction where the story is told were already working, but then almost at the end of that story cutscene the game completely freezes like before on the start screen. I'll attach the log file here, but I'm not really sure if anything changed compared to the previous one.

hookshot_log.txt

Intel Arc B390 (Core Ultra X7 358H laptop iGPU, Vulkan 1.4, driver 0x1962a0), Windows 11, build from foliage-linux-updater.

Findings from a day of testing on this GPU. Each was checked with frame dumps and RX_VK_DRAW_STATS, using the switches already in the renderer. Small patches below in case they help.

1. Hang after the intro movie (the "freeze" others report in this issue)
With robust buffer access on, a compare-exchange loop (CasLoop, e.g. StorageAtomicAddF32 in compute 435a0138b9013040) whose word is out of bounds never sees the value it expects, so the dispatch never ends. Intel does not lose the device, so the frame just never comes back. Bounding the loop (64 tries, a counter in a Function variable, done = success || tries >= 64) removed the hang in every run here.

2. Holes in the ground: colour passes that test EQUAL
The colour draws after the depth prepass (43ec86f35fd937b9 after 8a8304edb7bdf4bf, 6b4dea… after e28434…, 68642b… after cb71f7…) use dop2 (EQUAL) against depth written by a different program. Intel's compiler does not give the two programs identical positions, so most ground pixels fail the test: about 550k fragments for the colour pass against 1.8M for the depth one, and the sky shows through. Turning EQUAL into LESS_OR_EQUAL with a small depth bias towards the camera (−64 units, only when depth test is on, depth write off and the op is EQUAL) brought the ground back: dirt path, moss, shadows.

// vk_draw.cpp, dynamic_state(), after d.dop = compare_op(s.ds.df):
if (eq_bias > 0 && d.dt && !d.dw && d.dop == VK_COMPARE_OP_EQUAL) {
    d.dop = VK_COMPARE_OP_LESS_OR_EQUAL;
    d.bias_en = VK_TRUE;
    d.bias[0] = -eq_bias, d.bias[1] = 0.0f, d.bias[2] = 0.0f;
}

3. Indirect mesh draws
On Intel, RX_VK_MESH_ARGS=1 is needed: without it many world mesh draws get 0 groups. With it, 19 of 41 indirect mesh draws have work in the forest.

4. Still broken: white haze over Kokiri
Dumps show the scene correct up to c9ac7b6561a6203e (mean 0.48 0.31 0.10). The composite 1a7482c0ec9991ea (fog and half-resolution layers) then makes it 1.43 1.54 0.93: white-green haze, white water. Leaving that draw out (RX_VK_SKIP_FILE) removes the haze, but also the fog and the water.
Likely cause: the sun inscatter volume from ee7764a6b1ef459c is perfectly uniform (1.48–1.50 everywhere), so nothing shades the air. The 1600x1600 shadow map holds little geometry, and the shadow casters' indirect args are zero (ccf4f709e0deeac1, 22063ecfa481a731, 6b7f79e2ff3a2746, 50f7cddcf3bb96bd, written by cb2e06ddfb9d7d27 / 102f5b0abb0f1e63). RX_VK_DRAW_STATS lists "second-level pointers no binding covers" for cb2e06…, 44511d…, 6344c5… and 7650519…, all pointing at 0x1100000010.

5. Other

Occasional device loss on entering the forest: 2 in about 20 runs, in compute 3e6fe279463b020e or 499dbfd0721d2858.
Water draws as flat white, flashes of bright blobs, some white untextured props.

6. Menus and dialogue (videos below)

Two videos are attached: gameplay in Kokiri (with 1a7482c0ec9991ea left out through RX_VK_SKIP_FILE, RX_VK_MESH_ARGS=1), and the menus with what is left on screen after closing them.
The videos have no sound only because of the recording. In game, sound works fine.
When talking to someone, the dialogue box and its choices only show while Navi is the one speaking. With any other character, nothing is displayed.

I can test builds or switches on this GPU and send logs or dumps.

hookshot_log.txt
https://youtu.be/3iR5ipzBej0
https://youtu.be/Sc9DmmgvaOw

Thank you, this is very detailed and useful. A pull request with the bounded CasLoop and the EQUAL-depth change would be very welcome, so they can be tried on other GPUs as well.

@fuxau

Another data point for the Arc B390 / Core Ultra X7 358H (same chip as @fuxau's report above), but on Linux with Mesa ANV instead of Windows.

System

CPU/GPU: Intel Core Ultra X7 358H, Arc B390 iGPU (Panther Lake), 30 GB RAM
Driver: Mesa 26.2.5 (vulkan-intel)
OS: Arch-based (Omarchy), kernel 7.2.15, Hyprland 0.56.2 (Wayland)
Hookshot: no-visual-studio, built with Hookshot-no-visual-studio-x86_64.AppImage
No hookshot_env.txt (all default settings)

Works

The AppImage build finished without problems and the game starts
Switch Pro Controller over USB (kernel hid_nintendo) works with no setup
Intro movie, the Great Deku Tree scene, Link's house and walking outside in Kokiri Forest
Frame rate is very good when nothing new has to be compiled
After the pause entering Link's house, Link and the scene outside render correctly (no white haze or missing ground that I noticed)

Issues

Long black screen after the intro movie (over a minute) on the first run. It is not hung: 1 to 4 mkw_vk worker threads stay busy, the main thread is idle, the Mesa shader cache (~/.cache/mesa_shader_cache) keeps growing, and Kokiri Forest's ambient sounds are already open. It looks like first-run pipeline compilation is very slow on this iGPU. It recovered on its own, unlike the CasLoop hang above.
Frequent freezes during the Deku Tree scene, likely the same thing.
Another long freeze after Navi flies to Link's house. All 4 workers at 100% CPU, shader cache growing. It recovered after several minutes.
Link rendered completely white/untextured (just the outline, like a ghost) during the cutscene before that freeze. He looked correct once the compile finished, so this may be a draw that ran before its pipeline or textures were ready.
Bad flashing outside Link's house once it was playable; the picture looks glitchy while it happens.

I have not tried RX_VK_MESH_ARGS=1 or the other switches yet. I'm happy to test them, or builds, on this GPU under Linux and send logs.

Data point for Iris Xe on Linux (Mesa ANV), not Windows. The game runs and the intro movie plays at 57-60 fps, but the 3D scene never appears after it: the first mesh draw (frame 11154) has no program, because Gen12.2 has no VK_EXT_mesh_shader, and 1286 of the game's 14179 programs use the task or mesh stages (1155 with stages 1/6/7, 131 with 1/7).

Everything else on this card looks healthy: 14179 programs prepared in 55.5 s, 21718 translated, the only 10 failures are a network left out on this card (the upscaler networks on the linear path, expected without VK_KHR_cooperative_matrix), 2596 of 17695 MB of VRAM used, 5-7 ms of GPU time a frame.

Device line and the filtered log are in #454: #454

Follow-up on the Arc B390 (Core Ultra X7 358H iGPU), Windows 11, driver 0x1962a0. This is a regression in main since foliage-linux-updater; it is not about #548.

Device lost when entering Kokiri Forest after the intro movie. The window stays black while the sound and the HUD go on. The log shows submit … failed (-4), and the checkpoints name a different program almost every time: draw 999fd641ba1fc2b0 most often, also 55fc7e951c87de74. It always happens around frame 2600-2700, as the forest first appears. With RX_VK_SKIP_PROG=999fd641ba1fc2b0, the next draw faults instead, so it looks like memory rather than one shader.

Runs, same scripted start, each about 4 min:

Engine	Switches	Device lost entering the forest
`main` at `3d6a388` (no local changes)	none	yes
`main` at `53af338` (no local changes)	none	yes
`3d6a388` + #548 + local changes	none, my own fixes switched off, or no `hookshot_env.txt`	yes, 3 of 3
same	`RX_VK_MESH_NO_ZERO=1`	yes
same	`RX_VK_COMPUTE_WAIT=1`	yes
same	`RX_VK_EVICT_NO_FLUSH=1 RX_VK_NO_RB_REFRESH=1 RX_VK_RELEASE_DRAIN=1`	yes
same	`RX_VK_KEEP_RETIRED=1`	no in 4 of 5 runs (~55 fps in the forest)

So the retired pools given back early (f2203e4, "give back retired pools' imports once the GPU is past them") seem to free memory the GPU still reads on Intel. The one failing run with RX_VK_KEEP_RETIRED=1 faulted in compute 4b03b3040d7cf076. That one, and 499dbfd0721d2858, already faulted now and then on foliage-linux-updater, so they look like a separate, older problem.

VK_EXT_device_fault is not available on this driver (RX_VK_FAULT_INFO=1 says so), so I have no faulting address. I can run a build with more logging around the give-back if that helps.

Release https://github.com/NotRexed/Hookshot/releases/tag/fast-updates no longer gives back memory the GPU used, on Windows (it was meant for a Linux AMD driver; fuxau traced the Arc device lost to it in #17, and the AMD logs show device lost right after it). If you had device lost, could you try this release and tell us? On Linux/Steam Deck the old behaviour stays; there, please try RX_VK_KEEP_RETIRED=1 and say whether the device lost goes away.

hookshot_log.txt

Not sure if I did this right but here are my logs for v2.02 heavy stutter and crashed
Arc140v

Posting my latest logs from the past few builds. Hope this helps. Can still load into the game and hear game audio, but game is completely black

hookshot_log.txt

hookshot_log.1.txt

hookshot_log.2.txt

GPU: Intel arc b580
CPU: Ryzen 7 5700X3D
RAM: 32GB ddr4

hookshot_log.txt
hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.3.txt

Game is very stuttery and flickers constantly, we need a LOD mod that can make the models lower quality with the textures still keeping a resolution, we need an actual graphics editor and when it lowers the resolution it should actually lower it because i see that its still rendering at 2k but scaling it down, it should lower the actual viewport resolution which should i.e make it perform better

Intel Arc 140V (Lunar Lake iGPU) — device lost in the Deku Tree intro + washed-out lighting

Hardware / software

Lenovo Yoga Slim 7 15ILL9 — Intel Core Ultra 7 258V, Intel Arc 140V (16GB shared), 32 GB RAM
Windows 11, Intel driver 32.0.101.9150 (latest; log reports 0x1963be)
Hookshot 2.0.5 (source cd9cebb6), clean build via HookshotBuilder; also tested 2.0.4 (63bbb535)
Game: own dump, update v131072
No hookshot_env.txt (stock defaults: robust buffers on, subgroups pinned to 32 on 0xe0)
Options: Quality preset Minimum (4GB) — resolution 50%, Lanczos, sharpness 50, handheld profile on, frame pacing on, game speed real time

1. Device lost (intermittent) in the Deku Tree intro cutscene
Three runs through the same cutscene: two completed (2.0.4 and 2.0.5, frame generation 2x), one crashed (2.0.5, frame generation off). After the crash the music keeps playing over a black screen; the game must be closed.

Checkpoints from the crash:

vk: submit 82203 failed (-4)
vk: device lost: 2 checkpoints (82245 markers set)
vk: stage 0x1: marker 81036 (dispatch of program 4b03b3040d7cf076, frame 11742)
vk: stage 0x2000: marker 81035 (dispatch of program ab7699ee7f536755, frame 11742)

The same compute program (4b03b3040d7cf076) also lost the device at this spot on an earlier build (2.0.1). On that build, RX_VK_NO_SUBGROUP_PIN=1 avoided the crash but produced garbage/washed-out output and a hang, so I'm running with the default pin.

2. Washed-out / over-bright lighting
Forest and Deku Tree scenes render as a white/over-exposed haze on both 2.0.4 and 2.0.5. The log reports 175 failed programs on 2.0.5.

3. Performance in the cutscene (for reference)
2.0.5's pipeline prediction fixed the shader stutter: 334 pipelines in 284 ms total, vs about 190 s of runtime pipeline compiles on 2.0.4. The cutscene still runs at 9–38 fps, with the game thread waiting on the GPU most of the time (nvn: GPU waits in 5 s: 54 sync waits (4509 ms)), and replay at about 12–19 ms/frame.

hookshot_log.txt

Intel Arc 130V (Lunar Lake iGPU): black screen after the intro cutscene, audio keeps playing (Hookshot 2.0.5)

System

CPU: Intel Core Ultra 5 236V
GPU: Intel Arc 130V (integrated, no dedicated VRAM; Task Manager shows 8GB, which is the share of system memory Windows allows the GPU to use), Latest Graphics Drivers
RAM: 16GB LPDDR5X (on-package, shared with the GPU)
OS: Windows 11
Hookshot 2.0.5

What happens
I start a new game. Cutscene plays until the part where it's meant to show the great deku tree. After that the screen goes black while the audio continues. I heard audio up until the point where green hat kid gets up and you're meant to move around.

hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.3.txt
hookshot_log.4.txt
hookshot_log.txt

Intel Arc A750 (Alchemist, Windows): extremely slow shader/pipeline compiles → endless black screen after intro

Adding an A750 data point, since nobody in this thread has reported Alchemist yet.

System

GPU: Intel Arc A750 (Alchemist, 8 GB)
Driver: 32.0.101.9150 (log reports 0x1963be), Vulkan 1.4.359
CPU: Ryzen 5 7500F (6C/12T), 16 GB RAM
OS: Windows 11 (build 26300)
Hookshot v2.0.5 (source cd9cebb6)
vulkaninfo: VK_EXT_mesh_shader present, meshShader = true, taskShader = true

From the log header:

vk: Intel(R) Arc(TM) A750 Graphics, Vulkan 1.4, driver 0x1963be; mesh shaders yes, host memory import yes, pipeline libraries yes
vk: subgroups: default 32 lanes, 8-32, pinned to 32 on stages 0xe0
vk: matrix multiplies in software (the cooperative matrices lack 16x8x16 f16)

1. First-start shader preparation: ~1 program per second

"Preparing shaders: X of 116427" advanced at roughly 1 per second (hookshot.exe using ~6 of 12 CPU threads, so it was working, not stuck). That works out to ~30+ hours for the full preparation. After ~15 minutes, hookshot_programs.bin was still 0 bytes, so it looked like nothing was saved along the way.

(116,427 also looks a lot higher than the ~32-40k programs other people report. Not sure if that's expected.)

2. With `RX_VK_PRECOMPILE=0`: title + intro movie fine, then black screen

hookshot_env.txt:

RX_VK_PRECOMPILE=0
RX_VK_MESH_ARGS=1

The title screen and intro movie render fine at 60 fps.
Once the 3D scene starts, the screen goes black and stays black. The process is still alive (no device lost, no crash) and the log keeps growing, but the periodic presents, … fps lines stop.
Pipeline compiles on the Intel Windows driver are extremely slow:

vk: compute pipeline of a54f19e927d8faef: SLOW compile, 67126 ms (on a worker)
vk: compute pipeline of 3e6fe279463b020e: SLOW compile, 14662 ms (on a worker)

Submits block for many seconds while it compiles:

vk: slow submit: 23585.6 ms: draw 23482.6 descriptors 655.7 texture lookups 489.6 uploads 90.4 pipelines 4.7 programs 11.1 commands 55.4 dispatch 57.8
vk: slow submit: 8027.0 ms: draw 7861.2 descriptors 109.8 texture lookups 48.3 uploads 45.3 pipelines 3.7 programs 5.0 commands 57.0 dispatch 153.8

Other things that may be relevant:

vk: … 16 programs (10 failed) …            (already at the title / intro stage)
vk: view of texture 0x1133ccb000 (vk 139) as vk 95 type 1 levels 0+1 layers 0..15+1 not made
vk: storage buffer NOT bound (reads zeros): program 68642bb810ee3e7c stage 7 …   (5 times)

3. Then it crashed inside the Intel Vulkan driver (~7 min in)

Shortly before the crash it was actually rendering the 3D scene (925 draws/frame), but at 0.5 fps, with 385 pipelines having taken 430 s in total:

vk: 11040 presents, 0.5 fps; a frame: 925 draws (0 skipped), 96 dispatches, 120 passes, … 385 pipelines (430891 ms), 341 programs (11 failed), 666 textures (2425 MB)
vk: a frame: 40.1 draws left out (not ready), 3.42 waits for shaders or pipelines (1998.8 ms); translation 2424 ms in all, 14 jobs queued

Then an access violation in igvk64.dll, on what looks like a worker thread (thread entry via ucrtbase, not the presentation thread):

CRASH: exception 0xc0000005 (read 0x190, guest 0xfffff00000000190) at igvk64.dll+0x79ddf3
CRASH: host backtrace: igvk64.dll+0x79ddf3 igvk64.dll+0x7a3661 igvk64.dll+0x6f8938 igvk64.dll+0x39f02b igvk64.dll+0x39ee30 hookshot_vk.dll+0x13d7c3 hookshot_vk.dll+0x148fc9 ucrtbase.dll+0x2cd30 KERNEL32.DLL+0x2dda7 ntdll.dll+0x7ee4c

Windows Error Reporting: APPCRASH, faulting module igvk64.dll 32.0.101.9150, offset 0x79ddf3. The address it reads (0x190) looks like a null pointer plus an offset, so possibly a driver bug in pipeline creation on a background compile thread. On the plus side, hookshot_programs.bin (41 MB) and hookshot_pipelines.bin (8.9 MB) were saved before the crash.

Summary

On Alchemist + Windows the main problem isn't device loss (none seen). Single compute pipelines take 15-67 s to compile on this driver, so both the precompile (~1/s) and on-the-fly compiling (multi-second submits → black screen) are effectively unusable. On top of that, the driver eventually segfaults (igvk64.dll+0x79ddf3), apparently while creating a pipeline. The bounded CasLoop / EQUAL-depth fixes discussed above probably won't help here. Preparing shaders at build time (#819), a persistent per-program cache saved as it goes, or skipping draws asynchronously instead of blocking the submit would probably help most.

Full log attached. Happy to test builds or env switches on this card.

hookshot_log.txt

Tracked in #999, follow there. That issue collects every report of Intel Arc / Core Ultra device lost, black screens and Linux ANV crashes, and this one is linked from it with its GPU, version and log details. The tracker carries over the Intel findings from this issue. 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.

Navigation Menu

Repository navigation

Intel GPU Issues #17

Intel Arc 140V (Lunar Lake iGPU) — device lost in the Deku Tree intro + washed-out lighting

Intel Arc A750 (Alchemist, Windows): extremely slow shader/pipeline compiles → endless black screen after intro

1. First-start shader preparation: ~1 program per second

2. With `RX_VK_PRECOMPILE=0`: title + intro movie fine, then black screen

3. Then it crashed inside the Intel Vulkan driver (~7 min in)

Summary

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Intel GPU Issues #17

Description

Activity

ArcaPhria commented on Nov 7, 2026

4pascal commented on Nov 7, 2026

4pascal commented on Nov 7, 2026

leosantizogo commented on Nov 7, 2026

leosantizogo commented on Nov 7, 2026

fuxau commented on Nov 7, 2026

NotRexed commented on Nov 7, 2026

felipecsl commented on Nov 8, 2026

zhiying-326 commented on Nov 8, 2026

fuxau commented on Nov 8, 2026

NotRexed commented on Nov 8, 2026

hontalasbranden-prog commented on Nov 8, 2026

4pascal commented on Nov 8, 2026

X360Z commented on Nov 8, 2026

motorcropmoon commented on Nov 9, 2026

Intel Arc 140V (Lunar Lake iGPU) — device lost in the Deku Tree intro + washed-out lighting

m3wiscool commented on Nov 9, 2026

NaylemMusic commented on Nov 9, 2026

Intel Arc A750 (Alchemist, Windows): extremely slow shader/pipeline compiles → endless black screen after intro

1. First-start shader preparation: ~1 program per second

2. With RX_VK_PRECOMPILE=0: title + intro movie fine, then black screen

3. Then it crashed inside the Intel Vulkan driver (~7 min in)

Summary

NotRexed commented on Nov 9, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

2. With `RX_VK_PRECOMPILE=0`: title + intro movie fine, then black screen