[Tracking] Intel Arc and Core Ultra iGPUs: device lost, black screen after the intro, Linux ANV crashes #999
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#999
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?
This issue collects every open report of Intel Arc / Core Ultra device lost, black screens and Linux ANV crashes, so there is one place to follow it. The individual reports were closed pointing here; their logs, screenshots and discussion stay in each linked issue.
Summary
On Intel Arc (A750, B580, Pro B50, B390) and Core Ultra iGPUs (Arc 130V / 140V, Meteor Lake):
Iris Xe and UHD 620 have no mesh shaders; see that tracker.
Affected GPUs and versions
Evidence from the logs
RX_VK_FORCE_UPSCALE_STUB=1andRX_VK_NETWORK_KEEP=nonedon't change it.storage buffer NOT boundat c5+0x60 in 68642bb8 / 6b4dea60 / 739acd67 / d905f52b.Workarounds
Reports merged here (14 issues, about 32 people)
b82bd36b82bd36; new SIGSEGV libvulkan_intel.so+0x9d8763 building pipeline b0b3b40244c71ec7 (grass-shadow points mesh, OutputPoints/P…Adding a report
Please update to v2.0.6 first (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher). Please add: GPU, driver (or Mesa) version, OS, and
hookshot_log.txt.All tracking issues
Man, do you sleep?! Thank for the updates and tracking all this.
v2.0.7 update
Took 2 tries to get the game loaded. First try is hookshot_log.1.txt. 2nd try (hookshot_log.txt) loaded the startup graphics and then the intro - all going at 60 fps. After the intro finished I thought the game had crashed, but left it running. I opened github to update this thread but after a LONG wait (5+ minutes), I heard the Deku tree talking! Popped the game back up - I hear audio, and see the subtitles, but no graphics on screen. I let it run through Deku and Navi talking but n0 graphics update - FPS reported at this point 20-30.
I think the graphics pipe gets lost based on this line appearing after the intro finishes
~3409: [hos host] vk: graphics pipeline for 0e0016204515849a not made (-13)
Seem the GPU is trying to draw again during the Deku tree sequence but nada on screen.
hookshot_log.1.txt
hookshot_log.txt
The game did not open the first time. The second attempt took a few minutes.
Stuttering during the titling screen.
The cutscene the fps fluctuated below 60 fps but near the end it was constant at 60 fps. The cutscene ended and stuck on the black screen.
Hookshot: v2.0.7
[System]
CPU: Ryzen 5600X
GPU: ARC B580
RAM: 32 Gb
OS: Fedora 45
hookshot_log.txt
The same problem. The first cutscene ends and it stucks on the black screen with sound.
Hookshot: v2.0.8
[System]
CPU: Ryzen 5600
GPU: Intel Arc B580
RAM: 16 GB
OS: Windows 11
hookshot_log.txt
@VictorNagibator: thanks for the v2.0.8 log. v2.0.8's new write-back pass was on for every GPU, and it lost the device on newer NVIDIA drivers (#1161). v2.0.9 turns it off by default, so please update to v2.0.9 and say whether the black screen after the first cutscene is gone.
v2.0.9 Update.
i5-13600
32GB system Ram
16 GB Arc Pro B50 - Mesa 26.2.5 - Mint 22.3
Thank for the shader and pipeline loading screen. That really helps.
Ultimately, I am getting the same results as v2.0.5 - Startup and Intro graphic display well @ 60 fps. After the main intro plays, screen black for 5 minutes and the Deku tree scene loads with black screen though audio playing and subtitles showing.
This took 4 attempts to start. First (no log) crashed the computer. Second (hookshot_log.2.txt) got through the shaders and started the pipelines before crashing. Third (hookshot_log.1.txt) tried more pipelines but never finished. 4th run (hookshot_log.txt), the game started but seemingly the pipelines never finished but as I said, the game started and then you see my update from above.
hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.txt
Update: I updated Mesa to 26.2.6, but no change. Pipelines don't finish, get to about 1380ish. Game will load but won't load the Deku tree scene after first intro.
Update v2.0.9
I have the same result as v2.0.8: black screen with sound after first cutscene :(
hookshot_log.txt
[Problem]
Pipelines is not able to finish by ending the game brutally.
I was able to open once without completing the pipelines.
First cutscene ends and the game freezes after waiting about 10 minutes it comes back.
Second cutscene is untextured at 4~23 fps until it crashes again.
[Version]
Hookshot: v2.0.8
Hookshot: v2.0.9
[System]
CPU: Ryzen 5600X
GPU: ARC B580
RAM: 32 Gb
OS: Fedora 45
[Logs]
hookshot_log_v2.0.8.txt
hookshot_log_v2.0.9.txt
v2.0.10 Update.
i5-13600
32GB system Ram
16 GB Arc Pro B50 - Mesa 26.2.6 - Mint 22.3
This did change some things.
Game went through startup and intro (60 fps). Then same black screen (with audio and subtitles, 15-25 fps reported) on Deku tree cinematic, but it actually loaded into it very quickly. No long delay before playing. And even proceeded to I guess Navi going to Link's house. But all black.
First run (hookshot_log.1.txt) it hangs at loading pipeline 1383 and crash. Seems there is something up at that point loading the pipelines. It keeps getting stuck there these past versions. Then the second run (hookshot_log.txt) proceeded as above.
hookshot_log.1.txt
hookshot_log.txt
Update v2.0.11
The same result as v2.0.8, as v2.0.9 and as v2.0.10: black screen with sound after first cutscene :(
[System]
CPU: Ryzen 5600
GPU: Intel Arc B580
RAM: 16 GB
OS: Windows 11
hookshot_log.txt
Hookshot: v2.0.11
CPU: Ryzen 7 5700X
GPU: 16gb Intel Arc A770
RAM: 48gb
OS: Windows 11 Home
Might as well put my 2 cents here and see if this helps with progress if any.
Loading of the pipelines seem to take longer and longer (don't know if thats normal)
Menu renders decent at least, flickers but decent on the ui (still funny to me how it seems to "explode" as it convulses)
Intro plays good with small stutters
And now the eternal black abyss before the deku tree ever makes an appearance
and crash
what the problem may be, i hope this log might help
hookshot_log.txt
Hi! I'm still experiencing crashes and freezes on Hookshot v2.0.11 using an Intel Arc 140V GPU.
System:
Laptop: Samsung Galaxy Book5 Pro
GPU: Intel Arc 140V
CPU: Intel Core Ultra 7
RAM: 32 GB
OS: Windows 11
Intel graphics driver: 32.0.101.9175
Hookshot: v2.0.11
Problem:
The game freezes or loses its picture during the Great Deku Tree introduction, sometimes after the Deku Tree tells Navi to find Link.
Without experimental settings, I have observed:
GPU 3D usage remaining at approximately 100%.
Hookshot CPU usage dropping from around 20–22% to 0.4–2%.
Memory usage reaching approximately 19 GB.
Background audio continuing temporarily before stopping.
GPU usage returning to normal immediately after closing Hookshot.
I also tested RX_VK_MESH_ARGS=1. With this setting, dialogue continued even after the picture disappeared, but GPU usage eventually dropped to 0%, Hookshot's memory usage increased to approximately 22 GB, and total system RAM usage reached 99%.
Relevant findings from the latest log:
vk: submit 72564 failed (-4)
vk: device lost: reading the checkpoints
The checkpoints include:
dispatch of program 499dbfd0721d2858, frame 10365
The log also shows an increasing number of retained capture buffers following the device-loss error.
I noticed the discussion in issue #17 about a possible infinite CasLoop on Intel Arc GPUs. Could this be related to the same underlying problem? Has the bounded CasLoop fix been incorporated into a branch or test build that I could try on my Arc 140V?
I'm happy to provide further logs or test a development build.
Thanks for your work!
hookshot_log.txt
I dream of the day this is playable on the new Intel G3 devices. Keep up the incredible work.
intel arc 140v
version 32.0.101.950
60fps cut scene 30fps innscene with deku tree and navi crashes before entering links house. heavy stutter and broken images constant flashing
v2.0.11
hookshot_log.1.txt
Adding an Intel Arc B390 report on Windows.
CPU: Intel Core Ultra X9 388H
GPU: Intel Arc B390 integrated graphics
RAM: 32 GB
OS: Windows 11 25H2, build 26200.9711
Intel graphics driver: 32.0.101.9175
Version covered by these logs: Hookshot v2.0.8, source 24534a6a
The opening movie plays normally. When the first real-time Deku Tree/Navi scene starts, the picture appears washed out and then stops updating while audio continues. Presentation counters stopped advancing, but background logging continued. This v2.0.8 log documents a hang without a recorded crash or device-lost error.
An earlier v2.0.6 test with the same driver recorded an access violation at igvk64.dll+0x79ddf3, followed by Vulkan submission failure -4. That separate log is included for comparison.
The v2.0.8 test used Vulkan, 50% internal resolution, handheld mode, and frame generation off. Diagnostic memory limits were RX_VK_VRAM_MB=3072 and RX_VK_MIRROR_MB=512; shader preparation and checkpoints were enabled.
hookshot-v2.0.8-hang.txt
previous-v2.0.6-driver-crash.txt
REPORT.txt
Update, same issue on 2.0.11
2.0.11 got a bit further in. Newest log Uploaded below
Hookshot-v2.0.11-B390-test-log.txt
intel arc b580 - driver ver. 32.0.101.9150 - Same issue black screen during Deku Tree .
Hookshot 2.0.11
Device Lost: reading checkpoints
hookshot_log.txt
v2.0.11: still black screen with sound. Arc B580, driver 101.9175, Windows 11 25H2, i5-9600KF (6C/6T). Log attached.
Same device lost as v2.0.2 and v2.0.4 (5 of my 6 runs):
New in this log: a 98.7 s submit right after the first
fd029a317a9a4b94network dispatch, just before the device lost:First-start preparation took ~2 h (38809 programs, 151 failed).
Happy to test a build or switch for
4b03b3040d7cf076.hookshot_log_v2.0.11.txt
I was able to get into gameplay(?) finally for the first time, but obviously performance is horrible. I was able to get to the part where Navi leaves to get Link, but the game crashed.
hookshot_log.txt
able to load save but crash leaving links house heavy texture problems arc 140v 2.0.11
hookshot_log.txt
Tested on version 2.0.12
GPU: Arc B580 Cpu: Ryzen 5600: Driver gpu: 32.0.101.9150
Game now crashes after the intro, in earlier versions the cutscene after the intro had a blackscreen, but the audio was still running.
hookshot_log.txt
Intel B580 here also, after latest update it doesn't just freeze it completely shuts down after intro cutscene. :(
Quick update: I tested Hookshot v2.0.12 on my Intel Arc 140V, but unfortunately the problem persists.
This time, Hookshot closed completely after the introductory sequence instead of remaining frozen.
I checked Windows Reliability Monitor and found two LiveKernelEvent 141 hardware errors, coinciding with the crashes.
The latest Hookshot log does not appear to contain the previous VK_ERROR_DEVICE_LOST message, but Windows is reporting GPU-related timeouts.
This suggests that the issue may still involve the Vulkan renderer or Intel graphics driver.
I've attached the latest log from v2.0.12. Hopefully, this helps narrow down the cause.
hookshot_log.txt
Intel Arc B580 – VK_ERROR_DEVICE_LOST on Hookshot v2.0.13
System:
0x1963d754e42459)I tested two runs. The first one ended with a manual restart from the in-game menu, after 4,370 frames.
The second run reached 9,849 frames at 60 FPS, but eventually froze and crashed around frame 9,890.
The final log reports:
The device-loss checkpoint also references:
I noticed this is the same compute program mentioned in another Intel Arc report as a possible intermittent device-loss point.
I've attached the complete
hookshot_log.txtfor investigation.hookshot_log.txt
v2.0.14 still has texture issues, but shader loading speed has improved; it no longer takes a long time to enter the game, and it doesn't get stuck on black screens.
The texture issue, however, persists.
GPU: Intel Arc A750 8GB VRAM
CPU: AMD Ryzen 7 5700X
RAM: 32 GB DDR4
Very good work so far.
Update v2.0.14
Now after first cutscene it crashes, no black screen - just crash
[System]
CPU: Ryzen 5600
GPU: Intel Arc B580
RAM: 16 GB
OS: Windows 11
hookshot_log.txt
pdate: tested v2.0.14 (source 3a9998c3) on my Intel Arc B390 / Core Ultra X9 388H, 32 GB RAM, Windows 11, Intel driver 32.0.101.9175.
The opening movie ran at approximately 60 FPS. The real-time Deku Tree scene then appeared with severe white haze/overexposure, briefly reporting 51–55 FPS before the picture froze.
The last logged presentation counter was 12000 (51.2 FPS). It stayed unchanged for over 30 seconds while audio-thread and controller logging continued. The FPS overlay also froze. No CRASH, FATAL, or device lost message appeared in the collected log.
This reproduces the render hang seen on v2.0.11. Full v2.0.14 test log attached.
Hookshot-v2.0.14-B390-test-log.txt
Exact same problem. No more black screen, just crash.
hookshot_log.txt
Tested v2.0.14 (source 3a9998c3) on an Intel Arc A770 16 GB with 32 GB of RAM, Windows 11 build 26200.9711, and Intel graphics driver 32.0.101.8801.
The opening sequence initially ran at approximately 60 FPS in 2560×1440 fullscreen mode. The screen then went black, and Windows reset the GPU.
hookshot_log.txt
pc:
*Arc B570 10gb Latest driver
*core i5 10400f
*24gb ddr4 3200
*installed on SSD
Just tried and it crashes on both loading a save, black screen and crash, and starting a new game the first cutscene looks perfect then it crashes and log shows this error (VK_ERROR_DEVICE_LOST), also on main menu there are some graphic issues like some flicker and some lines appearing for a secon across the screen...
hookshot_log.txt
v2.1.0 Update.
i5-13600
32GB system Ram
16 GB Arc Pro B50 - Mesa 26.2.5 - Mint 22.3
Game compiled. Shader build during compile did not complete. Started on first run. Shaders completed - though looks like some had errors. Pipelines started loading and the game crashed out of memory multiple times. Eventually it's the same story. Intro scene loads and then black. Though I was able to make it to where I see the HUD and can control Link. I could hear him responding to controls.
There has got to be something about these pipelines not finishing methinks.
hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.3.txt
hookshot_log.4.txt
hookshot_log.txt
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
Intel Arc B580 on Windows: the device is lost within seconds of the first real-time 3D frame, every time (8 of 8 runs with the default settings or one switch changed; a ninth run, with robust buffer access off, was lost earlier, on the title screen). The checkpoints say where the GPU stopped: usually at a compute dispatch, not always the same one, and at a draw once those were skipped. Skipping programs, leaving out mesh draws, leaving out the upscale networks, turning off the VRAM mirror and giving retired imports back did not help.
Setup
nx2/make_game.py, no DLSS), not with HookshotBuilder, frommainat commitf8efe05(2026-11-11 00:56 UTC). That is 6 commits before the v2.1.0 tag; none of the 6 mentions Intel or the device loss (they touch the pipeline state list and AMD subgroup profiles). The log's first line ishookshot unknown (source 18be5ca9): git was not on PATH during that build, so the version string isunknown;18be5ca9is the source hash, not a commit.make_game.py --check: build e0f3ccfa.igvk64.dll/igc64.dll32.0.101.9150; the log saysdriver 0x1963be,mesh shaders yes, host memory import yes, pipeline libraries yes).hookshot.exeexcluded from ProBalance, at Normal priority and affinity 0-15.Shader preparation
--prepare-shaderstranslated 38,809 programs in 1774 s (70 failed). Then the predicted-pipelines step printed nothing for 15 minutes and the builder stopped it ("the shaders were not prepared now"). There was no TDR at that point.PrepareBargives about 142/s on an RTX 3090.hookshot.exekept 9-12.5 of 16 threads busy, with the GPU at about 10%. It is the driver's compiler on the CPU.The device loss
Each run: title screen and menus at a steady 60 fps for minutes, then start the game from the menu. Within seconds of the first real-time 3D frame:
vk: submit N failed (-4), thenVK_ERROR_DEVICE_LOST, exit code 3.VK_EXT_device_fault not availableon this driver:RX_VK_FAULT_INFO(and the device-fault part of #1569) gives nothing here.VK_NV_device_diagnostic_checkpointsis on by default on this driver, so every run has the checkpoints. A marker is set before its draw or dispatch. "Top" (stage 0x1) is the last marker the GPU reached and "bottom" (stage 0x2000) the last one with all earlier work finished, so the work in flight runs from the dispatch the bottom marker names to the one the top marker names.499dbfd0721d2858; the next draw (a5da9f84b72d1471) never startedRX_VK_SKIP_PROG=499dbfd0721d28584b03b3040d7cf076; bottom:ab7699ee7f536755(the same pair as the earlier Windows reports here)RX_VK_SKIP_PROG=4b03b3040d7cf076592079442d7129da; bottom:435a0138b9013040RX_VK_MIRROR=0(log:VRAM mirror of buffer pools off)499dbfd0721d2858(as the baseline)RX_VK_KEEP_RETIRED=0+RX_VK_IMPORT_HIGH=85(log:imports given back past 85% ... on)592079442d7129da; bottom:435a0138b9013040RX_VK_ROBUST=0(norobust buffer access online in the log)b7914ae65792d0c8; bottom: draw ofdc310f71db89f779RX_VK_NO_MESH=1(task and mesh draws left out)4b03b3040d7cf076; bottom:ab7699ee7f536755RX_VK_SKIP_PROG=499dbfd0721d2858,ab7699ee7f536755,4b03b3040d7cf076,435a0138b9013040,592079442d7129dab8fec6ceae7175a9RX_VK_FORCE_UPSCALE_STUB=2(log:gameplay RGB9E5 upscale uses the typed fallback; nonetwork fd029a317a9a4b94dispatch)499dbfd0721d2858(as the baseline)With
RX_VK_ROBUST=0the driver built the pipelines again (11,501 in 1354 s), and the loss came right aftera frame's uploads took 803 ms: ASTC on the GPU 1 (0.8 MB, 802 ms). Windows logged LiveKernelEvent 141 for it too.The baseline was run once; the skip runs also had
RX_VK_FAULT_INFO=1, which does nothing on this driver.For
RX_VK_NO_MESH=1and for the five skipped programs the log prints nothing that confirms the switch was applied (only the draw side ofRX_VK_SKIP_PROGandRX_VK_SKIP_CODElogs a line). The other switches in the table are confirmed by a line in the log, quoted in the first column.What it suggests (not proven)
499dbfd0721d2858;ab7699ee7f536755/4b03b3040d7cf076;435a0138b9013040/592079442d7129da). With all five skipped at once the device was still lost, at a draw. So it does not look like one broken shader, or one family of them.4b03b3040d7cf076skipped, memory, no mesh, five skipped) the log hasa capture's wait for write-back N timed out (done N-4)just before the loss: the GPU was already several submissions behind.TdrDelayis not set on this PC, so Windows resets the GPU after its default 2 s. Whether these dispatches would finish with more time was not tested.shaderBufferFloat32AtomicAdd = true(VK_EXT_shader_atomic_float), and the back end makes the float add of499dbfd0721d2858with a compare-exchange loop.slow submit: ... memory syncof 220-250 ms just before the loss (124 ms in the no-mirror run).TdrDelay,RX_VK_COMPUTE_SERIAL=0,RX_VK_NO_INVARIANT=1,RX_VK_EQ_BIAS=0, PR #1569 (git was not available), the Vulkan validation layer, and other drivers.Logs attached, with paths replaced by
<game>:log_base_1.txt,log_skip_499_1.txt,log_skip_4b03_1.txt,log_sin_mirror_1.txt,log_memoria_1.txt,log_sin_robust_1.txt,log_sin_mesh_1.txt,log_skip_cinco_1.txt,log_sin_redes_1.txt.log_base_1.txt
log_memoria_1.txt
log_sin_mesh_1.txt
log_sin_mirror_1.txt
log_sin_redes_1.txt
log_sin_robust_1.txt
log_skip_4b03_1.txt
log_skip_499_1.txt
log_skip_cinco_1.txt
Fix for Intel Arc (Lunar Lake, Arc 140V): igvk64.dll crash + device lost at Kokiri
Tested on MSI Claw 8 AI+ (Core Ultra 7 258V, Arc 140V, driver 32.0.101.9175), v2.0.14. With the two changes below, 10 and 15
min runs in Kokiri gameplay, ~31 fps, no crash, no device lost.
1. Crash in
igvk64.dll+0x79ddf3(this issue)Cause:
pipeline_cache_savecallsvkGetPipelineCacheDataon its background thread while other threads are still creatingpipelines into the same cache. Intel's driver races on this and reads a null pointer. That's legal in Vulkan, so it's a driver
bug, but it's easy to avoid.
Workaround in
gpu/vk/vk_draw.cpp,pipeline_cache_save, right after thepcache_built_since_save < 32early return:2. VK_ERROR_DEVICE_LOST (TDR) when Kokiri gameplay starts
Cause: the Eden SPIR-V backend always emits
StorageAtomicAddF32as a compare-exchange loop (f32_add_cas). In one computeshader, thousands of invocations hit the same word, and on Arc the loop runs past the Windows GPU timeout. Arc supports
VK_EXT_shader_atomic_floatwithshaderBufferFloat32AtomicAdd, so emit a nativeOpAtomicFAddEXTinstead:vk_internal.h: addfloat_atomic_add = false,to the device feature flags.vk_main.cpp:optional(VK_EXT_SHADER_ATOMIC_FLOAT_EXTENSION_NAME, dev.float_atomic_add);VkPhysicalDeviceShaderAtomicFloatFeaturesEXTinto the feature query;dev.float_atomic_add &= fadd.shaderBufferFloat32AtomicAdd;. I also added an env switch,RX_VK_NO_FLOAT_ATOMIC, toturn this back off.
Cause: the Eden SPIR-V backend always emits
StorageAtomicAddF32as a compare-exchange loop (f32_add_cas). In one compute shader, thousands of invocations hit the same word, and on Arc the loop runs past the Windows GPUtimeout. Arc supports
VK_EXT_shader_atomic_floatwithshaderBufferFloat32AtomicAdd, so emit a nativeOpAtomicFAddEXTinstead:vk_internal.h: addfloat_atomic_add = false,to the device feature flags.vk_main.cpp:optional(VK_EXT_SHADER_ATOMIC_FLOAT_EXTENSION_NAME, dev.float_atomic_add);VkPhysicalDeviceShaderAtomicFloatFeaturesEXTinto the feature query;dev.float_atomic_add &= fadd.shaderBufferFloat32AtomicAdd;. I also added an env switch,RX_VK_NO_FLOAT_ATOMIC, to turn this back off.profile.h: addbool support_float32_atomic_add{};. Invk_shader.cpp, set it fromdev.float_atomic_add.collect_shader_info_pass.cpp:StorageAtomicAddF32setsused_storage_buffer_types |= IR::Type::U32 | IR::Type::F32;, so the F32 SSBO view exists.emit_spirv_atomic.cpp,EmitStorageAtomicAddF32, before the CAS fallback:emit_spirv.cpp: wheninfo.uses_atomic_f32_add && profile.support_float32_atomic_add, add extensionSPV_EXT_shader_atomic_float_addand capabilityAtomicFloat32AddEXT.sirit: add
Id OpAtomicFAdd(Id result_type, Id pointer, Id memory, Id semantics, Id value), which emitsspv::Op::OpAtomicFAddEXT.This changes the translator sources, so the shader stamp changes and the shaders get prepared again once (~30 min on this machine).
Still open on Arc: outdoor scenes look washed out / white haze. Indoors looks fine.
For Intel DG2/Xe1 user under mesa/ANV: The compilation of pipelines were extrodinarily slow and finally lead to memory overflow due to frequent spilling of GRFs. I am working on https://github.com/HHHHanasak1/xess-xmx-linux/pull/64 which hopefully could address this problem by forcing BRW to use 256 GRFs. If the compilation did overflow your memory, please have a try at this mesa build.
@peigongdsd Is this live to try? Looks like the workflow still needs approval, and the last release was yesterday. Seems once merged, you just run install.sh? If it creates instability, can then run uninstall.sh to fallback to my current Mesa 26.2.6?
No rush, I am still testing and improving. With this 256 GRFs I am able to compile the compute pipelines but it is still very slow now
v2.1.0 (633eb435): now crashes instead of showing a black screen. Arc B580, driver 101.9175, Windows 11 25H2, i5-9600KF. 3 runs, 3 logs attached.
Every run ends with
VK_ERROR_DEVICE_LOST(submit returns -4). Windows logs aLiveKernelEvent 141(GPU reset) at the same moment.4b03b3040d7cf076(frame 2381)ab7699ee7f536755592079442d7129da(frame 1347)435a0138b9013040499dbfd0721d2858(frame 12061)499dbfd0721d2858The
f8efe05test above found the same two programs: first499dbfd0721d2858, then4b03b3040d7cf076afterab7699ee7f536755. These runs show both on the v2.1.0 release.592079442d7129daalso stopped one of my v2.0.2 runs.In all three runs, the first dispatch of the upscale network
fd029a317a9a4b94(typed upscale helper) appears in the log shortly before the failed submit. My v2.0.11 log showed the same thing.hookshot_v2.1.0_run1_save.txt
hookshot_v2.1.0_run2_save.txt
hookshot_v2.1.0_run3_newgame.txt
Runs great besides the textures going missing all the time.
On the newest update, one of the hottest issues still isnt fixed.
ARC A580
Hi! This is my first contribution here: a cause and a fix for the white veil over Kokiri on Intel iGPUs. The fix is in PR #2464. I worked on it with the help of an AI assistant (Claude Code) and checked everything on my own machine.
My PC
HOS_OUTPUT_RES=3,RX_VK_FIFO=1,RX_VK_PREPARE_BACKGROUND=1.What I saw: Kokiri Forest covered in white. The ground was missing and fog/sky was painted over it, worst in wide views. Characters, houses and plants were drawn normally.
Cause: on an iGPU the buffer pools have no VRAM mirror (
mirror_on()is off for non-discrete GPUs). The GPU therefore reads the uniform buffers in the game's memory when it runs the frame. By then the game has already written the next frame's per-object matrices there.ffb53ed102dd9908) drew the terrain with those stale matrices, so it landed off screen and the depth stayed at far.1a7482c0ec9991ea) treats far depth as sky and paints over the ground.So this is not a driver bug. Any GPU without mirrors should be affected;
RX_VK_MIRROR=0on a discrete card would probably reproduce it, but I have not tested that.Workaround for v2.1.0 now: add this line to
hookshot_env.txt:It copies the uniforms as submitted. Kokiri renders correctly and fps are unchanged on my machine (~8.5-11).
Fix: the PR turns this on by default when the pools are not mirrored.
The investigation details (per-draw depth readback vs a CPU projection of the same draws) are in the PR.
Feedback welcome, especially from other Intel iGPU owners: does the line above fix Kokiri for you too?
Before :
After :
More reports of this, collected here:
https://github.com/user-attachments/assets/3f6ae18f-cc10-4cf3-81aa-ff50cc01aa1a
Intel
hookshot version 2.1.0. Same graphic glitches but able to maintain close to 30fps and move around and leave links house for the first time.
hookshot_log.txt
Crashes immediately after the initial video sequence plays right before the Deku tree would start talking. While running on Intel GPU. I was told to also upload here on the Discord. Hookshot Version 2.1.0
hookshot_log.txt
System specs:
GPU Intel Arc A770 Le 16Gb
CPU Ryzen 5 9600x
32 Gb DDR5 ram
Driver
32.0.101.9150
More reports of this, collected here:
Same situation of game crashing after the first cutscene. Tried several config and none is working. And every time I need to watch the cutscene, lol.
Thanks for all the work. Is there any way I could fix this?
Able to get into gameplay, but during the cutscene where Saria appears for the first time after link opens the door crashes the game. Many textures arent loaded correctly or at all and plenty of flickering.
Intel Arc 140V (Lunar Lake iGPU): white-flash flicker fixed, crash fixed, Intel XeSS added
Base: Hookshot v2.0.14, Vulkan back end.
Device: MSI Claw, Intel Arc 140V (integrated), Windows, 1920x1200.
Game: Ocarina of Time (Switch 2).
TL;DR
01igvk64.dllinsidevkGetPipelineCacheData(this issue)010102Both patches apply cleanly to v2.0.14 with
git apply. They were checked in order on a clean tree:01, then02.1. White flash every 8 frames: root cause
Symptom. One frame in 8 turns white over the whole screen: the fog/haze loses its sky light. It is always the frame where the reflection probe's cubemap is swapped in.
Trigger. It happens only when
maybe_split(gpu/vk/vk_replay.cpp) cuts one guest submission into several Vulkan command buffers (RX_VK_CHUNK, default 120).RX_VK_CHUNK=0(no split): 0 flashes, but 18 fps drops to 10.Cause. At every part boundary,
maybe_splitcalledflush_ub_updates(). That wrote the inline uniform updates (NOP_UPDATE_UB) recorded so far into guest memory in the middle of the submission. Then it movedub_first_of_recordingforward.An unsplit submission writes all of its updates once, at its end, in
finish_recording. Draws in later parts that read those ranges directly from guest memory (not through an overlay copy) therefore saw a different state than an unsplit run. On the probe-swap frame this gives the white haze.Fix (3 lines). At a part boundary, do not flush and do not advance
ub_first_of_recording. The last part flushes the whole submission's updates, exactly like an unsplit submission.RX_VK_SPLIT_UBFLUSH=1restores the old behaviour.Measured. Same scene, 25 s each, 4 back-to-back runs,
RX_VK_CHUNK=120:No fps cost. The split keeps its benefit, while
RX_VK_CHUNK=0costs about 45% fps.Ruled out first (each tested on its own, no change):
RX_VK_TABLE_NOW=1).CLEAR_BUFon the CPU (RX_VK_CLEAR_CPU_MAX=0).Lichii (Eden-based) splits just as often (every 128 draws) and does not flicker. That confirms the boundary itself is fine.
2. Crash in
vkGetPipelineCacheData(this issue)Intel's driver dereferenced a null pointer (
igvk64.dll+0x79ddf3) invkGetPipelineCacheData. This happened while other threads were building pipelines with the same cache. Vulkan allows that usage, so this is a driver race.Fix: on Intel (
vendorID 0x8086), the pipeline cache is saved at exit only, not in the background.RX_VK_PCACHE_BG_SAVE=1restores the old behaviour.3. Other Intel / iGPU fixes in patch
01vk_draw.cppdraw_hazardsvk_draw.cppdrawRX_VK_NO_STORAGE_HAZARD=1vk_draw.cppuniform_rangeRX_VK_UB_SNAPSHOT=0vk_memory.cppgpu_buffer_bind4. Intel XeSS (patch
02)XeSS Super Resolution takes DLSS's place in
gpu/vk/vk_dlss.cpp. It uses the same inputs DLSS already gets: camera, LDR colour, depth, low-res motion vectors in pixels, and the host's jitter. Only the NGX calls are replaced by XeSS calls.HOOKSHOT_XESS_SDK=<path to Intel's XeSS SDK>adds-DHOOKSHOT_XESS(nx2/build.py). Without it, or when the NGX SDK is set, nothing changes.libxess.dllis loaded from the folder of the game's executable, and its functions are resolved at run time. No import library is needed, so this works with llvm-mingw.vk_main.cpp:dlss_device_features).Intel XeSSandIntel XeSS AAinstead ofNVIDIA DLSSandNVIDIA DLAA(vk_menu.cpp).libxess.dll2.0.2. Log:Intel XeSS draws OoT's upscale: 1536x864 -> 2048x1152.Recommended settings on Intel Arc 140V (measured with both patches)
Best: Handheld profile on, Render resolution
Auto, UpscalerIntel XeSS.Same scene, 25 s per run:
Notes
Auto. With a fixed value (67% or 50%), XeSS did not run at all: the log has no XeSS lines and the game's own upscale is used. The higher fps in that case comes from not running XeSS.ultrawide=1(fill 16:10) works in Docked only, not with the handheld profile.RX_VK_CHUNKat its default (120).RX_VK_CHUNK=0also removes the flashes, but costs about 45% fps.How to apply and build
gpu/andnx2/).libxess.dllfrom the SDK into the game's folder, next to the executable.Intel XeSS.Only patch
01is needed for the flicker and crash fixes. Patch02is optional.Still open (not caused by these patches)
submit_recording,value_rec.emplace(r.value, seq)keeps the first part's recording for a split submission, becauseemplacenever overwrites. As a result,wait_recorded()can return once part 1 is done. Replacing it withvalue_rec[v] = std::max(value_rec[v], seq)did not change the flashes and cost fps here, but the mapping looks wrong.01-intel-flicker-and-crash-fixes.patch (4 files, 90 lines)
02-intel-xess.patch (6 files, 548 lines)
GPU: Intel Arc 140V (Lunar Lake iGPU, 18 GB shared) – MSI Claw 7 AI+, Core Ultra 7 258V
Driver: 32.0.101.9150 (8 Oct 2026)
OS: Windows 11
Version: v2.1.0 (source 633eb435)
Game runs (~57-60 fps on title screen) but with graphical glitches:
Title screen: background behind the logo intermittently flickers yellow/black, without any input.
“Paramètres” menu (from title screen): a large black diagonal band across the screen (screenshot attached).
Settings: Frame gen Off, HDR Off, Upscaler: game’s own, Render res: Auto, Profile: Docked, Robust buffers: Auto. “ASTC as RGBA8” is not shown in the Debug tab.
screenshot attached.
I have yet to test, but I have been getting OOM crashes here, nx2navi, and Tuxchii when compiling/building shaders. Dev at Tuxchii (xTopher1049) has said "On Linux with Mesa drivers (Intel Arc, AMD, Steam Deck), Prepare Shaders was keeping every finished shader in a cache held in memory instead of on disk. " This could be a source of issues during shader and pipeline building though not sure if this is just a Tuxchii issue.
He has prepared a test for me to try. I will revert.
Update: Tuxchii still crashed at the same point. I know its another project but still seeing these OOM crashes on shader builds everywhere.
For info:
Arc Pro B50, Mesa 26.2.6, Mint 22.3
i5-13600, 32 GB system RAM
I guess its the mesh shader that's causing problem for intel gpus, even i set it into compute mode, still dosent fix the graphical glitch. low fps even with the frame gen.
GPU: Intel Arc A750
Driver: 32.0.101.9175 WHQL Certified (Latest)
OS: Windows 11
Version: v2.1.0 (source 633eb435)
Tracker upkeep note (merged pull requests and code checked against main
51da0464; no new test run was made for it).Main
51da0464includes #2464's uniform-buffer snapshots on non-mirrored Intel devices, #2513's loop-based storage-table searches and #2288's corrected native-ASTC accounting. These are concrete completed subcases, but preparation memory exhaustion and in-play compute-queue blocking are not thereby fixed: normal and fallback compute jobs still share the Intel serial queue, and a pending pipeline can leave its dispatch out. The already reported UHD770 result remains a limitation rather than new evidence, and #1610's author owns the oversized-compile follow-up. Please keep the tracker open; the latest combined patches on an older base need separate current-main isolation before their remaining changes can be judged.