fix(build): an RX_MARCH choice is not reported as a CPU without AVX2 #2223

Merged

Brett-D merged 1 commit from fix/rx-march-message into main

2026-11-11 19:30:20 +00:00

Brett-D commented

2026-11-11 09:06:05 +00:00

(Migrated from github.com)

Problem

With RX_MARCH=znver2 (Steam Deck, Zen 2: AVX2, FMA and more), nx2/build.py printed build: this CPU has no AVX2: the game is built for znver2 (a little slower). The message assumed any level other than x86-64-v3 was the CPU check's fallback.

Change

this CPU has no AVX2 is now printed only when host_march() chose the level. An explicit RX_MARCH other than x86-64-v3 is reported as build: the game is built for <march> (RX_MARCH). Flags are unchanged.

Testing

tests/test_cpu_target.py gains a test that runs the actual selection block from build.py with mocked RX_MARCH and host_march() values. It fails on main (znver2 reported as "no AVX2") and passes on Windows and Linux.

**Problem** With `RX_MARCH=znver2` (Steam Deck, Zen 2: AVX2, FMA and more), `nx2/build.py` printed `build: this CPU has no AVX2: the game is built for znver2 (a little slower)`. The message assumed any level other than `x86-64-v3` was the CPU check's fallback. **Change** `this CPU has no AVX2` is now printed only when `host_march()` chose the level. An explicit `RX_MARCH` other than `x86-64-v3` is reported as `build: the game is built for <march> (RX_MARCH)`. Flags are unchanged. **Testing** `tests/test_cpu_target.py` gains a test that runs the actual selection block from `build.py` with mocked `RX_MARCH` and `host_march()` values. It fails on main (`znver2` reported as "no AVX2") and passes on Windows and Linux.

hckrman101 (Migrated from github.com) approved these changes

2026-11-11 17:34:32 +00:00

hckrman101 (Migrated from github.com) left a comment

Looks good. The message now says "no AVX2" only when host_march() made the choice, and an explicit RX_MARCH is reported as such. The flags are untouched. The empty-string RX_MARCH case behaves the same as before (falls through to host_march()), and the test's four cases cover both branches, including the silent ones. All CI checks are green and the PR is mergeable.

Note on #2383 (single-precision FMA/FRECPS/FRSQRTS fused on x86-64-v3): it only touches the comment above this block in nx2/build.py, so the two don't conflict. The interaction is that an explicit RX_MARCH now gets a truthful message, which matters more once the fast path depends on the level. An RX_MARCH=znver2 build has FMA but is not x86-64-v3, so #2383 should key on the feature (__FMA__) rather than on the string x86-64-v3. That is for #2383, not this PR.

Nit: the test slices build.py by text and execs it. That is fine here and matches how other tests in the repo work, but it will need updating if the block is reshaped.

Looks good. The message now says "no AVX2" only when `host_march()` made the choice, and an explicit `RX_MARCH` is reported as such. The flags are untouched. The empty-string `RX_MARCH` case behaves the same as before (falls through to `host_march()`), and the test's four cases cover both branches, including the silent ones. All CI checks are green and the PR is mergeable. Note on #2383 (single-precision FMA/FRECPS/FRSQRTS fused on x86-64-v3): it only touches the comment above this block in `nx2/build.py`, so the two don't conflict. The interaction is that an explicit `RX_MARCH` now gets a truthful message, which matters more once the fast path depends on the level. An `RX_MARCH=znver2` build has FMA but is not x86-64-v3, so #2383 should key on the feature (`__FMA__`) rather than on the string `x86-64-v3`. That is for #2383, not this PR. Nit: the test slices `build.py` by text and `exec`s it. That is fine here and matches how other tests in the repo work, but it will need updating if the block is reshaped.