#640 - [AMD RX 5500 XT / RDNA1] Missing Geometry Due to Unsupported Mesh Shaders — Lichii Compute Shader Fallback Works - MagicBeanDev/Hookshot

joao0205-lab commented

2026-11-08 15:21:50 +00:00

(Migrated from github.com)

The idea

[AMD RDNA1] Mesh Shader fallback request — RX 5500 XT renders missing geometry in Lichii

Hello Hookshot developers!

I'm using an AMD Radeon RX 5500 XT 8 GB (RDNA1), which does not support native Mesh Shaders.

Hookshot launches and runs on my PC, but significant parts of the environment are missing, including terrain, buildings, vegetation and certain objects.

I recently tested Lichii Build 117 on the same hardware and noticed an important difference:

Hookshot: Higher FPS, but some geometry is invisible.
Lichii Build 117: Lower FPS (around 15), but objects that were invisible in Hookshot are now visible.
Specific example: A box near the Great Deku Tree is visible in Lichii but invisible in Hookshot.

Lichii has an experimental Mesh Shader fallback implementation that uses Compute Shaders and a conventional graphics pipeline.

Relevant implementation:

Would it be technically feasible to implement a similar fallback in Hookshot for RDNA1 GPUs and other hardware without native Mesh Shader support?

I understand this may require significant work and could have performance limitations. However, even a slower fallback would be valuable if it allowed the missing geometry to render correctly.

I can provide screenshots comparing both projects on the same GPU.

My PC specifications:

GPU: AMD Radeon RX 5500 XT 8 GB
CPU: Intel Xeon E5-2650 v4 (12 cores / 24 threads)
RAM: 16 GB
Graphics API: Vulkan

Thank you for your work and for considering compatibility with older GPUs!

Anything else

No response

### The idea ## [AMD RDNA1] Mesh Shader fallback request — RX 5500 XT renders missing geometry in Lichii Hello Hookshot developers! I'm using an **AMD Radeon RX 5500 XT 8 GB (RDNA1)**, which does not support native Mesh Shaders. Hookshot launches and runs on my PC, but significant parts of the environment are missing, including terrain, buildings, vegetation and certain objects. I recently tested **Lichii Build 117** on the same hardware and noticed an important difference: - **Hookshot:** Higher FPS, but some geometry is invisible. - **Lichii Build 117:** Lower FPS (around 15), but objects that were invisible in Hookshot are now visible. - **Specific example:** A box near the Great Deku Tree is visible in Lichii but invisible in Hookshot. Lichii has an experimental Mesh Shader fallback implementation that uses Compute Shaders and a conventional graphics pipeline. Relevant implementation: <img width="1366" height="768" alt="Image" src="https://github.com/user-attachments/assets/ef3ad74d-c541-46eb-9244-97fb0d1908f7" /> <img width="1366" height="768" alt="Image" src="https://github.com/user-attachments/assets/e8f76555-27cf-4d7f-9735-d1ea10b0c3e1" /> Would it be technically feasible to implement a similar fallback in Hookshot for RDNA1 GPUs and other hardware without native Mesh Shader support? I understand this may require significant work and could have performance limitations. However, even a slower fallback would be valuable if it allowed the missing geometry to render correctly. I can provide screenshots comparing both projects on the same GPU. **My PC specifications:** - GPU: AMD Radeon RX 5500 XT 8 GB - CPU: Intel Xeon E5-2650 v4 (12 cores / 24 threads) - RAM: 16 GB - Graphics API: Vulkan Thank you for your work and for considering compatibility with older GPUs! ### Anything else _No response_

shayderrr commented

2026-11-08 15:23:17 +00:00

(Migrated from github.com)

I'll work on this

shayderrr commented

2026-11-08 16:58:43 +00:00

(Migrated from github.com)

Fixed

Nitnek commented

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

(Migrated from github.com)

Found what #640 changes on a GPU that has mesh shaders (re: the revert in 806c566). In build_graphics() (gpu/vk/vk_draw.cpp), the new stage filter is not limited to fallback programs:

