Skip to content

[Quality][P0] Add deterministic reference-scene visual and GPU performance qualification #128

Description

@proggeramlug

Parent: #126
Related: #24

Problem

Bloom has useful pieces—golden tests, tools/bloom-reference, tools/cycles_reference, realtime examples, and tools/validate.sh—but not one repeatable qualification workflow. tools/validate.sh is report-oriented, reference cameras/configuration are not a versioned contract, and performance measurements can be hidden by vsync or warm-up behavior.

Without a stable corpus, “UE-quality,” “looks better,” and “costs 1 ms” are not independently verifiable claims.

Outcome

A deterministic command and machine-readable result format that compares realtime Bloom output against approved baselines/reference renders across fixed scenes, cameras, quality tiers, motion sequences, and adapters.

Required design

Manifest

Add a versioned manifest (for example tools/quality/scenes.toml) with, per case:

  • scene asset path and content hash/version;
  • camera transform/FOV and optional deterministic camera animation;
  • resolution, warm-up frames, measured frames, seed, timestep, render scale, and quality tier;
  • features required/forbidden;
  • reference image path or generation command;
  • thresholds for SSIM plus a perceptual metric such as FLIP, and targeted masks/metrics where global scores are misleading;
  • CPU/GPU/VRAM budgets and the baseline machine class used for hard gates.

Corpus

Start with:

  • examples/pbr-spheres for BRDF/material lobes;
  • examples/sponza for interior GI, shadowing, leakage, and temporal behavior;
  • examples/bistro for scale, sun/sky, streaming pressure, and exterior materials;
  • DamagedHelmet.glb for canonical glTF material fidelity;
  • one moving skinned + alpha-tested case;
  • one 10k+ draw/meshlet and many-light stress case.

Every scene needs at least one still pose and relevant features need a short motion sequence. Assets that cannot live in Git must be fetched by content hash with a license/source manifest.

Runner and outputs

  • Run uncapped with fixed timestep; exclude startup, shader compilation, and warm-up frames from steady-state timing.
  • Capture named render-graph intermediates through a single debug-capture API.
  • Produce result.json, final/intermediate PNGs, heatmaps, and a compact HTML/Markdown summary.
  • Record commit, dirty flag, build profile, OS, adapter, driver, backend, capability tier, resolution, and all renderer settings.
  • Exit non-zero on hard threshold failure. Support --report-only explicitly for local exploration.

Baseline governance

  • Baseline updates require a command that writes a review bundle, never an implicit overwrite.
  • A PR changing a baseline must include before/after/diff, metric deltas, timing deltas, and a reason.
  • Allow backend-specific baselines only when a documented raster/floating-point difference cannot be normalized.

Acceptance criteria

  • One documented command runs the quick corpus locally; one runs the full corpus on a hardware runner.
  • Re-running an unchanged commit/config on the same machine produces identical metadata and stable metrics within documented noise bounds.
  • The harness detects seeded regressions in BRDF energy, shadow placement, GI leakage, motion history, and texture orientation.
  • Vsync cannot make a performance regression appear unchanged; per-pass GPU timestamps and CPU frame work are reported.
  • CI uploads all evidence on failure and a compact summary on success.
  • The full corpus covers high-end desktop plus at least one constrained tier; unsupported features report their chosen fallback.
  • tools/validate.sh, Lumen follow-up: benchmark harness for SSGI quality / convergence #24, and existing reference tools are reused or superseded with migration notes rather than left as competing workflows.

Likely files

  • tools/validate.sh
  • tools/bloom-reference/
  • tools/cycles_reference/
  • new tools/quality/
  • renderer screenshot/debug-output plumbing under native/shared/src/renderer/
  • .github/workflows/test.yml or a dedicated scheduled/hardware workflow

Verification

The PR must attach one complete result bundle from each available backend and demonstrate an intentional failure.

Non-goals

  • Claiming that one scalar metric captures artistic quality.
  • Hard-gating shared GitHub runners on unstable GPU timing.
  • Checking unlicensed third-party assets into the repository.

Dependencies

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions