Fix ROCm GPU arch detection: prefer torch device properties, robust hipInfo.exe lookup on Windows

[danielhanchen]

Problem

On Windows ROCm setups, get_rocm_gpu_arch() probes hipinfo.exe with subprocess.run(["hipinfo.exe"], ...), which resolves through PATH only. In practice hipInfo.exe is rarely reachable that way:

• Hosts without the HIP SDK don't have it on PATH at all.
• AMD's PyTorch wheels for Windows ship hipInfo.exe into the environment's Scripts directory (next to python.exe), which is only on PATH while the venv is activated — not when the interpreter is invoked directly, via uv run, or embedded.

The probe then raises FileNotFoundError, and every import bitsandbytes logs:

ERROR:bitsandbytes.cuda_specs:Could not detect ROCm GPU architecture: [WinError 2] The system cannot find the file specified
WARNING:bitsandbytes.cuda_specs:
ROCm GPU architecture detection failed despite ROCm being available.

while ROCM_GPU_ARCH silently degrades to "unknown" — even though the GPU works fine.

Fix

1. Prefer torch.cuda.get_device_properties(0).gcnArchName — torch already knows the architecture on both Linux and Windows, with no subprocess at all. Feature-flag suffixes (e.g. gfx90a:sramecc+:xnack-) are stripped to keep the existing "gfx..." format. This introduces no new device initialization: importing bitsandbytes already initializes the device context in cextension.py via get_cuda_specs() → torch.cuda.get_device_capability().
2. Keep the rocminfo / hipInfo.exe parsing as a fallback, and on Windows additionally try hipInfo.exe next to python.exe (where AMD's wheels place it) before giving up.
3. The ERROR/WARNING logging is preserved for genuine failures; behavior on non-ROCm builds is unchanged.

Validation

On a Strix Halo (gfx1151) Windows 11 machine with AMD's wheels (torch 2.11.0+rocm7.13.0), venv not activated, so Scripts is not on PATH and shutil.which("hipinfo.exe") is None:

• Before: ROCM_GPU_ARCH == "unknown" plus the ERROR/WARNING above on import.
• After: the torch-properties path returns gfx1151 with no log output; forcing the subprocess fallback (mocking torch.cuda.is_available to False) also returns gfx1151 via the Scripts-relative hipInfo.exe.

Added two mocked unit tests that run on any backend. On the ROCm box:

tests/test_cuda_setup_evaluator.py: 6 passed, 4 skipped (CUDA-only)

All pre-commit hooks pass on the changed files.

Context

• Adding support for building for AMD on Windows #1846 introduced the Windows hipinfo.exe probe (superseding fix ROCm GPU architecture detection failed on windows #1843 / Update cuda_specs.py #1833, which reported this same failure mode); [ROCm] Windows workflow for creating wheels with ROCm 7.2.1 support #1915 added the Windows ROCm wheels.
• Downstream, Unsloth currently works around this by prepending the venv Scripts directory to PATH before importing bitsandbytes (Windows/WSL installer: fix winget msstore cert failure, amd-smi DiskPart prompt, and enable AMD GPU (Strix Halo gfx1151) unslothai/unsloth#5940, commit f48fc9a). This PR fixes it at the source so downstream consumers don't need that.

🤖 Generated with Claude Code

[danielhanchen]

Closing this for now.

[matthewdouglas]

@danielhanchen This seems like a reasonable change - what's the reason for closing?