for (const Stage& st : p.stages) {
    if (st.vk_stage & (VK_SHADER_STAGE_COMPUTE_BIT | VK_SHADER_STAGE_TASK_BIT_EXT | VK_SHADER_STAGE_MESH_BIT_EXT))
        continue;   // (hookshot: the fallback's dispatches are not graphics stages)

With native mesh shaders, the task and mesh stages are the pipeline's own stages, so every mesh program gets built with only its fragment stage. In the fallback, those stages are already VK_SHADER_STAGE_COMPUTE_BIT, so the TASK/MESH bits only ever match native mesh programs. This one-line change fixes it here:

if (p.fallback && (st.vk_stage & (VK_SHADER_STAGE_COMPUTE_BIT | VK_SHADER_STAGE_TASK_BIT_EXT | VK_SHADER_STAGE_MESH_BIT_EXT)))
    continue;

Tested on an RTX 3070 8 GB, Windows, main at 2ff3cff (before the revert), loading an autosave at the Kakariko gate:

build	GPU time a frame	fps	grass / foliage	device lost
`2ff3cff`	11 ms, then 157–240 ms after ~30 s	6	missing	in several runs
`2ff3cff` + the change above	13 ms, steady over ~4 min	44	back	no
`ea4eced` with its `gpu/vk/*.cpp/.h` part reverted (SPIR-V part kept)	13 ms	44	back	no

I found it by bisecting with timed input and the GPU time log line. The slowdown shows only when the save is loaded soon after the title screen. A run that waited about 100 s on the title stayed fast, which hid it in my first bisect. The RX_VK_GPU_PROFILE=1 breakdown during the slow frames shows all the 1536x864 colour+depth passes 5–10x slower, not a single program. That fits invalid mesh pipelines rather than a shader that is simply expensive.

One more thing for #352 and #422: with #640 in, the floating Death Mountain trees were gone too, but only because nothing drawn by mesh programs was drawn anymore (grass, leaves, those trees). With the fix, the floating trees are back, so those two issues are still open.

Found what #640 changes on a GPU that has mesh shaders (re: the revert in `806c566`). In `build_graphics()` (`gpu/vk/vk_draw.cpp`), the new stage filter is not limited to fallback programs: ```cpp for (const Stage& st : p.stages) { if (st.vk_stage & (VK_SHADER_STAGE_COMPUTE_BIT | VK_SHADER_STAGE_TASK_BIT_EXT | VK_SHADER_STAGE_MESH_BIT_EXT)) continue; // (hookshot: the fallback's dispatches are not graphics stages) ``` With native mesh shaders, the task and mesh stages are the pipeline's own stages, so every mesh program gets built with only its fragment stage. In the fallback, those stages are already `VK_SHADER_STAGE_COMPUTE_BIT`, so the TASK/MESH bits only ever match native mesh programs. This one-line change fixes it here: ```cpp if (p.fallback && (st.vk_stage & (VK_SHADER_STAGE_COMPUTE_BIT | VK_SHADER_STAGE_TASK_BIT_EXT | VK_SHADER_STAGE_MESH_BIT_EXT))) continue; ``` Tested on an RTX 3070 8 GB, Windows, `main` at `2ff3cff` (before the revert), loading an autosave at the Kakariko gate: | build | GPU time a frame | fps | grass / foliage | device lost | |---|---|---|---|---| | `2ff3cff` | 11 ms, then 157–240 ms after ~30 s | 6 | missing | in several runs | | `2ff3cff` + the change above | 13 ms, steady over ~4 min | 44 | back | no | | `ea4eced` with its `gpu/vk/*.cpp/.h` part reverted (SPIR-V part kept) | 13 ms | 44 | back | no | I found it by bisecting with timed input and the `GPU time` log line. The slowdown shows only when the save is loaded soon after the title screen. A run that waited about 100 s on the title stayed fast, which hid it in my first bisect. The `RX_VK_GPU_PROFILE=1` breakdown during the slow frames shows all the 1536x864 colour+depth passes 5–10x slower, not a single program. That fits invalid mesh pipelines rather than a shader that is simply expensive. One more thing for #352 and #422: with #640 in, the floating Death Mountain trees were gone too, but only because nothing drawn by mesh programs was drawn anymore (grass, leaves, those trees). With the fix, the floating trees are back, so those two issues are still open.

hckrman101 commented

2026-11-08 21:30:10 +00:00

(Migrated from github.com)

#792 brings back the compute fallback for GPUs without mesh shaders (ea4eced, reverted in 806c566 / b11058c). It also fixes the device loss on GPUs that do have mesh shaders, which caused the revert. It hasn't been tested on a real RDNA1 card, so a run on an RX 5500 XT would help.

#792 brings back the compute fallback for GPUs without mesh shaders (ea4eced, reverted in 806c566 / b11058c). It also fixes the device loss on GPUs that do have mesh shaders, which caused the revert. It hasn't been tested on a real RDNA1 card, so a run on an RX 5500 XT would help.

JimLee0629 commented

2026-11-08 23:42:07 +00:00

(Migrated from github.com)

I just tested this on an RX 5500 XT, but the rendering issue persists—many models are still missing, making it unplayable.

github-sync referenced this issue

2026-11-12 06:25:49 +00:00

Montains not rendering and some light flashings #422

github-sync referenced this issue

2026-11-12 06:26:00 +00:00

Reland the mesh shader fallback with its graphics stage filter limited to fallback programs #779

github-sync commented

2026-11-12 06:27:10 +00:00

Owner

@Mcnelius commented on GitHub · 2026-11-12 06:26 UTC · original

tengo un ryzen 5 5600x, una rx580 de 8gb, 16 de ram, el juego abre, pero se van los fps por el suelo, no suben de 4fps.

> [@Mcnelius](https://github.com/Mcnelius) commented on GitHub · 2026-11-12 06:26 UTC · [original](https://github.com/NotRexed/Hookshot/issues/640#issuecomment-6816445834) tengo un ryzen 5 5600x, una rx580 de 8gb, 16 de ram, el juego abre, pero se van los fps por el suelo, no suben de 4fps.

Rows
Columns

[AMD RX 5500 XT / RDNA1] Missing Geometry Due to Unsupported Mesh Shaders — Lichii Compute Shader Fallback Works #640

The idea

[AMD RDNA1] Mesh Shader fallback request — RX 5500 XT renders missing geometry in Lichii

Anything else