11-09-2020, 07:06 AM
(This post was last modified: 11-09-2020, 09:17 AM by josemendez.)
Hi there,
I’m unable to reproduce this, going to investigate further. For the time being, you can switch your solver to the Oni backend. It will work without using Burst, instead using a native c++ lib with about the same performance (even a bit better in some scenes). See:
http://obi.virtualmethodstudio.com/tutor...kends.html
Edit: I find surprising that ApplyCollisionConstraintsBatchJob.positions is regarded as UNKNOWN_OBJECT_TYPE in the error message you posted: it's a plain NativeArray? What Burst/Jobs versions are you using?
Regarding performance/vectorization, the current bottleneck for Burst is not CPU cycles spent on arithmetic instructions, but job scheduling by far: scheduling a job is quite often as slow or slower than executing it. This is specially problematic for small constraint batches. For this reason, we're currently concentrating our efforts on merging jobs together, which is what we've done in 5.6 (available next week) for a noticeable performance improvement.
After that there's some more low-hanging fruit for vectorization, such as removing branches from constraint application methods. Then there's the possibility of processing multiple constraints at once during batch execution/processing. This is what we do in the C++ lib: instead of letting vectorization on the hands of the compiler we use SIMD intrinsics and manually unroll/vectorize where possible. Over time our intention is to port these optimizations to Burst, and have the Burst backend outperform the native backend.
I’m unable to reproduce this, going to investigate further. For the time being, you can switch your solver to the Oni backend. It will work without using Burst, instead using a native c++ lib with about the same performance (even a bit better in some scenes). See:
http://obi.virtualmethodstudio.com/tutor...kends.html
Edit: I find surprising that ApplyCollisionConstraintsBatchJob.positions is regarded as UNKNOWN_OBJECT_TYPE in the error message you posted: it's a plain NativeArray? What Burst/Jobs versions are you using?
Regarding performance/vectorization, the current bottleneck for Burst is not CPU cycles spent on arithmetic instructions, but job scheduling by far: scheduling a job is quite often as slow or slower than executing it. This is specially problematic for small constraint batches. For this reason, we're currently concentrating our efforts on merging jobs together, which is what we've done in 5.6 (available next week) for a noticeable performance improvement.
After that there's some more low-hanging fruit for vectorization, such as removing branches from constraint application methods. Then there's the possibility of processing multiple constraints at once during batch execution/processing. This is what we do in the C++ lib: instead of letting vectorization on the hands of the compiler we use SIMD intrinsics and manually unroll/vectorize where possible. Over time our intention is to port these optimizations to Burst, and have the Burst backend outperform the native backend.