Stat Unit: Frame time larger than game, draw and GPU...why?

rantrod · August 11, 2016, 10:44pm

As the title says,

Frame: 18ms
Game: 11ms
Draw: 15ms
GPU: 15ms

I thought Frame was supposed to reflect the highest of the other three. What does it mean when Frame is higher than the other three?

rantrod · August 12, 2016, 11:53pm

I notice that the higher the Draw goes, the higher that padding goes Frame. My framerate target being 60fps, 15ms is pretty close. With a draw of 16ms, Frame moves up to 19-20ms.

rantrod · August 18, 2016, 6:29am

I had a theory that “Frame” meant the results of the Render thread but the numbers don’t seem to match either when I look into it using “stat startfile/stat stopfile”. It’s possible the stat commands add a bit to the render thread throwing it off and that extra amount is not recorded.

rantrod · August 19, 2016, 4:15am

Definitely not the render thread. I got an instance of Frame being 24ms but the render thread was at 18ms. That’s a pretty big gap. Not sure what’s the holdup when the Game, Draw, and GPU are all under the Frame time by several milliseconds.

indygoof · August 20, 2016, 7:32am

Just a wild guess: You are probably running in the editor, and Slate is probably having fun with your timings.

with “profilegpu” you should see an estimate on how long the SlateUI itself took, and i think its not counted into Draw/GPU time.
Try starting your game as standalone without the editor open and see what timings are then.

rantrod · August 20, 2016, 9:06pm

Not running it in editor, but I’ll look into how much Slate takes. I thought it was a CPU issue so I didn’t look at profilegpu. I’ll try that next, thanks.

rantrod · August 23, 2016, 10:21pm

I don’t think it’s Slate. With only ‘stat unit’, slate on the GPU is small (0.1ms) and on the CPU it’s about 0.6ms. With something like ‘stat scenerendering’ slate can go up 10ms, but that’s not what I’m doing. Doesn’t look like Slate alone accounts for the 3ms I’m losing somehow. This is one of those Heisenbugs where observing it changes its behavior. ‘stat startfile’, ‘stat unit’, etc will affect the very values that they are trying to calculate.

rantrod · August 25, 2016, 12:57am

I saw another case where Frame was 5ms higher than any other value. If someone knew if the number is just artificially high and related to having ‘stat unit’ on, that’d be great.

It’s possible ‘Frame’ reflects ‘stat SceneRendering’ but it’s hard to say because turning on SceneRendering makes the Frame shoot up > 10ms. If someone could confirm what ‘Frame’ reflects, that would be great.

rantrod · August 25, 2016, 9:56pm

I might report this as a documentation bug. Why add stats like ‘Frame’ and ‘Draw’ and not explain what they mean? Draw moves up and down depending on occlusion, transparency layers, how many meshes are rendered, how many dynamic shadows are being generated, and other miscellaneous factors. It would be good to know exactly what is included in it. ‘Frame’ is completely unexplained. The only pseudo-explanation I can find is in this document: How to improve game thread CPU performance in Unreal Engine - Unreal Engine

rantrod · August 26, 2016, 10:10pm

This was a hardware specific issue related to VR. If you’re near the framerate threshold of 60fps you might miss the window for rendering the new frame and instead the system will reproject the old data. This reprojection can add several ms to the process, depending on how badly you are missing frame. The fact the other stats displayed under 60fps but still getting this reprojection penalty was a symptom of spikes in fps that average out in the display.