[itxtoledo]

Problem

On Windows with ROCm on RDNA2 GPUs (gfx103x, e.g. RX 6650 XT / gfx1032), Kokoro generation fails because MIOpen cannot JIT-compile the RNN and InstanceNorm kernels used by the model:

MIOpen(HIP): Error [Compile] ... MIOpenRNNHiddenStateUpdate.cpp ...
... 'type_traits' file not found
...
miopenStatusUnknownError

The failure happens in Kokoro's text encoder (LSTM) and in its InstanceNorm layers, so the request aborts before producing audio.

Fix

Detect Windows + ROCm + gfx103x in kokoro_backend.py and temporarily disable torch.backends.cudnn.enabled for the duration of the Kokoro generation. On ROCm this routes RNN / InstanceNorm / convolution through PyTorch's native implementations, which still run on the GPU, instead of MIOpen. The previous value is restored in a finally block.

A module-level lock serializes Kokoro generations on this path so concurrent requests cannot restore the flag mid-generation.

The fallback is strictly scoped:

• only on Windows (sys.platform == "win32")
• only on ROCm (torch.version.hip is not None)
• only on RDNA2 (gcnArchName starts with gfx103)

CUDA, CPU, Linux ROCm, and other GPU architectures are unaffected.

Testing

• GPU: AMD Radeon RX 6650 XT (gfx1032, 8 GB)
• OS: Windows 11
• Runtime: ROCm 10.1 + torch 2.14.0+rocm10.1.0
• Voice: Kokoro pf_dora, pt-BR, text Olá mundo
• Before: request failed with miopenStatusUnknownError
• After: 0.88 s WAV at 24 kHz, mono, ~568 MB VRAM; audio verified by listening

This change does not touch the ROCm build or runtime. It fixes the MIOpen op failure once the runtime can enumerate the GPU. On this GPU, ROCm 7.2.1 currently crashes during device enumeration (a separate AMD issue), so the test was done with ROCm 10.1.

Changes

• backend/backends/kokoro_backend.py