MagicBeanDev/Longshot
MagicBeanDev/Longshot
Watch
74
95
Fork
You've already forked Longshot
 98
Code Issues 230 Pull requests 280 Projects Releases 9 Packages Wiki Activity Actions 797

perf(build): the game is built for the player's own CPU (-march=native), keyed by the CPU clang resolves it to #524

Merged
HumanBean merged 1 commit from HumanBean/Longshot:perf/native-cpu into main 2026-11-14 18:29:27 +00:00
Conversation 2 Commits 1 Files changed 4 +104 -33
HumanBean commented 2026-11-14 17:45:36 +00:00
Owner

Why

The game is compiled on each player's own PC, but always for the x86-64-v3 level (AVX2), so a newer CPU's extra instructions (AVX-512 on Zen 4/5 and some Intel CPUs) and its own tuning go unused. This builds it for the CPU it is built on, as issue 182 asks, without letting a changed CPU reuse objects made for another.

What changed

  • build: nx2/build.py, after CPU and MTUNE are set: a CPU that would get x86-64-v3 (and no RX_MARCH) is built with -march=native instead. CPUs without AVX2 keep x86-64-v2 / x86-64 as before, and RX_MARCH still decides when it is set.
  • build: -march=native names no CPU, and object keys are made from the flags (flag_text/object_key). On its own it would keep the same keys on another CPU (a new CPU, the disk in another PC, an object store that outlives the CPU) and link objects made for instructions the CPU may lack, which is the no-AVX2 Xeon crash that nx2/build.py cites as issue 363's crash again. So native_cpu() (new, nx2/host_cpu.py) asks clang what native is here (clang -###: -target-cpu, -tune-cpu, the -target-feature list), and build.py adds -DLONGSHOT_NATIVE_CPU=<cpu>_<tune>_<sha1 of the features> to the flags, e.g. znver4_znver4_… on a Ryzen 9 7900X. Another CPU, or the same model with AVX-512 off, gets other keys and compiles again. The build log names it: build: the game is built for this PC's CPU (…).
  • build: native tunes for the CPU as well (clang's -tune-cpu follows -target-cpu), so the tuning setting goes: host_mtune() (its only rule was znver2 on a Steam Deck, which native gives the Deck's Zen 2 anyway) and RX_MTUNE are removed, and no -mtune is passed (it would override native's).
  • build: if clang can't say what native is, the default stays x86-64-v3. An explicit RX_MARCH=native that clang can't resolve stops the build, so it never produces keys that name no CPU. On Windows the query opens no console (CREATE_NO_WINDOW).
  • Unchanged: the AppImage's prebuilt renderer stays x86-64-v3 (scripts/linux/appimage.sh sets RX_MARCH), and so does make_game.py's check_cpu (it reads host_march(), which is unchanged). -ffp-contract=off stays, so float rounding is the same. No code path depends on AVX-512 (the only feature-gated code checks AVX2/FMA, which v3 already has).
  • tests: tests/test_cpu_target.py: test_steamdeck_mtune goes with host_mtune(); new NativeCpu: the name from clang's output (CPU, tune, features; feature order doesn't matter), another CPU or another feature set gives another name, no answer gives None, and build.py's block (native only when the CPU chose v3 and no RX_MARCH, the name in CPU, the stop for an explicit native, no -mtune left in build.py).
  • docs: docs/development.md, the RX_MARCH row (the new default, the key, native's tuning).

Flags and settings

Flag What it does Default now Recommendation Helps on Doesn't help on Untested on
RX_MARCH The CPU level to build for; native is now the default on a CPU with v3's features, keyed by the CPU clang finds native on v3 CPUs (was x86-64-v3); x86-64-v2 / x86-64 below On: the game is always built on the PC it runs on. RX_MARCH=x86-64-v3 is the way back Expected: CPUs with more than v3 (AVX-512: Zen 4/5, some Intel). Not measured CPUs at about v3 (most of the gain would be tuning) Every CPU: nothing was run
RX_MTUNE Removed, with host_mtune()'s Steam Deck rule: native tunes for the CPU itself - - - - -

Measurements

Not measured: the owner chose to open this without a measurement, as it changes only how the game is compiled. The expected gain is small (0-2 %: the lifted code is mostly scalar and at -O1, which clang doesn't vectorize; only the -O2 hot pieces could use AVX-512), and no number backs it yet. Build time should not change (the target level hardly changes clang's work); not measured either.

Testing

Tested: nothing was run on this PC: no build, no game, and no local checks (tests/run_all.py is left to CI). clang -march=native -### on this PC's clang (Ryzen 9 7900X, CachyOS) prints -target-cpu znver4 and the AVX-512 features, which is the output native_cpu() reads.

Not tested: a build with this change, so the clang query and the new keys have never run in a build; the game built at native, on any CPU; Windows (llvm-mingw's clang, the nul device for -o); the AppImage's player build (its clang resolving native, the dry run in scripts/linux/check_player_build.sh).

Needs other testers:

  • Windows, any CPU with AVX2: a first build, expecting build: the game is built for this PC's CPU (<cpu>_…) in the log and the game starting (request to open)
  • Linux AppImage: the same (request to open)
  • An Intel CPU with AVX-512 off or none (12th gen and later): the same, expecting the game to start (request to open)

Screenshots

Nothing on screen.

Risk and rollback

  • A wrong answer from clang about the CPU (a VM or Wine reporting features the CPU lacks) would build instructions the CPU can't run: the game stops at its first one (0xc000001d on Windows). RX_MARCH=x86-64-v3 builds as before.
  • A Steam Deck where clang can't resolve native now builds at plain x86-64-v3 without znver2 tuning (before: v3 tuned for znver2).
  • Each player's game binary now differs by CPU, so a crash may reproduce only on that CPU; the build log names it.
  • The first build after this lands compiles every object again on v3 CPUs (the flags change). Reverting the commit is enough.

Reviewer notes

nx2/build.py's block after MTUNE, then native_cpu() in nx2/host_cpu.py. The resolved name is put in the flags as a define, not as -march=<cpu>, so the compiler still gets exactly what native gives it (the feature list, not only the CPU's name).

Issues

Fixes #182

Checklist

For everyone

  • One topic.
  • The title is a Conventional Commit (type(scope): description).
  • Rebased on current main.
  • python -I -B tests/run_all.py run and passing (any failure that also fails on main is named above). (not run here: left to CI)
  • Tested in the game, or what wasn't is named under Testing.
  • Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests).
  • Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. (not measured: the owner's choice, see Measurements)
  • 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.

If applicable

  • AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
  • Flags noted, and the switch reference updated (docs/development.md, the README).
  • 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.
  • Docs updated.

🤖 Generated with Claude Code

## Why The game is compiled on each player's own PC, but always for the x86-64-v3 level (AVX2), so a newer CPU's extra instructions (AVX-512 on Zen 4/5 and some Intel CPUs) and its own tuning go unused. This builds it for the CPU it is built on, as [issue 182](https://git.magicbean.dev/MagicBeanDev/Longshot/issues/182) asks, without letting a changed CPU reuse objects made for another. ## What changed - build: `nx2/build.py`, after `CPU` and `MTUNE` are set: a CPU that would get `x86-64-v3` (and no `RX_MARCH`) is built with `-march=native` instead. CPUs without AVX2 keep `x86-64-v2` / `x86-64` as before, and `RX_MARCH` still decides when it is set. - build: `-march=native` names no CPU, and object keys are made from the flags (`flag_text`/`object_key`). On its own it would keep the same keys on another CPU (a new CPU, the disk in another PC, an object store that outlives the CPU) and link objects made for instructions the CPU may lack, which is the no-AVX2 Xeon crash that `nx2/build.py` cites as issue 363's crash again. So `native_cpu()` (new, `nx2/host_cpu.py`) asks clang what native is here (`clang -###`: `-target-cpu`, `-tune-cpu`, the `-target-feature` list), and build.py adds `-DLONGSHOT_NATIVE_CPU=<cpu>_<tune>_<sha1 of the features>` to the flags, e.g. `znver4_znver4_…` on a Ryzen 9 7900X. Another CPU, or the same model with AVX-512 off, gets other keys and compiles again. The build log names it: `build: the game is built for this PC's CPU (…)`. - build: native tunes for the CPU as well (clang's `-tune-cpu` follows `-target-cpu`), so the tuning setting goes: `host_mtune()` (its only rule was `znver2` on a Steam Deck, which native gives the Deck's Zen 2 anyway) and `RX_MTUNE` are removed, and no `-mtune` is passed (it would override native's). - build: if clang can't say what native is, the default stays `x86-64-v3`. An explicit `RX_MARCH=native` that clang can't resolve stops the build, so it never produces keys that name no CPU. On Windows the query opens no console (`CREATE_NO_WINDOW`). - Unchanged: the AppImage's prebuilt renderer stays `x86-64-v3` (`scripts/linux/appimage.sh` sets `RX_MARCH`), and so does `make_game.py`'s `check_cpu` (it reads `host_march()`, which is unchanged). `-ffp-contract=off` stays, so float rounding is the same. No code path depends on AVX-512 (the only feature-gated code checks AVX2/FMA, which v3 already has). - tests: `tests/test_cpu_target.py`: `test_steamdeck_mtune` goes with `host_mtune()`; new `NativeCpu`: the name from clang's output (CPU, tune, features; feature order doesn't matter), another CPU or another feature set gives another name, no answer gives `None`, and build.py's block (native only when the CPU chose v3 and no `RX_MARCH`, the name in `CPU`, the stop for an explicit native, no `-mtune` left in build.py). - docs: `docs/development.md`, the `RX_MARCH` row (the new default, the key, native's tuning). ## Flags and settings | Flag | What it does | Default now | Recommendation | Helps on | Doesn't help on | Untested on | |---|---|---|---|---|---|---| | `RX_MARCH` | The CPU level to build for; `native` is now the default on a CPU with v3's features, keyed by the CPU clang finds | **`native`** on v3 CPUs (was `x86-64-v3`); `x86-64-v2` / `x86-64` below | On: the game is always built on the PC it runs on. `RX_MARCH=x86-64-v3` is the way back | Expected: CPUs with more than v3 (AVX-512: Zen 4/5, some Intel). Not measured | CPUs at about v3 (most of the gain would be tuning) | Every CPU: nothing was run | | `RX_MTUNE` | **Removed**, with `host_mtune()`'s Steam Deck rule: native tunes for the CPU itself | - | - | - | - | - | ## Measurements Not measured: the owner chose to open this without a measurement, as it changes only how the game is compiled. The expected gain is small (0-2 %: the lifted code is mostly scalar and at -O1, which clang doesn't vectorize; only the -O2 hot pieces could use AVX-512), and no number backs it yet. Build time should not change (the target level hardly changes clang's work); not measured either. ## Testing **Tested:** nothing was run on this PC: no build, no game, and no local checks (`tests/run_all.py` is left to CI). `clang -march=native -###` on this PC's clang (Ryzen 9 7900X, CachyOS) prints `-target-cpu znver4` and the AVX-512 features, which is the output `native_cpu()` reads. **Not tested:** a build with this change, so the clang query and the new keys have never run in a build; the game built at native, on any CPU; Windows (llvm-mingw's clang, the `nul` device for `-o`); the AppImage's player build (its clang resolving native, the dry run in `scripts/linux/check_player_build.sh`). **Needs other testers:** - Windows, any CPU with AVX2: a first build, expecting `build: the game is built for this PC's CPU (<cpu>_…)` in the log and the game starting (request to open) - Linux AppImage: the same (request to open) - An Intel CPU with AVX-512 off or none (12th gen and later): the same, expecting the game to start (request to open) ## Screenshots Nothing on screen. ## Risk and rollback - A wrong answer from clang about the CPU (a VM or Wine reporting features the CPU lacks) would build instructions the CPU can't run: the game stops at its first one (0xc000001d on Windows). `RX_MARCH=x86-64-v3` builds as before. - A Steam Deck where clang can't resolve native now builds at plain `x86-64-v3` without `znver2` tuning (before: v3 tuned for `znver2`). - Each player's game binary now differs by CPU, so a crash may reproduce only on that CPU; the build log names it. - The first build after this lands compiles every object again on v3 CPUs (the flags change). Reverting the commit is enough. ## Reviewer notes `nx2/build.py`'s block after `MTUNE`, then `native_cpu()` in `nx2/host_cpu.py`. The resolved name is put in the flags as a define, not as `-march=<cpu>`, so the compiler still gets exactly what native gives it (the feature list, not only the CPU's name). ## Issues Fixes https://git.magicbean.dev/MagicBeanDev/Longshot/issues/182 ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [x] Rebased on current `main`. - [ ] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). (not run here: left to CI) - [x] Tested in the game, or what wasn't is named under Testing. - [x] Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). - [ ] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. (not measured: the owner's choice, see Measurements) - [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. ### If applicable - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [x] Flags noted, and the switch reference updated (docs/development.md, the README). - [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] Docs updated. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
perf(build): the game is built for the player's own CPU (-march=native), keyed by the CPU clang resolves it to
All checks were successful
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been skipped
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been skipped
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been skipped
Details
Third-party parts / The same as upstream (pull_request) Has been skipped
Details
PR description / Description follows the template (pull_request_target) Successful in 17s
Details
CI / Conventional Commit title (pull_request) Successful in 13s
Details
CI / Workflow lint (actionlint) (pull_request) Successful in 19s
Details
Third-party parts / As their notes say (pull_request) Successful in 30s
Details
7318c14905 
A CPU with x86-64-v3's features now gets the game built with -march=native: whatever it
has beyond v3 (AVX-512 on Zen 4/5 and some Intel CPUs, newer extensions) and its own
tuning. The game is always built on the PC it runs on, so nothing ships for another CPU.

-march=native names no CPU, and the object keys are made from the flags: alone it would
keep the same keys on another CPU (a new one, the disk in another PC) and link objects
made for instructions the CPU may lack. nx2/host_cpu.py's native_cpu() asks clang
(-###) for its -target-cpu, -tune-cpu and -target-feature list, and build.py adds it as
-DLONGSHOT_NATIVE_CPU=<cpu>_<tune>_<features hash>, so another CPU compiles again.

If clang can't say, the default stays x86-64-v3; an explicit RX_MARCH=native or
RX_MTUNE=native stops the build. RX_MARCH=x86-64-v3 builds as before. CPUs without
AVX2 keep x86-64-v2 / x86-64, and the AppImage's prebuilt renderer stays x86-64-v3
(scripts/linux/appimage.sh sets RX_MARCH).

Fixes #182

Co-Authored-By: Claude Opus 5.5 <[email protected]>
HumanBean force-pushed perf/native-cpu from 7318c14905
All checks were successful
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been skipped
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been skipped
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been skipped
Details
Third-party parts / The same as upstream (pull_request) Has been skipped
Details
PR description / Description follows the template (pull_request_target) Successful in 17s
Details
CI / Conventional Commit title (pull_request) Successful in 13s
Details
CI / Workflow lint (actionlint) (pull_request) Successful in 19s
Details
Third-party parts / As their notes say (pull_request) Successful in 30s
Details
to 8c4b730864
Some checks failed
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been skipped
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been skipped
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been skipped
Details
Third-party parts / The same as upstream (pull_request) Has been skipped
Details
CI / Conventional Commit title (pull_request) Successful in 3s
Details
CI / Workflow lint (actionlint) (pull_request) Successful in 5s
Details
Third-party parts / As their notes say (pull_request) Successful in 10s
Details
Website / Website on Cloudflare (pull_request_target) Has been skipped
Details
PR description / Description follows the template (pull_request_target) Failing after 4s
Details
2026-11-14 18:05:17 +00:00 Compare
HumanBean commented 2026-11-14 18:05:23 +00:00
Author
Owner

Pushed 8c4b7308: the tuning setting is removed. -march=native tunes for the CPU too (clang's tune CPU follows the target CPU), so host_mtune() (its one rule was znver2 on a Steam Deck, which native gives the Deck's Zen 2 anyway) and RX_MTUNE go, and no -mtune is passed. test_steamdeck_mtune goes with host_mtune(); NativeCpu checks that build.py has no -mtune left. Description updated. Still not built or run here; run_all is left to CI.

Pushed 8c4b7308: the tuning setting is removed. -march=native tunes for the CPU too (clang's tune CPU follows the target CPU), so host_mtune() (its one rule was znver2 on a Steam Deck, which native gives the Deck's Zen 2 anyway) and RX_MTUNE go, and no -mtune is passed. test_steamdeck_mtune goes with host_mtune(); NativeCpu checks that build.py has no -mtune left. Description updated. Still not built or run here; run_all is left to CI.
HumanBean changed title from WIP: perf(build): the game is built for the player's own CPU (-march=native), keyed by the CPU clang resolves it to to perf(build): the game is built for the player's own CPU (-march=native), keyed by the CPU clang resolves it to 2026-11-14 18:29:22 +00:00
HumanBean deleted branch perf/native-cpu 2026-11-14 18:29:27 +00:00
PirateKingIsh commented 2026-11-14 22:31:16 +00:00
First-time contributor

Tested on Windows with a Ryzen 7 9800X3D (Zen 5): it builds, the game starts, and I measure no gain and no loss.

Hardware: Ryzen 7 9800X3D, RTX 5090, NVIDIA 621.24, 64 GB, Windows 11 26200.
Built: nightly-148 @ 8b619764 (nightly-147 plus #571, a docs change) with that release's Builder (LongshotBuilder.exe --portable --cli), twice from the same game files: as it is, and with RX_MARCH=x86-64-v3.

The build. The clang query works with the Builder's llvm-mingw on Windows. The log has build: the game is built for this PC's CPU (znver5_znver5_7c8212492d), then "compiled in 327s, 0 failed". The native game was started five times (one run of a minute, four of about four minutes): each time it loaded a save and ended by its own quit. No crash, no device lost.

The measurement.

Baseline: nightly-148 @ 8b619764 built with RX_MARCH=x86-64-v3
Compared: nightly-148 @ 8b619764 as it builds (native: znver5)
One commit built two ways, not main against a PR: the change is merged, and RX_MARCH is its switch.
Scene: child Link; the control client's teleport to Hyrule Field (then 6 s forward) and to the Market; in each, 40 s standing and 40 s with the right stick held right. The time of day was not recorded.
Settings: default options, built without the DLSS SDK, HOS_FPS_MAX=1000. No window (longshot_ctl.py launch --profile test). From the log: "oe: output resolution 2560x1440"; "boot: widescreen: picture 3416x1440, scene 2560x1080" (the default Aspect ratio follows my 21:9 screen); "vk: no window: presents render offscreen (1920x1080)".
Method: frame times from RX_VK_FRAME_LOG with 1.5 s cut from each end of a segment; one warm-up run each, then three runs each, interleaved (native, v3, v3, native, native, v3); the median of the three. 1% low = 1000 / the mean of the slowest 1% of a segment's frame times.
median of 3 runs fps, x86-64-v3 fps, native Δ 1% low, x86-64-v3 1% low, native Δ
Hyrule Field, standing 111.90 112.33 +0.4% 80.04 82.87 +3.5%
Hyrule Field, camera turning 104.70 104.54 -0.2% 63.84 63.45 -0.6%
Market, standing 77.20 75.04 -2.8% 51.89 51.98 +0.2%
Market, camera turning 85.61 85.83 +0.3% 44.57 44.64 +0.2%

In every row the two builds differ by less than the three native runs differ from each other (up to 6% in fps, up to 16% in the 1% low). No frame over 50 ms in any measured segment.

One thing I would not call a loss without more runs: standing in the Market, native was the slower one in each of the three pairs (71.98 against 76.27, 75.04 against 77.20, 76.54 against 77.52 fps), with the gap shrinking each time.

Log lines, from a native run in the Market:

[hos host] longshot nightly-148-8b619764 (source b6daf910)
[hos MainThread] vk: NVIDIA GeForce RTX 5090, Vulkan 1.4, driver 0x9b460000; mesh shaders yes, host memory import yes, pipeline libraries yes
[hos host] vi: frame rate uncapped: pacing, the game's limiter and its time step follow the frames
[hos Presentation Thread] vk: 24000 presents, 75.7 fps; a frame: 2486 draws (0 skipped), 121 dispatches, 161 passes, 145 barriers, 6 submits, ...

Not measured: with a window (these are the offscreen path's frame intervals), DLSS and frame generation, other areas, v3.0.0-rc.3, and build time (one build each: 327 s native, 296 s x86-64-v3, the second with a warm file cache).

The runs and this text were done with AI assistance (Claude).

**Tested on Windows with a Ryzen 7 9800X3D (Zen 5): it builds, the game starts, and I measure no gain and no loss.** Hardware: Ryzen 7 9800X3D, RTX 5090, NVIDIA 621.24, 64 GB, Windows 11 26200. Built: nightly-148 @ 8b619764 (nightly-147 plus #571, a docs change) with that release's Builder (`LongshotBuilder.exe --portable --cli`), twice from the same game files: as it is, and with `RX_MARCH=x86-64-v3`. **The build.** The clang query works with the Builder's llvm-mingw on Windows. The log has `build: the game is built for this PC's CPU (znver5_znver5_7c8212492d)`, then "compiled in 327s, 0 failed". The native game was started five times (one run of a minute, four of about four minutes): each time it loaded a save and ended by its own quit. No crash, no device lost. **The measurement.** ``` Baseline: nightly-148 @ 8b619764 built with RX_MARCH=x86-64-v3 Compared: nightly-148 @ 8b619764 as it builds (native: znver5) One commit built two ways, not main against a PR: the change is merged, and RX_MARCH is its switch. Scene: child Link; the control client's teleport to Hyrule Field (then 6 s forward) and to the Market; in each, 40 s standing and 40 s with the right stick held right. The time of day was not recorded. Settings: default options, built without the DLSS SDK, HOS_FPS_MAX=1000. No window (longshot_ctl.py launch --profile test). From the log: "oe: output resolution 2560x1440"; "boot: widescreen: picture 3416x1440, scene 2560x1080" (the default Aspect ratio follows my 21:9 screen); "vk: no window: presents render offscreen (1920x1080)". Method: frame times from RX_VK_FRAME_LOG with 1.5 s cut from each end of a segment; one warm-up run each, then three runs each, interleaved (native, v3, v3, native, native, v3); the median of the three. 1% low = 1000 / the mean of the slowest 1% of a segment's frame times. ``` | median of 3 runs | fps, x86-64-v3 | fps, native | Δ | 1% low, x86-64-v3 | 1% low, native | Δ | |---|---:|---:|---:|---:|---:|---:| | Hyrule Field, standing | 111.90 | 112.33 | +0.4% | 80.04 | 82.87 | +3.5% | | Hyrule Field, camera turning | 104.70 | 104.54 | -0.2% | 63.84 | 63.45 | -0.6% | | Market, standing | 77.20 | 75.04 | -2.8% | 51.89 | 51.98 | +0.2% | | Market, camera turning | 85.61 | 85.83 | +0.3% | 44.57 | 44.64 | +0.2% | In every row the two builds differ by less than the three native runs differ from each other (up to 6% in fps, up to 16% in the 1% low). No frame over 50 ms in any measured segment. One thing I would not call a loss without more runs: standing in the Market, native was the slower one in each of the three pairs (71.98 against 76.27, 75.04 against 77.20, 76.54 against 77.52 fps), with the gap shrinking each time. Log lines, from a native run in the Market: ``` [hos host] longshot nightly-148-8b619764 (source b6daf910) [hos MainThread] vk: NVIDIA GeForce RTX 5090, Vulkan 1.4, driver 0x9b460000; mesh shaders yes, host memory import yes, pipeline libraries yes [hos host] vi: frame rate uncapped: pacing, the game's limiter and its time step follow the frames [hos Presentation Thread] vk: 24000 presents, 75.7 fps; a frame: 2486 draws (0 skipped), 121 dispatches, 161 passes, 145 barriers, 6 submits, ... ``` Not measured: with a window (these are the offscreen path's frame intervals), DLSS and frame generation, other areas, v3.0.0-rc.3, and build time (one build each: 327 s native, 296 s x86-64-v3, the second with a warm file cache). The runs and this text were done with AI assistance (Claude).
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
area/accessibility
Barriers for people with disabilities

  
area/audio
Sound and music

  
area/input
Controllers, keyboard, mouse

  
area/install
Installing, updating, building from your game

  
area/menu
In-game menu and settings

  
area/renderer
Vulkan renderer, shaders, effects

  
area/saves
Save files

  
area/upscaling
DLSS, FSR, frame generation

  
beanstalk: approved @ 1697603
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 2c5a62e
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 4fd82b7
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 64d6d09
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 6f91fae
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 70a78f9
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 8d361dc
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ 9d8356e
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ abf2227
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ d82f202
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ e5f1e40
Set by Beanstalk for show; the farm's database is what counts

  
beanstalk: approved @ ee8ab5f
Set by Beanstalk for show; the farm's database is what counts

  
ci: approved
A maintainer approved CircleCI for this fork PR (sticky; removed after 14 quiet days)

  
good first issue
A good start for a new contributor

  
gpu/amd
AMD GPUs

  
gpu/igpu
Integrated GPUs

  
gpu/intel
Intel GPUs

  
gpu/nvidia
NVIDIA GPUs

  
help wanted
Extra hands or knowledge wanted

  
kind
bug
 Something doesn't work as it should

  
kind
chore
 Build, CI, dependencies, tidying

  
kind
docs
 Documentation

  
kind
feature
 A new feature or an improvement

  
kind
performance
 Frame rate, frame time, loading, memory

  
kind
question
 A question rather than a change

  
needs measurements
Waiting for before/after measurements

  
platform/linux
Affects Linux (a change for every system carries both Windows and Linux)

  
platform/macos
macOS (Apple silicon or Intel Macs)

  
platform/steam-deck
Steam Deck

  
platform/windows
Affects Windows (a change for every system carries both Windows and Linux)

  
preview
Maintainers: deploy a preview of this PR's website (read its changes first). Removed after the run.

  
priority
critical
 Crashes, data loss, or blocks most players

  
priority
high
 Important: next in line

  
priority
low
 Nice to have

  
regression
Worked in an earlier build, broken in a newer one: highest priority, above other bugs

  
status
blocked
 Waits on something else first

  
status
confirmed
 Reproduced or agreed on

  
status
duplicate
 Already reported or proposed

  
status
invalid
 Not a problem in this project

  
status
needs-info
 Waiting for more information from the reporter

  
status
wontfix
 Will not be worked on

  
testing wanted
Wanted: a test on other hardware (posts a test request in #test-requests)

  
ci: approved
No labels
area/accessibility
area/audio
area/input
area/install
area/menu
area/renderer
area/saves
area/upscaling
beanstalk: approved @ 1697603
beanstalk: approved @ 2c5a62e
beanstalk: approved @ 4fd82b7
beanstalk: approved @ 64d6d09
beanstalk: approved @ 6f91fae
beanstalk: approved @ 70a78f9
beanstalk: approved @ 8d361dc
beanstalk: approved @ 9d8356e
beanstalk: approved @ abf2227
beanstalk: approved @ d82f202
beanstalk: approved @ e5f1e40
beanstalk: approved @ ee8ab5f
ci: approved
good first issue
gpu/amd
gpu/igpu
gpu/intel
gpu/nvidia
help wanted
kind
bug
kind
chore
kind
docs
kind
feature
kind
performance
kind
question
needs measurements
platform/linux
platform/macos
platform/steam-deck
platform/windows
preview
priority
critical
priority
high
priority
low
regression
status
blocked
status
confirmed
status
duplicate
status
invalid
status
needs-info
status
wontfix
testing wanted
ci: approved
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
MagicBeanDev/Longshot!524
No description provided.