Summary
On an AMD GPU with ROCm, torchmcubes builds CPU-only without any error, then
falls back at runtime. Because PyTorch's ROCm build makes torch.cuda.is_available()
return True (HIP maps onto the CUDA API surface), downstream libraries assume
the GPU kernel path exists. The result is a silent performance cliff rather than
a failure.
Environment
- GPU: AMD Radeon Graphics,
gfx1100 (Navi 31), 48 GB
- ROCm 7.2.1, PyTorch 2.9.1 (ROCm build), Python 3.12, Ubuntu 24.04
torch.cuda.is_available() → True
torch.cuda.get_device_name(0) → AMD Radeon Graphics
Build output
-- Looking for a CUDA compiler
-- Looking for a CUDA compiler - NOTFOUND
CMake Warning at CMakeLists.txt:25 (message):
NO CUDA INSTALLATION FOUND, TRYING TO INSTALL CPU VERSION ONLY!
The build succeeds. At runtime:
Torchmcubes was not compiled with CUDA support, use CPU version instead.
Why this is worth flagging
ROCm systems have no nvcc, so the CUDA compiler probe can never succeed, but
they do have hipcc and a fully capable GPU. The current CMake logic treats
"no nvcc" as "no GPU".
Measured impact in TripoSR on the hardware above, mean of 14 assets:
| Stage |
Time |
Device |
| Transformer inference |
1051 ms |
GPU |
| Marching cubes (this library) |
1332 ms |
CPU fallback |
Surface extraction now costs more than the model itself, and is the single
largest non-GPU stage in the pipeline.
Suggested directions
- HIP build path. PyTorch ships
torch.utils.hipify, which mechanically
converts CUDA sources to HIP. The kernels here look like good candidates
since they use standard CUDA constructs rather than vendor-specific intrinsics.
- Detect HIP in CMake. Probe for
hipcc / HIP_PATH alongside the CUDA
check so ROCm systems take a GPU path instead of falling through.
- At minimum, document it. A README note that ROCm is unsupported and will
silently build CPU-only would save people from diagnosing a slowdown that
looks like a model problem.
Offer
I hit this while building an image-to-3D pipeline on Radeon hardware and worked
around it downstream. Happy to test a HIP build on gfx1100 and report back, or
to help with the CMake detection change if that's useful.
Summary
On an AMD GPU with ROCm,
torchmcubesbuilds CPU-only without any error, thenfalls back at runtime. Because PyTorch's ROCm build makes
torch.cuda.is_available()return
True(HIP maps onto the CUDA API surface), downstream libraries assumethe GPU kernel path exists. The result is a silent performance cliff rather than
a failure.
Environment
gfx1100(Navi 31), 48 GBtorch.cuda.is_available()→Truetorch.cuda.get_device_name(0)→AMD Radeon GraphicsBuild output
-- Looking for a CUDA compiler
-- Looking for a CUDA compiler - NOTFOUND
CMake Warning at CMakeLists.txt:25 (message):
NO CUDA INSTALLATION FOUND, TRYING TO INSTALL CPU VERSION ONLY!
The build succeeds. At runtime:
Torchmcubes was not compiled with CUDA support, use CPU version instead.
Why this is worth flagging
ROCm systems have no
nvcc, so the CUDA compiler probe can never succeed, butthey do have
hipccand a fully capable GPU. The current CMake logic treats"no nvcc" as "no GPU".
Measured impact in TripoSR on the hardware above, mean of 14 assets:
Surface extraction now costs more than the model itself, and is the single
largest non-GPU stage in the pipeline.
Suggested directions
torch.utils.hipify, which mechanicallyconverts CUDA sources to HIP. The kernels here look like good candidates
since they use standard CUDA constructs rather than vendor-specific intrinsics.
hipcc/HIP_PATHalongside the CUDAcheck so ROCm systems take a GPU path instead of falling through.
silently build CPU-only would save people from diagnosing a slowdown that
looks like a model problem.
Offer
I hit this while building an image-to-3D pipeline on Radeon hardware and worked
around it downstream. Happy to test a HIP build on
gfx1100and report back, orto help with the CMake detection change if that's useful.