Currently at latest 1.1.0-exp. release, I still have the following performance issues profile from my project at android device i.e. Mi 9T Pro (Snagdragon 855) and would like to know when official is planning to address each item that it will fix at 1.1, 1.2 or later?
Remove GhostInputSystemGroup system stalling caused by GhostUpdateSystem:UpdateJob. Expected to reduce around 1ms.
Probably (potentially) maybe 1.2 or later.
Fixing the stall for the ghost input system is kinda little hard to do (because of the job dependencies in updating the OwnerIsLocal component). But, if you are willing to accept the possibility that the flag is outdated of one frame (when it become true or false) then we just opt to move the GhostInputSystem before the GhostUpdateSystem.
The SolveAndIntegrateSystem stalling is almost on physics and the way they do the successive rescheduling of jobs for the step.
Batching rebuild physics world is in there radar.
GhostCollectinSystem and PredictedSimulationSystemGroup are in the radar.
I see. The flag is outdated of one frame (when it become true or false) are u refer to GhostOwnerIsLocal component that sometimes will stay enable/disable late 1 frame? But since I not sure how impactful for this changes, can implement it as define like GHOST_INPUT_SPEEDUP so I can switch back and forth to test it?
Tertle fixed SolveAndIntegrateSystem and PredictedSimulationSystemGroup stalling but at editor there’s netcode rpc error spamming needs to fix. Though player runtime build still working fine. I can try to submit a minimal repo if u want. Anyway I think official can merge this awesome improvement into official release together with error spamming fixed. https://discussions.unity.com/t/925091/17
It did not solve them, it hacked them by removing waiting for job completetion and put the burden at the end of the command buffer. I already fixed the stalling in the PredictedSimulationSystemGroup too long ago (just the PR didn’t land yet).
The SolveAndIntegrateSystem can be fixed, but requires change in Physics, and does not solve the inner problem of that loop either.
^ don’t use this in netcode unless you update the netcode rate managers and how they handle rewind allocator otherwise you will corrupt your memory silently
There will be not any removal for SystemState.BeforeOnUpdate.Complete(), because that would be a too big of a change at the moment. Can be discussed to be maybe an opt-in for certain systems but need to be discussed at Entities level. So I would say, ask that question to the other forum for better and larger visibility.
We have recently released (if not will be soon) a new sample that show how to customise the full physics loop to:
Build only once per prediction loop (or better, when thing change and require that update)
Disable/Enable certain systems only on the filnal step
Use immediate mode for both step and update
It requires to create a custom BuildPhysicsWorld system at the moment for keeping physics pretty much untouched avoid changes in package, and let iterate on some ideas before making the default physics systems customisable without that need.
GhostCollectionSystem
We are planning some optimisation for this early this year. So stay tuned.
GhostInputSystem
For the GhostInputSystem, and in particular the fact you need to wait on the main thread until GhostUpdateSystem jobs has completed) there are two possibility we are looking at:
Changing how the OnwerIsLocal is updated, so it can be done in parallel to other GhostUpdate jobs, effectively removing the wait.
Move the GhostInputSystemGroup before the GhostUpdateSystem. However, this introduce two side-effect:
a) The OwnerIsLocal is not up-to-date. What that mean: you sample and push the input for it even though it will be not controlled by the player if the owner is changed. That it is not a big of a problem, because that is also the case anyway due to the latency (you are sending input to a ghost you think you are in control, but the server has actually changed the owner).
b) The ghost data is not up-to-date when you sample the input. That means, if you are getting some value from replicated components, it may be out of date. That can be a problem or not depending on the case.
That would suggest this compromise solution does not look great. The most correct would be let user to choose where they want to sample the input (before and after) and letting them to eventually wait or not for any dependencies. That immediately suggests two groups are necessary: one before and one after the GhostUpdateSystem, that it is a little strange honestly.
We are going to release a sample about it (so you can further customize the loop the way you want). The reason why we did not embed the logic in the package is because I personally prefer having you guys in total control on what you want to do and how.
We are showing how to customize the various pieces and how to mix multi-threaded/jobified physic update with immediate mode as well.
There will be other improvement for the Build physics part from physics team, but we are still checking what the impact are in term of Netcode.
