npx skills add ...
npx skills add nvidia/omniperf --skill diagnose-perf
First-responder performance triage for Isaac Sim and Isaac Lab. Identifies bottleneck category (GPU-bound, CPU-bound, VRAM, loading) using nvidia-smi and system tools without profiling. Use when a user reports slow FPS, stuttering, high latency, or wants a quick health check before profiling. NOT for applying specific fixes (use perf-tuning), capturing traces (use profiling), or analyzing traces (use nsys-analyze).
npx skills add nvidia/omniperf --skill diagnose-perf
Quick triage to identify the most likely performance bottleneck in an Isaac Sim or Isaac Lab workload. This skill does NOT require profiling tools — it uses only nvidia-smi, standard Linux utilities, and Kit config inspection.
For deeper analysis after triage, use the profiling and nsys-analyze skills.
Run these commands and check for red flags:
Key fields to check:
| Field | Red Flag | Action |
|---|---|---|
| Performance State | P2 or higher (P3, P8…) | GPU in power-saving mode — run a workload to wake it, or set nvidia-smi -pm 1 |
| Clocks Throttle Reasons | Any "Active" | Thermal or power throttling — check cooling, power limits |
| FB Memory Usage | >90% used at idle | Other processes hogging VRAM — check with nvidia-smi process list |
| PCIe Generation | Gen2 or Gen1 | Bandwidth bottleneck for large scenes — check BIOS/motherboard |
| GPU Current Temp | >85°C | Thermal throttling likely — improve airflow |
Red flag: Governor is powersave or schedutil — for benchmarks, performance is recommended:
Red flag: Swap usage > 0 during Isaac runs means system RAM is insufficient.
Start the Isaac workload, then capture GPU metrics while it runs:
Columns: pwr (watts), gtemp (°C), sm (SM utilization %), mem (memory utilization %), fb (VRAM MB used)
If the user ran a benchmark skill, check the output JSON for FPS:
Use the GPU monitoring data to classify the bottleneck:
| SM Util | Mem Util | VRAM | CPU | Diagnosis | Handoff |
|---|---|---|---|---|---|
| >80% | Low | OK | Low | GPU compute-bound (rendering or physics) | Profile with nsys to separate RTX vs PhysX zones |
| Low | >80% | High | Low | VRAM bandwidth-bound | Use perf-tuning for texture/material/Fabric options |
| Low | Low | >95% | Low | VRAM capacity-bound (near OOM) | Use perf-tuning for scene/render-resolution options |
| Low | Low | OK | >80% | CPU-bound | Use perf-tuning for Python/USD/Fabric options |
| High | Low | OK | High | Balanced load (good!) | Already well-utilized — micro-optimize with profiler |
| Low | Low | OK | Low | Idle/waiting | Check if rate-limited, sleeping, or blocked on I/O |
| Spiky | Any | Growing | Any | Loading-bound | Use profiling/nsys-analyze if the loading source is unclear |
Without profiling, check these heuristics:
profiling skill with NVTX markersDo not apply fixes from this skill. Use the bottleneck classification above to choose the next skill:
perf-tuning with the red flags and bottleneck category.profiling to capture traces, then nsys-analyze.benchmark-isaacsim or benchmark-isaaclab for WARM results.Common handoff topics for perf-tuning: headless/viewport work, Fabric, debug visualization, CPU governor, RTX quality, PhysX settings, collision geometry, and waitIdle/async rendering.
After running Phases 1-3, summarize findings in this format:
For the full performance settings reference (physics, rendering, app loop), see the perf-tuning skill.
Settings can be applied via:
.kit files in apps/ directory--/setting/path=valuecarb.settings.get_settings().set("/setting/path", value)This triage identifies the category of bottleneck. For specific hotspots, use:
Escalate when: