AMD ROCm: Hunyuan3D-2 Turbo successfully runs end-to-end on Radeon Pro W5500 (gfx1012, 8 GB)

Author: Donnis32Created Aug 25, 2026Updated Aug 25, 2026

Summary

I successfully ran Hunyuan3D-2 Turbo end-to-end on an AMD Radeon Pro W5500 (8 GB VRAM) under Linux using ROCm 7.2 and PyTorch 2.13.

The pipeline completed all 50 diffusion steps, completed volume decoding, and exported a valid GLB mesh.

This may be useful to other AMD/ROCm users because the W5500 is an older gfx1012 GPU with only 8 GB VRAM.

Related discussion:

  • #52 — Not working on AMD cards?
  • #53 — Which steps to ignore for shape generation only?

Hardware

  • GPU: AMD Radeon Pro W5500
  • Architecture: gfx1012:xnack-
  • VRAM: 7.98 GiB
  • System RAM: 23 GiB
  • CPU: Intel Xeon E3-1270 v5
  • OS: Manjaro Linux

Software

  • ROCm/HIP: 7.2.53211
  • PyTorch: 2.13.0
  • Torchvision: 0.28.0
  • Python: 3.14
  • Model: Hunyuan3D-2 Turbo
  • Model subfolder: hunyuan3d-dit-v2-0-turbo

Important ROCm detail

The W5500 reports:

gfx1012:xnack-

PyTorch's ROCm architecture detection did not include gfx1012 in the architecture flags being generated for the extension build.

The custom rasterizer therefore had to be explicitly built with:

PYTORCH_ROCM_ARCH=gfx1012

This produced:

--offload-arch=gfx1012

The CUDA custom rasterizer sources were also hipified and built as HIP sources.

The resulting custom rasterizer passed a GPU smoke test:

Smoke test on device 0: gfx1012:xnack-
custom_rasterizer OK

VRAM limitation and workaround

Running the complete shape pipeline entirely on the GPU produced an out-of-memory error during diffusion sampling.

The W5500 has only 7.98 GiB VRAM.

The successful configuration instead uses explicit CPU/GPU offloading.

The shape model is moved to GPU for inference and returned to CPU after the forward pass.

The VAE is moved to GPU for latent decoding.

The geometry decoder is moved to GPU for volume/mesh extraction.

This allowed the complete pipeline to run without exceeding the 8 GB VRAM limit.

Device-placement fixes

The standard Accelerate CPU offload mechanism was not sufficient for this pipeline because the custom Hunyuan3D pipeline is not a standard Diffusers pipeline.

Several explicit device-placement issues had to be corrected.

Scheduler

The scheduler's sigma tensors remained on CPU while model outputs were on CUDA.

They were explicitly moved to the active device before scheduler operations.

VAE

The VAE initially remained on CPU while receiving CUDA latent tensors.

The VAE was explicitly moved to GPU during latent decoding.

Geometry decoder

During volume decoding, the geometry decoder's Fourier embedding frequencies remained on CPU while geometry queries were on CUDA.

The geometry decoder was explicitly moved to GPU during mesh extraction.

Successful result

Diffusion:

50/50
approximately 9 minutes

Volume decoding:

7134/7134
approximately 36.5 minutes

Total generation time:

approximately 45.5 minutes

Final mesh:

Vertices: 700,774
Faces:    1,401,058

Output:

hunyuan_test.glb

The GLB was independently loaded using trimesh:

Type: <class 'trimesh.scene.scene.Scene'>
Scene geometries: 1
geometry_0 vertices = 700774 faces = 1401058
VALID GLB LOAD

Resource usage

Peak system RAM was approximately 33% of 23 GiB.

CPU utilization was generally concentrated on approximately 2–3 CPU threads.

The GPU fan remained at relatively low speed for most of the run.

The primary limitation was therefore runtime rather than system RAM.

Reproduction

The working configuration used a Python virtual environment containing the ROCm-enabled PyTorch installation.

Set the environment variables for the build:

bash
export VENV_DIR=/path/to/Hunyun3D-2-ROCm/.venv-rocm7
export PATH=/opt/rocm/bin:$PATH
export PYTORCH_ROCM_ARCH=gfx1012

Source: Tencent-Hunyuan/Hunyuan3D-2