Add a physics-plus-render mode to the render benchmark

[mataylor-nvidia]

Description

Follow-up to #7702. That PR added the Isaac-RenderBenchmark-Franka-Cabinet task, whose scene is always driven through the physics solver. This adds a mode switch so the same scene can be benchmarked with or without the solver doing that actuation work, plus a physics timer so what physics costs is visible either way.

• source/isaaclab/isaaclab/sim/simulation_context.py: adds PHYSICS_PROFILE_SCOPE around the physics step in SimulationContext.step, gated by the ISAACLAB_PHYSICS_PROFILE environment variable. This mirrors the existing ISAACLAB_RENDER_PROFILE timer added by Added Rendering Benchmark #7702 — same scope-name-per-backend approach, same wp.ScopedTimer print format — and is off by default, so an ordinary run pays neither the print nor the device synchronization.
• source/isaaclab_tasks/.../render_benchmark_env_cfg.py: new benchmark_mode field ("render" | "physics_render"), read from the BENCHMARK_MODE environment variable and rejecting unknown values at import, so a typo fails at launch instead of quietly benchmarking the default for a whole sweep.
• source/isaaclab_tasks/.../render_benchmark_env.py: _animate_joints picks its drive path from the mode. "physics_render" requests the sinusoid as actuator position targets, which is what the task did before. "render" instead writes the joint positions and zero velocities straight into the simulation.
• scripts/benchmarks/benchmark_renderer.py: turns the physics timer on for every run, the same way Added Rendering Benchmark #7702 turns on the render timer, and declares the scope name and its log pattern. The script's parsing and reporting are untouched — physics timings land in the run log next to the render ones.

uv run --no-sync python scripts/benchmarks/benchmark_renderer.py newton_*
BENCHMARK_MODE=physics_render uv run --no-sync python scripts/benchmarks/benchmark_renderer.py newton_*

Note that the physics backend still integrates in "render" mode, because an Isaac Lab environment has no way to skip its own physics step; the mode changes how the joints are driven, not whether the step happens.

Known issue

Greptile and the Isaac Lab review bot both flagged the same defect in "render" mode, and they are right: _animate_joints runs from _pre_physics_step, so the direct joint write is followed by decimation physics steps before the camera is read. The implicit actuator drives are still active with their previous targets, and gravity and joint limits also apply, so the rendered frame is the post-step state rather than the analytic sinusoid the docstrings currently claim. The fix is to either apply the pose after physics and before the render, or soften the documented contract. Not yet addressed — do not merge as-is.

Type of change

• New feature (non-breaking change which adds functionality)

Release backport

• Backport this pull request to the active release branch after it merges into develop

Checklist

• I have read and understood the contribution guidelines
• I have run the pre-commit checks with ./isaaclab.sh --format
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• I have added a changelog fragment under source/<pkg>/changelog.d/ for every touched package
• I have added my name to the CONTRIBUTORS.md or my name already exists there

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; the current changes address both previously reported render-pose and stale-transform defects without introducing a new actionable issue.

Summary

This PR adds separate render and physics-plus-render benchmark modes, introduces opt-in synchronized physics-step profiling, and extends benchmark reporting with per-frame physics and combined timing statistics.

• Direct render-mode poses are now applied after physics and explicitly propagated before the camera read.
• Renderer scene-state cadence is invalidated so the direct pose reaches the next lazy camera render.
• Physics timings are accumulated across decimated steps and reported alongside render and total timings.
• Configuration, lifecycle, parsing, and mode ordering receive focused tests.

Diagram

sequenceDiagram
    participant E as Benchmark environment
    participant P as Physics backend
    participant S as Simulation context
    participant R as Render context
    participant C as Camera

    E->>P: Run decimated physics steps
    S->>S: Record physics-step timings
    alt render mode
        E->>P: Write analytic joint pose and zero velocity
        E->>S: forward()
        E->>R: Reset scene-state cadence
    else physics_render mode
        E->>P: Set actuator targets before physics
    end
    E->>C: Read lazy camera output
    C->>R: Synchronize scene and render
    R->>R: Record render timing

Loading

_{Reviews (4) · Last reviewed commit: "Parse every timed scope out of a run log..."}

[isaaclab-review-bot]

Isaac Lab Review Bot

The physics-plus-render benchmark plumbing is coherent, but render mode writes the analytic joint pose before the environment’s decimated physics steps. The camera therefore observes a subsequently integrated state rather than necessarily the exact pose promised by the new documentation.

• Design and architecture: The mode switch and profiling scope are consistently connected across task configuration, environment behavior, subprocess environment variables, timing parsing, and reporting. However, the render-mode design does not fully isolate the rendered pose from physics because the direct state write occurs in _pre_physics_step, before physics integration.
• API: The new mode values, profiling scope, CLI option, and additive JSON fields are kept consistent and covered by tests. The documented contract for benchmark_mode="render" overstates the behavior by claiming the rendered scene is exactly the analytic sinusoid even though physics steps occur after the direct write.
• Implementation: Physics timings are accumulated across decimated steps and paired with each render timing appropriately. The render-mode state path needs adjustment: apply the direct pose immediately before rendering if exact analytic poses are required, or revise the documentation and benchmark claims to describe the post-integration pose accurately.

Minor fixes needed. Posted 1 actionable finding inline.

Automated review; human maintainers own approval decisions.

[mataylor-nvidia]

@greptile review

[mataylor-nvidia]

@greptile review

[mataylor-nvidia]

run-ci

[daniela-hase]

PHYSICS_SCOPE and PHYSICS_SCOPE_PATTERN seems to not be used anywhere, is that right?

[mataylor-nvidia]

I've updated parse_log -> parse_frames to ingest these

[mataylor-nvidia]

@greptile review

[mataylor-nvidia]

run-ci