Game: on a Steam Deck the Kokiri Forest hang does not come back without RX_VK_MESH_NOCULL (main `9c9d69ed`), and the line costs 2 to 10% of the GPU time #579

New issue

Open

opened 2026-11-14 20:30:08 +00:00 by p0lux · 0 comments

p0lux commented

2026-11-14 20:30:08 +00:00

Contributor

The README, docs/common-issues.md and docs/development.md tell every Steam Deck player to add RX_VK_MESH_NOCULL=2c56dc1006942f74 to longshot_env.txt, against the hang of https://github.com/NotRexed/Hookshot/issues/817 (gfx_0.0.0 timeout in Kokiri Forest or the Great Deku Tree). On this Deck the hang no longer comes back without the line, and the line costs GPU time. One Deck is not enough to change the advice, so this asks for a second one.

Longshot version

Game and host built from main 9c9d69ed (v2.1.0-rc.3-463-g9c9d69ed). The renderer is that main with the renderer-only changes of open pull requests (#391, #384, #387, #223, #567, #568; built with ThinLTO). None of them changes gpu/vk/vk_shader.cpp, where the task shaders are translated and mesh_nocull_wanted lives.

What happened

The hang was real here. On 2026-11-10, on a Hookshot build of that day, the line was taken out once: loading Kokiri Forest gave ring gfx_0.0.0 timeout in journalctl -k, a GPU reset and VK_ERROR_DEVICE_LOST. It was the only run without the line that day and the only reset.
It has not come back without the line, on 2026-11-14, on the build above:
- without a screen: the shaders prepared again for the setting (no culling off line in the log any more), then a Kokiri Forest save loaded twice, 720 presents each: no error, 0 GPU timeouts in the kernel's log;
- in play, by a person on the Deck's screen: Kokiri Forest, then into the Great Deku Tree: no freeze, no crash. Only the tree's first rooms had been visited when this was written.
Earlier runs without the line, 12 and 13 November, on a build of Hookshot's main of those days with local renderer changes: Hyrule Field, a heavy view, a Kokiri Forest load and a 240 s camera turn there: no GPU timeout.
The log says the mesh programs run as compute shaders on this Deck:

vk: no mesh shaders: task and mesh programs run as compute shaders (issue 640 fallback)
vk: mesh shaders: Automatic, from the default: the compute path

I do not know that this is why the hang is gone. mesh_nocull_wanted's comment gives the cause as the culling shader's walk over a depth grid, and does not tie it to the native mesh path.

What the line costs

GPU time a frame, with the line then without (culling off, every meshlet drawn against the game's own culling):

	with the line	without
Kokiri Forest, standing still, 14 November (single runs)	20.93 ms	19.30 / 18.98 ms
Kokiri Forest, standing still, 13 November	21.5 to 21.8 ms	19.3 to 19.6 ms
Hyrule Field, 12 November	24.8 to 24.9 ms	24.24 ms
a heavy view, 12 November	20.0 to 20.1 ms	19.38 ms
a camera turn, 12 November	about 17.0 ms	16.22 ms

That is 2 to 5% of the GPU time, and 8 to 10% in Kokiri Forest. It is not a frame rate gain where the replay thread is the limit: in Kokiri Forest the single runs of 14 November gave 26.58 fps with the line and 25.59 / 25.27 without (that scene varies that much from run to run), and 25.06 against 24.84 on the 13th. In Hyrule Field, where the GPU counts for more, it was 25.64 fps without against 24.80 to 25.47 with.

Where in the game

Kokiri Forest and the Great Deku Tree, the two places the README names.

Graphics card, CPU, RAM and operating system

Steam Deck OLED: AMD Custom APU 0932 (RADV VANGOGH), Mesa 26.2.0-devel, 16 GB, SteamOS 3.9.5, kernel 7.2.7-valve2; the GPU's clock fixed at 1600 MHz.

Changes from the defaults

Minimum preset (RX_VK_LOW_SPEC=1), handheld profile (HOS_HANDHELD=1), the game's own upscaler, RX_VK_VRAM_MB=2400, RX_VK_TEX_MAX_DIM=1024, RX_VK_LOAD=create, HOS_RESERVE_CORE=0, RX_VK_MESH_OPT=1; RX_VK_MESH_NOCULL commented out.

What is not known

One Steam Deck OLED. No Steam Deck LCD, no other RDNA 2 GPU.
The Great Deku Tree was only entered; no long session without the line yet; Kakariko and the other dungeons not visited.
The hang of 10 November was seen once, on another build. Nothing here says which change since then removed it.

What would help

Another Steam Deck player on a current main: take the line out (the first start prepares the shaders again, about 4 minutes), walk through Kokiri Forest and into the Great Deku Tree, then say whether journalctl -k | grep -i timeout shows gfx_0.0.0 timeout.
If it holds, the three places in the docs could give the line as the fix for a Deck that does hang rather than as a line every Deck should add. I can send that change.

The README, `docs/common-issues.md` and `docs/development.md` tell every Steam Deck player to add `RX_VK_MESH_NOCULL=2c56dc1006942f74` to `longshot_env.txt`, against the hang of https://github.com/NotRexed/Hookshot/issues/817 (`gfx_0.0.0 timeout` in Kokiri Forest or the Great Deku Tree). On this Deck the hang no longer comes back without the line, and the line costs GPU time. One Deck is not enough to change the advice, so this asks for a second one. ## Longshot version Game and host built from main 9c9d69ed (`v2.1.0-rc.3-463-g9c9d69ed`). The renderer is that main with the renderer-only changes of open pull requests (#391, #384, #387, #223, #567, #568; built with ThinLTO). None of them changes `gpu/vk/vk_shader.cpp`, where the task shaders are translated and `mesh_nocull_wanted` lives. ## What happened - **The hang was real here.** On 2026-11-10, on a Hookshot build of that day, the line was taken out once: loading Kokiri Forest gave `ring gfx_0.0.0 timeout` in `journalctl -k`, a GPU reset and `VK_ERROR_DEVICE_LOST`. It was the only run without the line that day and the only reset. - **It has not come back without the line**, on 2026-11-14, on the build above: - without a screen: the shaders prepared again for the setting (no `culling off` line in the log any more), then a Kokiri Forest save loaded twice, 720 presents each: no error, 0 GPU timeouts in the kernel's log; - in play, by a person on the Deck's screen: Kokiri Forest, then into the Great Deku Tree: no freeze, no crash. Only the tree's first rooms had been visited when this was written. - **Earlier runs without the line**, 12 and 13 November, on a build of Hookshot's main of those days with local renderer changes: Hyrule Field, a heavy view, a Kokiri Forest load and a 240 s camera turn there: no GPU timeout. - The log says the mesh programs run as compute shaders on this Deck: ``` vk: no mesh shaders: task and mesh programs run as compute shaders (issue 640 fallback) vk: mesh shaders: Automatic, from the default: the compute path ``` I do not know that this is why the hang is gone. `mesh_nocull_wanted`'s comment gives the cause as the culling shader's walk over a depth grid, and does not tie it to the native mesh path. ## What the line costs GPU time a frame, with the line then without (`culling off, every meshlet drawn` against the game's own culling): | | with the line | without | |---|---|---| | Kokiri Forest, standing still, 14 November (single runs) | 20.93 ms | 19.30 / 18.98 ms | | Kokiri Forest, standing still, 13 November | 21.5 to 21.8 ms | 19.3 to 19.6 ms | | Hyrule Field, 12 November | 24.8 to 24.9 ms | 24.24 ms | | a heavy view, 12 November | 20.0 to 20.1 ms | 19.38 ms | | a camera turn, 12 November | about 17.0 ms | 16.22 ms | That is 2 to 5% of the GPU time, and 8 to 10% in Kokiri Forest. It is not a frame rate gain where the replay thread is the limit: in Kokiri Forest the single runs of 14 November gave 26.58 fps with the line and 25.59 / 25.27 without (that scene varies that much from run to run), and 25.06 against 24.84 on the 13th. In Hyrule Field, where the GPU counts for more, it was 25.64 fps without against 24.80 to 25.47 with. ## Where in the game Kokiri Forest and the Great Deku Tree, the two places the README names. ## Graphics card, CPU, RAM and operating system Steam Deck OLED: AMD Custom APU 0932 (RADV VANGOGH), Mesa 26.2.0-devel, 16 GB, SteamOS 3.9.5, kernel 7.2.7-valve2; the GPU's clock fixed at 1600 MHz. ## Changes from the defaults Minimum preset (`RX_VK_LOW_SPEC=1`), handheld profile (`HOS_HANDHELD=1`), the game's own upscaler, `RX_VK_VRAM_MB=2400`, `RX_VK_TEX_MAX_DIM=1024`, `RX_VK_LOAD=create`, `HOS_RESERVE_CORE=0`, `RX_VK_MESH_OPT=1`; `RX_VK_MESH_NOCULL` commented out. ## What is not known - One Steam Deck OLED. No Steam Deck LCD, no other RDNA 2 GPU. - The Great Deku Tree was only entered; no long session without the line yet; Kakariko and the other dungeons not visited. - The hang of 10 November was seen once, on another build. Nothing here says which change since then removed it. ## What would help - Another Steam Deck player on a current main: take the line out (the first start prepares the shaders again, about 4 minutes), walk through Kokiri Forest and into the Great Deku Tree, then say whether `journalctl -k | grep -i timeout` shows `gfx_0.0.0 timeout`. - If it holds, the three places in the docs could give the line as the fix for a Deck that does hang rather than as a line every Deck should add. I can send that change.