To display frame timing, right click on vrmonitor, and select Display Frame Timing under Diagnostics.
Click 'show in headset' to bring up the display in VR as well. This will show up on the back side of your right most controller (or at the origin if no controllers are attached).
Here's some example output:
This view attempts to show you how your frame time is spent. The reported times are stacked: solid yellow (e.g. under the blue spike near the left) represents the cpu delay before rendering started for that frame. Blue is the amount of time spent rendering that frame on the gpu while green is the amount of time spent rendering in the compositor.
This example was captured while the expensive high quality overlay was in use, so the compositor is taking up way more time than it would otherwise.
Switching to raw mode shows a bit more info. This mode is not stacked - all values represent isolated timings. The labels along the right indicate which color matches which line and can be toggled on and off to make it easier to read (or help determine which line is which).
- frame - this value should remain at a stead 11.1ms for headsets running at 90hz, and will spike up to higher intervals when dropping frames
- prediction - this shows the number of ms we are predicting ahead each frame
- scene gpu - the time spent rendering the scene
- distort gpu - the time spent rendering in the compositor (distortion pass plus any overlays, hardbounds, etc.)
- distort cpu - cpu time spent between getting a new frame and calling present
- scene cpu - cpu time between calling WaitGetPoses and Submitting scene textures for both eyes (includes any IPC overhead)
- running start - amount of running start time used (should hover around 3ms)
- present - cpu time taken by the call to D3D Present (this can stall in certain situations - e.g. when the compositor loses fullscreen)
The slider will allow you to zoom in and out. When you zoom in far enough, the stacked view will change to a bar graph.
In this capture, we dropped a frame, then had some delayed rendering (before the scene itself started rendering), then dropped a second frame before things get going for real. That tall cyan bar on the second spike represents the delay before WaitGetPoses was called for that frame. It's the inverse of the running start time; normally WaitGetPoses should be getting called 3ms before the frame starts (-3ms on the graph, which we don't display).
Switching to raw mode, we can see that initial spike was due to scene cpu time (maybe we're calling WaitGetPoses before we're ready to start rendering for real). You can also see the running start time coming from below zero on that first frame. This is perhaps to be expected since it's the first frame, though we might be able to do better here.
Here's another example from when the compositor has lost fullscreen. The present time is blocking until the end of the frame. This in turn eats into our running start time (the cyan bits poking up at the bottom), causing a bubble before we start rendering (the solid yellow). We still make framerate just fine, but this is not ideal. This example is using the fast compositor shader path, and is more inline with what you should expect for gpu perf there (the little green bits on the tips).
The same view in raw mode:
If you see something that doesn't make sense, post about it on the forums.