A frame can only be predicted to a specific point in time, so any additional uses will utilize reprojection to accommodate changes in head pose. The white line drawn on the GPU graph shows the number of times a given frame was presented.This can happen when a newer frame finished in time (e.g. This value can also be zero if the frame was never displayed. A given frame might be ready in time, but since it was predicted out an additional frame, was not necessarily displayed until later. The dark green line drawn on the GPU graph indicates the number of vsync intervals before the frame was actually viewed.For an application making framerate, this should hold steady at 1. The cyan line drawn on the GPU graph reports the number of vsync intervals before the frame was ready to be used.Applications which are consistently taking longer than a single vsync interval to deliver frames will eventually be throttled, to smooth out the experience. The cyan line drawn on the CPU graph indicates the throttling level at the time that frame was recorded.Note: A frame will never be displayed before the vsync interval is was predicted to even if it finished rendering in time this avoids "reverse reprojecting" the frame which can cause judder for animated objects in the scene. Since these poses are provided to the application before the frame is rendered, this can only be a guess based on prior behavior. The yellow line drawn on the CPU graph represents the number of additional vsync intervals ahead the poses provided to the application were predicted in order to accommodate rendering taking more than a single vsync interval to complete.When zoomed in far enough, the stacked view will change to a bar graph, which is useful for seeing individual frame timings. The slider allows you to zoom in and out. ** Provides a single frame's timing information to the app */ struct Compositor_FrameTiming This is the same data returned by IVRCompositor.GetFrameTiming. Use the checkbox next to each label to filter the data. You'll notice the green gpu band take a bit more time when this graph is visible in VR, as rendering Overlays incurs additional work by the compositor.Ĭlicking 'Details' shows a breakdown of all the individual timing being tracked. This will show up on the back side of your right controller (or at the origin if no controllers are attached). To examine this in more detail requires use of gpuview ( ).Ĭlicking 'Show in Headset' will display this graph in VR as well. The brown 'Other' section in the gpu timing reflects any gpu bubbles, context switching overhead, or gpu work from other application getting scheduled in between other segments of work for that frame.
The cpu timing here does not capture any parallel work being performed (e.g. The 'scene' portion is the amount of work performed between when WaitGetPoses returns, and the second eye texture is Submitted ( ), while 'other' is any time spent after this for rendering the application's companion window, etc. The blue sections are time spent by the application these are further split between 'scene' and 'other'. The default view splits out cpu and gpu performance in a pair of stacked graphs: Then click on Performance, find the Display Frame Timing button and click it. To display the frame timing graph, right-click on the SteamVR status window and select Settings, or select Settings from the drop-down in the upper left corner.
0 kommentar(er)
