Using ComfyUI with ROCm 7.14

ComfyUI's official AMD docs recommend using ROCm 7.2. However, I tested it with the latest ROCm 7.14 on an AMD Strix Halo, and it flies.

Upgrading to ROCm 7.14 made my 1 MP gens in Krea 2 go from ~55s to ~45s (~18% faster) with the exact same prompt. Batch of four 1024 x 1024 SDXL images went from ~100s to ~76 s (~24% faster).

This guide assumes you are starting from scratch. If you already have ComfyUI set up, skip to creating the venv.

¶Get the appropriate Python version

ComfyUI devs recommend Python 3.12, 3.13 or 3.14 with a disclaimer that some custom nodes might not work properly with Python 3.14.

I use Comfy with Python 3.14 and all of my custom nodes (admittedly not many) work just fine. If something doesn't work on your system, try Python 3.12 or 3.13.

¶Find your GPU architecture

Run rocm-smi --showproductname, match the GFX Version to the table below, and note it down. You will need this while creating the venv:

¶Make sure your system has the HSA runtime

You probably have it installed, but verify just in case and note the full versioned filename. This will be useful if you face the 100% CPU usage bug:

ls /lib64/libhsa-runtime64.so.1.*

On Fedora 44, I got /lib64/libhsa-runtime64.so.1.18.0. Yours may differ.

If missing, install it, then try the above command again:

# Fedora
sudo dnf install rocm-runtime

# Ubuntu / Debian
sudo apt install libhsa-runtime64-1

# Arch
sudo pacman -S hsa-rocr

¶Install ComfyUI

¶Clone the ComfyUI repo and cd into it

git clone https://github.com/Comfy-Org/ComfyUI
cd ComfyUI

¶Create the venv

Inside the ComfyUI folder, run:

python3 -m venv venv-rocm714
source venv-rocm714/bin/activate
pip install -U pip wheel

If you already have a venv set up, this will create a parallel environment with ROCm 7.14 PyTorch. This way, you can switch between the two environments if needed.

¶Install ROCm 7.14 PyTorch

Important: device-gfx1151 will work only with Ryzen AI Max+ 395 / 390 (Strix Halo) systems. Replace it with your GPU's tag.

pip install --index-url https://repo.amd.com/rocm/whl-multi-arch/ \
  "torch[device-gfx1151]==2.12.0+rocm7.14.0" \
  "torchvision[device-gfx1151]==0.27.0+rocm7.14.0" \
  "torchaudio==2.11.0+rocm7.14.0"

¶Install remaining ComfyUI dependencies

pip install --no-deps -r requirements.txt

Verify:

python -c "import torch; print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))"

This should print 2.12.0+rocm7.14.0 True your-GPU-name.

¶Fix idle CPU spin (possibly Fedora 44-only)

On Fedora 44, I noticed that starting ComfyUI permanently pegged one CPU thread to 100%, even when not generating anything. I tried multiple flags, but nothing fixed it. This also happened on ROCm 7.2 so it's not a 7.14-specific regression.

I made my clanker investigate the issue and it found a solution.

AI writing disclaimer: Unlike the rest of the article, this section has been written by an LLM. I don't know if its explanation is correct, but I can attest that the problem is real and the solution works.

The ROCm 7.14 HSA runtime has a bug where its AsyncEventsLoop thread busy-spins at 100% CPU when idle. The system HSA runtime from the AMD GPU driver doesn't have this issue. To work around it, build a small shim that stubs the newer symbols the system runtime is missing, then use LD_PRELOAD to force the system runtime.

Make sure you have a C compiler:

# Fedora
sudo dnf install gcc

# Ubuntu / Debian
sudo apt install gcc

# Arch
sudo pacman -S gcc

Build the shim (one-time):

cat > hsa_shim.c << 'EOF'
#define STUB __attribute__((visibility("default"))) int
STUB hsa_amd_agent_preload() { return 1; }
STUB hsa_amd_counted_queue_acquire() { return 1; }
STUB hsa_amd_counted_queue_release() { return 1; }
STUB hsa_amd_external_semaphore_handle_close() { return 1; }
STUB hsa_amd_external_semaphore_handle_open() { return 1; }
STUB hsa_amd_memory_async_batch_copy() { return 1; }
STUB hsa_amd_queue_create() { return 1; }
STUB hsa_amd_signal_get_event_id() { return 1; }
STUB hsa_amd_svm_discard_batch_async() { return 1; }
STUB hsa_amd_vmem_export_fabric_handle() { return 1; }
STUB hsa_amd_vmem_import_fabric_handle() { return 1; }
STUB hsa_ext_image_create_v2() { return 1; }
STUB hsa_ext_image_data_get_info_v2() { return 1; }
STUB hsa_ext_image_destroy_v2() { return 1; }
STUB hsa_ext_image_mipmap_array_get_level() { return 1; }
EOF
gcc -shared -fPIC -o libhsa_shim.so hsa_shim.c

Verify the fix (no thread should hit 100%):

Replace the 1.18.0 version number with what ls showed you above.

LD_PRELOAD="./libhsa_shim.so /lib64/libhsa-runtime64.so.1.18.0" \
  python -c "import torch; import time; torch.zeros(1,device='cuda'); time.sleep(10)"

¶Run ComfyUI

We're ready to go. Strix Halo and other high-VRAM can use the --highvram flag.

Replace the 1.18.0 version number with what ls showed you above (only applies if you faced the 100% CPU usage bug. If you didn't, skip the LD_PRELOAD part).

LD_PRELOAD="./libhsa_shim.so /lib64/libhsa-runtime64.so.1.18.0" \
  python main.py --bf16-vae --disable-mmap --highvram

You might see a E-001h rocSHMEM Could not open libnuma warning. This is harmless and only relevant for multi-GPU setups.

For other GPUs (or to conserve VRAM on Strix Halo), use these settings (based on community feedback):

LD_PRELOAD="./libhsa_shim.so /lib64/libhsa-runtime64.so.1.18.0" \
  python main.py --bf16-vae --disable-mmap --enable-dynamic-vram --disable-pinned-memory --reserve-vram 1.0

¶Other flags to try

I haven't played with these yet, but feel free to experiment:

 --use-pytorch-cross-attention --disable-smart-memory

¶Switching between ROCm environments

If you have an existing venv, you can go back to ROCm 7.2 by deactivating 7.14 and activating the original venv:

deactivate
source venv/bin/activate
python main.py --bf16-vae --disable-mmap --highvram --listen 0.0.0.0

Now run ComfyUI as usual.