feat: detect AMD/ROCm GPUs and install ROCm PyTorch for extensions

[samuk10]

What & why

Modly's GPU detection (detectGpuInfo in electron/main/ipc-handlers.ts) only probes nvidia-smi. On an AMD machine there is no NVIDIA GPU, so it reports accelerator: 'cpu' and the extension installer passes the default torch_flavor: 'cuda' — extensions then either fail to install PyTorch or install a CPU build, and the AMD GPU sits unused.

Pure-PyTorch extensions like Hunyuan3D 2 Mini already support ROCm in their setup.py (torch_flavor == "rocm" → ROCm wheel index), but the app never passes that flag, so the branch is unreachable today.

The fix

Add detectRocmGpu() (Linux-only): when ROCm userspace is installed (/opt/rocm or rocminfo present) and rocminfo reports an AMD GPU agent (gfx*), and no NVIDIA GPU is present, pass torch_flavor: 'rocm' to the extension's setup.py.

• No change for NVIDIA users (the ROCm branch only triggers when gpuSm === 0).
• No change for macOS / Apple Silicon.
• Minimal: one new helper + one field in the existing runExtensionSetup args (no signature or call-site changes).

Tested

AMD Radeon RX 7600 (gfx1102), Ubuntu 26.04, ROCm 6.3:

• Setup log now shows [setup] -> PyTorch + ROCm 7.2 (previously fell through to cu118/CPU and failed on Python 3.14).
• Hunyuan3D 2 Mini installs, loads on the GPU, and generates meshes end-to-end.

Docs

Adds docs/rocm-amd-setup.md — a step-by-step guide covering the two environment prerequisites (Python 3.12 to avoid the 3.14 PyTorch wheel gap; ROCm via TheRock, which officially supports gfx1102), how to run, and which extensions work on AMD — including why TripoSG doesn't (its diso dependency is a CUDA-only C++ extension).

🤖 Generated with Claude Code

[lightningpixel]

Thanks for this — ROCm support is a real gap, and the end-to-end validation on a 7600 with Hunyuan3D Mini is exactly the kind of legwork that makes a feature like this trustworthy. A few things to fix before this lands.

1. detectRocmGpu() — the gfx pattern misses the ISA names that end in a letter

return /gfx\d{3}/.test(out)

AMD gfx ids aren't all-digit. rocminfo prints Name: gfx90a:sramecc+:xnack- on MI210/MI250/MI250X and gfx90c on Ryzen APUs, and \d{3} can't match either. Those machines return false and fall straight back to 'cuda' — the bug this PR is fixing. Your gfx1102 and gfx942 match fine, which is why local testing wouldn't surface it.

The pattern is also loose in the other direction: it matches any gfx* agent, including integrated GPUs that ROCm doesn't support (gfx1036 on a Raphael iGPU), so an APU box with no usable discrete GPU gets ROCm wheels that fail at runtime.

Something like /\bgfx[0-9a-f]{3,4}\b/i fixes the first half; for the second, parsing the Name: lines of GPU-type agents rather than substring-matching the whole blob would be more robust.

2. The existence guard and the executable lookup disagree

if (!existsSync('/opt/rocm') && !existsSync('/usr/bin/rocminfo')) return false
const out = execFileSync('rocminfo', [], { … })

The guard checks fixed paths, the probe resolves off PATH. TheRock — the distribution this PR's own doc recommends — installs neither of those paths, so a working TheRock setup bails before the probe runs. And a /opt/rocm install whose bin/ isn't on PATH passes the guard and then throws ENOENT; that's the common case for a GUI-launched Electron app, which doesn't inherit PATH edits made in shell rc files. Probing the absolute path first with a PATH lookup as fallback would cover both.

3. execFileSync blocks the Electron main process

runExtensionSetup runs on the main thread, and rocminfo is slow — it can hang outright when the amdgpu driver is wedged, in which case the whole 5s timeout is spent with the UI, IPC and window frozen. detectGpuInfo() right above is promise-based/spawn for exactly this reason; worth matching it. The result is also recomputed at each call site rather than cached, so this happens on every install and repair.

4. torch_flavor and accelerator contradict each other

const torchFlavor = process.platform === 'linux' && gpuSm === 0 && detectRocmGpu() ? 'rocm' : 'cuda'

Two issues in one line. On the ROCm path gpuSm === 0, so accelerator (computed just above as gpuSm > 0 ? 'cuda' : 'cpu') stays 'cpu' and the payload goes out as {accelerator: 'cpu', torch_flavor: 'rocm'}. Any setup.py gating GPU deps on accelerator or gpu_sm still takes the CPU branch, so this only works for scripts that happen to branch exclusively on the new field.

And the else-branch hardcodes 'cuda' for everything else — a CPU-only Linux box and an Apple Silicon Mac are both now told torch_flavor: 'cuda'. Deriving it from accelerator (rocm / cuda / mps / cpu) resolves both problems at once.

5. docs/rocm-amd-setup.md — the venv claim doesn't hold

Modly's findSystemPython() tries python3.12 first, so on the next launch it rebuilds its backend venv with 3.12.

checkSetupNeeded() (electron/main/python-setup.ts:79) only returns true when python_setup.json is below SETUP_VERSION, the requirements hash changed, or the venv python is missing. Putting python3.12 on PATH changes none of those, so runFullSetup never re-runs and the 3.14 venv is kept — a reader following the doc stays broken and has no way to tell why. The doc should say to delete the venv and python_setup.json first.

Also worth noting there: findSystemPython() is only reached on the Linux/macOS dev branch of runFullSetup. A packaged Linux build goes through ensureStableEmbeddedPython and uses the bundled interpreter, so the "install Python 3.12" prerequisite doesn't apply to normal packaged installs as written.

Minor: the header says "Tested on … ROCm 6.3" but step 3 tells the reader to expect [setup] -> PyTorch + ROCm 7.2. Someone on 6.3 can't tell whether they succeeded.

One suggestion: detectRocmGpu is pure string parsing over external output, which is cheap to test and awkward to verify by hand — you'd need three different AMD cards. A unit test over captured rocminfo output for gfx1102, gfx90a and gfx942 would have caught #1 and would keep the pattern honest as new ISAs appear.

[samuk10]

hi, sorry about some mistakes in this PR.
I don't have the RX7600 (bought RTX5060TI) ... that said I can't help with this PR anymore.
should we close?