MagicBeanDev/Longshot

Watch

Fork 102

fix(linux): a start from the Steam Deck's Game Mode no longer compiles every pipeline the preparation built #900

Open

zeldaootr wants to merge 2 commits from zeldaootr/Longshot:radv-vrs-key-switch into main

zeldaootr commented

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

Contributor

Type: fix · Risk: low · Tested on: Steam Deck OLED (SteamOS 3.9.5, RADV, Mesa 26.2.0-devel); Linux game-free checks · Needs: none

Why

On a Steam Deck, every start from Game Mode compiled again all 32,438 pipelines the preparation had built: about 25-30 minutes at "Loading pipelines" before the title, where a start from the desktop loaded them in about 20 seconds. Game Mode sets RADV_FORCE_VRS_CONFIG_FILE (Steam's Half Rate Shading switch) for everything it starts, and while that file exists RADV gives every graphics pipeline another key, so neither our pipeline cache nor the driver's finds what the preparation made.

The cause was measured on the Deck before the fix:

With the variable naming a file, holding 1x1 (as Game Mode's does) or empty: the start compiles, about 20 pipelines a second.
With the variable naming no file, or with only Mesa's cache folder changed: no compile.

No issue on the tracker covers it (searched: VRS, RADV_FORCE_VRS, half rate shading, Game Mode, shader cache).

How to reproduce

Seen on: SteamOS 3.9.5 (Steam Deck OLED), RADV VANGOGH, Mesa 26.2.0-devel
Settings and switches: defaults
Steps: prepare outside Game Mode (the Builder, or a start from the desktop), then start from Steam in Game Mode. From a shell the same shows with printf 1x1 > <scratch>/vrs-1x1.txt and a start with RADV_FORCE_VRS_CONFIG_FILE=<scratch>/vrs-1x1.txt.
Expected: the precompile loads its pipelines in seconds.
Actual: vk: noted pipelines: 6374 of 38345 pipelines in 10 s ... 8932 of 38345 pipelines in 130 s, about 20 a second.

What changed

The game drops Game Mode's RADV_FORCE_VRS_CONFIG_FILE before Vulkan loads, by default, and says so in its log. RX_VK_HALF_RATE_SHADING=1 keeps it for a player who wants Steam's Half Rate Shading and accepts the compile.

host: host/hos_main.c driver_env_choose(), in the Linux main after longshot_env.txt is read (so the switch works from there) and before the window or anything else can load Vulkan:
- When the variable names a file that exists, which is when RADV reads it, it is unset, and named in LONGSHOT_DRIVER_ENV_SET. That variable is for the renderer's driver cache line in the sibling PR "fix(vk): the start names the driver's shader cache ..."; with this PR alone nothing reads it.
- One line goes to stderr, and again to the game's own log once it is open (driver_env_log() in game_main).
- A name with no file, an empty value or no variable: nothing changes and nothing is said, since RADV then reads nothing either.
- RADV_FORCE_VRS, a rate someone set by hand, is never touched. Game Mode doesn't set it.
docs: docs/development.md's row for RX_VK_HALF_RATE_SHADING, and docs/tested/2026-11-15-gamemode-vrs-zeldaootr-deck01.md for the Deck run.
tests: tests/test_driver_env_choose.py cuts driver_env_choose out of hos_main.c, compiles it and runs it against a 1x1 file, an empty file, =0, =1, a name with no file, an empty value, no variable, and RADV_FORCE_VRS set; it also checks the call's place in main and the log line in game_main. The stand-in in tests/display_startup_failure_test.cpp follows.

Beyond the Deck:

Other drivers: no driver but RADV reads the variable, and RADV forces VRS only on gfx10.3 and later. Dropping it changes nothing elsewhere.
Half Rate Shading: gives Longshot little. RADV leaves a fragment program that reads its position at full rate, and nearly all of ours do. With the variable dropped, Steam's toggle does nothing for this game.
Sandboxes: the existence check runs in the game's own process, so it sees the same /tmp RADV sees.
Restart now (hos_relaunch.c) starts again from the first environment, and that start drops it again. Processes the game starts inherit the dropped state.

Measurements

Verdict: fixed. With Game Mode's variable set, the start no longer compiles: the precompile took 12.5-18.9 s and the title came in 45-51 s, against about 20 pipelines a second (25-30 minutes) before; the same as the starts without the variable.

Baseline: the Before column is an earlier Deck build of main @ aa95d35f with other open PRs (the same caches and scene), from the session that found the cause; main itself was not run in the After session. The After column is the local integration vrs-verify (bfc69759): main @ aa95d35f with this PR and its two siblings. Their changes don't move these numbers: one adds log lines, the other writes the cache only after a precompile of 30 s or more, and none of these starts took that long. Rebased since onto main @ f637b42d: main's changes to host/hos_main.c in between (a comment, the saves move) don't touch the driver's environment, so the numbers hold.
Hardware: Steam Deck OLED, AMD Custom GPU 0932 (RADV VANGOGH), Mesa 26.2.0-devel (git-5c65d4fc31), SteamOS 3.9.5 (20261023.100), 16 GB
Scene: the start-up, up to the title; scratch game folders, each start with a fresh copy of the same warm caches; headless, defaults, the precompile at its default
Method: the start's vk: precompile: ... in N ms and vk: noted pipelines: N of M pipelines in T s lines, and the time to the title. After: 4 starts interleaved a, b, b, a; with 2 runs each the median is their mean. Before: one start per arm, stopped at 150 s while compiling.
How to reproduce: printf 1x1 > <scratch>/vrs/vrs-1x1.txt; arm b sets RADV_FORCE_VRS_CONFIG_FILE to it, arm a doesn't

	Before: main @ `aa95d35f` (with other open PRs)	After: this PR @ `d3680c96` (in `vrs-verify` bfc69759)
b: the variable naming a `1x1` file, precompile	compiles: 6,374 of 38,345 in 10 s, 8,932 in 130 s (about 20 a second), stopped at 150 s	18,923 / 12,481 ms (median 15,702 ms), nothing compiled
b: time to the title	over 25 minutes at that rate	51 / 45 s (median 48 s)
the same, the file empty	compiles: 6,369 of 38,345 in 10 s, 8,739 in 120 s	not run (the existence check doesn't read the content; the game-free check covers it)
a: no variable, precompile	22,350 ms	17,379 / 20,670 ms (median 19,025 ms)
a: time to the title	56 s	52 / 54 s (median 53 s)

Before, b (1x1):  vk: noted pipelines: 6374 of 38345 pipelines in 10 s ... 8932 of 38345 pipelines in 130 s
Before, a:        vk: precompile: 27660 programs, 32438 graphics and 3623 compute pipelines, 2284 mesh fallback programs in 22350 ms (21843 ms of it the caches opened, the notes and programs read)

After, a1: vk: precompile: 27660 programs, 32438 graphics and 3623 compute pipelines, 2284 mesh fallback programs in 17379 ms (16873 ms of it the caches opened, the notes and programs read)
After, b1: vk: RADV_FORCE_VRS_CONFIG_FILE=<scratch>/vrs/vrs-1x1.txt dropped: with it RADV gives every graphics pipeline another key than the preparation's and compiles them all again; Steam's Half Rate Shading has no effect on Longshot (RX_VK_HALF_RATE_SHADING=1 keeps it)
After, b1: vk: precompile: 27660 programs, 32438 graphics and 3623 compute pipelines, 2284 mesh fallback programs in 18923 ms (18416 ms of it the caches opened, the notes and programs read)
After, b2: (the same dropped line) ... in 12481 ms (11974 ms of it the caches opened, the notes and programs read)
After, a2: ... in 20670 ms (20163 ms of it the caches opened, the notes and programs read)

Flags and settings

One new switch; by default the variable is dropped.

Flag	What it is	Before this PR	After this PR	Effect	Helps / doesn't help / untested	Recommendation
`RX_VK_HALF_RATE_SHADING=1`	keeps Game Mode's `RADV_FORCE_VRS_CONFIG_FILE`	kept (nothing dropped it)	dropped unless `=1`	with `1`, Steam's Half Rate Shading reaches the game, and a start in Game Mode compiles its own pipelines	the drop measured on a Deck (above); `=1` checked game-free only	unset (drop) for everyone
`LONGSHOT_DRIVER_ENV_SET`	set by the host: the driver variables it dropped (not for players)	not set	`RADV_FORCE_VRS_CONFIG_FILE` when dropped	read by the sibling diagnostics PR's driver cache line; nothing reads it here	n/a	leave to the host

Testing

Tested:

Steam Deck OLED, the run above: the drop line, no compile, the title in under a minute with the variable set.
tests/test_driver_env_choose.py: fails at the test commit (08711eba, host/hos_main.c has no driver_env_choose) and passes at the fix.
host/hos_main.c syntax-checked with gcc for Linux and llvm-mingw clang for Windows (stand-ins for the two generated headers it includes): no errors, as main, and no warnings in the new code with -Wall -Wextra. The Linux game build itself ran on the Deck.
The full tests/run_all.py on Linux: 529 passed, 18 failed, 79 skipped (tools this PC lacks), 8 at once, on this PR merged with its two siblings onto main @ f637b42d. The 18 fail the same way on main @ f637b42d run alone: test_appimage_player_build, test_bake_portability, test_crash_dialog, test_crt_options, test_env_on, test_lift_cache, test_lift_cleanup_error, test_linux_preflight, test_linux_update, test_make_game_cache, test_missing_nup, test_mods_size_table, test_options_budget_once, test_pipeline_tour, test_readback_late, test_vk_occlusion_queries, test_vk_pgo, test_walk_key. The checks that read this PR's files pass, among them test_driver_env_choose, test_driver_cache_env, test_precompile_save, test_pipeline_cache_save, test_prepare_stall, test_display_startup_failure and test_tested_configurations.

Not tested: RX_VK_HALF_RATE_SHADING=1 in the game (the start then compiles, as before this PR; the game-free check covers that the variable is kept and the log says so); a start through Steam in Game Mode itself, rather than the variable set by hand (Game Mode's session sets the same variable to a file holding 1x1, which is what arm b set).

Must be tested: None.

Risks

What could break: Steam's Half Rate Shading no longer reaches Longshot unless RX_VK_HALF_RATE_SHADING=1. A player whose caches were last written by a start in Game Mode may have them under the VRS keys only, and then compiles the noted pipelines once more after updating.

Turning it off: RX_VK_HALF_RATE_SHADING=1 in longshot_env.txt or the environment.

Compatibility: the pipeline keys in Game Mode become those of every other start, so the caches the preparation made are found. Nothing is translated again; saves, longshot_options.ini and the vk ABI are unchanged.

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.
python -I -B tests/run_all.py passes (any failure that also fails on main is named).
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.
Numbers from the same PC, scene and settings, at least 2 interleaved runs each, the median reported.
Switches documented (docs/development.md; the README for a menu row) and shipped at their recommended value.
A file in docs/tested/ for each new measured run (format in docs/tested-configurations.md).
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:** Steam Deck OLED (SteamOS 3.9.5, RADV, Mesa 26.2.0-devel); Linux game-free checks · **Needs:** none ## Why On a Steam Deck, every start from Game Mode compiled again all 32,438 pipelines the preparation had built: about 25-30 minutes at "Loading pipelines" before the title, where a start from the desktop loaded them in about 20 seconds. Game Mode sets `RADV_FORCE_VRS_CONFIG_FILE` (Steam's Half Rate Shading switch) for everything it starts, and while that file exists RADV gives every graphics pipeline another key, so neither our pipeline cache nor the driver's finds what the preparation made. The cause was measured on the Deck before the fix: - With the variable naming a file, holding `1x1` (as Game Mode's does) or empty: the start compiles, about 20 pipelines a second. - With the variable naming no file, or with only Mesa's cache folder changed: no compile. No issue on the tracker covers it (searched: VRS, RADV_FORCE_VRS, half rate shading, Game Mode, shader cache). ## How to reproduce **Seen on:** SteamOS 3.9.5 (Steam Deck OLED), RADV VANGOGH, Mesa 26.2.0-devel **Settings and switches:** defaults **Steps:** prepare outside Game Mode (the Builder, or a start from the desktop), then start from Steam in Game Mode. From a shell the same shows with `printf 1x1 > <scratch>/vrs-1x1.txt` and a start with `RADV_FORCE_VRS_CONFIG_FILE=<scratch>/vrs-1x1.txt`. **Expected:** the precompile loads its pipelines in seconds. **Actual:** `vk: noted pipelines: 6374 of 38345 pipelines in 10 s` ... `8932 of 38345 pipelines in 130 s`, about 20 a second. ## What changed The game drops Game Mode's `RADV_FORCE_VRS_CONFIG_FILE` before Vulkan loads, by default, and says so in its log. `RX_VK_HALF_RATE_SHADING=1` keeps it for a player who wants Steam's Half Rate Shading and accepts the compile. - host: `host/hos_main.c` `driver_env_choose()`, in the Linux `main` after `longshot_env.txt` is read (so the switch works from there) and before the window or anything else can load Vulkan: - When the variable names a file that exists, which is when RADV reads it, it is unset, and named in `LONGSHOT_DRIVER_ENV_SET`. That variable is for the renderer's driver cache line in the sibling PR "fix(vk): the start names the driver's shader cache ..."; with this PR alone nothing reads it. - One line goes to stderr, and again to the game's own log once it is open (`driver_env_log()` in `game_main`). - A name with no file, an empty value or no variable: nothing changes and nothing is said, since RADV then reads nothing either. - `RADV_FORCE_VRS`, a rate someone set by hand, is never touched. Game Mode doesn't set it. - docs: `docs/development.md`'s row for `RX_VK_HALF_RATE_SHADING`, and `docs/tested/2026-11-15-gamemode-vrs-zeldaootr-deck01.md` for the Deck run. - tests: `tests/test_driver_env_choose.py` cuts `driver_env_choose` out of `hos_main.c`, compiles it and runs it against a `1x1` file, an empty file, `=0`, `=1`, a name with no file, an empty value, no variable, and `RADV_FORCE_VRS` set; it also checks the call's place in `main` and the log line in `game_main`. The stand-in in `tests/display_startup_failure_test.cpp` follows. Beyond the Deck: - **Other drivers:** no driver but RADV reads the variable, and RADV forces VRS only on gfx10.3 and later. Dropping it changes nothing elsewhere. - **Half Rate Shading:** gives Longshot little. RADV leaves a fragment program that reads its position at full rate, and nearly all of ours do. With the variable dropped, Steam's toggle does nothing for this game. - **Sandboxes:** the existence check runs in the game's own process, so it sees the same `/tmp` RADV sees. - **Restart now** (`hos_relaunch.c`) starts again from the first environment, and that start drops it again. Processes the game starts inherit the dropped state. ## Measurements **Verdict:** fixed. With Game Mode's variable set, the start no longer compiles: the precompile took 12.5-18.9 s and the title came in 45-51 s, against about 20 pipelines a second (25-30 minutes) before; the same as the starts without the variable. Baseline: the Before column is an earlier Deck build of main @ aa95d35f with other open PRs (the same caches and scene), from the session that found the cause; main itself was not run in the After session. The After column is the local integration `vrs-verify` (bfc69759): main @ aa95d35f with this PR and its two siblings. Their changes don't move these numbers: one adds log lines, the other writes the cache only after a precompile of 30 s or more, and none of these starts took that long. Rebased since onto main @ f637b42d: main's changes to `host/hos_main.c` in between (a comment, the saves move) don't touch the driver's environment, so the numbers hold. Hardware: Steam Deck OLED, AMD Custom GPU 0932 (RADV VANGOGH), Mesa 26.2.0-devel (git-5c65d4fc31), SteamOS 3.9.5 (20261023.100), 16 GB Scene: the start-up, up to the title; scratch game folders, each start with a fresh copy of the same warm caches; headless, defaults, the precompile at its default Method: the start's `vk: precompile: ... in N ms` and `vk: noted pipelines: N of M pipelines in T s` lines, and the time to the title. After: 4 starts interleaved a, b, b, a; with 2 runs each the median is their mean. Before: one start per arm, stopped at 150 s while compiling. How to reproduce: `printf 1x1 > <scratch>/vrs/vrs-1x1.txt`; arm b sets `RADV_FORCE_VRS_CONFIG_FILE` to it, arm a doesn't | | Before: main @ aa95d35f (with other open PRs) | After: this PR @ d3680c96 (in `vrs-verify` bfc69759) | |---|---|---| | b: the variable naming a `1x1` file, precompile | compiles: 6,374 of 38,345 in 10 s, 8,932 in 130 s (about 20 a second), stopped at 150 s | 18,923 / 12,481 ms (median 15,702 ms), nothing compiled | | b: time to the title | over 25 minutes at that rate | 51 / 45 s (median 48 s) | | the same, the file empty | compiles: 6,369 of 38,345 in 10 s, 8,739 in 120 s | not run (the existence check doesn't read the content; the game-free check covers it) | | a: no variable, precompile | 22,350 ms | 17,379 / 20,670 ms (median 19,025 ms) | | a: time to the title | 56 s | 52 / 54 s (median 53 s) | ``` Before, b (1x1): vk: noted pipelines: 6374 of 38345 pipelines in 10 s ... 8932 of 38345 pipelines in 130 s Before, a: vk: precompile: 27660 programs, 32438 graphics and 3623 compute pipelines, 2284 mesh fallback programs in 22350 ms (21843 ms of it the caches opened, the notes and programs read) After, a1: vk: precompile: 27660 programs, 32438 graphics and 3623 compute pipelines, 2284 mesh fallback programs in 17379 ms (16873 ms of it the caches opened, the notes and programs read) After, b1: vk: RADV_FORCE_VRS_CONFIG_FILE=<scratch>/vrs/vrs-1x1.txt dropped: with it RADV gives every graphics pipeline another key than the preparation's and compiles them all again; Steam's Half Rate Shading has no effect on Longshot (RX_VK_HALF_RATE_SHADING=1 keeps it) After, b1: vk: precompile: 27660 programs, 32438 graphics and 3623 compute pipelines, 2284 mesh fallback programs in 18923 ms (18416 ms of it the caches opened, the notes and programs read) After, b2: (the same dropped line) ... in 12481 ms (11974 ms of it the caches opened, the notes and programs read) After, a2: ... in 20670 ms (20163 ms of it the caches opened, the notes and programs read) ``` ### Flags and settings One new switch; by default the variable is dropped. | Flag | What it is | Before this PR | After this PR | Effect | Helps / doesn't help / untested | Recommendation | |---|---|---|---|---|---|---| | `RX_VK_HALF_RATE_SHADING=1` | keeps Game Mode's `RADV_FORCE_VRS_CONFIG_FILE` | kept (nothing dropped it) | dropped unless `=1` | with `1`, Steam's Half Rate Shading reaches the game, and a start in Game Mode compiles its own pipelines | the drop measured on a Deck (above); `=1` checked game-free only | unset (drop) for everyone | | `LONGSHOT_DRIVER_ENV_SET` | set by the host: the driver variables it dropped (not for players) | not set | `RADV_FORCE_VRS_CONFIG_FILE` when dropped | read by the sibling diagnostics PR's driver cache line; nothing reads it here | n/a | leave to the host | ## Testing **Tested:** - Steam Deck OLED, the run above: the drop line, no compile, the title in under a minute with the variable set. - `tests/test_driver_env_choose.py`: fails at the test commit (08711eba, `host/hos_main.c has no driver_env_choose`) and passes at the fix. - `host/hos_main.c` syntax-checked with gcc for Linux and llvm-mingw clang for Windows (stand-ins for the two generated headers it includes): no errors, as main, and no warnings in the new code with `-Wall -Wextra`. The Linux game build itself ran on the Deck. - The full `tests/run_all.py` on Linux: 529 passed, 18 failed, 79 skipped (tools this PC lacks), 8 at once, on this PR merged with its two siblings onto main @ f637b42d. The 18 fail the same way on main @ f637b42d run alone: `test_appimage_player_build`, `test_bake_portability`, `test_crash_dialog`, `test_crt_options`, `test_env_on`, `test_lift_cache`, `test_lift_cleanup_error`, `test_linux_preflight`, `test_linux_update`, `test_make_game_cache`, `test_missing_nup`, `test_mods_size_table`, `test_options_budget_once`, `test_pipeline_tour`, `test_readback_late`, `test_vk_occlusion_queries`, `test_vk_pgo`, `test_walk_key`. The checks that read this PR's files pass, among them `test_driver_env_choose`, `test_driver_cache_env`, `test_precompile_save`, `test_pipeline_cache_save`, `test_prepare_stall`, `test_display_startup_failure` and `test_tested_configurations`. **Not tested:** `RX_VK_HALF_RATE_SHADING=1` in the game (the start then compiles, as before this PR; the game-free check covers that the variable is kept and the log says so); a start through Steam in Game Mode itself, rather than the variable set by hand (Game Mode's session sets the same variable to a file holding `1x1`, which is what arm b set). **Must be tested:** None. ## Risks **What could break:** Steam's Half Rate Shading no longer reaches Longshot unless `RX_VK_HALF_RATE_SHADING=1`. A player whose caches were last written by a start in Game Mode may have them under the VRS keys only, and then compiles the noted pipelines once more after updating. **Turning it off:** `RX_VK_HALF_RATE_SHADING=1` in `longshot_env.txt` or the environment. **Compatibility:** the pipeline keys in Game Mode become those of every other start, so the caches the preparation made are found. Nothing is translated again; saves, `longshot_options.ini` and the vk ABI are unchanged. ## 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`. - [x] `python -I -B tests/run_all.py` passes (any failure that also fails on `main` is named). - [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] Numbers from the same PC, scene and settings, at least 2 interleaved runs each, the median reported. - [x] Switches documented (docs/development.md; the README for a menu row) and shipped at their recommended value. - [x] A file in `docs/tested/` for each new measured run (format in `docs/tested-configurations.md`). - [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 19:51:10 +00:00

test(linux): a check that Game Mode's RADV_FORCE_VRS_CONFIG_FILE is dropped before Vulkan loads 08711ebae6

`tests/test_driver_env_choose.py` fails on main. The Steam Deck's Game
Mode sets `RADV_FORCE_VRS_CONFIG_FILE` naming an existing file, and
with it RADV gives every graphics pipeline another key: measured on a
Deck OLED, the 32,438 noted pipelines compiled at about 20 a second
instead of loading in 22 s. Nothing in the game drops it.

Assisted-by: Claude

fix(linux): a start from the Steam Deck's Game Mode no longer compiles every pipeline the preparation built

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

Website / Website on Cloudflare (pull_request_target) Has been skipped

Details

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

Details

d3680c96e0

Game Mode sets `RADV_FORCE_VRS_CONFIG_FILE` (`/tmp/radv_vrs.<random>`,
"1x1" with Half Rate Shading off) for Steam and everything it starts.
When the file exists RADV forces VRS and gives every graphics pipeline
another key, so neither the driver's cache nor ours has what the
preparation (desktop mode) built. Measured on a Steam Deck OLED (RADV,
Mesa 26.2.0-devel), same install and caches: 22 s for the precompile
without it, about 20 pipelines a second (25-30 minutes) with it, empty
file or "1x1"; a name with no file, or another Mesa folder, changed
nothing.

`host/hos_main.c` `driver_env_choose` drops it before anything loads
Vulkan when it names an existing file (when RADV reads it; no other
driver does), names it in `LONGSHOT_DRIVER_ENV_SET`, and says so on
stderr and in the game's own log (`driver_env_log`).
`RX_VK_HALF_RATE_SHADING=1` keeps it. `RADV_FORCE_VRS`, a rate set by
hand, is left alone.

Assisted-by: Claude