Pull requests / #2784

#2784 HIP: the RX 6600 / 6650 XT (gfx1032) in setup's cards and CMake's unvalidated list

open · @chenxyz129 · 0 commentaires · Sur GitHub

BenchmarksSetup & installServer & APIAMD / HIPNVIDIA / CUDAModels & quantsDocumentationWindows

Description

Issue: Refs #1375 (the gfx1032 report), #1378 (the open RX 6600 benchmark)

## Summary

Adds gfx1032 (AMD Radeon RX 6600 / 6650 XT, RDNA2) to the architectures setup installs and builds for, and to CMake's
`_strata_hip_unvalidated` list, so this card is no longer refused.

The engine already compiles for gfx1032: `include/strata/hip_compat/intrinsics.hpp` gates
`__gfx1030__ || __gfx1031__ || __gfx1032__` on the same signed-dot4 branch, and `docs/AMD_HIP.md` already listed gfx1032
as "the same `dp4a` path, no hardware report". Only the setup and CMake lists were missing. Built and run on one
RX 6650 XT (gfx1032, 8 GB, Fedora, ROCm 7.1.1).

## What changed

- `cmake/hip_backend.cmake`: gfx1032 added to `_strata_hip_unvalidated`, next to gfx1030/gfx1031 (the same `dp4a`
  path). A `-DCMAKE_HIP_ARCHITECTURES=gfx1032` now builds with the usual "not validated" warning instead of
  `FATAL_ERROR`.
- `setup.py`: gfx1032 added to `ROCM_INDEXES` (the `gfx103X-all` wheels, as gfx1030/gfx1031), `AMD_ARCHS` (so setup
  detects and builds for the card), `AMD_NAMES`, the `AMD_CARDS` sentence and the AMD header comment.
- `docs/AMD_HIP.md`: gfx1032 moved out of "Not validated" into a line of its own (like gfx1031), with what was run.
- `docs/OLDER_GPUS.md`: an RX 6600 / 6650 XT row in the AMD table.
- `tools/test_setup_amd.py`: gfx1032 is asserted to take the same wheels and path as gfx1030/gfx1031.

**Left alone:** the engine and kernel sources, the CUDA and SYCL backends, and every existing card's entry. On a
machine without a gfx1032 card nothing changes.

## How it was checked

- `python tools/test_setup_amd.py` -> 36 tests OK; `python tools/test_setup_rocm_pins.py` -> 17 tests OK (both run
  before and after the change).
- HIP engine built for gfx1032 on the machine (ROCm 7.1.1, rocBLAS from the `_rocm_sdk_libraries_gfx103X_all` wheel,
  see the notes below): `./build-hip/strata-device --selftest` ->
  `HIP arch gfx1032 wave32 (compiled for gfx1032) ... strata-device selftest OK`.
- A model served end to end (Qwen3.8-Flash-Next Q2_0 on the 8 GB card): `/v1/models` reports it loaded and chat
  answers are correct.

## Extra Notes

- Reported **unvalidated**, like gfx1030 in #311: one machine, and no llama.cpp parity or KL/quality run yet. A
  same-day A/B against a build on a supported card, and `tools/qwen35/parity.py` / `tools/quant_quality.py`, are not in
  this PR - I can follow up with them.
- Two notes specific to this box are **not** part of the patch (Fedora / AMD library packaging, not Strata):
  1. Fedora's ROCm 7.1.1 lives in `/usr` (no `/opt/rocm`, libraries in `lib64`); a small symlink shim gives setup the
     `ROCM_PATH` layout it expects, without changing system detection.
  2. The system rocBLAS Tensile library has no gfx1032 kernels, so a dense GEMM aborts or silently returns zeros. The
     `_rocm_sdk_libraries_gfx103X_all` wheel's `librocblas.so.5` **and** its library data must replace the system pair
     together; replacing only the library data is not enough (checked with a probe where the correct result is known).
     If other gfx1032 users hit it, it may deserve a line in `docs/AMD_HIP.md` - I left it out of this PR.
- Windows detection (`_WIN_AMD_DID` / `_WIN_AMD_NAME`) is not touched: I have no Windows machine here, so
  `setup --backend hip` on a Windows gfx1032 card is untested. The ready-made Windows zip has no gfx1032 code, like
  gfx1031 before 0.1.40.2, but the build is available from source (`-DCMAKE_HIP_ARCHITECTURES=gfx1032`).

Sur le site

Liens install, modèles, releases.