fix: scale FabricFrameView selections to the view, not the stage

[pv-nvidia]

Description

Camera world-pose resolution stalled at high environment counts on the PhysX backend, badly enough to time out benchmarks. There are two independent bottlenecks, one per commit.

1. FabricFrameView resolved prim paths on the host, against the whole stage

Cameras read their poses from Fabric. To do that the frame view needs to know where each camera's data sits in Fabric memory, so it builds a lookup table from "camera number" to "Fabric slot".

Building that table was very slow. The view selected prims by requiring the Fabric world and local matrix attributes — but every xformable in the stage carries those, so the selection matched the entire stage (~1.1M prims at 8192 environments), not the view's handful of cameras. Finding its own prims in that list then meant building a Python dictionary over all of it, on the host:

path_to_idx = {str(p): i for i, p in enumerate(selection.GetPaths())}

That ran twice per rebuild (once for the children, once for their parents), and rebuilt whenever PrepareForReuse() reported a bucket change — in practice on every environment reset.

Two costs follow. The obvious one is that the work scales with the size of the whole scene. The less obvious one is that it creates a very large number of short-lived Python objects, stressing the garbage collector.

Fix: author a private per-view uint index attribute on each managed prim (and on each unique parent), holding that prim's view index. Every selection requires the matching index attribute, so selections resolve to exactly the view's prims. The view-to-Fabric slot mapping is then rebuilt by inverting that attribute in a single Warp kernel launch:

fabric_slots[view_indices[fabric_slot]] = fabric_slot

That is O(view) device work with no host-side path resolution and no Python objects created per frame.

There is also no cache, so there is nothing to invalidate. The table is rebuilt from live Fabric data on every access, which means a bucket reorder can never leave a stale mapping behind. Selections are still checked with GetCount(), which is exact here: the index attribute belongs to one view, so the count can only change if one of that view's prims actually disappeared — and then the view raises a clear error instead of silently reading the wrong prim.

Attribute names embed a process-wide monotonic uid, so a dead view's leftover attributes can never satisfy a live view's selection. Parent reads get their own read-only selection, keeping the child RO/RW flip semantics from #5677 intact.

2. SceneDataProvider.create_mapping did a linear scan per item

for i, path in enumerate(input_paths):
    mapping[i] = paths.index(path)   # O(N) scan, per path

Fix: build the reverse dict once (first occurrence wins, matching list.index semantics), then resolve each path in O(1).

How the problem was found

The stall was invisible in Tracy. Comparing captures before and after the commit that introduced it, Kit's own per-frame work is unchanged — App Update totals 65.1 s before and 62.3 s after, over ~120 frames. All the lost time sits in the gaps between frames, where the main thread is blocked in Python and Kit records nothing.

A py-spy capture found the cause: _compute_fabric_indices_for accounted for 11.86% of samples and the garbage collector for a further 1.47%, reached through camera.reset() → get_world_poses().

Fixes nvbug 6535498.

Type of change

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

Benchmarks

End-to-end symptom

Task Isaac-Lift-KukaAllegro-Camera, 8192 environments, presets=physx,isaacsim_rtx_renderer,duo_camera. Commit 69888c34e471 (which introduced the problem) against its parent e5f99d320338:

	Parent	With the problem
Mean environment step	699 ms	7193 ms
Slow steps (over 3 s)	1 of 100	28 of 100, averaging 18.9 s
GPU utilization	23.4%	4.7%

GPU and CPU utilization both drop during the slow steps, which is what a stall looks like — the pipeline is waiting, not doing extra work.

Selection size — the actual fix

L40, cuda:0, 1024-prim view (1024 children + 1024 parents). "Filler" is xformable prims not in the view but carrying Fabric matrices — i.e. the rest of a real scene.

filler prims	develop selection	this PR
0	2,048	1,024
10,000	12,048	1,024
100,000	102,048	1,024

develop scales with the stage; this PR is pinned to the view.

