MagicBeanDev/Hookshot

Archived

Watch

Fork 0

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

Closed

opened 2026-11-07 22:31:45 +00:00 by Tobim6 · 4 comments

Tobim6 commented

2026-11-07 22:31:45 +00:00

(Migrated from github.com)

Builder version

foliage-linux-updater

How you built

Linux AppImage

Game files given to it

A .nup

The error

Hi, love how active you are. I get a black screen after the initial cutscenes, when the 3D world rendering would start. Log attached.

Visual Studio or Build Tools version, and Windows SDK version

N/A

Operating system and free space on the output drive

Arch Linux, 51GB after installing.

Before you send it

I'm on the newest release, or it still fails on it.
I searched the open issues for this error.
I'm not attaching game files or anything built from them.

### Builder version foliage-linux-updater ### How you built Linux AppImage ### Game files given to it A .nup ### The error ```text Hi, love how active you are. I get a black screen after the initial cutscenes, when the 3D world rendering would start. Log attached. ``` ### Visual Studio or Build Tools version, and Windows SDK version N/A ### Operating system and free space on the output drive Arch Linux, 51GB after installing. ### Before you send it - [x] I'm on the newest release, or it still fails on it. - [x] I searched the open issues for this error. - [x] I'm not attaching game files or anything built from them.

Tobim6 commented

2026-11-07 22:32:02 +00:00

(Migrated from github.com)

hookshot_log.txt

[hookshot_log.txt](https://github.com/user-attachments/files/34529896/hookshot_log.txt)

WellyngtonMolinari commented

2026-11-08 00:49:06 +00:00

(Migrated from github.com)

just wait and be patient during the black screen

👍 1

6a6f7368-2 commented

2026-11-08 20:50:02 +00:00

(Migrated from github.com)

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.

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 #17 among the EQUAL-depth passes, 68642b… and 6b4dea…, are stage-7 (mesh) programs here.
#748 (Arc B390, Mesa 26.2.5) segfaults inside ANV at the first task/mesh draw.
#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 #17 (the same machine as #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.)

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 #17 among the EQUAL-depth passes, `68642b…` and `6b4dea…`, are stage-7 (mesh) programs here. - #748 (Arc B390, Mesa 26.2.5) segfaults inside ANV at the first task/mesh draw. - #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 #17 (the same machine as #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.)

NotRexed commented

2026-11-09 05:47:24 +00:00

(Migrated from github.com)

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.