MagicBeanDev/Hookshot

Archived

Watch

Fork 0

Black screen after intro Intel gpu #498

Closed

opened 2026-11-08 06:30:34 +00:00 by TotalGamerxk · 5 comments

TotalGamerxk commented

2026-11-08 06:30:34 +00:00

(Migrated from github.com)

Builder version

Builder fix

How you built

Hookshot Builder app (Windows)

Game files given to it

A .nup

The error

Black screen after first cutscene, everything runs 60fps perfect until that and then black screen

Visual Studio or Build Tools version, and Windows SDK version

Latest build tools, SDK, and visual studio

Operating system and free space on the output drive

Windows 11

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 Builder fix ### How you built Hookshot Builder app (Windows) ### Game files given to it A .nup ### The error ```text Black screen after first cutscene, everything runs 60fps perfect until that and then black screen ``` ### Visual Studio or Build Tools version, and Windows SDK version Latest build tools, SDK, and visual studio ### Operating system and free space on the output drive Windows 11 ### 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.

NotRexed commented

2026-11-08 08:47:53 +00:00

(Migrated from github.com)

The logs here show the cause: after the logo, Intel's driver compiled the game's large compute shaders on the thread that presents frames (one took 58 s; about 25 in a row stalled a single frame for 157 s), so nothing was drawn and the window looked frozen. Release https://github.com/NotRexed/Hookshot/releases/tag/ultrawide compiles them in the background instead, so the game keeps running while they build (the 3D may look incomplete for the first minute or two on the very first start). Please update and try again; if it still stays black, wait 3 minutes and attach hookshot_log.txt.

DevPedro99 commented

2026-11-08 19:04:54 +00:00

(Migrated from github.com)

Tried on Intel Arc B580 on https://github.com/NotRexed/Hookshot/releases/tag/v2.0.2, black screen at the same spot:

hookshot_log.txt

Tried on Intel Arc B580 on https://github.com/NotRexed/Hookshot/releases/tag/v2.0.2, black screen at the same spot: [hookshot_log.txt](https://github.com/user-attachments/files/34552224/hookshot_log.txt)

Henrique143 commented

2026-11-08 19:40:02 +00:00

(Migrated from github.com)

Same problem here on an Intel Arc B580 with v2.0.2. The logs show a Vulkan device lost at the same compute dispatch, 4b03b3040d7cf076, in 3 of my 4 runs, which might help narrow it down.

System

GPU: Intel Arc B580 (12 GB), driver 101.9175 (latest), Vulkan 1.4
CPU: Intel Core i5-9600KF (6 cores / 6 threads), 32 GB RAM
OS: Windows 11 25H2 (build 26200)
Hookshot v2.0.2 (source 998ef8f9), built with Hookshot Builder from my own .nup dump

What happens

New game: the logo and the first cutscene play, then the screen goes black. Audio keeps playing.
Loading a save made after the first cutscene: black screen when Kokiri Forest loads.

I waited several minutes each time. The shaders were already prepared (precompile: 4315 programs ... in 1276 ms), and the big compute pipelines compile in the background (dispatch of ... left out: its compute pipeline is still compiling). So this seems to be a different problem from the shader-compile stall diagnosed earlier in this thread.

What the logs show

Every run ends with VK_ERROR_DEVICE_LOST (submit returns -4). In 3 of 4 runs the checkpoints stop at the same place: top of pipe at 4b03b3040d7cf076, bottom of pipe at ab7699ee7f536755. So ab7699ee7f536755 finished, and 4b03b3040d7cf076 started but never finished:

vk: submit 9745 failed (-4)
vk: device lost: 2 checkpoints (25585 markers set)
vk:   stage 0x1: marker 25429 (dispatch of program 4b03b3040d7cf076, frame 1392)
vk:     before: dispatch of program ab7699ee7f536755
vk:     before: dispatch of program 7984161db3e053b5
vk:     before: dispatch of program 138596a0ca6720c8
vk:     before: INDIRECT dispatch of program f0fed2bbccae7bdc
vk:     before: dispatch of program f0fed2bbccae7bdc
vk:     before: INDIRECT dispatch of program cb2e06ddfb9d7d27
vk:     after: marker 25430 dispatch of program 755a777ada52677d, frame 1392
vk:   stage 0x2000: marker 25428 (dispatch of program ab7699ee7f536755, frame 1392)

Run	Log	Where	Top-of-pipe checkpoint
1	`hookshot_log.1.txt`	new game, after the first cutscene	`4b03b3040d7cf076` (frame 11612)
2	`hookshot_log.txt`	save, entering Kokiri Forest	`4b03b3040d7cf076` (frame 1240)
3	`hookshot_log_upscale_stub.txt`	save, entering Kokiri Forest	`592079442d7129da` (frame 1941)
4	`hookshot_log_network_keep_none.txt`	save, entering Kokiri Forest	`4b03b3040d7cf076` (frame 1392)