Slot-mapping rebuild (mean ms, the path hit on every reset)

filler prims	develop child	develop parent	develop full RO rebuild	PR child	PR parent
0	4.67	5.40	10.24	0.137	0.191
10,000	24.05	24.69	62.47	0.139	0.193
100,000	274.21	270.47	556.41	0.137	0.190

develop grows linearly with stage size — 556 ms per rebuild at 100k filler prims. This PR is flat at ~0.14 ms, a ~2000× reduction, and unchanged from 0 to 100k filler prims. First access at 100k filler: 1824 ms → 383 ms.

create_mapping (pure Python, reversed path order)

N	develop	this PR	speedup
1,000	0.0038 s	0.0001 s	27×
5,000	0.0862 s	0.0007 s	120×
20,000	1.3241 s	0.0030 s	434×
50,000	8.5507 s	0.0092 s	929×
200,000	(not run)	0.0467 s	—

Outputs verified identical at every N. At the ~200k rigid bodies of an 8192-environment scene the old path takes minutes.

Tests

Suite	Result
isaaclab_physx/test/sim/test_views_xform_prim_fabric.py	77 passed, 4 skipped
isaaclab/test/sim/test_views_xform_prim.py (USD contract)	63 passed
isaaclab_newton/test/sim/test_views_xform_prim_newton.py	58 passed
isaaclab/test/sensors/test_camera.py (main consumer)	35 passed
isaaclab/test/utils/warp/test_proxy_array.py	81 passed

New: test_selections_match_only_the_view_prims asserts each selection matches exactly the prims the view manages. Verified that it fails without the fix — with the selections unscoped it reports matched 8 prims, expected 4, because the child selections pick up the parents too.

test_fabric_rebuild_after_topology_change was updated to drive the new refresh paths (both child selections plus the parent selection) instead of the removed _rebuild_{ro,rw}_arrays.

The 4 skips are environmental: empty device parameter sets, and Fabric hierarchy bindings that are unavailable in a headless experience.

Coverage gap: test_physx_scene_data_backend.py and test_ovphysx_scene_data_backend.py both skip at collection on the machine used here, so the create_mapping change is exercised only by the standalone benchmark above, not by the test suite. Worth a look in CI, where those backends are available.

Screenshots

Not applicable — no visual change. The benchmarks above cover the behaviour change.

Notes for reviewers

Index attributes are never removed, and they accumulate. _initialize_fabric authors the index attribute but nothing drops it, so every view over the same prims leaves another uint behind. Measured over 8 successive views on one stage (512 prims), attributes on a single prim went 1 → 8 and first-access rose monotonically from 120 ms to 173 ms; construction and rebuild times stayed flat. The uid scheme keeps this correct, but it is a per-stage leak that grows with view churn. Worth deciding whether the view should remove its attributes on teardown — there is currently no __del__ / close hook.

Relationship to #6554

#6554 found the same two slow paths. This PR takes its SceneDataProvider fix unchanged (credited with a Co-authored-by line) and replaces its Fabric frame view fix.

#6554 kept the whole-stage selection and the Python dictionary, and cached the result, reusing it while the number of selected prims stayed the same. Two problems with that. The cache key is unsafe: an equal prim count does not mean the prims or their order stayed the same, so after a bucket reorder or a same-count membership change the cached indices point at the wrong prims and cameras silently read another prim's transform. And it treats the symptom — the underlying operation is still proportional to the size of the whole scene, just performed less often.

Making the selection small removes the need for a cache at all, so both problems go away.

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]

Greptile Summary

This PR replaces stage-wide host path resolution with per-view Fabric index attributes and GPU-built slot mappings, while also making scene-data path mapping linear rather than quadratic.

• Scopes child and parent Fabric selections using private per-view index attributes.
• Reconstructs view-to-Fabric slot mappings from live selection data on each access.
• Optimizes SceneDataProvider.create_mapping with a first-occurrence reverse dictionary.
• Adds focused selection-size and topology-refresh coverage plus changelog entries.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete changed-code defect identified.

