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

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:

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 Black screen after initial cutscenes on Intel Core Ultra 7 155H Intel Arc iGPU. #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 Leave the shader warm-up out only after two failed starts #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 Prepare: compute programs laid out as play lays them out; every compute program and its texture variants; predicted graphics pipelines #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.