AMD ROCm: Hunyuan3D-2 Turbo successfully runs end-to-end on Radeon Pro W5500 (gfx1012, 8 GB)
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=gfx1012This produced:
--offload-arch=gfx1012The 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 OKVRAM 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 minutesVolume decoding:
7134/7134
approximately 36.5 minutesTotal generation time:
approximately 45.5 minutesFinal mesh:
Vertices: 700,774
Faces: 1,401,058Output:
hunyuan_test.glbThe GLB was independently loaded using trimesh:
Type: <class 'trimesh.scene.scene.Scene'>
Scene geometries: 1
geometry_0 vertices = 700774 faces = 1401058
VALID GLB LOADResource 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:
export VENV_DIR=/path/to/Hunyun3D-2-ROCm/.venv-rocm7
export PATH=/opt/rocm/bin:$PATH
export PYTORCH_ROCM_ARCH=gfx1012Source: Tencent-Hunyuan/Hunyuan3D-2