Skip to content

Recover on CPU after CUDA inference failure - #2

Merged
Pedrojok01 merged 4 commits into
Pedrojok01:mainfrom
Slavenin:fix/gpu-inference-cpu-fallback
Aug 23, 2026
Merged

Recover on CPU after CUDA inference failure#2
Pedrojok01 merged 4 commits into
Pedrojok01:mainfrom
Slavenin:fix/gpu-inference-cpu-fallback

Conversation

@Slavenin

Copy link
Copy Markdown
Contributor

Problem

A CUDA execution provider can accept a session at startup but fail only when the first model kernel runs.

This happens with CUDA provider builds that do not contain a kernel image for a newer GPU architecture. For example, RTX 50 / Blackwell GPUs (SM 120) can fail with:

CUDA error cudaErrorNoKernelImageForDevice:
no kernel image is available for execution on the device

Before this change, LinuxBroadcast logged the inference error and dropped every subsequent frame, leaving the virtual camera without usable output.

Changes

  • Retain the selected ONNX model bytes in the feeder.

  • When GPU inference fails, rebuild the segmenter with the CPU execution provider.

  • Retry the frame that triggered the GPU error on CPU, so the virtual camera continues immediately.

  • Publish the live backend state from the feeder to the Pipeline and GUI.

  • Show a persistent GPU unavailable · CPU footer badge after recovery.

    • The original technical error is available in the badge hover text.
  • Log an explicit warning explaining that GPU acceleration was disabled and CPU processing is now active.

  • Document the RTX 50 / Blackwell limitation and the requirement for a custom ONNX Runtime CUDA provider built with CMAKE_CUDA_ARCHITECTURES=120 (or native).

The fallback is intentionally not limited to Blackwell. Session creation alone does not prove that a CUDA provider can execute every model kernel, so any delayed GPU inference failure is recovered the same way.

Validation

  • cargo test --workspace

    • 65 tests passed
    • 1 test ignored
  • Manually reproduced on an RTX 5070:

    • CUDA session initialization succeeded.
    • The first RVM inference failed with cudaErrorNoKernelImageForDevice.
    • LinuxBroadcast logged the fallback warning.
    • Processing continued successfully on CPU.

Example log after this change:

[WARN lb_pipeline::lazy] GPU acceleration was disabled after an inference error;
LinuxBroadcast is now using CPU. ort run rvm: ... cudaErrorNoKernelImageForDevice ...
To restore GPU acceleration, install an ONNX Runtime CUDA provider built for this GPU.

Issue #1

@Pedrojok01 Pedrojok01 linked an issue Aug 23, 2026 that may be closed by this pull request
@Pedrojok01 Pedrojok01 added the bug Something isn't working label Aug 23, 2026
Pedrojok01 and others added 2 commits August 23, 2026 22:02
The three-element handle tuple trips clippy::type_complexity, which is
denied in CI. Introduce a FeederHandles alias for it.

The alias sits above spawn_feeder's doc comment: placing it directly
above the fn separates the existing #[allow(clippy::too_many_arguments)]
from its target.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018MH5oQSAY4LyjHrreceGw6

@Pedrojok01 Pedrojok01 left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, thank you for the fix!
LGTM

@Pedrojok01
Pedrojok01 merged commit 103bac7 into Pedrojok01:main Aug 23, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Background replacement doesn't work

3 participants