MagicBeanDev/Longshot

Watch

Fork 101

fix(vk): the device line says whether the driver offers mesh shaders, not only whether this run uses them #865

Open

zeldaootr wants to merge 2 commits from zeldaootr/Longshot:log-mesh-capable into main

zeldaootr commented

2026-11-15 18:08:03 +00:00

Contributor

Type: fix · Risk: low · Tested on: Linux, the game-free checks (no GPU) · Needs: none

Why

On a Steam Deck every log says mesh shaders no and vk: no mesh shaders: task and mesh programs run as compute shaders, although its driver (RADV) offers mesh shaders: Longshot leaves them unused on Linux AMD on purpose (Automatic takes the compute path there: https://github.com/NotRexed/Hookshot/issues/2245). People, us included, read those lines as "the Deck's driver has no mesh shaders" and drew the wrong conclusions about what the Deck can do. The log knew the driver's answer (dev.mesh_capable) and never said it.

How to reproduce

Seen on: Steam Deck, SteamOS, RADV VANGOGH (Mesa)
Settings and switches: defaults
Steps: start the game and read the vk: lines near the top of longshot_log.txt
Expected: the log says the driver offers mesh shaders and that this run does not use them, and why
Actual: on main:

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
vk: AMD Custom GPU 0932 (RADV VANGOGH), Vulkan 1.4, driver 0x6801063; mesh shaders no, host memory import yes, pipeline libraries yes

What changed

The log states both facts: whether the driver offers mesh shaders, and whether this run uses them. On a Steam Deck with the defaults the three lines become:

vk: mesh shaders offered by the driver but not used: task and mesh programs run as compute shaders (issue 640 fallback)
vk: mesh shaders: Automatic, from the default: the compute path (Linux AMD: RADV's own can hang the GPU, issue 2245)
vk: AMD Custom GPU 0932 (RADV VANGOGH), Vulkan 1.4, driver 0x6801063; mesh shaders offered by the driver but not used (Automatic runs Linux AMD on the compute path: RX_VK_MESH_SHADERS=native to try), host memory import yes, pipeline libraries yes

Elsewhere the device line's field reads used (it said yes), offered by the driver but not used (Compute chosen) under RX_VK_MESH_SHADERS=compute or RX_VK_FORCE_MESH_FALLBACK=1, or not offered by the driver (an RX 5000, a GTX 10). What runs is unchanged.

vk: mesh_rule::device_note in gpu/vk/mesh_mode.h words the device line's field from the driver's answer (dev.mesh_capable), this run's (dev.mesh_shader) and the mode; create_device and mkwvk_init in gpu/vk/vk_main.cpp log it, and the compute path's line and the mode line say the same. The comment that called the Steam Deck OLED an RDNA3 APU names Van Gogh, RDNA2 (and the ROG Xbox Ally X, RDNA3.5)
The device line's readers take the GPU and driver from the text before ; mesh shaders (host/hos_crash_dialog.h, scripts/cpu_report.py, scripts/pipeline_tour.py, nx2/pipeline_share.py), which is unchanged; the note has no ; of its own, and the checks hold it to that
docs: RX_VK_MESH_SHADERS's row in docs/development.md names the device line's three answers
tests: tests/test_mesh_mode_switch.py compiles device_note and checks each case, and checks the source logs it and no longer says "no mesh shaders" on the compute path (it fails on main). The log fixtures of tests/test_cpu_report.py, tests/test_crash_dialog.py and tests/test_pipeline_share.py carry the new wording; the fixtures that stand for older logs keep mesh shaders yes

Measurements

Verdict: nothing to measure: the change is log text only. The same lines are logged, once each at the start, and what runs is unchanged.

Flags and settings

None

Testing

Tested: the game-free checks on Linux, with g++ and with clang:

tests/test_mesh_mode_switch.py fails at the test's commit (on main's source: "the compute path's line says there are no mesh shaders where the driver offers them") and passes here, device_note compiled with -Wall -Wextra -Werror.
The 44 checks that read gpu/vk/vk_main.cpp, gpu/vk/mesh_mode.h, docs/development.md or the device line, through tests/run_all.py: all pass but 4 that fail the same way on main @ aa95d35f on this PC (test_appimage_player_build, test_crash_dialog, test_vk_pgo, test_walk_key). test_crash_dialog stops at an assertion of its own (line 415) before the fixture this PR changes; host/hos_crash_dialog.h finds the device line by ; mesh shaders , which the new line keeps.
gpu/vk/vk_main.cpp with -fsyntax-only -Wall -Wextra for Linux (clang) and Windows (llvm-mingw): the same diagnostics as on main.

Not tested: the full tests/run_all.py (this PC was shared and loaded); the new lines in a game run: the change is the logged text alone, and each case of device_note is compiled and checked.

Must be tested:

None

Risks

What could break: a script outside this repository that looks for mesh shaders yes or mesh shaders no in a log. The readers in this repository take the text before ; mesh shaders, which is unchanged.

Turning it off: revert the commit.

Compatibility: Nothing changes.

Checklist

Everyone

One topic.
The title is a Conventional Commit (type(scope): description) of the status line's type.
Why gives the reason plainly and links the issues that fit (the tracker searched).
Measurements has a verdict, or one line saying why there is nothing to measure.
Testing names what was tested, what wasn't, and what must still be tested, where and how.
Rebased on current main. Onto main 94abdd57 (head fef2087e) with no conflict, with the commit subjects made Conventional Commits, which CI's lint job now checks for every commit, on a base that has CI's config (#417); each commit's change is the same as before by git patch-id. The commits named in this description are from before this rebase: 5cbc0e83 is now 98352756, 1f44245a is now fef2087e. Re-run on 94abdd57: test_mesh_mode_switch fails at the test-only commit 98352756 and passes at the head, with g++ 13.3 and clang 23.1.5; of the 49 checks that are this PR's or read its files (g++ 13.3), 42 pass, 2 skip (a tool this PC lacks) and the 5 that fail fail on main 94abdd57 too (test_appimage_player_build, test_crash_dialog, test_vk_occlusion_queries, test_vk_pgo, test_walk_key). Its edit of test_crash_dialog can't pass on main, where that check fails for another reason (fixed by #626): with that PR's fix merged in, it passes with g++ and clang.
python -I -B tests/run_all.py passes (any failure that also fails on main is named). 527 passed, 16 failed, 50 skipped on Linux with g++. 15 of the failures also fail on main on this PC: test_appimage_player_build, test_bake_portability, test_cpm_discovery, test_crash_dialog, test_env_on, test_lift_cache, test_lift_cleanup_error, test_make_game_cache, test_options_budget_once, test_pipeline_tour, test_readback_late, test_vk_pgo, test_walk_key, nx2/test_texture_init_barrier and test_mods_size_table. The other one, test_pipeline_cache_save, is a timed wait that failed in the full run on a busy PC and passes when run alone, 2 of 2.
No game files, dumps, build output or generated files.
third_party/ untouched (a new folder with a PROVENANCE.md instead).
The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

When it applies

AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
A game-free test added for the fix, failing on main and passing here.
A check under tests/ that reads changed source updated in this PR, not weakened.
Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths.
Docs updated.

**Type:** fix · **Risk:** low · **Tested on:** Linux, the game-free checks (no GPU) · **Needs:** none ## Why On a Steam Deck every log says `mesh shaders no` and `vk: no mesh shaders: task and mesh programs run as compute shaders`, although its driver (RADV) offers mesh shaders: Longshot leaves them unused on Linux AMD on purpose (Automatic takes the compute path there: https://github.com/NotRexed/Hookshot/issues/2245). People, us included, read those lines as "the Deck's driver has no mesh shaders" and drew the wrong conclusions about what the Deck can do. The log knew the driver's answer (`dev.mesh_capable`) and never said it. ## How to reproduce **Seen on:** Steam Deck, SteamOS, RADV VANGOGH (Mesa) **Settings and switches:** defaults **Steps:** start the game and read the `vk:` lines near the top of `longshot_log.txt` **Expected:** the log says the driver offers mesh shaders and that this run does not use them, and why **Actual:** on `main`: ``` 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 vk: AMD Custom GPU 0932 (RADV VANGOGH), Vulkan 1.4, driver 0x6801063; mesh shaders no, host memory import yes, pipeline libraries yes ``` ## What changed The log states both facts: whether the driver offers mesh shaders, and whether this run uses them. On a Steam Deck with the defaults the three lines become: ``` vk: mesh shaders offered by the driver but not used: task and mesh programs run as compute shaders (issue 640 fallback) vk: mesh shaders: Automatic, from the default: the compute path (Linux AMD: RADV's own can hang the GPU, issue 2245) vk: AMD Custom GPU 0932 (RADV VANGOGH), Vulkan 1.4, driver 0x6801063; mesh shaders offered by the driver but not used (Automatic runs Linux AMD on the compute path: RX_VK_MESH_SHADERS=native to try), host memory import yes, pipeline libraries yes ``` Elsewhere the device line's field reads `used` (it said `yes`), `offered by the driver but not used (Compute chosen)` under `RX_VK_MESH_SHADERS=compute` or `RX_VK_FORCE_MESH_FALLBACK=1`, or `not offered by the driver` (an RX 5000, a GTX 10). What runs is unchanged. - vk: `mesh_rule::device_note` in `gpu/vk/mesh_mode.h` words the device line's field from the driver's answer (`dev.mesh_capable`), this run's (`dev.mesh_shader`) and the mode; `create_device` and `mkwvk_init` in `gpu/vk/vk_main.cpp` log it, and the compute path's line and the mode line say the same. The comment that called the Steam Deck OLED an RDNA3 APU names Van Gogh, RDNA2 (and the ROG Xbox Ally X, RDNA3.5) - The device line's readers take the GPU and driver from the text before `; mesh shaders` (`host/hos_crash_dialog.h`, `scripts/cpu_report.py`, `scripts/pipeline_tour.py`, `nx2/pipeline_share.py`), which is unchanged; the note has no `;` of its own, and the checks hold it to that - docs: `RX_VK_MESH_SHADERS`'s row in `docs/development.md` names the device line's three answers - tests: `tests/test_mesh_mode_switch.py` compiles `device_note` and checks each case, and checks the source logs it and no longer says "no mesh shaders" on the compute path (it fails on `main`). The log fixtures of `tests/test_cpu_report.py`, `tests/test_crash_dialog.py` and `tests/test_pipeline_share.py` carry the new wording; the fixtures that stand for older logs keep `mesh shaders yes` ## Measurements **Verdict:** nothing to measure: the change is log text only. The same lines are logged, once each at the start, and what runs is unchanged. ### Flags and settings None ## Testing **Tested:** the game-free checks on Linux, with g++ and with clang: - `tests/test_mesh_mode_switch.py` fails at the test's commit (on `main`'s source: "the compute path's line says there are no mesh shaders where the driver offers them") and passes here, `device_note` compiled with `-Wall -Wextra -Werror`. - The 44 checks that read `gpu/vk/vk_main.cpp`, `gpu/vk/mesh_mode.h`, `docs/development.md` or the device line, through `tests/run_all.py`: all pass but 4 that fail the same way on `main` @ aa95d35f on this PC (`test_appimage_player_build`, `test_crash_dialog`, `test_vk_pgo`, `test_walk_key`). `test_crash_dialog` stops at an assertion of its own (line 415) before the fixture this PR changes; `host/hos_crash_dialog.h` finds the device line by `; mesh shaders `, which the new line keeps. - `gpu/vk/vk_main.cpp` with `-fsyntax-only -Wall -Wextra` for Linux (clang) and Windows (llvm-mingw): the same diagnostics as on `main`. **Not tested:** the full `tests/run_all.py` (this PC was shared and loaded); the new lines in a game run: the change is the logged text alone, and each case of `device_note` is compiled and checked. **Must be tested:** - None ## Risks **What could break:** a script outside this repository that looks for `mesh shaders yes` or `mesh shaders no` in a log. The readers in this repository take the text before `; mesh shaders`, which is unchanged. **Turning it off:** revert the commit. **Compatibility:** Nothing changes. ## Checklist ### Everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`) of the status line's type. - [x] Why gives the reason plainly and links the issues that fit (the tracker searched). - [x] Measurements has a verdict, or one line saying why there is nothing to measure. - [x] Testing names what was tested, what wasn't, and what must still be tested, where and how. - [x] Rebased on current `main`. Onto main 94abdd57 (head fef2087e) with no conflict, with the commit subjects made Conventional Commits, which CI's lint job now checks for every commit, on a base that has CI's config (https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/417); each commit's change is the same as before by `git patch-id`. The commits named in this description are from before this rebase: 5cbc0e83 is now 98352756, 1f44245a is now fef2087e. Re-run on 94abdd57: `test_mesh_mode_switch` fails at the test-only commit 98352756 and passes at the head, with g++ 13.3 and clang 23.1.5; of the 49 checks that are this PR's or read its files (g++ 13.3), 42 pass, 2 skip (a tool this PC lacks) and the 5 that fail fail on main 94abdd57 too (`test_appimage_player_build`, `test_crash_dialog`, `test_vk_occlusion_queries`, `test_vk_pgo`, `test_walk_key`). Its edit of `test_crash_dialog` can't pass on main, where that check fails for another reason (fixed by https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/626): with that PR's fix merged in, it passes with g++ and clang. - [x] `python -I -B tests/run_all.py` passes (any failure that also fails on `main` is named). 527 passed, 16 failed, 50 skipped on Linux with g++. 15 of the failures also fail on `main` on this PC: `test_appimage_player_build`, `test_bake_portability`, `test_cpm_discovery`, `test_crash_dialog`, `test_env_on`, `test_lift_cache`, `test_lift_cleanup_error`, `test_make_game_cache`, `test_options_budget_once`, `test_pipeline_tour`, `test_readback_late`, `test_vk_pgo`, `test_walk_key`, `nx2/test_texture_init_barrier` and `test_mods_size_table`. The other one, `test_pipeline_cache_save`, is a timed wait that failed in the full run on a busy PC and passes when run alone, 2 of 2. - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### When it applies - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [x] A game-free test added for the fix, failing on `main` and passing here. - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. - [x] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. - [x] Docs updated.

zeldaootr added 2 commits

2026-11-15 18:08:03 +00:00

The mesh mode check asks the log to say what the driver offers apart from what the run uses 5cbc0e832f

It fails on main: on a Steam Deck every log says `mesh shaders no` and `vk: no mesh shaders: ...`, though RADV offers `VK_EXT_mesh_shader` and Automatic only leaves it unused on Linux AMD (issue 2245). `dev.mesh_capable`, the driver's answer, is never logged.

Assisted-by: Claude

The device line says whether the driver offers mesh shaders apart from whether this run uses them

Website / Website on Cloudflare (pull_request_target) Has been skipped

Details

PR description / Description follows the template (pull_request_target) Successful in 5s

Details

CI / Conventional Commit title (pull_request) Has been cancelled

Details

CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been cancelled

Details

CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been cancelled

Details

CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been cancelled

Details

CI / Workflow lint (actionlint) (pull_request) Has been cancelled

Details

Guide screenshots / Guide images and local UI source review (pull_request) Has been cancelled

Details

Third-party parts / As their notes say (pull_request) Has been cancelled

Details

Third-party parts / The same as upstream (pull_request) Has been cancelled

Details

1f44245a14

On a Steam Deck every log said `mesh shaders no` and `vk: no mesh shaders: ...`, read as a driver without them, though RADV offers `VK_EXT_mesh_shader` and only Automatic's Linux AMD rule (issue 2245) leaves it unused. The device line's field is now `used`, `offered by the driver but not used (...)` with the reason, or `not offered by the driver` (`mesh_rule::device_note`); the compute path's line and the mode line say the same. The comment that called the Steam Deck OLED an RDNA3 APU names Van Gogh, RDNA2.

Assisted-by: Claude

BeanIssues added the

area/renderer

kind

bug

labels

2026-11-15 18:08:05 +00:00

zeldaootr force-pushed log-mesh-capable from 1f44245a14

Website / Website on Cloudflare (pull_request_target) Has been skipped

Details

PR description / Description follows the template (pull_request_target) Successful in 5s

Details

CI / Conventional Commit title (pull_request) Has been cancelled

Details

CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been cancelled

Details

CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been cancelled

Details

CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been cancelled

Details

CI / Workflow lint (actionlint) (pull_request) Has been cancelled

Details

Guide screenshots / Guide images and local UI source review (pull_request) Has been cancelled

Details

Third-party parts / As their notes say (pull_request) Has been cancelled

Details

Third-party parts / The same as upstream (pull_request) Has been cancelled

Details

to fef2087e09

CI / Conventional Commit title (pull_request) Blocked by required conditions

Details

CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Blocked by required conditions

Details

CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Blocked by required conditions

Details

CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Blocked by required conditions

Details

CI / Workflow lint (actionlint) (pull_request) Blocked by required conditions

Details

Guide screenshots / Guide images and local UI source review (pull_request) Blocked by required conditions

Details

Third-party parts / As their notes say (pull_request) Blocked by required conditions

Details

Third-party parts / The same as upstream (pull_request) Blocked by required conditions

Details

Website / Website on Cloudflare (pull_request) Blocked by required conditions

Details

PR description / Description follows the template (pull_request_target) Successful in 4s

Details

Website / Website on Cloudflare (pull_request_target) Has been skipped

Details

2026-11-15 19:16:51 +00:00

Compare

zeldaootr commented

2026-11-15 19:16:52 +00:00

Author

Contributor

Rebased onto main 94abdd57 (head fef2087e), with no conflict; the commit subjects are now Conventional Commits, which CircleCI's lint job checks for every commit of a pull request (#417), and the base has the CI's config, which a fork's pull request needs at its own head. No other change: each commit's change is the same as before by git patch-id.
Re-run on 94abdd57: test_mesh_mode_switch fails at the test-only commit 98352756 and passes at the head, with g++ 13.3 and clang 23.1.5; of the 49 checks that are this PR's or read its files (g++ 13.3), 42 pass, 2 skip (a tool this PC lacks) and the 5 that fail fail on main 94abdd57 too (test_appimage_player_build, test_crash_dialog, test_vk_occlusion_queries, test_vk_pgo, test_walk_key). Its edit of test_crash_dialog can't pass on main, where that check fails for another reason (fixed by #626): with that PR's fix merged in, it passes with g++ and clang. The description names the new commits.

Rebased onto `main` 94abdd57 (head fef2087e), with no conflict; the commit subjects are now Conventional Commits, which CircleCI's lint job checks for every commit of a pull request (https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/417), and the base has the CI's config, which a fork's pull request needs at its own head. No other change: each commit's change is the same as before by `git patch-id`. Re-run on 94abdd57: `test_mesh_mode_switch` fails at the test-only commit 98352756 and passes at the head, with g++ 13.3 and clang 23.1.5; of the 49 checks that are this PR's or read its files (g++ 13.3), 42 pass, 2 skip (a tool this PC lacks) and the 5 that fail fail on main 94abdd57 too (`test_appimage_player_build`, `test_crash_dialog`, `test_vk_occlusion_queries`, `test_vk_pgo`, `test_walk_key`). Its edit of `test_crash_dialog` can't pass on main, where that check fails for another reason (fixed by https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/626): with that PR's fix merged in, it passes with g++ and clang. The description names the new commits.

BeanIssues added the

risk

low

label

2026-11-15 20:27:12 +00:00