Pull requests / #376
#376 HIP: a failed first configure no longer leaves the kernels at -O0
closed · @BlueKingMuch · 0 comentários · No GitHub
BenchmarksSetup & installAMD / HIPWindowsLinux
Descrição
When a configure fails because the HIP compiler cannot compile at all, the build folder keeps empty per-configuration HIP flags, and every build in that folder afterwards compiles all kernels at -O0, while C and C++ still get -O3. setup configures `build-hip` every time, so one failed attempt is enough. On Windows two things here do it: Visual Studio 2026's `<cmath>` (#373), and #356's setup.py with the HIP SDK in its default folder (below). On an RX 6800 the engine built afterwards decoded at 0.24-0.27 tok/s instead of 28. CMake caches `CMAKE_HIP_FLAGS_<CONFIG>` while it enables HIP, from the values its platform files set once the compiler is identified (`CMAKE_HIP_FLAGS_<CONFIG>_INIT`). When the identification compile fails, those values are empty: the configure caches them and stops. The next configure of the same folder identifies the compiler but keeps the cached values, as CMake does with any cached setting. The HIP sources then compile without `-O` (clang's default is -O0) and without `-DNDEBUG`. ## What changes - After `enable_language(HIP)`, `cmake/hip_backend.cmake` gives each empty per-configuration HIP flag the value CMake computed for the compiler (`CMAKE_HIP_FLAGS_<CONFIG>_INIT`), which is what a fresh build folder gets. Flags with a value, from CMake or the command line, are left alone, so a folder whose configure never failed is unchanged. (A flag set empty on purpose with `-D` is filled too.) - `setup.py`'s engine fingerprint (`ENGINE_SOURCES`) now covers `cmake/` as well, so a change there alone, like this one, recompiles a locally built engine on its next start. That includes NVIDIA engines compiled locally, whenever `cmake/` changes. An alternative would be for setup to delete `build-hip/CMakeCache.txt` after a failed configure. This way also covers manual builds and folders that are already in that state. ## How it happened here RX 6800, Windows 11, HIP SDK 7.2, CMake 4.0.1, Visual Studio 2026 Build Tools. The first setup run failed on VS 2026's `<cmath>` (#373); CMake's configure log in `build-hip` shows the HIP compiler's identification failing there. The next run passed with the `<cmath>` fix, and the HIP sources compiled without `-O` (that folder's `CMakeCache.txt` still has `CMAKE_HIP_FLAGS_DEBUG` empty; `_RELEASE` was empty until a first version of this fix filled it). The engine was 0.1.30 with #247's Windows build, `--expert-cache 2048`: | | HIP flags empty (-O0) | -O3 -DNDEBUG | |---|---|---| | decode | 0.24-0.27 tok/s | 28.1-28.3 tok/s | | decode window (verify, commit, draft) | 7.06-7.50 s | 59-62 ms | `STRATA_VERIFY_PROFILE` at -O0 put the time in the GPU's own stages (per window: q8+qkv GEMVs 1468 ms and out-proj 849 ms in the DeltaNet layers, the LM head 540 ms); the waits for flags the CPU raises were 41 ms of its 8.4 s per window. ## Reproduced Configure only, gfx1100, the Release flags CMake cached and the `FLAGS` of `native_mmvq.cu` in `build.ninja`. **Windows 11**, HIP SDK 7.2, CMake 4.0.1, VS 2026 Build Tools; 0.1.31 with #356 and #373, without and with this PR. The failing first configure is #356's setup.py as it is: it passes `-DCMAKE_HIP_FLAGS=--rocm-path=C:/Program Files/AMD/ROCm/7.2 --rocm-device-lib-path=...`, the space splits the flag (`clang++: error: no such file or directory: 'Files/AMD/ROCm/7.2'`) and "The HIP compiler identification is unknown". The second configure, in the same folder, leaves those flags out (the SDK's clang finds its installation by itself): | | without this PR | this PR | |---|---|---| | fresh folder, one working configure | `-O3 -DNDEBUG` | (not run; nothing is empty there) | | 1st configure with #356's flags (fails), 2nd without them | `CMAKE_HIP_FLAGS_RELEASE` empty, `native_mmvq.cu` compiles without `-O` | `-O3 -DNDEBUG` (`_DEBUG`: `-O0 -g -Xclang -gcodeview`, as in a fresh folder) | **Linux**, CMake 3.28, TheRock's ROCm 7.10 clang, configured the way setup does it: | | main | this PR | |---|---|---| | fresh folder | `-O3 -DNDEBUG` | `-O3 -DNDEBUG` | | 1st configure with a `--rocm-device-lib-path` that does not exist (fails: "The HIP compiler identification is unknown"), then the right flags in the same folder | `CMAKE_HIP_FLAGS_RELEASE` empty, `native_mmvq.cu` compiles without `-O` | `-O3 -DNDEBUG` | To reproduce: configure with `-DCMAKE_HIP_FLAGS="--rocm-path=<root> --rocm-device-lib-path=/nowhere"`, then again with the right device-library path, and look at `CMAKE_HIP_FLAGS_RELEASE` in `CMakeCache.txt` or at the `FLAGS` of a `.cu` object in `build.ninja`. The kernels themselves do not change; this only gives them the flags a fresh build folder gives them. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_015Ld5YDzuKW1hgMVwwgRZDP
No site
Links install, modelos, releases.