[EtienneLescot]

Summary

Multi-GPU DRM render-node selection for the Linux helper and the compositor's VA-API export encoder, split out of #1476 so the vaMapBuffer2 shim can land first. The probing is @PyVoyager's work; their commit keeps their name.

• Export encoder (pipeline_linux.rs): VaapiEncoder::open now opens on the render node of the GPU wgpu renders on, read from VK_EXT_physical_device_drm (Gpu::render_node in d3d_linux.rs). Order: OPENSCREEN_LINUX_RENDER_NODE, then that node. The renderD128..135 scan runs only when the driver does not expose the node (lavapipe, Vulkan 1.0 instance). No new dependency: ash and wgpu-hal are already there.
• Helper (dmabuf_import.rs, encoder.rs): honors OPENSCREEN_LINUX_RENDER_NODE, then probes /dev/dri/renderD128..renderD135. The importer and the encoder walk one candidate list, in the same order, so they pick the same node.
• The Vulkan H.264 queue check runs after the device is created again (it read a null device).

Draft: what is missing

• The helper importer can still open on a GPU other than the desktop compositor's. Its dmabufs come from the Wayland compositor through PipeWire, and nothing the helper receives names the exporting device, so there is no clean source for the right node. Setup on the wrong node succeeds and mapping fails per frame; OPENSCREEN_LINUX_RENDER_NODE stays the workaround.
• Not compiled locally (no Linux reachable). CI's Linux compositor tests and the Nix build are the compile proof.
• Needs a run on a hybrid-GPU Linux machine: the export log should show h264_vaapi on the rendering GPU's node. Plus the evidence the crates/compositor/** and electron/native/** locks ask for.

Related issue

Refs #1340
Follows #1476.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[EtienneLescot]

Hi @PyVoyager, this PR carries your render-node probing, split out of #1476 (your commit keeps your name). CI compiles it, but nobody on our side has a hybrid-GPU Linux machine.

Could you build this branch (fix/linux-render-node-probing, head 415a3b8e) on your Carrizo + discrete laptop and share:

1. the helper log of a short screen recording, without OPENSCREEN_LINUX_RENDER_NODE set;
2. the log of an export of that recording: it should show h264_vaapi opening on the render node of the GPU that renders;
3. whether the recording and the export play back fine.

Thanks a lot for the original write-up!