Build libtorchaudio GPU extensions on ROCm via HIPIFY (torchvision-style)

[ethanwee1]

https://amd-hub.atlassian.net/browse/ROCM-24803

Summary

Rebased onto release/2.11.0.1 (b83203e8). Source-only ROCm GPU port — no manual hipify() in setup.py (addresses @jithunnair-amd review).

Uses built-in CUDAExtension hipify for .cu bodies; headers made HIP-safe via cuda_compat.h + USE_ROCM guard widening + hipcub routing.

Companion PRs

• ROCm/pytorch#3562 — Windows B:/C: CUDAExtension realpath fix
• ROCm/pytorch#3382 — related_commits pin (post-merge: flip origin to ROCm/audio)

Prior validation

• Windows gfx110X wheel build passed (TheRock 28953516514)
• GPU smoke + 784 unit tests passed on gfx110X (multi-GPU-only tests excluded on single-GPU runner)

Validation (this rebase)

TheRock Windows build on ew/rocm-24803-validation after rebase to a0da46b3.

[ethanwee1]

TheRock test build (Windows gfx110X-all) via ROCm/pytorch#3382:
https://github.com/ROCm/TheRock/actions/runs/28538325024

[ethanwee1]

Closing in favor of #16 (cuda_compat.h compat shim). The torchvision-style HIPIFY in extension.py still leaves headers like cuda_utils.h and macros.h with CUDA-only includes; TheRock run 28538325024 failed on those. Validated Windows build: 28529085509 with #16.

[ethanwee1]

HIPIFY v2 pushed (0c7509ef):

• Reverted USE_CUDA || USE_ROCM header guard widening (was pulling cuda_fp16.h into CPU compiles).
• Hipify via realpath() paths + nested globs + header_include_dirs (fixes cuda_utils.h still showing cuda_runtime_api.h on Windows B:/C: subst).
• Pass -DUSE_CUDA on hipcc only (GPU TUs); upstream #ifndef USE_ROCM shuffle branches unchanged.

ROCm/pytorch#3382 pin updated to this commit.

[ethanwee1]

HIPIFY v3 (133b6687): fixed header_include_dirs to point at the extension -I root (src/) instead of src/libtorchaudio, so hipify resolves and rewrites the <libtorchaudio/...> angle-bracket includes (root cause of compute.hip still including the original cuda_utils.h).

Test build (Windows gfx110X-all) via ROCm/pytorch#3382: https://github.com/ROCm/TheRock/actions/runs/28953516514

[ethanwee1]

✅ SUCCESS — HIPIFY v3 build passed (Windows gfx110X-all):
https://github.com/ROCm/TheRock/actions/runs/28953516514

Produced torchaudio-2.11.0.1+devrocm...-cp312-cp312-win_amd64.whl (0 cuda_runtime* not-found errors). The header_include_dirs fix let hipify rewrite the <libtorchaudio/...> includes to the hipified headers, so the torchvision-style HIPIFY approach now builds cleanly — no manual per-symbol compat shim.

[jithunnair-amd]

CUDAExtension does hipify under the hood. I'd like to see if we can use that hipify invocation in a way that will address the issues raised by this PR (the right header_include_dir for eg.). If torchaudio source needs an update instead, that's a viable path too, esp. since it'd be updates in our own fork.

Also, if hipify needs an update to handle the Windows issue with B:/C: drive, that's a legitimate path forward too.

In essence, I would prefer not to invoke hipify manually in torchaudio setup file, as that's not the developer example we want to set.

[ethanwee1]

Thanks @jithunnair-amd — reworked to drop the manual hipify_python.hipify() call from setup.py/extension.py entirely. The port is now done purely as torchaudio source updates in our fork (your option 2), relying on the built-in CUDAExtension hipify for the .cu source bodies:

• cuda_compat.h maps the CUDA runtime symbols that appear in headers (cudaStream_t, cudaError_t, cudaSuccess, cudaGetErrorString/Name, cudaGetLastError, cudaSetDevice, cudaMemcpy*, cudaMemset*, cudaStreamSynchronize) to their HIP equivalents under USE_ROCM.
• Widened the rnnt/forced_align GPU #ifdef USE_CUDA guards, macros.h, and Options::stream_ to also cover USE_ROCM.
• Routed cub through hipcub under USE_ROCM.

Context on why not just the built-in hipify: CUDAExtension calls hipify with hipify_extra_files_only=True, so all_files is limited to the listed source files and the include-rewrite skips project headers (cuda_utils.h, etc.) even though the extension already passes the correct header_include_dirs (src/). So the headers need to be HIP-safe in-source regardless — hence the small compat header + guard changes rather than a torch-side hipify change.

The Windows B:/C: subst cross-drive HIPIFY issue is handled separately in ROCm/pytorch#3382 (torch/utils/cpp_extension.py realpath normalization), which is a general CUDAExtension fix.

This source-only version is byte-identical to the tree that previously built + passed GPU tests on gfx110X (784 torchaudio unit tests passed; rnnt/forced_align/cuda_ctc smoke). Pin in ROCm/pytorch#3382 updated to 9808bfc9.

[ethanwee1]

Rebased onto release/2.11.0.1 (a0da46b3). Ready for review — source-only HIP port (no manual hipify() in setup.py).

TheRock validation build on combined branch ew/rocm-24803-validation:

Run: https://github.com/ROCm/TheRock/actions/runs/31709842398

Companion PRs:

• ROCm/pytorch#3382 — related_commits pin
• ROCm/pytorch#3562 — Windows cross-drive HIPIFY fix

cc @jithunnair-amd @pablo-garay for review

[ethanwee1]

Build failure analysis for run 31709842398:

Not a PyTorch/torchaudio code issue. The build died in Install requirements before checkout/build started:

choco install --no-progress -y ninja --version 1.13.1
A newer version of ninja (v1.13.2) is already installed.
Chocolatey installed 0/1 packages. 1 packages failed.

The windows-2022 runner image was updated (20260802.262) and now ships ninja 1.13.2, while TheRock main still pins 1.13.1 via chocolatey (which refuses downgrade).

Redispatch using Pablo's ninja-tolerant workflow branch (same fix as users/garayp/win-ninja-tolerant) + the ROCm version from the July passing build:

New run: https://github.com/ROCm/TheRock/actions/runs/31711078734

Input	Value
repository / ref	ROCm/TheRock @ users/garayp/win-ninja-tolerant
rocm_version	7.14.0.dev0+331251018497de4049c7d8447c7b2d1dcdfd012e (same as 28953516514)
pytorch_git_ref	ew/rocm-24803-validation