Repository navigation
fix(scene): browser sources paint on the GPU under X11 on Mesa - #73
Conversation
Quest-Claim: 5fea8ca4b0bed1e9
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 6 minutes. View limit details
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. |
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed head 9de4d36 against base c929c40.
No actionable findings. The ANGLE override is confined to Raster::Gpu with Display::X11, after selecting X11 Ozone. The existing Wayland selection, software/headless fallback, render-node override and shared-texture handoff remain unchanged. Selecting the EGL backend is a focused correction rather than adding CPU copies or a timing workaround.
Direction: keep this scoped X11 fix. The retained quests correctly leave Mesa Wayland validation, the no-output initialization hang, allocation-failure reporting and NVIDIA X11 unresolved; this change should not be treated as completing those paths.
Verification limits: GitHub-only static review of all three changed files and surrounding display selection/CEF initialization and paint handling. I did not run quest context, builds, browser tests or hardware trials, independently verify the reported GPU paints, or measure frame time, GPU copies or encoder load. The reported clipboard/cookie failures and headless hangs are not validated or fixed by this review.
(Written by review (OpenAI))
Under X11, CEF allocates shared textures on the device the X server hands out over DRI3, whatever --render-node-override says. With the studio on another GPU, that GPU's tiling came out scrambled while the source still read as copied on the GPU. The studio now asks the X server for its DRI3 device at setup and takes the CPU path, saying why, when it is not the studio's GPU. A page painting into memory now carries why, which the Sources panel shows on hover and Health lists while the program shows the source. On NVIDIA under XWayland, the GPU path already paints since --use-angle=gl-egl (#73), which finishes quest/m0/cef-x11-nvidia.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Problem
quest/m0/cef-headless.md asked whether browser sources paint on the GPU path under a real Mesa desktop session, since its first trial used a headless sway. nixos2 (Intel UHD 630, Mesa 26.2.4, plus an RTX 2070) now logs into GNOME on the Intel GPU, but with no monitor attached.
What the trial found on nixos2:
wl_output. Chromium'sWaylandConnection::Initializekeeps round-tripping until one appears, so CEF'sinitializenever returns (gdb:wl_display_roundtrip_queueunderWaylandConnection::Initialize,wayland_connection.cc:297). No GPU process ever starts, and every page staysStarting. The same happens with the studio on the RTX 2070. So the Wayland path paints only with a display connected, and the Mesa question needs an HDMI dummy plug (see the quest's## Waiting).libGLX_mesa: ANGLE draws through GLX, so nothing lands in the DMA-BUF shared image. This is the "textures import but come back empty" result from the sway trial too. A 500 ms delay before import did not change it, so it is not a sync race.Approach
--use-angle=gl-egl, so ANGLE draws through EGL, as it already does on Wayland. With it, Intel under XWayland paintsPaint::Gpu(Intel X-tiled modifier, imported by ANV).Stop()callsOnStopped(), and CEF'sCefVideoConsumerOSRleavesOnStoppedandOnLogempty.gl-egl. On nixos2's XWayland, CEF also allocated on the Intel GPU that runs the X server, even with the studio on the RTX 2070.Impact
Choices made without asking
wl_outputhang is left in the quest, not fixed here. A setup probe could pick X11 or the CPU path when the Wayland display has no output. That needs a Wayland client inmoq-scene, and fixing it now would change what the pending Mesa trial sees. Recommended: do it in the quest's next PR, alongside the allocation-failure signal.gl-eglonly on X11. Wayland already uses EGL.Alternatives
--use-angle=vulkan: not tried.gl-eglkeeps the GL path Wayland uses and was enough.Validation
Every run was on nixos2 over ssh, in GNOME's session (
XDG_RUNTIME_DIR=/run/user/1000), withVK_DRIVER_FILESset to Mesa'sintel_icd. Each page's paint was printed by a temporaryeprintln!that is not committed.initialize; 0 paintsDISPLAY=:0), Intel, beforeon_accelerated_paint(16)on_paint(19)The X11 run has two failures:
copy_and_cut_reach_the_clipboard: the X11 path keeps CEF's native copy (#59), which goes to the X clipboard, but the test reads only the studio's relay (Helper::copied()). Before this PR the X11 path never painted, so the test never reached that point.cookies_survive_a_restart: also fails on the CPU path, and on a clean checkout ofmain(claim commit 07415d9, CPU path). The page's request reaches the test's loopback server twice, but CEF never paints. Pre-existing.Other checks:
nix develop --command quest gate just cion nixos2 (Linux) at 6172f71: passes, 276 tests.nix develop --command quest gate just cion nixos2 (Linux) at 9b77257 (mainat 299a97a merged in, including the moq pin bump from moq-dev/studio#69): passes, 278 tests.quest checkpasses on macOS. Nothing ran locally on macOS (disk space). Later commits change only quest files and mergemain(a quest-only change).just render-swjob already fails onmain, with helpers exiting on SIGTRAP: run 42235026329.Follow-ups
initialize, never reads the socket's end. Three test runs that hit their timeout left helpers spinning against GNOME until they were killed by hand. Suggested fix:PR_SET_PDEATHSIGon the helper.cookies_survive_a_restartfails on nixos2 on every path, and the nightlyrender-swfails on SIGTRAP.copy_and_cut_reach_the_clipboardcannot pass on the X11 path. Either read the X clipboard there, or say the suite runs only on Wayland and with no display.Review
quest review), gpt-6.1-sol, medium effort.origin/main(299a97a) without conflicts, so this record still counts for it.(Written by Claude Opus 5.5)
🤖 Generated with Claude Code