Supported threading model for updating USD/Fabric off the main thread

Omniverse Core Platform Extensions
1

Operating System:
Windows
Linux
Kit Version:
110 (Kit App Template)
109 (Kit App Template)
108 (Kit App Template)
107 (Kit App Template)
106 (Kit App Template)
105 (Launcher)
Kit Template:
USD Composer
USD Explorer
USD Viewer
Custom
GPU Hardware:
A series (Blackwell)
A series (ADA)
A series
50 series
40 series
30 series
GPU Driver:
Latest
Recommended (573.xx)
Other
I’m benchmarking two implementations of an Omniverse Kit connector (Sdf-layer authoring vs. USDRT/Fabric) for a paper, and I’d like to get the threading guidance right before I finalise the experiments. Could you help clarify a few points?

Setup

  • Kit 110.0.0, Windows, RTX renderer with the Fabric Scene Delegate enabled
  • An in-process extension receives updates from an external simulation (spawn, destroy, attribute updates) and applies them on the main thread
  • USD arm: raw Sdf authoring into the session layer, one Sdf.ChangeBlock per batch
  • USDRT arm: Fabric writes through the USDRT API

Questions

1. Composed stage: Is authoring to an Sdf layer that is part of the composed stage from a non-main thread supported?

2. Detached layer: Is it supported to author deltas into a standalone Sdf layer on a worker thread and apply them on the main thread once per frame? If so, what is the recommended way?

3. Fabric: What is Fabric’s threading model? Is writing attributes through USDRT from a worker thread safe, and what synchronisation with the FSD and render update is required?

4. Best-practice baseline: What does NVIDIA recommend for per-frame dynamic prim updates and spawn/destroy in classic USD (for example ChangeBlock)?

Thanks and Regards

Rashik

2

hey @rashikoz

Thanks for your questions! Let me plug in someone from USDRT team that can help. Appreciate your patience

3

Hi,

1. Composed stage: Is authoring to an Sdf layer that is part of the composed stage from a non-main thread supported?

No, USD itself does not support this. But this can work if no other thread is prevented from reading/writing USD while your non-main thread is writing (kinda defeats the purpose for performance).

2. Detached layer: Is it supported to author deltas into a standalone Sdf layer on a worker thread and apply them on the main thread once per frame? If so, what is the recommended way?

That should work but still needs to be done carefully as some internal states are shared (e.g. TfTokens and SdfPaths creation will aquire locks).

3. Fabric: What is Fabric’s threading model? Is writing attributes through USDRT from a worker thread safe, and what synchronisation with the FSD and render update is required?

Fabric is not thread-safe for writing (same as USD). The Cesium extension provides the best example of complex geometry tile streaming into Fabric: cesium-omniverse/src/core/src at main · CesiumGS/cesium-omniverse · GitHub .

4. Best-practice baseline: What does NVIDIA recommend for per-frame dynamic prim updates and spawn/destroy in classic USD (for example ChangeBlock)?

My main recommendation is to avoid doing this, the least worst way is to rely on a PointInstancer and add/remove instances which is done without actually adding/removing any UsdPrim, just modifying the PointInstancer attributes.

Feel free to check this repo as well:

Hope this helps,

Aloys

4

Hi Aloys,

Thank you for the quick and clear answers, and thanks to Ashley for bringing you in. This settles the threading question for us: we will keep all stage and Fabric writes on the main thread. We’ll use the PointInstancer recommendation and the omniverse-performance repo to define the best-practice USD baseline in our comparison.

Thanks

Rashik