Repository navigation
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughAdds configurable Windows software-GPU activation with Chromium switches and environment parsing. Extends crash markers with notification timestamps. Updates startup fallback selection, state tracking, notice presentation, retry handling, marker acknowledgment, and crash breadcrumbs. Adds Vitest coverage for environment parsing, switch application, notice eligibility, notice content, and marker notification persistence. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
15b3a22 to
2bee28b
Compare
|
Valid but we may want to inform the user. Let me think on this a sec |
Sync update (
|
8f345f9 to
354711b
Compare
The existing crash-burst fallback only applied disableHardwareAcceleration + --disable-gpu. On headless virtual adapters (e.g. Sunshine Zako) Chromium still forks a GPU child that STATUS_BREAKPOINT-crashes under those flags, so the relaunch never reaches ready (stablyai#10093). Apply the proven software combo (--in-process-gpu --disable-gpu --use-angle=swiftshader) when the sticky marker engages, and allow ORCA_SOFTWARE_GPU=1 for first-launch opt-in without waiting for a crash burst.
Surface a one-shot info dialog when Windows software GPU / SwiftShader fallback engages, so users know rendering is in a slower stability mode. Marker path notifies on first activation only; env opt-in is once per session.
354711b to
90ffcec
Compare
Sync update (
|
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
|
Thanks @innocarpe for investigating the Windows GPU fallback path. Merged fix #11295 now owns this behavior on current main and deliberately avoids the SwiftShader/in-process combination proposed here, which would broaden privileged parsing of untrusted WebGL content. We will retain your diagnosis as historical credit and request no rebase, retest, or other follow-up. Closing this superseded branch. |
4 participants
Summary
Fixes Windows headless / virtual-display hosts (e.g. Sunshine + Zako) where Chromium's GPU child STATUS_BREAKPOINT-crashes on every launch and Orca never reaches a usable window.
ELI5
When Windows graphics is so broken that Orca keeps dying at startup, Orca now restarts itself in a safer "draw everything in software" mode that actually works on virtual/remote displays — and you can force that mode yourself with an environment variable.
Root cause & fix
Orca's existing crash-burst fallback relaunched with only
disableHardwareAcceleration+--disable-gpu— the exact flags reporters had already tried without success — so the GPU child kept crashing. This PR routes the Windows software-GPU path through the combo proven to reachreadyon those hosts:--disable-gpu+--in-process-gpu+--use-angle=swiftshader, applied beforeapp.whenReady(). It also adds a first-launch opt-in viaORCA_SOFTWARE_GPU=1so operators can skip the crash-burst cycle on known-bad adapters, while preserving the Windows-only, non-serve guard and the sticky-marker path.Evidence
Validated & rebased onto latest main during a bug-bash triage on 2026-07-23. Rebase applied cleanly onto
origin/main.windows-software-gpu.test.tsexercises the fallback combo (disableHardwareAcceleration + disable-gpu + in-process-gpu + use-angle swiftshader) andORCA_SOFTWARE_GPUenv parsing.Cannot find module './windows-software-gpu'(suite fails to load, 0 tests run) — the fix module is net-new, so the failure manifests as module-not-found rather than an assertion diff. Pass-on-branch AND fail-when-reverted = TRUE.npx oxlint src/main/startup/windows-software-gpu.ts src/main/index.ts=> exit 0.Trade-offs
After a GPU crash burst (unchanged 3-crashes/30s window) the software path is stricter (in-process + SwiftShader), so terminal/WebGL may be slower on those already-broken hosts. Healthy GPUs are unaffected;
ORCA_SOFTWARE_GPU=1is opt-in only.Regression risk
Low. Changes are gated behind the existing Windows-only, non-serve guard plus the crash marker or explicit env opt-in; the
!envRequested && !markerearly-return is preserved, so non-Windows and healthy-GPU startup paths are untouched. The passing test proves the new branch behavior.Credit to @innocarpe (Wooseong Kim). Validated, rebased, and hardened via automated bug-bash review; original fix design preserved.