Add opt-in async OVRTX rendering

[pv-nvidia]

Description

Adds an opt-in asynchronous render path to the OVRTX renderer, so rendering can overlap with simulation and Python work. It is off by default (async_rendering=False), leaving existing behavior unchanged.

What this adds

A single on/off switch, OVRTXRendererCfg.async_rendering (default False):

• False: synchronous rendering.
• True: asynchronous rendering. Each render() submits the render and returns immediately, so rendering overlaps simulation and Python work; camera outputs arrive one frame later. The first frame after (re)initialization is consumed synchronously so the first camera read returns a valid frame instead of the zero-initialized buffer.

Internally the renderer delegates frame execution to a _RenderStrategy pair: _SyncRenderStrategy writes transforms straight into OVRTX and consumes each step inline, while _AsyncRenderStrategy pipelines steps and double-buffers transform staging. The async strategy is created only when async is enabled, so sync call sites carry no branching.

Async works on both scene-ownership paths. Under ovstage the renderer borrows the stage's storage, so each ovstage scene write first settles any render still in flight.

Two environment variables support testing and benchmarking:

• OVRTX_ASYNC_RENDERING overrides async_rendering (0/false/no/off disable, any other non-empty value enables). This is the only task-agnostic switch; a Hydra override such as env.scene.base_camera.renderer_cfg.async_rendering=True names a camera that a given task may not define.
• OVRTX_NUM_BUFFERS sets the render queue depth: renders kept in flight before the oldest is drained (default 2, values below 2 are clamped). Larger values overlap more simulation at the cost of extra frames of camera latency.

Camera-output read ordering

Also improves camera-output throughput for synchronous rendering as well as asynchronous. OVRTX waits for render completion with a GPU-side wait on the CUDA default stream, which on Linux hits a driver GPU-context scheduling issue that runs most of the graphics work while the render-output copy waits. Camera outputs are now read without a GPU-side wait, with the calling thread waiting instead — roughly 30% higher throughput on a camera task on Linux, and slightly faster on Windows too.

Two variables select how the read is ordered against the render: ISAAC_LAB_OVRTX_RENDER_VAR_SYNC_STREAM picks the GPU-side barrier (0 default/none, default, or warp), and ISAAC_LAB_OVRTX_RENDER_VAR_MAP_WAIT (default 1) toggles the host-side wait. Selecting neither would race the render and is rejected.

Correctness

The async path is covered by golden-image tests that reuse the synchronous goldens, since async output must match within the existing SSIM / pixel-difference tolerances: test_rendering_cartpole_kitless.py::test_rendering_cartpole_kitless_async for both kitless physics backends (ovphysx, newton). Per-env tolerances are declared as [sync, async] and resolved through max_different_pixels_percentage_for(), guarded by test_rendering_tolerance_lookup.py.

Unit tests cover the pieces that are hard to observe end to end:

• test_ovrtx_scene_write_barrier.py — an ovstage scene write settles in-flight renders, and delivery targets the correct frame's buffers.
• test_ovrtx_scene_backend_binding.py — every scene operation resolves to the selected backend, with no unpaired implementation.
• test_ovrtx_strategy_selection.py, test_ovrtx_render_ordinal.py, test_ovrtx_strategy_drain_state.py, test_ovrtx_async_teardown.py.

The isaaclab_ov suite passes (164 tests), including the clone-plan tests after the async-state refactor.

Benchmarks

Measured with the RSL-RL training benchmark (scripts/benchmarks/training.py) with training in the loop (real PPO updates, not just environment stepping) on the KukaAllegro lift camera task — a manipulation task with per-env RGB cameras, so representative of a real training workload rather than a rendering microbenchmark.

FPS is RSL-RL Perf/total_fps (whole training step, including the policy update); collection FPS is the rollout phase where rendering runs. Single runs with schema output — treat as throughput signals.

Benchmark provenance:

• GPU: NVIDIA L40
• OVRTX: 0.3.0.312915
• Task: Isaac-Lift-KukaAllegro-Camera, 4096 envs, seed 42, 200 iterations
• Selectors: physics=newton_mjwarp renderer=ovrtx presets=rgb64

KukaAllegro lift camera (RSL-RL, training in the loop)

metric	sync	async	speedup
total FPS (mean)	31,864	45,545	1.43x
collection FPS (mean)	33,663	50,199	1.49x

End-to-end training throughput improves ~1.43x; the rollout phase, where rendering overlaps simulation, improves ~1.49x. A per-phase profile of this task shows rendering is ~63% of the iteration, so overlapping it with the remaining ~37% of non-render work is where the gain comes from.

Command (prefix with OVRTX_ASYNC_RENDERING=1 for async, OVRTX_ASYNC_RENDERING=0 for sync):

OVRTX_ASYNC_RENDERING=1 python scripts/benchmarks/training.py \
    --rl_library rsl_rl \
    --task Isaac-Lift-KukaAllegro-Camera \
    --seed 42 \
    --max_iterations 200 \
    --benchmark_formatter schema \
    --output_path ./results/kuka_<sync_or_async> \
    --headless \
    physics=newton_mjwarp renderer=ovrtx presets=rgb64

Enabling async adds one frame of camera latency.

Type of change

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

Screenshots

Not applicable — performance/API change with no visual UI. Async RGB output is validated against the sync goldens by the correctness tests above.

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 (do not edit CHANGELOG.rst or bump extension.toml — CI handles that)
• I have added my name to the CONTRIBUTORS.md or my name already exists there

affected files were reverted, features already on develop

[pv-nvidia]

This change was not needed

[pv-nvidia]

This code was deleted, where did it end up?