Intel GPU Issues #17
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
2 participants
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot#17
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.StorageAtomicAddF32in compute435a0138b9013040) 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 (
43ec86f35fd937b9after8a8304edb7bdf4bf,6b4dea…aftere28434…,68642b…aftercb71f7…) usedop2(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.3. Indirect mesh draws
On Intel,
RX_VK_MESH_ARGS=1is 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 composite1a7482c0ec9991ea(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
ee7764a6b1ef459cis 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 bycb2e06ddfb9d7d27/102f5b0abb0f1e63).RX_VK_DRAW_STATSlists "second-level pointers no binding covers" forcb2e06…,44511d…,6344c5…and7650519…, all pointing at0x1100000010.5. Other
3e6fe279463b020eor499dbfd0721d2858.6. Menus and dialogue (videos below)
1a7482c0ec9991ealeft out throughRX_VK_SKIP_FILE,RX_VK_MESH_ARGS=1), and the menus with what is left on screen after closing them.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
CasLoopand the EQUAL-depth change would be very welcome, so they can be tried on other GPUs as well.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
vulkan-intel)no-visual-studio, built withHookshot-no-visual-studio-x86_64.AppImagehookshot_env.txt(all default settings)Works
hid_nintendo) works with no setupIssues
mkw_vk workerthreads 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 theCasLoophang above.I have not tried
RX_VK_MESH_ARGS=1or 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 withoutVK_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
mainsincefoliage-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: draw999fd641ba1fc2b0most often, also55fc7e951c87de74. It always happens around frame 2600-2700, as the forest first appears. WithRX_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:
mainat3d6a388(no local changes)mainat53af338(no local changes)3d6a388+ #548 + local changeshookshot_env.txtRX_VK_MESH_NO_ZERO=1RX_VK_COMPUTE_WAIT=1RX_VK_EVICT_NO_FLUSH=1 RX_VK_NO_RB_REFRESH=1 RX_VK_RELEASE_DRAIN=1RX_VK_KEEP_RETIRED=1So 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 withRX_VK_KEEP_RETIRED=1faulted in compute4b03b3040d7cf076. That one, and499dbfd0721d2858, already faulted now and then onfoliage-linux-updater, so they look like a separate, older problem.VK_EXT_device_faultis not available on this driver (RX_VK_FAULT_INFO=1says 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=1and 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
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
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
0x1963be), Vulkan 1.4.359cd9cebb6)vulkaninfo:VK_EXT_mesh_shaderpresent,meshShader = true,taskShader = trueFrom the log header:
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.binwas 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 screenhookshot_env.txt:presents, … fpslines stop.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:
Then an access violation in
igvk64.dll, on what looks like a worker thread (thread entry via ucrtbase, not the presentation thread):Windows Error Reporting: APPCRASH, faulting module
igvk64.dll32.0.101.9150, offset0x79ddf3. 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) andhookshot_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.Same thing Happened on Intel Arc a750 GPU too.
Issue for #17
Title: Arc A770 (DG2) / Mesa 26.2.6: v2.1.0 freezes at the save load inside Mesa's
brw_reg_alloc, and 30 networks are still left out on this cardEnvironment
source e561602e, rendererhookshot_vk.sosource 633eb435romfscomplete (186 583 files), languagefrVulkan 1.4, driver 0x6802006, type 2apiVersion 1.4.354, backend Xe KMD (MESA: warning: Support for this platform is experimental with Xe KMD)7.2.15-ogc1.1.fc45.x86_64Intel(R) Graphics (RPL-S)(device 0) andllvmpipe(device 2); the game picks device 1, the A770The GPU reports mesh shaders, host memory import and pipeline libraries, but no 16x8x16 f16 cooperative matrices:
Symptom
Two things, on a fresh v2.1.0 update (the builder replaced
bin/hookshotandbin/hookshot_vk.so, then ran--prepare-shadersby itself):a network left out on this card— 30 distinct keys in this run (v2.0.14 refused ten of the same family). That is the "black picture under the HUD" the source comments describe, and it is why the picture stays empty in v2.0.14 too.What the frozen process is doing (gdb)
gdb -p <pid> -batch -ex "thread apply all bt"while it is frozen — the render thread and two worker threads are 100 % CPU inside the Intel Vulkan driver, not inside Hookshot:So the freeze is Mesa's Intel register allocator (spilling) on one very large shader. Hookshot itself logs 64 programs "lowered with extended registers" of about 1132–1136 REGMAP words; on a card without f16 cooperative matrices, the translated networks are exactly the kind of shader that puts the allocator into this state.
No GPU reset at all —
journalctl -khas 0xereset/hang/timeout lines over the session, and there is no device-lost.Log excerpts
The in-play preparation does finish (76 s). Then the last frame line, repeated for as long as the process lives:
Two of the refused keys, with their dispatch shapes:
All 30 distinct keys of this run (
grep 'not translated' hookshot_log.txt):The ten v2.0.14 refused, all of which are in the list above:
e409733c45530d75,8306877b7dc8784b,de3c10dba4ff39d3,a41c78faa56ccf7d,e959b9b1451491c0,5a4d7378db437fed,8b73eaee02efc5e4,14140d4c1dbe754f,4c2c129fe950b041,3f6f2b1d671badcd.Note that the dispatch samples its own output image (
imgand the thirdtexare the same address0x10755b4000), so the linear fallback (upscale_stub, "out_area > in_area" and not also an input) cannot take it — the same situation as in v2.0.14, where the result was 60 fps, 2 draws a frame, and a black picture under the HUD.Configurations tested (all freeze at 1080 presents)
hookshot_env.txt/ optionsRX_VK_MESH_ARGS=1+RX_VK_PREPARE_BACKGROUND=1brw_reg_allocRX_VK_NETWORK_KEEP=allinhookshot_env.txtnot translatedlinesRX_VK_NETWORK_KEEP=allexported by the shell insteadINTEL_DEBUG=noopt(Mesa without its optimisation passes)brw_reg_alloc::spill_regframe_generation=0,hdr=0,dlss=0,resolution=0Duration tested each time: 2 to 5 minutes with no additional present, 15–16 GB RSS, no swap growth, no kernel event.
Question about
RX_VK_NETWORK_KEEP=allAccording to
vk_shader.cpp(v2.1.0, around line 1599),keep == "all"setskept_one = true, so the throw at line 1610 should not happen. But setting it, either inhookshot_env.txtor in the process environment, still produces all 30a network left out on this cardlines, key for key.hookshot_env.txtlogs noleft out (only the game's switches…)line for it, so the file is read. Is there another path that refuses these compute networks, or isRX_VK_NETWORK_KEEPread before the file is applied?Unrelated, in case it matters
Audio:
vk/host logsaudio: output on the default device (0 devices), stereoeven though PipeWire has several sinks; the game's stream does reach the default sink (a Bluetooth headset), so this is only reported in case the "0 devices" enumeration is wrong.Attachments
hookshot_log.txt(full log of the run above)thread apply all bt) taken while frozenhookshot_log.txt
In my case (intel arc b580, Ryzen 5600G, 16GB of RAM and Windows 11) the game runs fine until the end of the first cutscene (after Ganondorf shows Link THE HAND). After the screen flashes white then black, and I assume tries to load in Kokiri Forest, the window app crashes completely with error:
vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, and nothing sent to it runs any more (on Linux, dmesg or journalctl -k around this time names the reset)
hookshot_log.txt