On this card the matrix multiplies run in software (the cooperative matrices lack 16x8x16 f16), so at first I suspected the upscale network fd029a317a9a4b94, which is the only network kept on Intel. That doesn't seem to be it. With RX_VK_NETWORK_KEEP=none the network was left out and replaced by the linear upscale as intended, but the device was lost before it ever ran:

vk: submit 9745 failed (-4)                    <- device lost (line 1467)
...
vk: program fd029a317a9a4b94 does not translate: its dispatch replaced by a linear upscale of 0x10000540200 1536x864 (vk 122) into 0x100121ffe00 2048x1152 (vk 122)   (line 1566)

My guess, which I haven't confirmed: 4b03b3040d7cf076 hangs on Intel. It could be another unbounded loop like the compare-and-swap ones fixed for AMD and Intel in v2.0.2 (#548), or something in the software matrix-multiply path. It runs past the Windows GPU timeout (TDR, 2 s), and Windows resets the device.

What I tried

RX_VK_FORCE_UPSCALE_STUB=1: still black (run 3). The network still ran.
RX_VK_NETWORK_KEEP=none: still black (run 4). The network was skipped, and the device was still lost at 4b03b3040d7cf076.

Logs attached

hookshot_log.1.txt: run 1, new game, black after the first cutscene
hookshot_log.txt: run 2, loading a save, black entering Kokiri Forest
hookshot_log_upscale_stub.txt: run 3, with RX_VK_FORCE_UPSCALE_STUB=1
hookshot_log_network_keep_none.txt: run 4, with RX_VK_NETWORK_KEEP=none
hookshot_log.2.txt: only the updater message from moving the device-lost-fix build to v2.0.2

If there's a switch to skip or bound 4b03b3040d7cf076, or a test build, I'm happy to try it. Thanks for the work on this!

hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.txt
hookshot_log_network_keep_none.txt
hookshot_log_upscale_stub.txt

