Skip to content

Native Windows AMD ROCm setup: verified HIP path and remaining engine parity gaps #2468

Open

Description

@Pates2004

Problem

VoiceStudio 0.5.6 on native Windows does not provision a ROCm runtime for supported Radeon GPUs out of the box. The stock desktop Python environment targets the pinned default torch stack; AMD Windows needs a separate Python 3.12 / ROCm wheel set, and CUDA-oriented engine and sidecar assumptions do not all transfer to HIP. This is distinct from the previously completed general AMD GPU request #124.

Repro / hardware

  • Windows 11 Pro build 26300; Radeon RX 9070 XT (gfx1201, 16 GB), driver 32.0.31044.16; HIP SDK 7.2.0.
  • Install the upstream Windows Electron build, start local setup, then check the installed torch variant and ASR execution provider. The normal CUDA-oriented recipe does not set up the AMD Windows ROCm wheels or the Windows HIP CTranslate2 wheel.
  • No WSL or Docker is involved.

Local prototype findings (not an upstream release)

  • Explicit, user-initiated setup with automatic AMD GPU identification (plus a manual Automatic / NVIDIA-CPU / AMD selector) installed Python 3.12, torch/torchaudio/torchvision ROCm 7.2.1, and the SHA-256-checked official CTranslate2 4.8.2 Windows HIP wheel. Verification executed GPU kernels and declined to mark an incomplete runtime ready. NVIDIA and Linux default paths are unchanged.
  • OmniVoice English/Polish synthesis, faster-whisper tiny/small EN/PL transcription on HIP, and a separate clean managed VoxCPM2 ROCm sidecar install and 48-kHz output were observed. A local, unsigned NSIS installer was installed, ran packaged same-origin ASR/TTS API smokes, and was uninstalled. These are tests on one machine, not a device support guarantee.
  • A separate optional EN/PL alignment model can improve word timestamps, but transcription must retain the faster-whisper timestamps if that model is unavailable offline. The setup progress UI must reset between uv sync, multi-GB ROCm wheels, and CTranslate2 archive phases instead of announcing downloads complete early.
  • CosyVoice produced real 24-kHz GPU audio for WAV and MP3 references in an isolated worker after Windows-ROCm-only soundfile I/O adaptation, but its one-click installer is still Python 3.10 / CPU. TorchCodec 0.8.1 with FFmpeg 7.1 failed to load against AMD torch (WinError 127), so other formats are unverified. ONNX components ran on CPU.
  • Stock WhisperX 3.7.4 fails to import with the supported torchaudio 2.9.1 because pyannote.audio 3.4.0 uses removed torchaudio.AudioMetaData. An isolated experimental GPU VAD/alignment patch worked for a small EN/PL sample but is not a maintained, distributable solution. Unquantized MOSS-TTS-v1.5 weights exceed the currently available VRAM on this 16-GB GPU. Other engines/diarization/translation and live NVDA output are not validated.

Proposal / review request

Provide an opt-in or device-selected native Windows AMD runtime with a pinned, checksummed wheel recipe, GPU smoke checks before claiming acceleration, resumable download UI and honest CPU fallback; preserve the NVIDIA and other OS defaults. Add engine-specific ROCm recipes only after clean installs and real audio on supported hardware. Do not claim full CUDA feature parity yet. Can maintainers advise whether to split the local prototype into focused PRs for the desktop installer/runtime, faster-whisper HIP routing, and verified VoxCPM2? I can supply the local patch and regression tests; nothing has been pushed or submitted as a PR yet.

