I am on Unity 2022 LTS in Editor. Using OpenXR, URP and ECS.
Graphs with Valve Index at 80Hz. (Also tried with Pico 4 streaming from PC also not working)
Graphs from Editor, but IL2CPP build have the same issue.
I am unable to get rid of the “late start” in the steamVR advanced timing dialogue, without removing my gameplay code. So should I leave more milliseconds on the CPU idle, so this can work? I would like to be able to run at 120Hz (8ms per frame)
Am I expected to leave >3ms of the 8ms (@ 120Hz) idle?
Can I trigger the “XR.Display.PopulateNextFrameDesc” earlier in the XRBeginFrame/Gfx.WaitForRenderThread? (which looks like CPU ideling, since it increases at lower FPS)
The running start should not cost extra CPU time, it just moves the place where frame is send to GPU. RIght?
Valve says ‘‘Late Start’ is a special case where the application has exceeded its cpu budget for the frame, but has not yet dropped a frame due to this. This extra wiggle room comes from what we call ‘running start’; it provides a 3ms buffer before the frame starts (i.e. vsync), for the application to begin feeding the gpu render commands for that frame.’ https://developer.valvesoftware.com/wiki/SteamVR/Frame_Timing
Example of ValveIndex running at 80Hz. In a demo level. UnityProfiler + Steam Frame Timing
XRBeginFrame = 4.93 ms
XR.Display.PopulateNextFrameDesc = 0.079 ms
-Entire Frame = slightly bigger than 12.5ms (12.5ms == 80hz)
When I disable my Physics and run the same level (the player loop goes from 3.43ms to 1.21ms):
XRBeginFrame = 7.35 ms
XR.Display.PopulateNextFrameDesc = 3.67 ms (Note this is much bigger, it looks like its doing something)
-Entire Frame = slightly bigger than 12.5ms (12.5ms == 80hz)
Finally the late start is mostly gone, but I can’t leave 7.35 ms of the CPU idle per frame :-(.
(Edit: guess I should add I am using DX11 on windows 10.)
While looking for some more debugging information I noticed that when RenderDoc is Loaded in Unity. (just loaded, not used) The behavior is much more like you would expect.
But why would RenderDoc influence the start time of events on the render thread?
This gives me the feeling there is not a performance problem, but more a scheduling problem.
80Hz without RenderDoc loaded. Note : The Green VFX bars on the render thread are happening below the WaitForRenderThread of the main thread.
The frame time is slightly bigger than 12.5ms (80Hz), but this also sometimes happens with RenderDoc loaded, while still showing the ‘improved’ frame timing with render doc loaded.
80Hz with RenderDoc loaded : Note the Green VFX bars have been pushed earlier in the frame on the RenderThread leaving room for the XR.Display.PopulateNextFrameDesc (which is equal to not having a “Late start” in SteamVR.
I’ve removed all my VFX, just to exclude one of the possible sources. But the issue persists. There is a “CustomRenderTexture.Update” in the Render Thread. This is pushed earlier in the frame with RenderDoc loaded.
Edit: I was able to remove these, so they are not relevant. The issue is unchanged Below SimulationSystemGroup there is a - AsyncUploadManager.AsyncResourceUploadAll - GFX.SetRenderTarget - FillQuadIndexBuffer - Gfx.DrawDynamic These are pushed later in the frame with RenderDoc loaded (see Red anotation in 2nd image).
But I don’t know what it is or what triggers it to be run there.
Dx12 crashes windows at random intervals on my 5700xt, I am just going to assume this is a driver issue. So I will try to see if Vulkan is stable enough to develop with.
Since my issue is mainly a quality of life one I could still use Dx11, and just accept the 1 frame of extra latency.
I saw very similar confusing behavior recently and fixed it by removing Magica Cloth (Magica Cloth | Physics | Unity Asset Store) from the project. It’s still on DX11, 2022.3, and runs great now with Magica Cloth 2.
