Re-verify cuda-link/TensorRT + retire dead cuDNN setx (re-creates abandoned PR)#3
Open
forkni wants to merge 24 commits into
Open
Re-verify cuda-link/TensorRT + retire dead cuDNN setx (re-creates abandoned PR)#3forkni wants to merge 24 commits into
forkni wants to merge 24 commits into
Conversation
- tensorrt.py: bump tensorrt_cu12 to 10.16.1.11, polygraphy 0.49.26, onnx-graphsurgeon 0.6.1; add FP8-quant block (modelopt + cupy-cuda12x + numpy re-lock); re-pin onnxruntime-gpu==1.24.4 with --no-deps after modelopt downgrade; drop shell-style quotes inside package specs (run_pip uses subprocess + .split(), quotes become literal arg chars). - installer.py: remove torchaudio from cu128 config (not needed); minor ruff format cleanup. - verifier.py: float32_to_bfloat16 diagnostic points to onnx-gs 0.6.1 instead of suggesting an onnx downgrade. - __init__.py, __main__.py, cli.py: ruff format cleanup (blank lines, unused import, raw docstring).
Fixes 6 CVEs patched in deps audit 2026-05-23: - idna >=3.16 (CVE-2026-45409: punycode resource exhaustion) - Mako >=1.3.12 (CVE-2026-44307: Windows backslash path traversal) - urllib3 >=2.7.0 (CVE-2026-44432/44431: over-decompression, cross-origin redirect) Added to MANUAL_PINS and installed in phase7_numpy_lock so upgrade runs on both fresh and existing installs. Fresh pip resolves already satisfy these floors; this ensures the minimum on partial updates. pip and onnxruntime-gpu CVEs are handled separately: - pip: phase1_foundation already runs --upgrade pip (gets latest) - onnx 1.19.1: 6 CVEs deferred — 1.21.0 breaks FP8 quantization Co-Authored-By: Claude Opus 4.7 <[email protected]>
…0.3.2 cuda-link (CUDA-IPC zero-copy transport) was never installed on a clean install: setup.py only exposes it via the optional cuda_ipc extra (a git ref to a compiled cp311 extension), which installer.py's phase4 never requests to avoid forcing an MSVC/nvcc source build. Add phase4b_cuda_link, mirroring phase3b_insightface's Python-version-gated prebuilt-wheel install (--no-deps, non-fatal fallback to the mirror-DAT transport). Also fixes pywin32 306->311 in tensorrt.py to match setup.py's authoritative pin (8c8020a fixed every other TensorRT pin but missed this one). Co-Authored-By: Claude Opus 4.8 <[email protected]>
PYTORCH_CONFIGS["cu128"] pinned torch 2.7.0 / torchvision 0.22.0, but setup.py doesn't constrain torch at all -- this dict was the sole source of truth, and the repo's own README, PKG-INFO, and tests/quality/manifest.json all target torch 2.8.0+cu128 / torchvision 0.23.0 (the golden-image regression harness aborts on any divergence). Bump to match, pairing correctly with the already maintained tensorrt_cu12==10.16.1.11.
Unbounded nvidia-modelopt[onnx]>=0.19.0 floats to 0.45.0, whose [onnx] extra force-upgrades onnx past the immovable setup.py pin (1.19.1), breaking FP8 quant (negative QDQ scale on external-data loading). Confirmed live: a fresh Step 3 install left onnx 1.21.0 / modelopt 0.45.0 in the venv. Pin modelopt to the proven 0.43.0 (matches tests/quality/manifest.json) and re-assert onnx==1.19.1 alongside the existing onnxruntime-gpu re-assert.
Add Installer.phase4c_cuda_link_env(): after the cuda-link wheel is installed, persist CUDALINK_LIB_PATH to the user environment via setx (Windows-only, non-fatal) so TouchDesigner library mode resolves the venv site-packages with no manual env-var step. Wired into install() right after phase4b_cuda_link(). Bump the wheel URL and phase progress string from 1.12.0 to 1.12.1. Co-Authored-By: Claude Sonnet 5 <[email protected]>
phase4c_cuda_link_env only declared CUDALINK_LIB_PATH, so a fresh install silently degraded the native-wait IPC path to poll-sleep. SD's TD topology is bidirectional (TD Sender + SD Exporter are each a producer on their own IPC leg), and TD's Sender runs in a separate bundled-Python process that a runtime os.environ.setdefault can't reach -- the doorbell var must be setx-persisted like CUDALINK_LIB_PATH. Found via a clean-slate reproducibility test of PR #2's cuda-link handling (stripped venv package + all cuda-link env vars, then re-ran phase4b/phase4c to confirm they're self-sufficient).
The multi-agent code-review plugin exhausted 60 turns on PR #2 (feat/installer-error-report, a stacked diff with no CLAUDE.md to shortcut convention discovery) before posting a verdict. Bumping headroom rather than trusting a partial/incomplete review.
The multi-agent code-review plugin exhausted 60 turns on PR #2 (feat/installer-error-report, a stacked diff with no CLAUDE.md to shortcut convention discovery) before posting a verdict. Bumping headroom rather than trusting a partial/incomplete review.
subprocess.run(['setx', ...]) can raise FileNotFoundError/OSError if setx isn't resolvable, which propagated unhandled and aborted the install before phases 5-8 ran -- contradicting the method's own 'non-fatal' docstring. Wrap both calls in try/except OSError, matching the existing returncode!=0 warning path. Flagged independently by both the Claude and Copilot review passes on PR #1.
…onnx deps: cuda-link 1.12.1 + doorbell persistence fixes
feat: installer error-report generation (schema v1)
…ase4c The TD launcher (StreamDiffusionExt.Startstream) set this env var in its own stream subprocess on every launch, duplicated across three launch-path variants (windowless Popen, PowerShell, cmd batch). It also duplicated three now-removed no-op/harmful vars: CUDA_LAUNCH_BLOCKING (torch default), TORCHINDUCTOR_FX_GRAPH_CACHE (inert -- no torch.compile usage in streamdiffusion), and SDTD_L2_PERSIST/_MB (forced L2 persistence on regardless of backend, masking streamdiffusion's new mode-aware default that keeps it off under TensorRT). Persist TORCH_CUDNN_V8_API_ENABLED here via setx instead, next to CUDALINK_DOORBELL, so there's one declaration site inherited by every TD-launched process. Co-Authored-By: Claude Sonnet 5 <[email protected]>
…ep verification The main [8/8] verifier checked 13 deps but missed several that the installer actually installs: cuda-link (phase4b), its phase4c env vars (CUDALINK_LIB_PATH, CUDALINK_DOORBELL, TORCH_CUDNN_V8_API_ENABLED, SDTD_BASE_FOLDER_PATH), cuda-python, opencv-python, python-osc, and insightface. A broken cuda-link install or a failed setx would previously pass silently. - verifier.py: add 6 VERIFICATION_CHECKS entries (env-var check reads HKCU via winreg since setx doesn't update the current process's os.environ); cuda-link/ insightface self-SKIP off cp311/Windows so they never false-fail elsewhere. Also extend diagnose() version_checks and KNOWN_ERRORS. - tensorrt.py: add verify() covering tensorrt/polygraphy/onnx-graphsurgeon/triton (import) and cudnn/modelopt/cupy/pywin32 (distribution presence), gated by CUDA major version and platform. install() now calls verify() at its tail and returns the verification result instead of an unconditional True, so the separate "Install TensorRT" UI-button step is finally checked (previously it just printed a success message with no verification at all). Verified: extended `sd_installer verify` against the known-good SDTD_040_beta venv (RTX 4090, cu128) - 19/19 checks pass, including the new cuda-link and env-var checks.
No-op on torch 2.8 (cuDNN v8 API is default-on; only the inverse TORCH_CUDNN_V8_API_DISABLED opt-out is read). Traced while debugging why SDTD_L2_PERSIST appeared set unrequested -- both vars came from the same forced per-launch perf-env bundle in StreamDiffusionExt.Startstream. L2 was already fixed via the config-driven l2_persist override (a520fe6); this retires the last inert member: the phase4c setx and its matching verifier assertion. CUDALINK_LIB_PATH/DOORBELL/SDTD_BASE_FOLDER_PATH setx + asserts are untouched.
tensorrt_cu12 ships as an sdist that builds the top-level tensorrt/
wrapper package. On at least one install, the wrapper ended up in a
metadata-only state: dist-info present, tensorrt/ package dir missing.
`import tensorrt` then failed with ModuleNotFoundError even though
tensorrt_cu12_bindings and tensorrt_cu12_libs were both intact, and
re-running install() couldn't self-repair: plain `pip install
tensorrt_cu12==...` reports "already satisfied" and does nothing, so
the broken wrapper was stuck; is_installed("tensorrt") also returned
False, skipping the old-version-uninstall path; verify() detected the
failure but only printed a warning.
Add ensure_wrapper(), called right after each TensorRT install branch:
probe `import <module>` in a fresh subprocess, and if it fails, repair
with `pip install --force-reinstall --no-deps` (rebuilds the wrapper
from sdist without touching the already-good bindings/libs wheels) --
the exact fix that was applied manually to recover a broken install.
Also add a couple of retries to run_pip() to ride out a flaky
pypi.nvidia.com resolve, and invalidate_caches() before verify() so the
in-process import sees a wrapper ensure_wrapper() just rebuilt on disk.
Verified against the real module: simulated the empty-wrapper state
with a throwaway package (present -> broken -> ensure_wrapper repairs
-> present), confirmed no-op on an already-healthy import, and
confirmed run_pip retries transient failures but still raises once
retries are exhausted.
- ensure_wrapper() no longer lets a failed repair pip call raise past install(): cli.py has no try/except around install(), so an exhausted retry would abort before the remaining install steps and verify(), worse than the pre-PR "FAIL: tensorrt" report this PR was fixing. - _import_ok() passes the module name as an argv value instead of interpolating it into `python -c`, closing the injection-shaped f-string Copilot flagged (no live risk today, but the helper is reusable). - Drop tensorrt/polygraphy/onnx_graphsurgeon from sys.modules before verify(), since invalidate_caches() alone doesn't clear already in-process module objects that is_installed() may have imported. Co-Authored-By: Claude Sonnet 5 <[email protected]>
fix: self-heal empty tensorrt_cu12 wrapper + retry flaky pip installs
nvidia-modelopt[onnx]==0.43.0 hard-pins onnxruntime-gpu==1.22.0 on Windows, forcing a downgrade from the setup.py-authoritative 1.24.4 followed immediately by a --no-deps re-pin back to 1.24.4 (~420 MB of wasted download on every fresh TensorRT install). Drop the [onnx] extra and enumerate its (deterministic, version-pinned) deps explicitly with our own onnx/onnxruntime-gpu pins, so 1.22.0 never enters the resolve. Verified via pip --dry-run: all packages "already satisfied" at existing pins, zero onnxruntime-gpu churn. Co-authored-by: Claude Opus 5 <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
20 commits since the last common ancestor (3ba8ec9) -- installer v0.3.2 -> current, covering:
No divergence from dotsimulate/main -- this is a clean fast-forward-style promotion.