You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: NVIDIA build still runs on CPU on machines with an NVIDIA GPU #247
On the NVIDIA build of StemDeck, stem separation still runs on CPU on machines that have an NVIDIA GPU. The whole point of the NVIDIA build is to use CUDA, so it should detect the card and run on GPU — instead it silently falls back to CPU (slow separation).
This is distinct from the already-fixed Blackwell/sm_120 case (#239); it's being reported on NVIDIA cards generally.
Steps to reproduce
Install the NVIDIA (CUDA) build of StemDeck on a PC with an NVIDIA GPU.
Complete first-run setup.
Run a stem separation.
Observe it runs on CPU (slow) rather than the GPU — the startup/GPU summary reports CPU, or separation is much slower than expected.
Investigation notes (for triage)
GPU selection lives in ensure_torch_device (desktop/src-tauri/src/main.rs). Several points can each land on CPU silently — worth checking which one:
Mis-packaged CPU marker — is_cpu_only_package() short-circuits to CPU if a cpu-only marker file is present in the app root or data dir. If the NVIDIA build accidentally ships/writes that marker, it never even probes the GPU.
detect_nvidia_gpu() returns None — depends on nvidia-smi. Tauri child processes inherit a stripped PATH; there's a System32 fallback for the exe, but if nvidia-smi is missing/relocated or the 10s call times out, detection returns None → CPU.
verify_cuda_torch() returns false — wrong/CPU-only torch wheel installed, or a driver/CUDA-runtime mismatch, so torch.cuda.is_available() is false → CPU. install_cuda_torch may have "succeeded" while installing the wrong wheel for the card's compute capability.
Persisted torchDevice=cpu sticks — the result is persisted so later launches skip detection. A single failed first run (transient nvidia-smi timeout, network hiccup during the CUDA torch install) can pin the install to CPU permanently, even once the environment is fine. There may be no path to re-trigger detection short of clearing config.
Suspect (4) in particular for "it works on some NVIDIA PCs but not others" — a first-run failure gets cached.
Requests for the reporter
Which GPU model and driver version (nvidia-smi output)?
The GPU summary shown on the setup screen (e.g. "… CUDA … enabled" vs "falling back to CPU").
logs/setup.log from the StemDeck data folder — it records the CUDA install/verify steps.
A startup diagnostic that reports each decision separately—CPU marker detected, nvidia-smi result, installed Torch build, and torch.cuda.is_available()—would make silent fallback much easier to classify. Packaging CI could additionally assert that the NVIDIA artifact contains no cpu-only marker and that its bundled Python environment reports a CUDA-enabled Torch version. Distinguishing detection failure from CUDA initialization failure in the UI would also prevent both cases appearing simply as “CPU.”
Activity
hiSandog commentedon Jul 11, 2026
A startup diagnostic that reports each decision separately—CPU marker detected,
nvidia-smiresult, installed Torch build, andtorch.cuda.is_available()—would make silent fallback much easier to classify. Packaging CI could additionally assert that the NVIDIA artifact contains nocpu-onlymarker and that its bundled Python environment reports a CUDA-enabled Torch version. Distinguishing detection failure from CUDA initialization failure in the UI would also prevent both cases appearing simply as “CPU.”feat(settings): compute device selector for the self-hosted server
fix(desktop): NVIDIA build silently falling back to CPU (#247) (#267)
feat(pipeline): retry separation on CPU when a GPU attempt fails (#299)
fix(desktop): re-detect GPU after CPU→NVIDIA build swap (#316) (#317)
Fix the bugs reported against 0.19.0 (#737)