Reducing idle time on job threads

[josemendez]

Hi,

I've been observing the following while profiling our game:


Is this the expected ratio of idle time to job execution or is there anything we can do to utilize the threads more efficiently?
Granted, we are running this on a mobile processor, but we've optimized our cloth meshes and simulation parameters as far as possible.

Hi there,

Depends a lot on what your setup looks like, this might be normal or maybe it could be improved.

Let me explain some stuff first: physics simulation in general and cloth in particular can't be 100% parallelized, since interactions/constraints between bodies (for instance a contact between to particles/rigidbodies) usually require modifying some property of these bodies. For instance, changing the velocity of two particles when they collide with each other.

This means writing data to some memory location. Multiple threads writing to the same memory location -modifying the same particle- would lead to a race condition and potentially cause a crash or at the very least give incorrect results. Using synchronization primitives (mutexes, spinlocks) to protect access to each particle from multiple threads would negate any multithreading benefits, as it's slow.

For this reason constraints are grouped or batched in a way that no two constraints in the same batch affect the same particle. This way, constraints within the same batch can be safely solved in parallel, but different batches must be processed sequentially. There's a very watered-down explanation of this in the manual: http://obi.virtualmethodstudio.com/tutor...aints.html

At runtime Obi will merge and reorganize constraints from different cloth actors in the solver so that the minimum amount of batches is produced, maximizing parallelism. Most constraints are pre-batched during blueprint generation (distance, bend, tethers, etc) and some others are batched at runtime (contacts, friction) because they're created and destroyed dynamically.

With this in mind, this is the pseudocode for one simulation step in Obi:

Code:

// find contact constraints
// batch contact constraints

// solve all constraints
foreach constraint type
{
  for (int i = 0; i < iterations; ++i)
  {
      foreach batch in constraint type
      {
           parallel foreach constraint in batch
                  solveConstraint();
      }
  }
}

In your profiler pic, there's 3 clear cut things happening:
- Finding contacts (fully parallel)
- Sorting/merging contacts into batches for efficient paralellization. (parallel operation followed by sequential one)
- Solving all constraints (a sequence of parallel operations, as in the pseudocode above).



The one taking most time is constraint solving (the pseudocode loop above). I have no idea what's happening in there (as the work done by each individual thread is not clearly visible in the screenshot) but it probably means there's either many independent batches or many iterations, which hurts parallelism.

Could you share your solver settings, and some more info about your scene?