Comfy-Org / Comfy-Org/Comfy-Desktop
First-use install does not warn Pascal/10-series GPUs before installing a bundle without Pascal kernels
- Dominant language
- TypeScript
- Stars
- 458
- Forks
- 59
- Avg merge
- 22h 18m
- Merged PRs (30d)
- 45
Description
## Context
PR #1248 (`feat/pytorch-stack-switching`) added NVIDIA compute-capability probing (`nvidia-smi --query-gpu=compute_cap`) and per-stack kernel ranges to the PyTorch stack picker. For a Pascal / GTX 10-series card (sm 6.1), the picker annotates builds that dropped Pascal kernels (cu128: sm 7.5-12.0, cu130+) with an informational warning:
> May not support this machine's GPU - needs compute capability 7.5-12.0, detected 6.1
while the designated legacy build `cu126` (sm 5.0-9.0, which kept Maxwell/Pascal/Volta kernels) shows no warning. Warnings are informational only - they never hide or block an entry (detection can be wrong on multi-GPU boxes or before a driver install).
## Gap
The fresh-install (first-use) flow has no Pascal-specific behavior. `validateHardware()` only surfaces the Linux AMD `/dev/kfd` access warning; there is no compute-cap check when picking Local and installing the default bundle. A 10-series user therefore installs the standard NVIDIA distribution (a cu130 bundle with no Pascal kernels) with no warning, and only hits "no kernel image is available for execution on the device" at runtime. The new warnings only appear afterward, in the Change PyTorch / update picker, where the user could then switch to cu126.
## Proposed follow-up
Wire the existing compute-cap probe and mismatch logic into the first-use install flow:
- Probe compute capability before (or during) the fresh install when an NVIDIA GPU is detected.
- If no detected GPU falls inside the default bundle's kernel range, surface a non-blocking warning in the first-use UI (same pattern as the existing `first-use-hardware-warning` element used for the Linux AMD `/dev/kfd` case), and/or steer the user toward the cu126 legacy stack up front.
- Keep the same fail-open semantics as the picker: unknown or failed probes produce no warning, and the warning never blocks the install.
Most of the plumbing already exists in `src/main/sources/standalone/torchIndexManifest.ts` (`probeComputeCaps`, `capMismatch`) and `src/main/lib/gpu.ts` (`validateHardware`); this is mainly wiring plus deciding the UX for steering to cu126.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with probeComputeCaps and capMismatch in src/main/sources/standalone/torchIndexManifest.ts, then inspect validateHardware in src/main/lib/gpu.ts and the first-use-hardware-warning flow. The first-use install should detect a default-bundle mismatch, show a non-blocking warning or steer toward cu126, and remain silent when probing fails or returns unknown.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- desktop
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100