Linux, Intel Arc iGPU (Meteor Lake), 32 GB: the first start's shader preparation is OOM-killed at ~28 GiB, every start (v2.0.3, v2.0.2) #775

Closed

opened 2026-11-08 20:49:56 +00:00 by 6a6f7368-2 · 2 comments

6a6f7368-2 commented

2026-11-08 20:49:56 +00:00

(Migrated from github.com)

Hookshot version

v2.0.3 (Linux AppImage from the release; log: hookshot v2.0.3 (source 917a0ccb)), and the same on v2.0.2.

What kind of problem

Crash, freeze or black screen

What happened

Both builds went fine: --cli from my dump (update v131072, build e0f3ccfa, --check OK) with HOOKSHOT_JOBS=12, 13.5 minutes for v2.0.3, @@done. The game itself never got past the first start's shader preparation. This machine has 30.8 GiB of RAM and no swap, and the kernel's OOM killer ended every start that ran it: two on v2.0.3, three on v2.0.2. Before each kill, RSS went from 5-10 GiB to 26-29 GiB within 4 to 17 seconds.

RSS was sampled every ~4 s, timed from when the game was launched:

Version, start	Step running	RSS before the kill	Killed (anon-rss)
v2.0.3, 1st	`prepare_run`: translation with the driver warm-up, 11 workers (`cpus/2`)	5.0 GiB at 33 s, 15.8 GiB at 37 s	between 37 and 41 s (28.3 GiB)
v2.0.3, 2nd	warm-up left out; translation (`... in 36.7 s`), then `precompile_run`, 22 workers	1.8 GiB to 45 s, then 9.0 at 57 s, 13.4 at 62 s, 22.3 at 66 s	between 66 and 70 s (28.2 GiB)
v2.0.2, 1st	the warm-up, as above	4.7 GiB at 54 s, 9.9 GiB at 58 s	between 58 and 62 s (28.6 GiB)
v2.0.2, 2nd	translation (`... in 32.5 s`), then the precompile	7-12 GiB for 6 minutes, then 17.2 at 424 s, 25.9 at 432 s	between 453 and 458 s (27.6 GiB)
v2.0.2, 3rd	the precompile again, with the game shown only 8 CPUs	4.75 GiB at 21 s, 22.2 GiB at 29 s (26.6 GiB peak by then)	between 29 and 33 s (27.6 GiB)

The log lines, in order: on the 2nd start the last start did not finish the driver's part of the shaders: left out, then prepared 31985 shader programs (39417 new, 0 failed, 0 stage libraries) in 36.7 s (32.5 s on v2.0.2), then nothing until the kill. On v2.0.2's 3rd start, the last start did not get through the precompile (closed, or it crashed there): trying it once more and program cache ...: 39842 program keys kept, 5652241 KB.

Out of memory: Killed process 5621 (hookshot) total-vm:569259164kB, anon-rss:29684184kB ...   (v2.0.3, 1st)
Out of memory: Killed process 7427 (hookshot) total-vm:570287796kB, anon-rss:29570448kB ...   (v2.0.3, 2nd)
Out of memory: Killed process 22930 (hookshot) total-vm:569621292kB, anon-rss:29988480kB ...  (v2.0.2, 1st)
Out of memory: Killed process 25896 (hookshot) total-vm:570082932kB, anon-rss:28915552kB ...  (v2.0.2, 2nd)
Out of memory: Killed process 7455 (hookshot) total-vm:569343952kB, anon-rss:28955820kB ...   (v2.0.2, 3rd)

For v2.0.2's 3rd start I limited the CPUs the game sees to 8: the CPU affinity, plus /sys/devices/system/cpu/online = 0-7 in its own mount namespace, so std::thread::hardware_concurrency() should return 8 (the thread count, 38 against 55 on the 2nd start, fits that). It still died, with RSS going from 4.75 to 26.6 GiB within 8 seconds, just before the kill. So it isn't only the number of workers: it looks like one or a few huge compiles.

As far as I can read precompile_run, with no notes yet (the game never drew in these starts) it builds every kept compute program: program_cache_load_some() takes every record whose kind has bit 0 set (vk_shader.cpp, compute), all loaded before the workers start. I think the jumps come from the driver compiling some of them. But nothing is logged inside the precompile, so I can't tell which builds were running.