Activity

  1. added a commit that references this issue on Oct 1, 2026
  2. debpalash commented on Oct 1, 2026

    @debpalash
    Owner

    Thanks for the detailed HIP verification. Shipped in #2501: Settings → Performance → GPU acceleration now shows your cards, the installed PyTorch build and which engines use the GPU or run on CPU and why, and the Windows AMD diagnostics no longer blame a missing NVIDIA driver. Vulkan (audio.cpp) already runs on Radeon. Native Windows ROCm PyTorch wheels need torch >= 2.9 and a Windows AMD test runner before we can claim acceleration, so that stays open as the tracking item; focused PRs for it (pinned recipe + GPU smoke test) are welcome.

  3. Pates2004 commented on Oct 4, 2026

    @Pates2004
    Author

    The base native Windows ROCm installation is upstream in #3045. Its artifact hashes, dependency constraints, trusted package discovery and failed-probe memoization are preserved.

    The current follow-up is draft #3486, published head cad798748, integrated with main 58f6960af and with maintainer edits enabled. It includes the desktop runtime-package selector, verified managed HIP VoxCPM2, bounded SDK/header preparation and a qualified WhisperX ASR/alignment route. Cleanup #3512 remains separately reviewable; tests-only #3549 is integrated. #3513 was superseded by upstream #3517 and removed.

    The latest fix addresses inherited SDK selectors in app-owned Windows ROCm runtimes. Electron now removes only HIP_PATH, ROCM_HOME and ROCM_PATH from the final child environment used by backend startup, native/import checks and installation. Global settings, source/custom/user-managed runtimes, CPU/CUDA/other platforms and strict device/architecture/MIOpen controls stay intact. Explicit owned:false also protects a default-path runtime from Clean & Retry and runtime-package switching.

    Current checks:

    • Complete Electron main: 998 passed, 9 skipped across 90 files; full node TypeScript, all 11 changed TS/test formatter checks and three locale checks pass.
    • Six actual fail-before regressions now pass: SDK leakage plus unowned-default cleanup/preference mutation. All destructive test actions are mocked and synthetic.
    • Python: 92 native/release checks passed, plus 236 ASR integration checks passed, 1 opt-in Apple model/network smoke skipped and 2 subtests passed, with initially empty offline caches and no model-weight acquisition. Counts overlap larger historical suites and are not a substitute for current maintained CI.

    The previous d5a71199c package completed normal NSIS install/uninstall/cache restoration and independent genuine HIP runtime verification. Its real GUI reached managed ROCm health/native-helper checks but failed WhisperX catalogue preflight. Omni weights preloaded on HIP, but no ASR inference or Omni speech generation ran in that attempt. A later read-only comparison proved that the currently inherited HIP_PATH rejects the engine-specific qualifier while selecting the bundled SDK allows it. The original GUI's unrecorded effective environment was not reconstructed. The product fix is now published; a newly rebuilt packaged-GPU acceptance run is still pending.

    Earlier actual production WhisperX evidence remains valid for its original source and controlled SDK/temp environment: unchanged default large-v3, stock pyannote VAD, CT2 HIP/float16 and GPU wav2vec2 on RX 9070 XT/gfx1201, with 12/12 and 48/48 recognized words timed on 4.8-second and repeated 39.6-second French fixtures. It used no model override or gate exception. Earlier real faster-whisper, EN/PL VoxCPM2 and OmniVoice GPU results are documented separately. These do not turn the later failed GUI run into a pass.

    The profile still requires Windows x64/CP312, the exact ROCm 7.2.1/WhisperX 3.4.5 stack, gfx1201 and compatible ASCII SDK/header/TEMP/cache paths. Diarization, other GPUs/versions, problematic Unicode paths, fresh Windows, actual NVDA, human listening and complete CUDA-engine parity remain unqualified. No driver/global SDK changes or WSL installation were made. The PR stays draft; personal CLA and maintainer workflow approval remain external gates. No legal signature or upstream merge has been submitted.

  4. added
    enhancementNew feature or request
    and removed
    needs-triageMaintainer needs to evaluate this issue
    on Oct 25, 2026
  5. debpalash commented on Oct 25, 2026

    @debpalash
    Owner

    Community recipe for native Windows ROCm, closed as a duplicate of this issue: #3123.

  6. debpalash commented on Oct 27, 2026

    @debpalash
    Owner

    Status: the base native Windows ROCm install landed in #3045. The desktop runtime selector and HIP sidecar follow-up is #3486, under review. Separately, #3553 fixes the Linux ROCm torch swap, which failed on a Pillow conflict, so both platforms resolve the same torch trio.

  7. debpalash commented on Oct 27, 2026

    @debpalash
    Owner

    Update: #3602 covers part of this.

    Resolved by #3602

    • The setup GPU check no longer says Windows has no ROCm build. It names the installed PyTorch build and the ROCm opt-in for your OS.
    • HSA_OVERRIDE_GFX_VERSION remaps now come from the installed wheel's own arch list instead of a fixed table. Cards like gfx1152, gfx1035/1036, or a gfx1201 on a gfx1200-only build now run on the GPU, and remaps never cross an ISA generation.
    • A ROCm build without kernels for the card is reported as such instead of "ready".

    Still needs real AMD hardware

    • CosyVoice install on HIP
    • WhisperX / pyannote on AMD
    • Speaker diarization on AMD
    • End-to-end verification on a real RX 9070 (Windows and Linux)

    If you have one of these cards and can test any of the above, results would be very welcome.

  8. added
    trackingTracks multiple remaining work items
    needs-hardwareRequires testing on specific physical hardware
    on Oct 28, 2026
  9. Pates2004 commented on Oct 28, 2026

    @Pates2004
    Author

    Progress on #3486: source baf02f2d9542d1df77314c9abd3cb07f39d4a62c, including main dd68b5242. The PR remains draft with maintainer edits enabled. Its description now consolidates the implementation, actual evidence and open gates; setup/review guidance is available in English and Polish.

    Current-head installer and normal WebSocket TTS (2026-11-04)

    The current baf02f2d9 source now passes all 14 local packaging stages. Its actual Windows NSIS install, payload inspection, uninstall and updater-cache restoration pass with natural owned-process closure and unchanged protected data/Desktop state. This is a local test on the existing configured workstation; clean-Windows prerequisites and the complete current-artifact GUI flow remain unqualified. The previous source803 final installer has not been replaced by this candidate.

    An independent normal-main /ws/tts test passes on Windows 11 / RX 9070 XT, Torch 2.9.1 + ROCm 7.2.1: an ordered two-sentence request, real client disconnect after the first PCM, natural completion of in-flight work, then a successful new request. Exact produced PCM matches the transmitted sentence order and final tail. The four actual sentence renders preserve default 16 steps and postprocessing; 19,840 weighted LLM and 328 bundled-Higgs forwards execute on HIP, with zero observed weighted CPU forwards in those components. The normal source resolver and automatic Unicode-path ATen selection are used. Original, reaped and collected outer exits are zero, with natural closure of all 21 owned processes and handles; selected inputs plus full source, packaged-copy, model, cache and protected-original-profile checks pass afterward.

    This is source/API streaming evidence, not packaged renderer playback, saved-voice GUI or hard interruption of an active GPU kernel. The ordinary AudioSeal path uses its documented offline missing-generator passthrough; neural watermark embedding is not claimed. The earlier ordinary-HTTP diagnostic remains failed as described below. The current GUI attempts also remain failed before transcription: their fixture assumed refinement was off and then tried workspace navigation while the new first-run wizard was still displayed. Those observations are not established Radeon defects. The next GUI preparation follows the actual wizard and its automatic first-sound generation, without fabricated setup markers. Full dubbing, current-artifact GUI/NVDA, other engines/cards and the existing landing gates remain open.

    Sortformer package scope and main-process diagnostic

    Source baf02f2d9 separates Sortformer Q8_0 from Breeze TTS using the existing package-identity mechanism. The Model Library now downloads only the selected Sortformer file, and its native adapter, acceptance, readiness, performance plan and model link use the same package identity. Breeze and dots keep their own files and records; existing cached weights are reused. Three regressions failed before the correction and pass afterward. The final affected Python group passes 282 cases with four existing skips and four subtests; an overlapping policy group passes 634, and four pure model-linking cases pass. Documentation/projection and EN/PL setup guidance are synchronized. No production assent was fabricated or migrated; normal adapter acceptance is described below; full dubbing remains pending.

    The normal Sortformer adapter now independently passes at baf02f2d9: ordinary missing-consent refusal, acceptance of only the selected package in a fresh test profile, installed-only cache/readiness, and default automatic native-device selection. It selects Vulkan 0 / RX 9070 XT with no CPU fallback, without overriding the model, provider, device or native binary. One actual adapter invocation returns two speakers on the annotated 25.85-second AMI clip, DER 12.09% (zero collar, overlap included). Owned-process counters match the Radeon DXGI identity: two positive compute and 16 memory samples, about 3.10 GB dedicated residency. Native and owner original/reaped exits plus collected outer exit are zero, with natural nested/outer Job closure and all 629 selected protected inputs unchanged. This is normal source-adapter evidence, not per-tensor, installer/GUI, full dubbing or broad quality acceptance. Four-speaker/120-second/no-enforced-count limits remain. The first attempt remains failed before consent or inference: its diagnostic guard rejected SQLite's literal in-memory database. The corrected guard admits only that exact RAM form; real SQLite and three rejected outside-target controls pass.

    A real normal-backend-lifespan plus ordinary OmniVoice HTTP request at this head also returned finite, nonzero 24 kHz PCM16 (41,928 samples), with the default 16 steps/postprocessing/guidance and stable process-wide ATen/HIP. Actual weighted forwards in the main PID included 4,960 LLM and 82 bundled-Higgs GPU calls, with zero observed weighted CPU calls in those components. The SDK used the existing managed ASCII path; physical TEMP/cache paths contained Polish characters. The child environment followed the existing managed Electron launcher policy. Original/reaped child exits are zero, with natural Job closure and unchanged selected protected inputs.

    The complete diagnostic remains FAILED (outer exit 1): its filesystem observer recorded one refused operation involving the existing FFmpeg executable. Consequently this is scoped raw generation/placement evidence, not passing overall application acceptance. Earlier attempts remain failed too; one had mismatched tool paths, and another preserved a system HIP_PATH that the real managed launcher removes. The ordinary watermark path ran with its documented offline missing-checkpoint passthrough; neural embedding/detection is not claimed. No repeat inference solely to obtain a cleaner receipt is being counted as qualification.

    The earlier scoped hardware results and remaining gates are described in the PR. Pyannote model access, complete dubbing, current-artifact GUI/NVDA and broader engine/card qualification remain open. A current-head installer now has bounded local NSIS validation above; complete AMD/CUDA parity and full current-artifact GUI acceptance are not claimed.

  10. dutch2005 commented on Nov 2, 2026

    @dutch2005
    Contributor

    Verified native Windows RX 6700 XT (gfx1031) result, with a working HIP CTranslate2 candidate: full upstream report and reproduction.

    Environment: Windows 11 Pro x64/build 26300, driver 32.0.21045.20006, CPython 3.12.13, AMD ROCm/core/libraries/device-gfx1031 packages all 10.0.0. All tests used an isolated environment, and the loaded HIP/BLAS DLL paths were verified against that environment. No production runtime, global SDK, driver, or architecture override was changed.

    CTranslate2 Windows HIP wheel Actual GPU transcription on gfx1031
    Pinned official 4.8.2 Fails in float16, int8_float16 and float32 after successful discovery/model loading: hipErrorInvalidImage
    Official 4.8.4 Same failures; upgrading the version alone is insufficient
    Maintainer expanded-target artifact, source 9a7a074fe09521795f4172ecc42e4516700b3819 All three GPU precisions pass; CPU int8 also passes

    The candidate is the artifact linked by the CT2 maintainer in issue 2137: run 41108554536. Its actual device-code bundles include gfx1031, unlike both official release DLLs. A separate native HIP control also fails when compiled for gfx1030 and returns 42 when compiled for gfx1031 on this card.

    With cached Systran/faster-whisper-small.en, faster-whisper 1.2.1 and a 3.53075-second synthetic English clip, three calls per GPU precision and CPU int8 produced identical transcripts/token sequences. All four processes closed naturally with exit 0. A separate normal WAV-input cohort using the project's locked PyAV 15.1.0 also passed all four configurations. The minimal encoder reproduction does not require faster-whisper, Torch or an audio file.

    This narrows the conclusion behind #3712/#3734: the tested official artifacts fail on gfx1031, but native HIP CTranslate2 on ROCm 10 is viable with matching GPU code. Official 4.8.3 already switched its Windows build runtime to ROCm 10 via OpenNMT/CTranslate2#2106. This is not evidence that the newer release or test wheel works on gfx1010 or every RDNA 2 card.

    Integration still needs a reviewed, checksummed artifact and matching opt-in recipe/runtime validation. The existing exact-version/binary checks should remain in place; manually swapping a wheel into an app-managed environment is not a supported fix. A real encoder/inference check is needed before claiming GPU readiness, since discovery and compute-type reporting both passed for the broken wheels. The maintainer artifact has been reported upstream for inclusion in an official release; it has not been installed into VoiceStudio's production runtime.

    Limitations: short-model/short-clip source-environment evidence only; no long-form/batched/large-v3, diarization, app packaging, full engine parity or other-GPU qualification. Artifact IDs, hashes, module checks and reproduction steps are in the linked report. The separate fresh-dependency PyAV 19 decoding error is already tracked in SYSTRAN/faster-whisper#1589; the project-locked PyAV 15.1.0 path passed here.

  11. chenhz01 commented on Nov 2, 2026

    @chenhz01

    Following the thread - with #3602 the remap logic now reads the wheel's own arch list, which is the right primitive, but every remaining hardware-in-the-loop item (CosyVoice on HIP, WhisperX/diarization) still starts from the same question: does this wheel actually contain kernels for my gfx?

    This one-file check answers it without launching a model - it scans rocblas's TensileLibrary archives, compares them with the GPU torch reports, and only ever suggests same-ISA remaps, so an RX 9070 owner can paste a verdict instead of a guess:

    #!/usr/bin/env python3
    """Check whether a ROCm/HIP torch wheel ships kernels for the local GPU.
    
    Scans the bundled rocblas library for per-arch TensileLibrary archives,
    compares them with the GPU torch reports, and prints a verdict: native
    kernels, a same-ISA HSA_OVERRIDE_GFX_VERSION candidate, or a cross-gen
    warning (a remap must never cross an ISA generation).
    Usage: python hip_arch_check.py [<torch_lib_dir>]  # arg skips torch import
    """
    import glob, os, re, sys
    
    ARCH = re.compile(r"gfx\d+[0-9a-f]+")
    
    def local_gpu():
        try:
            import torch
        except ImportError:
            return None, "torch not importable; pass the wheel lib dir instead"
        if not getattr(torch.version, "hip", None):
            return None, "torch is a CUDA build, not ROCm/HIP"
        name = torch.cuda.get_device_properties(0).name
        m = ARCH.search(name or "")
        return (m.group(0) if m else None), name
    
    def wheel_archs(libdir):
        found = set()
        for pat in ("rocblas/library/TensileLibrary_lazy_gfx*.dat",
                    "rocblas/library/TensileLibrary_gfx*.dat"):
            for f in glob.glob(os.path.join(libdir, pat)):
                found.update(ARCH.findall(os.path.basename(f)))
        return sorted(found)
    
    def main():
        libdir = (sys.argv[1] if len(sys.argv) > 1
                  else os.path.join(os.path.dirname(__import__("torch").__file__), "lib"))
        gpu, note = local_gpu() if len(sys.argv) <= 1 else (None, "")
        archs = wheel_archs(libdir)
        print(f"wheel lib: {libdir}")
        print(f"rocblas archs present: {', '.join(archs) or 'NONE FOUND'}")
        if not gpu:
            print(note)
            return
        print(f"local GPU: {note} ({gpu})")
        if gpu in archs:
            print("verdict: native kernels present; no HSA_OVERRIDE_GFX_VERSION needed")
            return
        same_gen = [a for a in archs if a.startswith(gpu[:4])]
        if same_gen:
            print(f"verdict: same-ISA remap viable: HSA_OVERRIDE_GFX_VERSION={same_gen[0]}")
        elif archs:
            print("verdict: no kernels for this ISA generation; a remap would cross "
                  "generations - expect failure or a silent CPU fallback")
    
    if __name__ == "__main__":
        main()

    py_compile-clean and runnable on any HIP torch install; the TensileLibrary scan is the same source of truth #3602 adopted. If WhisperX-on-AMD becomes a priority, I contract for exactly this kind of fix - fixed price, working code. Otherwise happy to open a PR wiring this diagnostic into the setup GPU check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestneeds-hardwareRequires testing on specific physical hardwareready-for-humanRequires human implementationtrackingTracks multiple remaining work items

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions