An update rebuilds the game with the flags it was built with #2577

Closed

opened 2026-11-11 23:59:38 +00:00 by steefzilla · 2 comments

steefzilla commented

2026-11-11 23:59:38 +00:00

(Migrated from github.com)

The idea

Depends on #2576. This one is blocked until that record exists.

An update compiles whatever RX_MARCH happens to be in that process, or host_march() when it is unset. Extra CPU flags are not read from anywhere. Updating a game that was built for rocketlake with -mprefer-vector-width=256 on a machine that only exports those for a hand-run build produces an x86-64-v3 binary and drops the extra flag. The DLSS choice is already carried across an update. The CPU flags are not.

When the game folder has a recorded flag set, the update build should use it: pass that -march and -mtune through, keep -ffp-contract=off, and pass the recorded extra CPU flags. A folder with no record keeps today's behavior. A Steam Deck with no recorded tune can still add -mtune=znver2 from host_mtune(). An explicit record wins over that detection. The player can still override one build by setting RX_MARCH for that run.

Checked on v2.1.0, the newest release, and on nightly (fce53453, 187 commits later, 11 November 2026). Neither rebuilds an update with the flags the game was built with.

Anything else

The record has to be the source of the flags. Reading them back out of the binary with strings is not enough, because the current binary does not contain them, and a vendor library's embedded GCC line (-march=x86-64) is not this game's line.

### The idea Depends on #2576. This one is blocked until that record exists. An update compiles whatever `RX_MARCH` happens to be in that process, or `host_march()` when it is unset. Extra CPU flags are not read from anywhere. Updating a game that was built for `rocketlake` with `-mprefer-vector-width=256` on a machine that only exports those for a hand-run build produces an `x86-64-v3` binary and drops the extra flag. The DLSS choice is already carried across an update. The CPU flags are not. When the game folder has a recorded flag set, the update build should use it: pass that `-march` and `-mtune` through, keep `-ffp-contract=off`, and pass the recorded extra CPU flags. A folder with no record keeps today's behavior. A Steam Deck with no recorded tune can still add `-mtune=znver2` from `host_mtune()`. An explicit record wins over that detection. The player can still override one build by setting `RX_MARCH` for that run. Checked on v2.1.0, the newest release, and on `nightly` (`fce53453`, 187 commits later, 11 November 2026). Neither rebuilds an update with the flags the game was built with. ### Anything else The record has to be the source of the flags. Reading them back out of the binary with `strings` is not enough, because the current binary does not contain them, and a vendor library's embedded GCC line (`-march=x86-64`) is not this game's line.

NotRexed commented

2026-11-12 03:08:11 +00:00

(Migrated from github.com)

Thanks for the report. Reports of the same kind are collected in #2505, which lists this one with your details and links back here, so one fix closes them together. Follow #2505 for the fix and add new details there (or here). If this turns out to be separate it will be reopened.

steefzilla commented

2026-11-12 03:47:46 +00:00

(Migrated from github.com)

Thanks for looking. This is a feature request, not a failed build: an update should rebuild with the CPU flags the game was already built with. It depends on #2576. #2505 is for builds that fail, run out of disk, or take too long, and its list does not mention this. Could it be reopened as separate?