Can you please share some more details?
#CpuRigidBodyView fallback on Kinematic Targets despite "warp" backend?
nimble tiger
twin niche
Hello, & thank you for your reply.
Sure no prob. The goal of the Extension i'm creating is to "drive" / move a kinematic body in most efficient way during the simulation. Surprisingly there is perfect and most suitable Function in the Physics Tensor API - set_kinematic_targets. I am initializing the simulation view explicitly with "warp", and sim_view.cuda_context actually confirms: "we are on GPU". However, when I pass GPU-resident Warp arrays to set_kinematic_targets (following the wp_utils sample provided in docs), I get a crash indicating the backend is actually running on CPU:
[Error] [omni.physx.tensors.plugin] Incompatible device of transform tensor in function omni::physx::tensors::CpuRigidBodyView::setKinematicTargets: expected device -1, received device 0
View Request: tensors.create_simulation_view("warp")
The way around is to move data to CPU to get the Function running which makes you guess that engine most likely instantiates CPU RigidBodyView for kinematic bodies no matter what... this is working, however it is not to the specification provided, a time loss, not pure GPU solution and just an inconvenience in programming.
Is this by any chance a limitation in the current PhysX plugin logic for Kinematic Targets specifically? Is it possible that while reading data (positions/velocities) works on GPU, the specific code path for writing kinematic targets was never ported to the GPU backend, forcing a silent fallback to the CPU class.
Your feedback is much appreciated, keen to get pure GPU solution running. Thank you.
nimble tiger
Hello, & thank you for your reply.
Sure no prob. The goal of the Extension i'm ...
Is it possible to share code? Even if just a portion, just to see what you're doing
twin niche
hope this works. Just drop it in Script Editor and run on new / empty scene. Watch the log in the console particular the first line:
[Error] [omni.physx.tensors.plugin] Incompatible device of transform tensor in function omni::physx::tensors::CpuRigidBodyView::setKinematicTargets: expected device -1, received device 0
If i'm not doing anything wrong, than this one could be a potential candidate for the direct bug report. Thank you.
nimble tiger
hope this works. Just drop it in Script Editor and run on new / empty scene. Wat...
You're running this on which specific version please?
nimble tiger
After quite some testing, there's definitely some curious behaviour underneath this.
The frontend (with your code) seems to jump between warp and numpy, with device_ordinal = -1 (which means cpu). Which would tell me that this is a timing/warmup issue, meaning GPU pipeline is not yet available --> defaults to CPU.
WHY possible timing/warmup issue: Since trying to enforce the device_ordinal to 0 (so that cuda:0 would be picked up in parsing the device in warp frontend) and enforced the SimulationView frontend to be warp, did not result in NOT defaulting to CpuRigidBodyView.
Will need to do some more testing tomorrow, in hopes to get an example running with warp.
twin niche
Hi, and your help is much appreciated. 107, 109, tested on all "latest" version of PhysX / Tensor lib., issac binary , Kit - Templates SDK all what was available unfo. the same result, curious. Will need to do some more testing tomorrow, in hopes to get an example running with warp. - that would be great and really helpful🤞 Trying to bring in motion tons of S. Bodies - have to engage all efficiency available. This insight on warmup issue is quite interesting, this i haven't thought of, well let's test it!
I've isolated the view creation and explicitly forced the simulation to wait for 40 full physics steps after omni.timeline.play() before attempting to fetch the tensor view.
Unfo., even after this warmup period, TensorAPI.create_simulation_view("warp") still defaults to returning a CpuRigidBodyView, and it subsequently throws the exact same expected device -1, received device 0 error when passed the native cuda:0 tensor.
It appears that regardless of the warmup time or the EnableGPUDynamicsAttr flag being set, this specific API path refuses to allocate a GPU view for kinematic targets.
script is attached too.
nimble tiger
I will continue the investigation later today, need to finish up some other work