Skip to content

Windows ROCm wheels: include gfx1103 support for Radeon 780M #2137

New issue
New issue
Open
Open
Windows ROCm wheels: include gfx1103 support for Radeon 780M#2137

Description

@licat2023
licat2023
opened on Oct 27, 2026

Could the official Windows ROCm wheels include gfx1103, or clarify whether this architecture is intentionally outside the supported GPU list?

The official wheels import successfully, detect my Radeon 780M, and load a Whisper model, but fail when executing the encoder. The shipped GPU code objects omit gfx1103. An unmodified upstream source build targeting gfx1103 works on this machine.

Environment

  • Windows 11, Ryzen 7 7840H / Radeon 780M (gfx1103).
  • CPython 3.14.8, regular ABI, not free-threaded.
  • Official Windows ROCm wheels from the v4.8.2 and v4.8.4 release ZIPs, with ZIP sizes and SHA256 checked against the GitHub release asset metadata.
  • System ROCm 7.2; hipRuntimeGetVersion() returns 70260201.
  • Verified loaded amdhip64_7.dll, hipblas.dll, rocblas.dll, and hipblaslt.dll paths under the system ROCm 7.2 bin directory; CT2 itself was loaded from an isolated extraction of the official wheel.

Minimal reproduction

Extract the matching official wheel into a directory containing ctranslate2/, then run this script with a local CTranslate2 large-v3-turbo model and that directory:

python repro.py /path/to/large-v3-turbo /path/to/extracted-wheel

import ctypes
import os
from pathlib import Path
import sys

model_dir = sys.argv[1]
wheel_dir = Path(sys.argv[2]).resolve()
sdk = Path(r"C:\Program Files\AMD\ROCm\7.2")
os.environ["ROCM_PATH"] = str(sdk)
os.environ["HIP_PATH"] = str(sdk)
os.environ["ROCBLAS_USE_HIPBLASLT"] = "1"
os.environ.pop("HSA_OVERRIDE_GFX_VERSION", None)
dll_directory = os.add_dll_directory(str(sdk / "bin"))
hip = ctypes.WinDLL(str(sdk / "bin/amdhip64_7.dll"))
hipblas = ctypes.WinDLL(str(sdk / "bin/hipblas.dll"))
sys.path.insert(0, str(wheel_dir))

import ctranslate2
import numpy as np

assert Path(ctranslate2.__file__).resolve().parent == wheel_dir / "ctranslate2"
print("CTranslate2:", ctranslate2.__version__, flush=True)
print("GPU count:", ctranslate2.get_cuda_device_count(), flush=True)
model = ctranslate2.models.Whisper(
    model_dir, device="cuda", compute_type="float16", intra_threads=4
)
print("Model loaded", flush=True)
features = ctranslate2.StorageView.from_array(
    np.zeros((1, 128, 3000), dtype=np.float32)
)
model.encode(features)

Tested with the official v4.8.4 wheel; no faster-whisper dependency or audio file is needed for this reproduction:

CTranslate2: 4.8.4
GPU count: 1
Model loaded
RuntimeError: parallel_for failed: hipErrorInvalidImage: device kernel image is invalid

Separately, actual transcription through faster-whisper 1.2.1 fails inside WhisperModel.encode() with hipErrorInvalidDeviceFunction using system ROCm 7.2. This occurs with v4.8.2 / float16 and v4.8.4 / float16 or int8_float16. Retaining or removing HSA_OVERRIDE_GFX_VERSION=11.0.0 did not resolve the tested float16 cases.

Architecture and runtime controls

The v4.8.4 Windows ROCm build script sets:

gfx1030;gfx1100;gfx1101;gfx1102;gfx1150;gfx1151;gfx1200;gfx1201

Inspection of the embedded hipv4-amdgcn-amd-amdhsa--gfx* identifiers in both official DLLs shows the same architectures, without gfx1103.

As a separate control, I compiled the same tiny HIP kernel with SDK 7.2 for each target. It writes the integer 42 on the GPU and copies it back to the CPU:

Kernel target Result on this 780M
gfx1103 Returns 42, exit code 0
gfx1100 hipErrorInvalidImage, exit code 1
gfx1100 with HSA_OVERRIDE_GFX_VERSION=11.0.0 Same failure; device properties still report gfx1103

A local CT2 v4.8.2 build from unmodified upstream source, using WITH_HIP=ON and CMAKE_HIP_ARCHITECTURES=gfx1103, completes actual large-v3-turbo transcription in both float16 and int8_float16. That build uses SDK 7.1, MSVC 14.44, dynamic oneDNN and OPENMP_RUNTIME=COMP; it is not an otherwise identical build with only the architecture changed.