The new mappings preserve existing path semantics, and the Fabric access paths rebuild scoped slot maps before use without exposing retained indexed arrays to subsequent buffer refreshes.

Important Files Changed

Filename	Overview
source/isaaclab_physx/isaaclab_physx/sim/views/fabric_frame_view.py	Replaces whole-stage path lookup with tagged child and parent selections whose slot mappings are rebuilt on-device.
source/isaaclab/isaaclab/utils/warp/fabric.py	Adds kernels that invert per-view indices and gather parent Fabric slots.
source/isaaclab/isaaclab/scene_data/scene_data_provider.py	Preserves first-occurrence lookup semantics while reducing mapping construction from quadratic to linear time.
source/isaaclab_physx/test/sim/test_views_xform_prim_fabric.py	Updates topology-refresh coverage and verifies that selections contain only the view’s managed prims.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  V[FabricFrameView prim paths] --> T[Author per-view child and parent indices]
  T --> S[Scoped Fabric selections]
  S --> K[Warp kernels invert indices into Fabric slots]
  K --> I[Indexed Fabric matrix arrays]
  I --> P[Camera and frame pose reads]
  B[Backend transform paths] --> D[First-occurrence reverse dictionary]
  O[Requested output paths] --> D
  D --> M[Linear transform mapping]

Loading

_{Reviews (1): Last reviewed commit: "Removed comment" | Re-trigger Greptile}

[isaaclab-review-bot]

Isaac Lab Review Bot

The scoped Fabric selections and device-side slot mapping remove the whole-stage lookup bottleneck, while SceneDataProvider.create_mapping preserves first-occurrence semantics with linear-time construction. One maintainability and performance issue remains: each recreated view permanently leaves uniquely named Fabric index attributes on its prims.

• Design and architecture: Per-view tagged selections avoid host-side path resolution and stale mapping caches, but they introduce persistent per-view stage state without a lifecycle or reclamation mechanism. Repeated view creation therefore accumulates attributes and progressively increases initialization cost.
• API: create_mapping retains its documented behavior: first occurrence wins, unmatched paths map to -1, and identity mappings return None. Removed FabricFrameView helpers and fields are private, and the in-repository test consumer was migrated. A cleanup API or an explicitly documented one-view-per-stage lifetime contract is needed for the new authored attributes.
• Implementation: The child and parent tagging, scoped selections, count checks, and Warp mapping refresh paths are internally consistent. However, _initialize_fabric creates UID-suffixed attributes on managed prims and parents without any teardown path, so recreating views on a long-lived stage permanently widens Fabric state and measurably slows later initialization.

Minor fixes needed. Posted 1 actionable finding inline.

Automated review; human maintainers own approval decisions.

[isaaclab-review-bot]

🟡 Warning · Design Architecture — Per-view index attributes are never removed

_initialize_fabric authors two uid-suffixed uint attributes on every managed prim and unique parent, and no code path deletes them. Since the uid counter never reuses names, each view recreated over the same prims on a long-lived stage permanently adds another attribute pair, widening those prims' Fabric buckets and slowing subsequent view initialization. Add a teardown (explicit close/lifecycle hook) that drops this view's index attributes, or document the one-view-per-stage lifetime requirement.

[pv-nvidia]

No need to split all parts, we just need the last part! This can be optimized

[pv-nvidia]

We should cache _parent_path(p) for p in self.prim_paths) because we call _parent_path again later

[pv-nvidia]

Here we should use the earlier cached parent paths

[pv-nvidia]

Do we need this check at all?

Two cases exists here:

1. we have duplicate entries in the input_path. One of them will not be handled, which results in incorrect behavior either way
2. we have None or invalid paths. That will result in negative indices and the kernels won't like that, they will crash or give undefined behavior.

So it doesn't matter what we do, pick the first or last, we will get incorrect behavior anyway. So we better pick the most performant form. So could be just a dict comprehension