I am attempting to hit 72fps on quest and I’m seeing a lot of time spent in input actions.
Our single frame processing loop breaks down thus:
-
Fixed update = .5ms,
-
Update = 1.5ms
-
Lateupdate = 1.5ms
-
Inputbeforerender=1.3ms
-
Render = 6ms.
Fixed update is stacking due to the throttling, we are targeting 72hz physics tick to match our 72fps target. Update has most of our game logic. Late update is mostly occupied by IK solving. Before render input update is now where we are trying to get more savings because it appears to be doing a lot after each controller input action. Render loop is about 6ms which we can improve but I want to give us as much room as possible by removing unnecessary actions. Our loop is just over 72fps, closer to 60 so quest is throttling us all the way to 30fp, 40ms out of 55ms is spent throttling.
Input system pre-render update looks like it’s working on the 4 gameplay objects that track controllers / headset, but there appears to be a large portion spent after each controller update on something each time called InputActionState.DeferredResolutionOfBindings() I’m looking for more information about what this is doing exactly.
It appears to be doing hundreds of calls to GCHandle.get_Target() and InputActionMap.ResolveBindingIfNecessary() are these all bindings to the input objects that may be stacking and not removed? Can someone help me understand what’s going on here?
P.S.
There is also something taking up a large portion of our fixed update loop called FastMouse. I assume this is something to do with the unity UI input system but it’s happening in game and for smooth controller tracking we need as high of a fixed update sample as possible. The only reference I can find is at the end of this article Input events | Input System | 1.1.1 and we are building a VR game so I’m not looking to dedicated 30% of my fixed update to the mouse.