These observations suggest missing target coverage, rather than proving that adding one target will resolve every possible runtime/library issue. The v4.8.4 build script pins ROCm 10.0.0; I have tested system 7.2 and an existing TheRock 10.2.0a20260926 runtime, but not the exact 10.0.0 runtime.

Request and related reports

Would you consider adding gfx1103 to the Windows wheel architecture list and validating on a 780M? If intentionally unsupported, documenting the wheel's GPU architecture list would help users distinguish runtime installation problems from missing device code.

  • #2016 concerns the older SDK/wheel DLL-name mismatch. This report focuses on encoder execution after import and model loading succeed.
  • #2106 updates DLL discovery and the build runtime. The v4.8.4 target list still omits gfx1103.

Activity

  1. jordimas commented on Oct 30, 2026

    @jordimas
    jordimas
    on Oct 30, 2026
    Collaborator

    Hello. I have include this architecture, would be possible to test these rocm wheels are report if they work in your machine:
    https://github.com/jordimas/CTranslate2/actions/runs/41108554536/job/124244621482

    Thanks

  2. dutch2005 commented on Nov 2, 2026

    @dutch2005
    dutch2005
    on Nov 2, 2026

    Additional hardware result: the expanded-target wheel linked above works on an RX 6700 XT (gfx1031), where both official Windows ROCm release wheels fail. Adding this here because it is the same missing-target problem as the 780M report, rather than opening a duplicate.

    Environment

    • Windows 11 Pro x64, build 26300; Ryzen 9 5900X; Radeon RX 6700 XT, driver 32.0.21045.20006.
    • CPython 3.12.13; rocm, rocm-sdk-core, rocm-sdk-libraries, and rocm-sdk-device-gfx1031 all 10.0.0, from AMD's https://stable.repo.amd.com/rocm/whl-next/ index.
    • CTranslate2 official Windows ROCm release ZIPs for v4.8.2 and v4.8.4, compared with the Windows ROCm artifact from your run 41108554536, source 9a7a074fe09521795f4172ecc42e4516700b3819.
    • No Torch import, WSL, GPU architecture override, or global SDK/driver change. The tests ran in an isolated environment.
    • Loaded-module paths were checked: amdhip64_7.dll came from that environment's _rocm_sdk_core/bin; hipblas.dll, rocblas.dll, and libhipblaslt.dll came from its _rocm_sdk_libraries/bin. The machine also has an older global SDK, so these paths were explicitly verified after preloading the intended DLLs.

    Actual results

    Wheel GPU discovery/model loading GPU inference: float16, int8_float16, float32
    Official 4.8.2 Pass, GPU count 1 All fail with parallel_for failed: hipErrorInvalidImage: device kernel image is invalid
    Official 4.8.4 Pass, GPU count 1 All fail with the same error
    Expanded-target maintainer artifact Pass, GPU count 1 All pass; each child exits naturally with code 0

    The minimal Whisper.encode() reproduction below fails with official 4.8.4 and completes with the maintainer artifact. This does not depend on audio decoding, faster-whisper, or Torch.

    Actual faster-whisper 1.2.1 transcription was also checked with the cached Systran/faster-whisper-small.en snapshot d1d751a5f8271d482d14ca55d9e2deeebbae577f and a 3.53075-second synthetic English clip:

    • Three successive calls in the same model instance for each GPU precision above, plus CPU int8, all passed. All 12 calls returned the same transcript and token sequence; every process closed naturally with exit 0.
    • A separate normal WAV-input run using PyAV 15.1.0 passed all three GPU precisions and CPU int8, with the same output. The repeated-call cohort used decoded PCM to isolate CT2 from decoding.
    • Transcript SHA-256: cbaeba8fabff8503d8e709fa58169d19807a89d043e4dc7cd6bafe58507e5c2a.
    • The logs show cub_caching; switching precision did not repair the official wheels.

    This is a short-model/short-clip test, not long-form, batched, large-v3, diarization, packaged-app, or general hardware certification.

    Architecture control

    Parsing the actual __CLANG_OFFLOAD_BUNDLE__ headers, rather than scanning incidental strings, gives:

    • Official 4.8.2 and 4.8.4: gfx1030;gfx1100;gfx1101;gfx1102;gfx1150;gfx1151;gfx1200;gfx1201.
    • Maintainer artifact: those targets plus gfx1031;gfx1032;gfx1035;gfx1103.

    A separate minimal HIP kernel compiled with the same ROCm 10 compiler and run on this RX 6700 XT gives hipErrorInvalidImage when targeted at gfx1030, but returns the expected integer 42 when targeted at gfx1031. That supports missing device code as the explanation on this card. It does not establish that every ROCm 10/card/library combination works.

    Minimal reproduction

    In an isolated CPython 3.12 environment, install rocm[libraries,device-gfx1031]==10.0.0 from AMD's index and NumPy. Install either the official or test cp312 wheel with --force-reinstall --no-deps, then run python repro.py /path/to/local/faster-whisper-small.en:

    import ctypes
