docs: cover the pip SDK route and runtime pitfalls for Windows HIP builds

[Thatgfsj]

What

Fills the Windows gaps in docs/build.md HIP section, from a from-source deployment on Windows 11 / RX 7800 XT (gfx1101) last week:

1. pip / TheRock SDK route. AMD publishes no full ROCm installer for RDNA2/RDNA3 consumer cards on Windows, so the existing Windows bullet (x64 Native Tools Prompt + %HIP_PATH%\bin from an installer) is not reachable for exactly the cards most people want to use this backend on. The documented flow mirrors this fork's own windows-rocm release job step-by-step (rocm[libraries,devel] wheels, rocm-sdk init, rocm-sdk path --root/--cmake/--bin, the env vars, and the same cmake flags), including the MSVC-triple prerequisite.
2. Windows runtime notes.
   • the HIP runtime dependency chain ggml-hip.dll needs resolvable next to the exe (amdhip64_7.dll -> rocm_kpack.dll + amd_comgr.dll; hipblas.dll -> rocsolver.dll; hipBLASLt per-ISA kernel data dirs), and where pip SDK keeps them;
   • an incomplete chain fails LoadLibrary silently - the backend never registers and inference quietly runs on CPU at 1-2 t/s, easily mistaken for a slow GPU; llama-server --list-devices is the discriminator;
   • fattn-mma template instances are multi-GB each: --parallel 24 on 64 GB RAM aborted with clang frontend command failed due to signal (compiler OOM, not a source error); 6-12 built clean.

Verification

• Flags proven on 9a9394a89: full PQ2_0 Bonsai 27B + MTP serving path on gfx1101 - pp512 461 t/s, tg128 49.6 t/s, operator checks green. Details: Eval bug: Bonsai 2 PQ2_0 produces corrupt logits on Windows HIP gfx1151; CPU --no-repack is coherent #223 (comment)
• The silent CPU-fallback symptom was reproduced (1.77 t/s, --list-devices: (none)) and disappeared once the DLL set was colocated.
• The compiler-OOM was reproduced at --parallel 24 twice and built clean at --parallel 6.

Docs only; no code touched. Happy to adjust tone/placement - e.g. split the runtime notes into docs/backend/ if maintainers prefer.

[bri-prism]

Thanks for writing this up. The runtime notes are really useful, especially the silent CPU fallback and the --list-devices check. A few things to fix before merging:

1. The pip route isn't what this fork's releases use. windows-rocm in release.yml is inherited from upstream and doesn't run for our releases. Our Windows bundle (win-hip-radeon) is built by windows-hip in release-prism.yml, using the AMD HIP SDK installer (26.Q1). Could you describe the pip SDK as an alternative route rather than the supported or release one?
2. The HIP SDK installer does cover these cards. Our release CI builds gfx1030-1032 and gfx1100-1102 with it, including your gfx1101. Please drop "AMD publishes no full ROCm installer for RDNA2/RDNA3 consumer cards on Windows", or limit it to cases where the installer isn't an option.
3. "The Windows HIP release bundles ship them colocated" isn't accurate. Our bundle ships libhipblas.dll, libhipblaslt.dll, rocblas.dll and the rocblas/hipblaslt library folders, but not amdhip64_*, amd_comgr, rocm_kpack or rocsolver. The file names also differ between the installer and the pip SDK. Could you scope the DLL chain to pip-SDK builds?
4. The commands are PowerShell, but the text says x64 Native Tools Command Prompt, which is cmd. Please point to Developer PowerShell for VS instead, or say to run powershell from that prompt.
5. Please pin the wheel version, for example "rocm[libraries,devel]==7.14.0", so the steps stay reproducible.
6. The out-of-memory note mentions rocWMMA flash attention, but the cmake example doesn't set -DGGML_HIP_ROCWMMA_FATTN=ON. Either add it, as both release jobs do, or reword the note.