For comparison, #748 (Arc B390 / Panther Lake, Mesa 26.2.5, also Linux and 32 GB) got through the same preparation, warm-up included (prepared 31985 shader programs (39842 new, 0 failed, 3808 stage libraries) in 652.8 s). Since my 8-CPU start still died, this may come down to Mesa 25.3.6 or to Meteor Lake rather than the number of workers. This machine has no /dev/udmabuf, so v2.0.3 logs mem: guest memory stays host-pointer imports for the GPU ... /dev/udmabuf cannot be opened: its new memory path wasn't in play here.

Three things made it worse:

Nothing on screen on Linux. The window and swapchain already exist (the log has vk: swapchain 1920x1080 before this step), but nothing is presented while it runs. The progress callback writes "Preparing shaders: N of M" to a console from AllocConsole(), which is return FALSE in host/posix/windows.h. So my frontend's (Batocera/EmulationStation) loading screen stayed up for between about half a minute and 7.5 minutes, and then the game was gone.
The retry rule doesn't stop it. After two starts die in the precompile, the next start drops the notes (hookshot_pipelines.bin) and skips the step. As I read it, the compute list doesn't come from the notes, so the start after that builds the same compute pipelines and dies again: only every third start would skip it. I didn't try that start. Since prepare_run is stamped as done by then, it should behave like RX_VK_PRECOMPILE=0, which reaches the black screen I describe in #366.
The warm-up stays out once it's out. After one start dies in it, it's left out for the whole version (the hookshot_prepared.bin stamp). Its compute builds then happen in the precompile instead: on all 22 CPUs rather than 11, in a step that never stamps them out (item 2). PR #701 changes when the warm-up is left out (after two failed starts). Where it dies every time, that's one more killed start. PR #772 would have this step build 10,340 compute pipelines instead of 3,808. Here, the warm-up and the precompile already die building the current set.

What I expected: the preparation finishing, or being sized to the memory there is, as the builder already does for its compilers.

Workaround for the preparation: RX_VK_PRECOMPILE=0. The game then reaches the title about 35 s after launch and plays the opening at 60 fps most of the time (brief dips to about 45). But it goes black at the first frame of the world: details in #366. Creating hookshot_prepare_skipped beside the game should also skip the step (not tried).

Suggestions, in case they help:

log which program each worker starts (or note it in the .running file), so a start that dies names the build it died in, and the next start can leave just that one out;
start the warm-up's and the precompile's workers by free memory, not by CPU count;
on Linux, print the progress to stderr, and draw it in the window, which is already open;
once the precompile has died twice, leave its compute builds out too, or stamp it for the version as hookshot_prepared.bin does.

Where in the game

Before the title, on the first start after a build.

How often

Every time

Graphics card and driver version