Same problem here on an **Intel Arc B580** with **v2.0.2**. The logs show a Vulkan **device lost** at the same compute dispatch, **`4b03b3040d7cf076`**, in 3 of my 4 runs, which might help narrow it down. **System** - GPU: Intel Arc B580 (12 GB), driver 101.9175 (latest), Vulkan 1.4 - CPU: Intel Core i5-9600KF (6 cores / 6 threads), 32 GB RAM - OS: Windows 11 25H2 (build 26200) - Hookshot v2.0.2 (source 998ef8f9), built with Hookshot Builder from my own `.nup` dump **What happens** 1. **New game:** the logo and the first cutscene play, then the screen goes black. Audio keeps playing. 2. **Loading a save** made after the first cutscene: black screen when Kokiri Forest loads. I waited several minutes each time. The shaders were already prepared (`precompile: 4315 programs ... in 1276 ms`), and the big compute pipelines compile in the background (`dispatch of ... left out: its compute pipeline is still compiling`). So this seems to be a different problem from the shader-compile stall diagnosed earlier in this thread. **What the logs show** Every run ends with `VK_ERROR_DEVICE_LOST` (submit returns -4). In 3 of 4 runs the checkpoints stop at the same place: top of pipe at **`4b03b3040d7cf076`**, bottom of pipe at `ab7699ee7f536755`. So `ab7699ee7f536755` finished, and `4b03b3040d7cf076` started but never finished: ``` vk: submit 9745 failed (-4) vk: device lost: 2 checkpoints (25585 markers set) vk: stage 0x1: marker 25429 (dispatch of program 4b03b3040d7cf076, frame 1392) vk: before: dispatch of program ab7699ee7f536755 vk: before: dispatch of program 7984161db3e053b5 vk: before: dispatch of program 138596a0ca6720c8 vk: before: INDIRECT dispatch of program f0fed2bbccae7bdc vk: before: dispatch of program f0fed2bbccae7bdc vk: before: INDIRECT dispatch of program cb2e06ddfb9d7d27 vk: after: marker 25430 dispatch of program 755a777ada52677d, frame 1392 vk: stage 0x2000: marker 25428 (dispatch of program ab7699ee7f536755, frame 1392) ``` | Run | Log | Where | Top-of-pipe checkpoint | |---|---|---|---| | 1 | `hookshot_log.1.txt` | new game, after the first cutscene | `4b03b3040d7cf076` (frame 11612) | | 2 | `hookshot_log.txt` | save, entering Kokiri Forest | `4b03b3040d7cf076` (frame 1240) | | 3 | `hookshot_log_upscale_stub.txt` | save, entering Kokiri Forest | `592079442d7129da` (frame 1941) | | 4 | `hookshot_log_network_keep_none.txt` | save, entering Kokiri Forest | `4b03b3040d7cf076` (frame 1392) | On this card the matrix multiplies run in software (`the cooperative matrices lack 16x8x16 f16`), so at first I suspected the upscale network `fd029a317a9a4b94`, which is the only network kept on Intel. That doesn't seem to be it. With `RX_VK_NETWORK_KEEP=none` the network was left out and replaced by the linear upscale as intended, but the device was lost **before** it ever ran: ``` vk: submit 9745 failed (-4) <- device lost (line 1467) ... vk: program fd029a317a9a4b94 does not translate: its dispatch replaced by a linear upscale of 0x10000540200 1536x864 (vk 122) into 0x100121ffe00 2048x1152 (vk 122) (line 1566) ``` My guess, which I haven't confirmed: `4b03b3040d7cf076` hangs on Intel. It could be another unbounded loop like the compare-and-swap ones fixed for AMD and Intel in v2.0.2 (#548), or something in the software matrix-multiply path. It runs past the Windows GPU timeout (TDR, 2 s), and Windows resets the device. **What I tried** - `RX_VK_FORCE_UPSCALE_STUB=1`: still black (run 3). The network still ran. - `RX_VK_NETWORK_KEEP=none`: still black (run 4). The network was skipped, and the device was still lost at `4b03b3040d7cf076`. **Logs attached** - `hookshot_log.1.txt`: run 1, new game, black after the first cutscene - `hookshot_log.txt`: run 2, loading a save, black entering Kokiri Forest - `hookshot_log_upscale_stub.txt`: run 3, with `RX_VK_FORCE_UPSCALE_STUB=1` - `hookshot_log_network_keep_none.txt`: run 4, with `RX_VK_NETWORK_KEEP=none` - `hookshot_log.2.txt`: only the updater message from moving the `device-lost-fix` build to v2.0.2 If there's a switch to skip or bound `4b03b3040d7cf076`, or a test build, I'm happy to try it. Thanks for the work on this! [hookshot_log.1.txt](https://github.com/user-attachments/files/34553497/hookshot_log.1.txt) [hookshot_log.2.txt](https://github.com/user-attachments/files/34553499/hookshot_log.2.txt) [hookshot_log.txt](https://github.com/user-attachments/files/34553498/hookshot_log.txt) [hookshot_log_network_keep_none.txt](https://github.com/user-attachments/files/34553495/hookshot_log_network_keep_none.txt) [hookshot_log_upscale_stub.txt](https://github.com/user-attachments/files/34553496/hookshot_log_upscale_stub.txt)

Henrique143 commented

2026-11-08 21:54:08 +00:00

(Migrated from github.com)

Update: still happens on v2.0.4 (same B580, driver 101.9175, loading the same save into Kokiri Forest). The screen stays black.

Same device lost at the same program as before, 4b03b3040d7cf076, right after ab7699ee7f536755:

vk: submit 11936 failed (-4)
vk: device lost: 2 checkpoints (39462 markers set)
vk:   stage 0x1: marker 39309 (dispatch of program 4b03b3040d7cf076, frame 1705)
vk:     before: dispatch of program ab7699ee7f536755
vk:   stage 0x2000: marker 39308 (dispatch of program ab7699ee7f536755, frame 1705)

That makes 4 of my 5 device-lost runs that stop at 4b03b3040d7cf076. Log attached (hookshot_log_v2.0.4.txt). I'm happy to test a build or switch that skips or bounds 4b03b3040d7cf076.

hookshot_log_v2.0.4.txt

Update: still happens on **v2.0.4** (same B580, driver 101.9175, loading the same save into Kokiri Forest). The screen stays black. Same device lost at the same program as before, `4b03b3040d7cf076`, right after `ab7699ee7f536755`: ``` vk: submit 11936 failed (-4) vk: device lost: 2 checkpoints (39462 markers set) vk: stage 0x1: marker 39309 (dispatch of program 4b03b3040d7cf076, frame 1705) vk: before: dispatch of program ab7699ee7f536755 vk: stage 0x2000: marker 39308 (dispatch of program ab7699ee7f536755, frame 1705) ``` That makes 4 of my 5 device-lost runs that stop at `4b03b3040d7cf076`. Log attached (`hookshot_log_v2.0.4.txt`). I'm happy to test a build or switch that skips or bounds `4b03b3040d7cf076`. [hookshot_log_v2.0.4.txt](https://github.com/user-attachments/files/34555986/hookshot_log_v2.0.4.txt)

NotRexed commented

2026-11-09 05:50:35 +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.

Commenting is not possible because the repository is archived.