AMD wheels for Windows built against ROCm 7.2, but Windows HIP SDK installer only goes to 7.1.1

[PinW]

I have a speech to text project built on faster-whisper/CT2. With the recent ROCm support release, I added AMD GPU support to my project.

My project has a pre-built windows exe via pyinstaller, so I made a new version that bundles the CTranslate2 ROCm Windows wheel. But the problem is that the wheel is built against ROCm 7.2 and the latest HIP SDK Installer for Windows only goes up to 7.1.1

I thought they might be compatible anyways, but it turns out that libhipblas.dll in 7.1.1 changed to hipblas.dll in 7.2, causing a crash when CT2 loads. I personally run a custom version of CT2 built to work with an older GPU, and for that ROCm version (6.2) the file is also named hipblas.dll

Would be great to have the window wheels be compatible with the latest HIP installer, since that allows my users to only use windows installers without dealing with python/pip/etc

[sssshhhhhh]

Build your own whl if you need a specific version

[mmis1000]

The official repo goes for 7.2 though, and it's more complete than the installer (include ml stuffs).
If you need to run it with torch..etc, you can only use 7.2.

https://repo.radeon.com/rocm/windows/rocm-rel-7.2/

Not sure why is the dependency, but it's how it is currently.

[T0nd3]

Documented the version skew between the ROCm 7.2 pip wheels and the still-7.1.1 standalone AMD HIP SDK Installer in PR #2041 — specifically the hipblas.dll vs libhipblas.dll rename that breaks bundling.

The PR's Windows build guide now has a "Why not the official AMD HIP SDK Installer?" subsection that calls this out, points to this issue, and explains the two practical workarounds (build against 7.1 yourself, or wait for AMD to release a 7.2 installer).

This isn't a code fix on the CTranslate2 side — the version mismatch is on AMD's side and resolves itself once they ship a 7.2 installer. But hopefully the documentation update makes it easier to spot before you sink time into a broken bundle. Let me know if there's something else in your setup that could be addressed at the wheel-build level (e.g. an environment variable to force the alternate DLL name, though I haven't dug into whether that's feasible).