Black screen after initial cutscenes on Intel Core Ultra 7 155H Intel Arc iGPU. #366

Activity

1. Tobim6

   added

   bugSomething isn't workingSomething isn't working

   on Nov 7, 2026
2. Tobim6 commented on Nov 7, 2026

   

   Tobim6

   on Nov 7, 2026

   Author

   More actions

   hookshot_log.txt
3. WellyngtonMolinari commented on Nov 8, 2026

   

   WellyngtonMolinari

   on Nov 8, 2026

   More actions

   just wait and be patient during the black screen

   👍React with 👍1Reacted by Wellyngton Molinari
4. 6a6f7368-2 commented on Nov 8, 2026

   

   6a6f7368-2

   on Nov 8, 2026

   More actions

   Same chip here (Core Ultra 7 155H, Arc iGPU), on Batocera Linux with Mesa 25.3.6 ANV (Mesa's Intel Vulkan driver), on v2.0.3 and v2.0.2. It still goes black at the same spot. Waiting, as suggested above, didn't get me through: on v2.0.2 it stayed black for 17 minutes, then the OOM killer ended it. I think I found what it waits for.

   The first start's shader preparation is OOM-killed on this machine (#775), so I ran with RX_VK_PRECOMPILE=0. The title, New Game and the opening (tapestry, narration, logo) then ran at 60 fps most of the time. Entering the world:

   • dispatches were left out while their compute pipelines compiled (dispatch of 755a777ada52677d left out: its compute pipeline is still compiling, and 53d44ed9a67b3d78), as intended;
   • two submits stood still in draws waiting for their pipelines, then went on (v2.0.3: slow submit: 9672.8 ms: draw 9597.7 ... and slow submit: 4564.7 ms: draw 4409.3 ...);
   • then presents stopped. Nothing more was presented: the last count logged is 11880 presents on v2.0.3 and 26280 presents on v2.0.2.

   While it was black, only two threads were busy in my samples, each at 100%: one mkw_vk worker (of the 4) and mkw_vk serial builds. I sampled them with ptrace: the instruction pointer, plus a scan of the top of each stack for return addresses, so these aren't unwound stacks. Every instruction pointer was inside libvulkan_intel.so, mostly at +0x7fd712..0x7fd732, also +0x7fde3d, +0x37db98 and +0x769dfb. Batocera's Mesa is stripped, so I can't name the function. The hookshot_vk.so return addresses resolve to the same functions in every sample, on both versions (the serial builder's I symbolized on v2.0.2 only):

   Presentation Thread: jobs_wait <- draw()::$_1 <- draw()                (in a futex wait in every sample)
   mkw_vk worker:       libvulkan_intel.so <- build_graphics <- graphics_pipeline()::$_0 <- worker
   mkw_vk serial builds: libvulkan_intel.so <- dispatch()::$_0 <- jobs_push_serial's thread
   

   So a draw into targets made this frame can't be left out (may_skip = ... && targets_persistent(at)), and it waits for its graphics pipeline. On v2.0.2 I let it run until the end. The one graphics failure in that log is:

   [hos host] vk: graphics pipeline for 68642bb810ee3e7c not made (-13)
   [hos Presentation Thread] vk: NVN2 program 3d33bb73d3deee34 (stage 7) lowered with extended registers (577 REGMAP words)
   

   -13 is VK_ERROR_UNKNOWN, from ANV. 68642bb810ee3e7c is a mesh program (mesh program 68642bb810ee3e7c, NVN stage 7: 6 storage buffers in an earlier log). The log has no timestamps. By the RSS samples, which fell 3.2 GiB at that moment, it came about 16 minutes into the black screen. The Presentation thread then lowered the next program. No presents came after it, and RSS climbed again until the OOM about a minute later (anon-rss:26680040kB). RSS went from 5.3 GiB at the black screen to 18.7 GiB within 3 minutes, then grew about 9 MiB/s, so the driver's compiler looks like what used the memory.

   The pin made a difference. Each run started a new game and went into Kokiri, with the same result on v2.0.2 and v2.0.3:

   Run	Result at the world's first frame
   defaults (pinned to 32 on stages 0xe0: compute, task, mesh)	stuck at the same point: the last program lowered before the stall is 463f42630fce83a0 and the stacks match; on v2.0.2, 68642bb810ee3e7c failed with -13 after ~16 min and the OOM followed
   RX_VK_NO_SUBGROUP_PIN=1 (pinned to 32 on stages 0)	gets past that point: five more stage-7 programs are lowered (3d33bb73d3deee34, 66c494fe4cfa930b, b509ae330829ce02, d38b0d52a94ab5a8, e3fc8fcf540f7a48). Then a later graphics build stalls the same way (same stacks, same ANV offsets). The screen still stays black throughout: no present is logged after world entry (the last counts are 11880 on v2.0.2 and 11640 on v2.0.3). I quit after about 7 minutes each time.

   So on ANV, building that mesh pipeline with 32-lane subgroups looks like the expensive part. I know from the source comment at the pin (vk_main.cpp) that the mesh programs' lane masks depend on 32 lanes, so this isn't a fix, just where ANV's cost seems to be. Even unpinned, a later graphics build stalls too.

   RX_VK_NOOPT=1 (v2.0.2, pin on) stopped at the same point as the defaults. ANV may not act on that flag at all, so I'd read it as a second default run. PR #700's quick builds are AMD-only by default (RX_VK_QUICK_PIPELINES=1 elsewhere). They and its retry without the optimizer use the same flag, so they may not change anything on ANV. Its draw building its own pipeline wouldn't help either, since that one build ran for about 15 minutes.

   What would help me narrow it down: a log line when a graphics build starts (key and stages), so a stall names its build while it runs. I'm happy to test any build or switch on this machine.

   Possibly related:

   • Two programs fuxau lists in Intel GPU Issues #17 among the EQUAL-depth passes, 68642b… and 6b4dea…, are stage-7 (mesh) programs here.
   • Linux, Intel Arc B390 (Mesa ANV 26.2.5): segfault in libvulkan_intel.so on the first task/mesh draw after loading a save #748 (Arc B390, Mesa 26.2.5) segfaults inside ANV at the first task/mesh draw.
   • Intel Arc iGPU (Core Ultra 7 155H): device lost every time Navi leaves to find Link, then VRAM climbs to 48 GB and igvk64.dll crashes (v2.0.2) #741 is this chip on Windows. There the world draws until Navi leaves to find Link, and then the device is lost in compute 4b03b3040d7cf076 after ab7699ee7f536755. Both of those are among the dispatches left out here at the world's first frame.
   • felipecsl's B390 in Intel GPU Issues #17 (the same machine as Linux, Intel Arc B390 (Mesa ANV 26.2.5): segfault in libvulkan_intel.so on the first task/mesh draw after loading a save #748), on an older build, got through a black screen of over a minute and a later freeze of several minutes. Mine is the older Meteor Lake, on Mesa 25.3.6, so the Mesa version or the GPU generation may matter.

   (No device lost happened in any of my runs, so I can't add to the RX_VK_KEEP_RETIRED=1 question in #17.)
5. NotRexed commented on Nov 9, 2026

   

   NotRexed

   on Nov 9, 2026

   Owner

   More actions

   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. 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.
6. NotRexed

   closed this as a duplicateof [Tracking] Intel Arc and Core Ultra iGPUs: device lost, black screen after the intro, Linux ANV crashes #999 on Nov 9, 2026