Intel Arc Graphics (Meteor Lake iGPU), Mesa 25.3.6 ANV (Mesa's Intel Vulkan driver), Vulkan 1.4.328, i915 kernel driver. The log: vk: Intel(R) Arc(tm) Graphics (MTL), Vulkan 1.4, driver 0x6403006; mesh shaders yes, host memory import yes, pipeline libraries yes

CPU, RAM and operating system

Intel Core Ultra 7 155H (22 threads), 30.8 GiB RAM, no swap. Batocera 43 (glibc 2.40), Linux 6.18.16, X11 (openbox). The game is started by a script from its folder (bin/hookshot on v2.0.3, not --play), with stderr going to a file, and without network.

Changes from the defaults

No hookshot_env.txt. In hookshot_options.ini: fullscreen=1 and fps_counter=1. In the environment: HOS_SDL_VERSION=2 and HOOKSHOT_NO_UPDATE_CHECK=1 (v2.0.3). For v2.0.2's 3rd start, the 8-CPU limit above. For the workaround runs, RX_VK_PRECOMPILE=0.

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

I can't attach files from where I post this, so the lines that matter are quoted above. I can attach the full logs if you want them.

Screenshots or video

None: the screen showed my frontend's loading screen the whole time.

Before you send it

I'm on the newest release, or the problem is still there on it.
I searched the open issues for this problem.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

### Hookshot version v2.0.3 (Linux AppImage from the release; log: `hookshot v2.0.3 (source 917a0ccb)`), and the same on v2.0.2. ### What kind of problem Crash, freeze or black screen ### What happened Both builds went fine: `--cli` from my dump (update v131072, build e0f3ccfa, `--check` OK) with `HOOKSHOT_JOBS=12`, 13.5 minutes for v2.0.3, `@@done`. The game itself never got past the first start's shader preparation. This machine has 30.8 GiB of RAM and no swap, and the kernel's OOM killer ended every start that ran it: two on v2.0.3, three on v2.0.2. Before each kill, RSS went from 5-10 GiB to 26-29 GiB within 4 to 17 seconds. RSS was sampled every ~4 s, timed from when the game was launched: | Version, start | Step running | RSS before the kill | Killed (anon-rss) | |---|---|---|---| | v2.0.3, 1st | `prepare_run`: translation with the driver warm-up, 11 workers (`cpus/2`) | 5.0 GiB at 33 s, 15.8 GiB at 37 s | between 37 and 41 s (28.3 GiB) | | v2.0.3, 2nd | warm-up left out; translation (`... in 36.7 s`), then `precompile_run`, 22 workers | 1.8 GiB to 45 s, then 9.0 at 57 s, 13.4 at 62 s, 22.3 at 66 s | between 66 and 70 s (28.2 GiB) | | v2.0.2, 1st | the warm-up, as above | 4.7 GiB at 54 s, 9.9 GiB at 58 s | between 58 and 62 s (28.6 GiB) | | v2.0.2, 2nd | translation (`... in 32.5 s`), then the precompile | 7-12 GiB for 6 minutes, then 17.2 at 424 s, 25.9 at 432 s | between 453 and 458 s (27.6 GiB) | | v2.0.2, 3rd | the precompile again, with the game shown only **8** CPUs | 4.75 GiB at 21 s, 22.2 GiB at 29 s (26.6 GiB peak by then) | between 29 and 33 s (27.6 GiB) | The log lines, in order: on the 2nd start `the last start did not finish the driver's part of the shaders: left out`, then `prepared 31985 shader programs (39417 new, 0 failed, 0 stage libraries) in 36.7 s` (32.5 s on v2.0.2), then nothing until the kill. On v2.0.2's 3rd start, `the last start did not get through the precompile (closed, or it crashed there): trying it once more` and `program cache ...: 39842 program keys kept, 5652241 KB`. ``` Out of memory: Killed process 5621 (hookshot) total-vm:569259164kB, anon-rss:29684184kB ... (v2.0.3, 1st) Out of memory: Killed process 7427 (hookshot) total-vm:570287796kB, anon-rss:29570448kB ... (v2.0.3, 2nd) Out of memory: Killed process 22930 (hookshot) total-vm:569621292kB, anon-rss:29988480kB ... (v2.0.2, 1st) Out of memory: Killed process 25896 (hookshot) total-vm:570082932kB, anon-rss:28915552kB ... (v2.0.2, 2nd) Out of memory: Killed process 7455 (hookshot) total-vm:569343952kB, anon-rss:28955820kB ... (v2.0.2, 3rd) ``` For v2.0.2's 3rd start I limited the CPUs the game sees to 8: the CPU affinity, plus `/sys/devices/system/cpu/online` = `0-7` in its own mount namespace, so `std::thread::hardware_concurrency()` should return 8 (the thread count, 38 against 55 on the 2nd start, fits that). It still died, with RSS going from 4.75 to 26.6 GiB within 8 seconds, just before the kill. So it isn't only the number of workers: it looks like one or a few huge compiles. As far as I can read `precompile_run`, with no notes yet (the game never drew in these starts) it builds every kept compute program: `program_cache_load_some()` takes every record whose kind has bit 0 set (`vk_shader.cpp`, compute), all loaded before the workers start. I think the jumps come from the driver compiling some of them. But nothing is logged inside the precompile, so I can't tell which builds were running. For comparison, #748 (Arc B390 / Panther Lake, Mesa 26.2.5, also Linux and 32 GB) got through the same preparation, warm-up included (`prepared 31985 shader programs (39842 new, 0 failed, 3808 stage libraries) in 652.8 s`). Since my 8-CPU start still died, this may come down to Mesa 25.3.6 or to Meteor Lake rather than the number of workers. This machine has no `/dev/udmabuf`, so v2.0.3 logs `mem: guest memory stays host-pointer imports for the GPU ... /dev/udmabuf cannot be opened`: its new memory path wasn't in play here. Three things made it worse: 1. **Nothing on screen on Linux.** The window and swapchain already exist (the log has `vk: swapchain 1920x1080` before this step), but nothing is presented while it runs. The progress callback writes "Preparing shaders: N of M" to a console from `AllocConsole()`, which is `return FALSE` in `host/posix/windows.h`. So my frontend's (Batocera/EmulationStation) loading screen stayed up for between about half a minute and 7.5 minutes, and then the game was gone. 2. **The retry rule doesn't stop it.** After two starts die in the precompile, the next start drops the notes (`hookshot_pipelines.bin`) and skips the step. As I read it, the compute list doesn't come from the notes, so the start after that builds the same compute pipelines and dies again: only every third start would skip it. I didn't try that start. Since `prepare_run` is stamped as done by then, it should behave like `RX_VK_PRECOMPILE=0`, which reaches the black screen I describe in #366. 3. **The warm-up stays out once it's out.** After one start dies in it, it's left out for the whole version (the `hookshot_prepared.bin` stamp). Its compute builds then happen in the precompile instead: on all 22 CPUs rather than 11, in a step that never stamps them out (item 2). PR #701 changes when the warm-up is left out (after two failed starts). Where it dies every time, that's one more killed start. PR #772 would have this step build 10,340 compute pipelines instead of 3,808. Here, the warm-up and the precompile already die building the current set. What I expected: the preparation finishing, or being sized to the memory there is, as the builder already does for its compilers. **Workaround for the preparation:** `RX_VK_PRECOMPILE=0`. The game then reaches the title about 35 s after launch and plays the opening at 60 fps most of the time (brief dips to about 45). But it goes black at the first frame of the world: details in #366. Creating `hookshot_prepare_skipped` beside the game should also skip the step (not tried). Suggestions, in case they help: - log which program each worker starts (or note it in the `.running` file), so a start that dies names the build it died in, and the next start can leave just that one out; - start the warm-up's and the precompile's workers by free memory, not by CPU count; - on Linux, print the progress to stderr, and draw it in the window, which is already open; - once the precompile has died twice, leave its compute builds out too, or stamp it for the version as `hookshot_prepared.bin` does. ### Where in the game Before the title, on the first start after a build. ### How often Every time ### Graphics card and driver version Intel Arc Graphics (Meteor Lake iGPU), Mesa 25.3.6 ANV (Mesa's Intel Vulkan driver), Vulkan 1.4.328, i915 kernel driver. The log: `vk: Intel(R) Arc(tm) Graphics (MTL), Vulkan 1.4, driver 0x6403006; mesh shaders yes, host memory import yes, pipeline libraries yes` ### CPU, RAM and operating system Intel Core Ultra 7 155H (22 threads), 30.8 GiB RAM, no swap. Batocera 43 (glibc 2.40), Linux 6.18.16, X11 (openbox). The game is started by a script from its folder (`bin/hookshot` on v2.0.3, not `--play`), with stderr going to a file, and without network. ### Changes from the defaults No `hookshot_env.txt`. In `hookshot_options.ini`: `fullscreen=1` and `fps_counter=1`. In the environment: `HOS_SDL_VERSION=2` and `HOOKSHOT_NO_UPDATE_CHECK=1` (v2.0.3). For v2.0.2's 3rd start, the 8-CPU limit above. For the workaround runs, `RX_VK_PRECOMPILE=0`. ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt I can't attach files from where I post this, so the lines that matter are quoted above. I can attach the full logs if you want them. ### Screenshots or video None: the screen showed my frontend's loading screen the whole time. ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

6a6f7368-2 commented

2026-11-08 23:28:31 +00:00

(Migrated from github.com)

Full logs from the v2.0.3 runs: run 7 (first-start preparation, killed when it ran out of memory), run 9 (preparation off: stalls at the world's first frame), run 10 (RX_VK_NO_SUBGROUP_PIN=1: gets past that pipeline, then a later build stalls).

Full logs from the v2.0.3 runs: run 7 (first-start preparation, killed when it ran out of memory), run 9 (preparation off: stalls at the world's first frame), run 10 (`RX_VK_NO_SUBGROUP_PIN=1`: gets past that pipeline, then a later build stalls). - [hookshot_log-v2.0.3-run7-preparation-oom.txt](https://github.com/user-attachments/files/34557474/hookshot_log-v2.0.3-run7-preparation-oom.txt) - [hookshot_log-v2.0.3-run9-precompile-off.txt](https://github.com/user-attachments/files/34557475/hookshot_log-v2.0.3-run9-precompile-off.txt) - [hookshot_log-v2.0.3-run10-no-subgroup-pin.txt](https://github.com/user-attachments/files/34557476/hookshot_log-v2.0.3-run10-no-subgroup-pin.txt)

NotRexed commented

2026-11-09 05:56:37 +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.