[Proposal] Keep Newton MPM particle updates GPU-resident in Kit RTX

[maxkra15]

Proposal

Keep Newton MPM particle-position updates GPU-resident when Kit/Isaac RTX renders the simulation, and skip the shared CPU USD mirror for render paths that ingest Newton state directly.

Today the image is visually correct, but NewtonManager._sync_particle_points_prims() calls state_0.particle_q.numpy(), builds host Vt.Vec3fArray values, and writes UsdGeom.Points.points through pxr on every due render frame. For CUDA MPM this introduces a device-to-host readback, synchronization point, allocation, and CPU USD authoring.

Add a supported GPU update path from Newton CUDA particle_q to the registered MPM Points consumed by Kit RTX. Retain a CPU fallback where GPU Fabric/RTX point updates are unavailable.

Motivation

Large MPM scenes update many particle positions every frame, so the host round trip can dominate visualization cost and break an otherwise device-resident simulation loop.

The OVRTX renderer already hands aliased CUDA particle slices directly to its Points binding with producer-stream ordering. However, the shared Newton pre_render() sync is currently unconditional, so direct render paths can still pay the redundant CPU mirror before their own update.

This is separate from #7758: that issue tracks reusing the authored simulation Points and removing the duplicate <asset>/Particles prim; this issue tracks GPU transport regardless of which Points prim is used. Related implementation context: #7637.

Alternatives

Keep the existing CPU USD path and increase visual_update_frequency. This reduces update frequency but does not remove the host readback or CPU authoring cost.

Build Info

• Isaac Lab Version: develop / PR Author Newton MPM particles through USD #7637
• Isaac Sim Version: 6.1
• Newton Version: 1.6.0rc1

Additional context

OVRTX GPU-ingest work provides a useful reference in #6664 and #7157.

Checklist

• I have checked that there is no similar issue in the repo (required)

Acceptance Criteria

• Steady-state CUDA + Kit RTX MPM updates do not call particle_q.numpy(), construct host Vt point arrays, or author Points through host-side Usd.Attribute.Set.
• Registered MPM Points receive positions through a supported GPU Fabric/RTX path, with a CPU fallback for unsupported configurations.
• Direct GPU consumers such as OVRTX do not execute the redundant shared CPU particle mirror.
• Homogeneous and heterogeneous clones, multiple MPM assets, resets, and explicit state writes update the correct particle ranges and transforms.
• Widths, colors, materials, visibility, and visual_update_frequency behavior remain unchanged.
• Kit RTX moving-particle rendering coverage remains visually equivalent, and profiling shows no particle-position device-to-host transfer at render cadence.
• The solution is coordinated with [Proposal] Reuse authored Newton MPM Points as dynamic render targets #7758 so prim ownership and GPU transport can evolve independently.