So I am using LocalToWorld all over the place in a fully ECS system. BUT, I am wondering if by using LocalToWorld, all jobs scheduled have to sort of serialize even if the LocalToWorlds aren’t really used across the spectrum. There is some writing in some spots, but the writing won’t affect the other Entity components because they are unrelated, but I am guessing that each scheduled job needs to wait to make sure all of its dependencies are free before running them on the other cores.
I am wondering if at the start of each round I should transfer all the LocalToWorlds to separate components, let the scheduler schedule everything and then at the end of the round transfer this information back from separate components into their LocalToWorld matrices. That way entities don’t all rely on LocalToWorld sync points.
Also is there utility where I can put in a JobHandle and see all of it’s dependancies (methods / components) or something or am I misunderstanding what JobHandle can do.
Jobs can read the same component in parallel to each other as long as the component is declared ReadOnly. So if SystemA schedules jobs writing to LTW, then SystemB schedules jobs reading from LTW, then SystemC schedules jobs reading from LTW, and lastly SystemD schedules jobs writing to LTW, then SystemB and SystemC will only depend on SystemA’s JobHandle and thus SystemB and SystemC jobs can run at the same time. SystemD requires all readers to be done reading before it can write so it will depend on the JobHandles of both SystemB and SystemC.
I am using a lot of read and write GetComponentsFromEntityData (which is awesome and I didn’t realize that existed till I had used a complicated hashmap system to get that data), but now I realize it may be stopping scheduling of jobs properly. I have a lot of systems accessing ComponentsFromEntityData<> (like dozens) so it is going to introduce scheduling problems even if the LocalToWorlds are separate for separate entities and would never interact.
What I think I am gonna do is have a single system at the start that takes all the LTWs and transfers their matrices to another component on the entity at the start of my fixed update, everything can then be scheduled and then the last fixed update is transferring the new values back into the LTWs. I think this should help with parallelism unless I am missing something.
I’ve implemented my own LTW system, where different types of objects have different LTW, for example there is a BoatLTW and a SailLTW. Meshes still use LTW (so that Unity can render them), but they only have a LTW and are parented by new parent system to a BoatLTW or a SailLTW. Since there is no longer a bottleneck for LTW read / write, the code runs much tighter in the job system. It’s a lot more code, but it’s definitely helped scheduling efficient jobs.
The scheduler is very power, but if you have write bottlenecks the input dependencies will add a lot more unused CPU time.