Hunyuan3D 2.1 without CUDA: update adds ROCm and PBR texturing

The port of Hunyuan3D 2.1 to hardware without CUDA was updated on August 9, 2026, and now includes something that was previously completely absent: support for AMD graphics cards via ROCm (Linux and Windows) and PBR texturing. The previous version of the description explicitly stated that texturing without CUDA was impossible; now it has been verified end-to-end on both AMD and Apple Silicon.

The port itself consists of installers, a compatibility layer, and a Gradio web interface wrapped around the original Hunyuan3D 2.1 from Tencent. Input is a single image, output is a mesh in one of seven formats (obj, glb, ply, stl, fbx, dae, 3mf), and now also textures: a GLB with a real PBR material or an archive with OBJ, MTL, and maps.

Disclosure. The repository is maintained by Vladimir Talyzin — the same person who authors and owns cpu3d.com. We write about our own work and say so directly: all numbers below are taken from the repository description, the link to the source is above, and anyone can verify them.

What's new in the update

PBR texturing without CUDA. Generation of albedo and metallic-roughness plus UV baking — verified on both ROCm and Apple MPS.
A rasterizer that doesn't need a compiler — implemented in pure PyTorch. This is what makes texturing possible on Windows: the ROCm build of PyTorch there cannot link C++ extensions at all.
Attention that fits in memory. Chunked SDPA keeps peak allocation low on GPUs without flash attention and produces bit-identical results to running without chunking.
A pre-flight check that refuses rather than crashes the machine. Settings above what the GPU can handle are rejected with an explanation: on ROCm — because otherwise the driver will reset, on MPS — because Metal simply won't allocate such a buffer.

Teapot: source image and four views of the textured model — Input on the left, four views of the textured result on the right. The teapot is a topology test: the through-hole in the handle is preserved, and the unglazed bottom is textured separately from the glaze. Screenshot from the repository, computed on a Radeon 8060S.

How long it takes

The same input and identical settings on two machines. Both are the worst case for this model: neither has flash attention, so both ran the "Safe" preset, i.e., 6 views at 256 points.

Step	Radeon 8060S (gfx1151, Windows, ROCm 7.2)	Apple M4 Pro, 24 GB
Shape: 30 steps, octree 192	~6.4 min	5.7 min
PBR texture: 6 views, 256 points	~2.5 min	8.5 min
Rasterization: 80k faces, 2048x2048	~80 ms	152 ms

Note: the Radeon 8060S is integrated graphics, and texturing on it is faster than on the Mac. On the M4 Pro with 24 GB, this stage is tight on memory, with the run spilling about 8 GB into swap.

Sneaker: source image and four views of the textured model — The real PBR test — multiple materials in a single object: the outsole tread, the upper mesh, and the laces separate cleanly. Screenshot from the repository.

Why textures are computed at 256 points, not 768

It's not about memory capacity, but about how it grows. Multi-view attention concatenates all views into a single sequence, and the attention matrix grows quadratically. Measured, not estimated: 6 views at 256 points — 4.2 GiB, everything computes; 6 at 512 — 67.5 GiB, the machine hangs; 8 at 768 — 607.5 GiB, hopeless. That's why the "Safe" preset is used on hardware without flash attention, and the pre-flight check rejects anything above the limit: on ROCm it's 5 GiB.

The Windows-specific gotcha

The display driver has a watchdog: if a single GPU operation doesn't return within 2 seconds, Windows resets the GPU. The process doesn't crash — it keeps computing on a GPU that now returns incorrect numbers. After such a reset, multiplying 1024x1024 matrices of ones gave 947.3 instead of 1024, even though the sums remained exact. Meshes and textures silently come out corrupted, and it looks like a bug in the pipeline itself. The fix is raising TdrDelay to 60 seconds, and scripts/doctor.py separately verifies that the GPU is still computing correctly.

What you need to install it

Each platform has its own installer: install.sh for Apple Silicon, scripts/install_rocm.sh for AMD on Linux, scripts/install_rocm_windows.ps1 for AMD on Windows. You'll need to download about 30 GB of model weights: roughly 15 GB for shape, 6.5 GB for textures, and 4.5 GB for facebook/dinov2-giant. The interface is translated into English, Chinese, and Russian.

There are two licenses here, and this matters. The weights are under the Tencent Hunyuan 3D 2.1 Community License: it does not extend to the EU, the UK, or South Korea, and commercial use is limited to a threshold of 100 million monthly active users. The wrapper code itself is MIT, as a separate file.

What this means for the reference

In our reference, this port is listed as the tool page Hunyuan3D 2.1 without CUDA (Mac and AMD). The fact sheet and tool page text have been rebuilt from the updated repository: platforms now include Apple Silicon, MPS, and ROCm, there are seven export formats, and texturing has been added to shape generation. The original model around which all this is built is covered separately — Hunyuan3D 2.1.

The practical takeaway from the update is simple: until now, turning an image into a textured model on your own hardware meant either NVIDIA or nothing. Now the same path is possible on AMD integrated graphics and an Apple Silicon laptop — slower, but entirely on your own machine, without the cloud and without someone else's quotas.