Comfy-Org / Comfy-Org/Comfy-Desktop

First-use install does not warn Pascal/10-series GPUs before installing a bundle without Pascal kernels

Open
#1,329 1 comment 1 reaction 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.