Suppress OVRTX API deprecation warnings

[mataylor-nvidia]

Description

Add flag for upstream OVRTX to suppress deprecation warnings

Fixes # (103440)

Type of change

• Bug fix (non-breaking change which fixes an issue)

Screenshots

Please attach before and after screenshots of the change if applicable.

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

[greptile-apps]

Too many files changed for review (2800 files, 100 file limit).

[isaaclab-review-bot]

Isaac Lab Review Bot

The PR conditionally suppresses noisy OVRTX initialization and teardown logs and adds the required isaaclab_ov changelog fragment. However, legacy multi-environment initialization re-enters the same single-use force_log_level context manager, which can abort initialization.

• Design and architecture: Containing third-party log suppression around specific OVRTX calls is appropriately scoped, but the initialization path must not retain and reuse a single-use generator context manager across separate operation groups.
• API: No public symbols or signatures change. The observable change is limited to OVRTX logging verbosity during legacy initialization and teardown, and the changelog fragment correctly documents it under Fixed.
• Implementation: The teardown path creates a fresh suppression context for reset_stage, but _initialize_from_spec_legacy creates _level_ctx once and enters it around both stage loading and multi-environment cloning. When force_log_level is selected, the second entry is invalid. Construct a fresh context for each block or place both groups under one context.

Significant concerns. Posted 1 actionable finding inline.

Automated review; human maintainers own approval decisions.

[huidongc]

Did you try Python warnings.filterwarnings("ignore", category=DeprecationWarning)? How does it work?

[AntoineRichard]

Could we get PR descriptions? I noticed it's not the first time they are missing :)

In general I'm wondering if we could avoid generating these deprecation warnings? My concern is that this could suppress things that we care about.

[AntoineRichard]

I tested this on PR head b673b7fcc42e in a fresh Python 3.12 uv environment with ovrtx==0.4.0.346409 on an RTX 5090.

The legacy calls emit each deprecation twice through two independent paths:

1. Python emits a real DeprecationWarning from the Renderer.open_usd_from_string / Renderer.reset_stage decorators.
2. Native OVRTX emits a Carbonite [Warning] [omni.rtx] message for ovrtx_open_usd_from_string / ovrtx_reset_stage.

I also emitted unrelated Python warnings and direct native stdout/stderr control messages in each trial to detect collateral suppression.

Approach	Python OVRTX deprecations	Native OVRTX deprecations	Collateral behavior
Broad Python DeprecationWarning filter	Suppressed	Remain	Also hides unrelated Python deprecations
Message-targeted Python filter	Suppressed	Remain	Preserves unrelated warnings and stdout/stderr
PR fd-1 redirect	Remain	Remain in this run	Discards unrelated process-wide stdout
RendererConfig(log_level="error")	Remain	Suppressed	Hides every native warning
Carbonite omni.rtx=error	Remain	Suppressed	Hides every omni.rtx warning, but preserves errors and other channels
Targeted Python filter + omni.rtx=error	Suppressed	Suppressed	Still hides all other omni.rtx warnings

Important observations:

• The PR fd-1 redirect removed the unrelated native stdout control message, demonstrating that it suppresses more than OVRTX. It did not remove either native OVRTX deprecation in my run because Carbonite delivered those messages asynchronously after the context restored fd 1.
• The omni.rtx=error trial preserved omni.rtx errors during a forced GPU initialization failure and preserved a warning from the separate omni.platforminfo.plugin channel. However, useful omni.rtx warnings such as the CPU governor and IOMMU diagnostics disappeared.
• The current public Python RendererConfig exposes the global log_level, but not Carbonite channel rules.

My clear suggestion is:

1. Remove suppress_native_logging() and the fd-redirection call sites from this PR. The behavior is process-wide, can hide unrelated concurrent output, and is unreliable with asynchronous Carbonite delivery.
2. If removing the duplicate Python layer is still useful, use a scoped message-specific DeprecationWarning filter for only Renderer.open_usd_from_string and Renderer.reset_stage.
3. Do not set omni.rtx=error in Isaac Lab as the final solution, because it still suppresses warnings we may care about. The native duplicate should instead be addressed in OVRTX, ideally by avoiding duplicate Python/native deprecation reporting or by exposing a message-specific filtering mechanism.
4. Longer term, migrate the remaining legacy path to the already available ovstage APIs, which is the migration requested by the deprecation itself.

Until the native side offers narrower control or the legacy path is migrated, keeping the native deprecation visible is safer than suppressing the entire output stream or the whole omni.rtx warning channel.

[AntoineRichard]

For reference, this is the narrowly targeted Python option I tested:

import contextlib
import warnings


@contextlib.contextmanager
def _suppress_ovrtx_legacy_python_deprecations():
    with warnings.catch_warnings():
        warnings.filterwarnings(
            "ignore",
            message=r"Renderer\.(open_usd_from_string|reset_stage) is deprecated in ovrtx 0\.4\.",
            category=DeprecationWarning,
        )
        yield

It can be scoped directly around the two legacy calls:

with _suppress_ovrtx_legacy_python_deprecations():
    self._renderer.open_usd_from_string(combined_usd_string)

# ...

with _suppress_ovrtx_legacy_python_deprecations():
    self._renderer.reset_stage()

The message regex is important: unlike a blanket category=DeprecationWarning filter, this preserved an unrelated DeprecationWarning in the same block during my probe.

This only suppresses the Python decorator warnings. The native Carbonite duplicates still appear. For comparison, the per-channel experiment used the following OVRTX Carbonite configuration:

{
  "log": {
    "channels": {
      "omni.rtx": "error"
    }
  }
}

That retained omni.rtx errors and warnings from other channels, but removed every warning from omni.rtx, not only the deprecations. It therefore demonstrates that channel filtering works, but I would not recommend shipping that rule as the final Isaac Lab fix. The preferable native-side solution is for OVRTX to avoid the duplicate native warning or expose a narrower filter.

[AntoineRichard]

See my AI's comments, I would not merge as is.

[AntoineRichard]

@mataylor-nvidia what's the status on this?

[mataylor-nvidia]

Did you try Python warnings.filterwarnings("ignore", category=DeprecationWarning)? How does it work?

Yes tried this it does not work :(

outdated

[mataylor-nvidia]

I tested your suggestion @AntoineRichard but it was not work after the addition of the IsaacLab Loading screen