Build libtorchaudio GPU extensions on ROCm via HIPIFY (torchvision-style)#17
Build libtorchaudio GPU extensions on ROCm via HIPIFY (torchvision-style)#17ethanwee1 wants to merge 4 commits into
Conversation
…yle) Mirror torchvision's setup.py approach: run hipify_python.hipify() over the libtorchaudio sources when building for ROCm and compile the generated .hip outputs, instead of relying solely on the torch CUDAExtension HIPIFY (which only processes listed source files and left torchaudio headers/symbols like cuda_runtime_api.h, cudaSetDevice and cub un-converted). HIPIFY cannot rewrite preprocessor guards, so the #ifdef USE_CUDA gates around the rnnt/forced_align GPU headers, macros.h, and Options::stream_ are widened to `#if defined(USE_CUDA) || defined(USE_ROCM)`. Reference: https://github.com/ROCm/vision/blob/release/0.27/setup.py
|
TheRock test build (Windows gfx110X-all) via ROCm/pytorch#3382: |
…io#16) Revert the temporary HIPIFY-based pin (ROCm/audio#17) back to the compat-shim port commit that passed TheRock Windows validation (28529085509). The HIPIFY setup.py approach still leaves CUDA headers unconverted; the cuda_compat.h port in ROCm/audio#16 is the validated path. The Windows cross-drive HIPIFY fix remains in torch/utils/cpp_extension.py (this PR); it is unrelated to the audio-side port strategy.
…yle) Mirror torchvision's setup.py approach: run hipify_python.hipify() over libtorchaudio CUDA sources and headers, then compile the generated .hip outputs. Fixes vs the first HIPIFY attempt (TheRock 28538325024): 1. Do not widen `#ifdef USE_CUDA` to `USE_ROCM` in headers — that pulled `cuda_fp16.h` into CPU `.cpp` compiles because PyTorch defines USE_ROCM globally on ROCm extension builds. Keep upstream USE_CUDA guards; pass `-DUSE_CUDA` on hipcc/nvcc only for GPU translation units. 2. Hipify with `os.path.realpath()` paths and depth-aware include globs so headers like `cuda_utils.h` are rewritten on the same inode Windows runners use when B: is a subst alias of the C: checkout (otherwise the compiler reads un-hipified headers from the underlying path). 3. Include `cuctc/` in the hipify scope. Reference: https://github.com/ROCm/vision/blob/release/0.27/setup.py Paired with ROCm/pytorch#3382 (torchaudio pin + Windows cross-drive HIPIFY fix in torch/utils/cpp_extension.py — that fix is in PyTorch, not here).
Update ethanwee1/audio ew/rocm-24803-hipify-gpu-ext to 0c7509ef with: - realpath-based hipify (Windows B:/C: alias) - reverted USE_ROCM header guard widening - -DUSE_CUDA on hipcc for GPU units only
|
HIPIFY v2 pushed (
ROCm/pytorch#3382 pin updated to this commit. |
…e rewritten hipify resolves angle-bracket includes against header_include_dirs. The sources include headers as <libtorchaudio/...> via the extension -I root (src/), but v2 passed src/libtorchaudio, so hipify looked for src/libtorchaudio/libtorchaudio/... , failed to resolve, and left #include <libtorchaudio/cuda_utils.h> un-rewritten -> compiled the original cuda_utils.h with cuda_runtime_api.h. Point header_include_dirs at src/ (csrc.parent) so the includes resolve and get rewritten to the hipified header paths.
|
HIPIFY v3 ( Test build (Windows gfx110X-all) via ROCm/pytorch#3382: https://github.com/ROCm/TheRock/actions/runs/28953516514 |
|
✅ SUCCESS — HIPIFY v3 build passed (Windows gfx110X-all): Produced |
There was a problem hiding this comment.
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.
…header + guards) Addresses review feedback (jithunnair-amd) to not invoke hipify manually in the torchaudio setup file. Instead this ports libtorchaudio to ROCm via fork source updates only, relying on the built-in CUDAExtension hipify for the .cu source bodies: - cuda_compat.h maps the CUDA runtime symbols used in headers to their HIP equivalents under USE_ROCM. - Widen the rnnt/forced_align GPU #ifdef USE_CUDA guards, macros.h, and Options::stream_ to also cover USE_ROCM. - Route cub through hipcub under USE_ROCM. The Windows B:/C: subst cross-drive HIPIFY fix lives in ROCm/pytorch#3382 (torch/utils/cpp_extension.py).
|
Thanks @jithunnair-amd — reworked to drop the manual
Context on why not just the built-in hipify: The Windows B:/C: 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 |
2 participants
Port libtorchaudio's GPU extensions (rnnt loss, forced_align, CUDA CTC decoder) to build on ROCm/HIP, as torchaudio source updates in this fork — no manual hipify call in
setup.py(per review). Relies on the built-inCUDAExtensionhipify for the.cusource bodies.Changes
cuda_compat.h— maps the CUDA runtime symbols used in headers (cudaStream_t,cudaError_t,cudaSuccess,cudaGetErrorString/Name,cudaGetLastError,cudaSetDevice,cudaMemcpy*,cudaMemset*,cudaStreamSynchronize) to HIP underUSE_ROCM. (CUDAExtensionhipify useshipify_extra_files_only=True, so it does not rewrite project headers even with the rightheader_include_dirs.)#ifdef USE_CUDAguards,macros.h, andOptions::stream_to also coverUSE_ROCM.cubthroughhipcubunderUSE_ROCM.Paired with ROCm/pytorch#3382 (torchaudio pin + Windows B:/C: cross-drive HIPIFY fix in
torch/utils/cpp_extension.py).GPU testing
Validated on AMD Radeon PRO V710 (gfx110X) via TheRock workflow
.github/workflows/test_torchaudio_wheels.yml(branchethanwee/torchaudio-gpu-tests):rnnt_loss(fwd+bwd),forced_align,cuda_ctc_decoderimport all PASS.(This source-only version is byte-identical to the previously build+test-validated tree.)