import os
from pathlib import Path
import sys

os.environ.pop("HSA_OVERRIDE_GFX_VERSION", None)
for name in ("HIP_PATH", "ROCM_PATH", "ROCM_HOME"):
    os.environ.pop(name, None)
site = Path(sys.prefix) / "Lib/site-packages"
core, libs = site / "_rocm_sdk_core/bin", site / "_rocm_sdk_libraries/bin"
handles = [os.add_dll_directory(str(p)) for p in (core, libs)]
for path in (core / "amdhip64_7.dll", libs / "libhipblaslt.dll",
             libs / "rocblas.dll", libs / "hipblas.dll"):
    handles.append(ctypes.WinDLL(str(path)))

import ctranslate2 as ct2
import numpy as np

print(ct2.__version__, ct2.get_cuda_device_count(), flush=True)
model = ct2.models.Whisper(sys.argv[1], device="cuda", compute_type="float16")
print("Model loaded", flush=True)
features = ct2.StorageView.from_array(np.zeros((1, 80, 3000), dtype=np.float32))
model.encode(features)
print("Encoder completed", flush=True)

    device="cuda" is CT2's API spelling for GPU execution in these HIP wheels.

    Artifact identity

    • Official 4.8.2 release ZIP SHA-256: 43da4baa5feaee49f77e176277a9647f99c493173c81a0bc60f491cac97532c2.
    • Official 4.8.4 release ZIP SHA-256: 313a442358ac3d2b917d4302449ca17125a72b6eddf6fff6cd0d7ae4c2056b6f.
    • Maintainer artifact ID 13007973399, ZIP SHA-256 checked against GitHub's artifact metadata: 430fbf0aa7c4cddcaf17e432c18f937b1f80f3c73353b89f90e528f5b8125827.
    • Extracted test cp312 wheel SHA-256: 15f057c53c2e4a9911504995ff783bd8db494c177701aba64dc467379bb8e452.
    • Test ctranslate2.dll SHA-256: dd4092e29b5dcf4337c2f6e8d4f9aece377b19c46ff11a8d7ec1a76608b150fa.

    Please retain gfx1031 in the expanded architecture list for the next official Windows ROCm release. The test artifact supplies a working path for this card; the current official wheels do not.

  3. dutch2005 commented on Nov 2, 2026

    @dutch2005
    dutch2005
    on Nov 2, 2026

    Follow-up with real application integration of the expanded-target build at 9a7a074fe09521795f4172ecc42e4516700b3819 (HIP CT2 4.8.4): VoiceStudio's actual /transcribe and /v1/audio/transcriptions endpoints now both pass on an RX 6700 XT / gfx1031 using GPU float16. Explicit CPU selection also passes after process isolation. All four responses have matching transcript hashes, and both application test processes shut down with exit 0. The short input was synthetic speech with already-cached faster-whisper small.en weights; tests were offline.

    One additional compatibility issue surfaced with ROCm 10.0.0 / Torch 2.13.0+rocm10.0.0 on Windows 11 x64: CT2 CPU encoding in the Torch process aborts with exit 3 and OMP: Error #15: Initializing libiomp5md.dll, but found libomp140.x86_64.dll already initialized. DLL import tables show ctranslate2.dll imports Intel libiomp5md.dll and torch_cpu.dll imports LLVM libomp140.x86_64.dll. The crash occurs after VAD, inside CPU encode; ONNX VAD was not established as the duplicate-runtime owner.

    We retained the successful GPU build and moved the affected application's faster-whisper inference into a Torch-free worker, preserving options, VAD/timestamps and GPU-memory-to-CPU fallback. Actual worker DLL inspection in both GPU and CPU modes shows only libiomp5md.dll and no Torch libraries. No KMP_DUPLICATE_LIB_OK, DLL renaming, architecture spoofing or global SDK/driver change is used.

    Implementation and qualification limits: debpalash/VoiceStudio#3712 (head 0cd11650b15e69ce183c06bb862f98463f09bd1e); focused application issue: debpalash/VoiceStudio#3770. The underlying candidate wheel/DLL hashes are unchanged from the earlier report. A future Windows HIP build with an OpenMP runtime compatible with current AMD Torch, or without the conflicting runtime, may avoid this application isolation requirement; that rebuild has not been tested here.

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions