Skip to content

[Bug]: NVIDIA build still runs on CPU on machines with an NVIDIA GPU #247

Closed

Description

@thcp

What happened?

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

  1. Install the NVIDIA (CUDA) build of StemDeck on a PC with an NVIDIA GPU.
  2. Complete first-run setup.
  3. Run a stem separation.
  4. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Operating system

Windows

How did you install it?

Windows ZIP (NVIDIA build)

Activity

  1. added
    bugSomething isn't working
    on Jul 4, 2026
  2. hiSandog commented on Jul 11, 2026

    @hiSandog

    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.”

  3. self-assigned this
    on Oct 1, 2026
  4. added a commit that references this issue on Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions