docs: record RX 7900 XT Linux test runs #2202

Merged

simonwjackson merged 1 commit from docs-tested-rx7900xt into main

2026-11-11 20:33:44 +00:00

simonwjackson commented

2026-11-11 07:34:50 +00:00

(Migrated from github.com)

Changes

Ten rows in docs/tested-configurations.md, one per run, newest first, with shared settings marked "as above": four with RX_VK_FORCE_MESH_FALLBACK=1, four with RX_VK_TASK_MESH_FALLBACK=1, and two native-mesh controls. All ten reached gameplay and ran to the end of the scripted test with no GPU hang and no kernel log entries. Durations are whole-process times, not time standing still.

Mode	Runs	Median fps per run
`RX_VK_FORCE_MESH_FALLBACK=1`	4	46.6, 46.5, 46.5, 46.1
`RX_VK_TASK_MESH_FALLBACK=1`	4	43.8, 44.0, 43.9, 43.9
native mesh	2	45.4, 44.9

Each fps value is the median of the run's last five vk: N presents, X fps samples, taken standing on Link's house balcony in Kokiri Forest (from a save) before the scripted movement. These are the game's own present rates, not frame-generated display rates.

Build identity

The build is main 117eae7, built with make_game from a source copy without Git metadata, so its log line reads hookshot unknown (source 4ca6c9ae). A clean checkout of 117eae7 prints v2.0.11-730-g117eae7 (source 4ca6c9ae) from nx2/version.py, and all 1,697 entries of the build's recorded source manifest match it. It is not the v2.0.14 tag.

Not tested

The runs were unattended (headless Sway 1.12 + Xwayland, scripted input), not gamescope or a desktop session, and short (137–231 s). They don't show long-session stability and don't identify the cause of earlier RADV task-shader hangs (see #817 / #1000).

Checks

python -I -B tests/run_all.py: 361 passed and 10 skipped (Windows/game/GPU-only). Two checks hit the 600 s timeout under 16 parallel jobs (recorder_sync, fpx_sticky) and passed when rerun alone with --timeout 1200. git diff --check passed.

No RDNA3 rows yet, and AMD stability is the project's largest gap. These ten RX 7900 XT runs on Linux add short, repeatable observations of the mesh-fallback switches, without claiming AMD stability is solved. ## Changes Ten rows in `docs/tested-configurations.md`, one per run, newest first, with shared settings marked "as above": four with `RX_VK_FORCE_MESH_FALLBACK=1`, four with `RX_VK_TASK_MESH_FALLBACK=1`, and two native-mesh controls. All ten reached gameplay and ran to the end of the scripted test with no GPU hang and no kernel log entries. Durations are whole-process times, not time standing still. | Mode | Runs | Median fps per run | |---|---:|---| | `RX_VK_FORCE_MESH_FALLBACK=1` | 4 | 46.6, 46.5, 46.5, 46.1 | | `RX_VK_TASK_MESH_FALLBACK=1` | 4 | 43.8, 44.0, 43.9, 43.9 | | native mesh | 2 | 45.4, 44.9 | Each fps value is the median of the run's last five `vk: N presents, X fps` samples, taken standing on Link's house balcony in Kokiri Forest (from a save) before the scripted movement. These are the game's own present rates, not frame-generated display rates. ## Build identity The build is main `117eae7`, built with `make_game` from a source copy without Git metadata, so its log line reads `hookshot unknown (source 4ca6c9ae)`. A clean checkout of `117eae7` prints `v2.0.11-730-g117eae7 (source 4ca6c9ae)` from `nx2/version.py`, and all 1,697 entries of the build's recorded source manifest match it. It is not the v2.0.14 tag. ## Not tested The runs were unattended (headless Sway 1.12 + Xwayland, scripted input), not gamescope or a desktop session, and short (137–231 s). They don't show long-session stability and don't identify the cause of earlier RADV task-shader hangs (see #817 / #1000). ## Checks `python -I -B tests/run_all.py`: 361 passed and 10 skipped (Windows/game/GPU-only). Two checks hit the 600 s timeout under 16 parallel jobs (`recorder_sync`, `fpx_sticky`) and passed when rerun alone with `--timeout 1200`. `git diff --check` passed.

Joey-Magnus (Migrated from github.com) approved these changes

2026-11-11 20:07:22 +00:00

Joey-Magnus (Migrated from github.com) left a comment

minor, docs/tested-configurations.md:17: the branch no longer merges cleanly with main. Rows from 2026-11-11 were added at the top of the table since you branched, and both changes insert at the same place. When you rebase, put your ten 2026-11-10 rows under main's 2026-11-11 rows so the table stays newest first.

Thanks, this is useful: the first RDNA3 rows, and the description is careful about what the runs do and don't show (short, unattended, headless Sway, not a stability claim). I checked the switches against the tested build (`117eae7`): `RX_VK_FORCE_MESH_FALLBACK=1` turns mesh shaders off so the no-mesh compute fallback runs, `RX_VK_TASK_MESH_FALLBACK=1` sends task + mesh programs through the compute fallback while keeping mesh shaders, and neither is on by default on Linux RADV. So "native mesh (both fallback switches unset)" really is native. The build note explains the `hookshot unknown (source 4ca6c9ae)` log line, and ten rows for ten runs follows the page's "one row per test run" rule. **minor**, `docs/tested-configurations.md:17`: the branch no longer merges cleanly with main. Rows from 2026-11-11 were added at the top of the table since you branched, and both changes insert at the same place. When you rebase, put your ten 2026-11-10 rows under main's 2026-11-11 rows so the table stays newest first.