Skip to content

Hardware-WebGL jobs can skip Xvfb while recording still needs a display #21

Description

@p-forghani

Hardware-WebGL fleet jobs currently disable the Xvfb setup, but the playtest path still starts recorded headed Chromium.

Current behavior:

  • ops/orchestrate-playtests.js marks hardware-sensitive games with requiresHardwareWebgl.
  • It also sets audioXvfb = false for those jobs.
  • ops/remote/run-playtest.js then skips starting Xvfb when audioXvfb === false.
  • The playtest path still uses record: true and headless: false, and GStreamer records from an X11 display.

Why this matters:

On a worker that already has a usable DISPLAY, videos may still work. On a fresh worker without another display server, headed Chrome or GStreamer can fail before the WebGL renderer gate gives a clear result. That makes hardware-WebGL jobs environment-dependent and can turn a hardware capability problem into a generic browser/recording startup failure.

Expected:

Hardware-WebGL jobs should have an explicit display strategy for recorded headed playback. For example, start Xvfb like other recorded jobs and then rely on the existing WebGL renderer gate to fail workers that still report SwiftShader, or document/support a real Xorg/GPU-backed display path if Xvfb cannot satisfy the hardware-WebGL requirement.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions