Wrong frametimes for Deus Ex: Mankind Divided in DX12 mode about presentmon HOT 15 CLOSED

Just to clarify, there's nothing "wrong" about the MsBetweenDisplayChange data - in fact, it is letting you know when the image on screen changes, which is a big part of the picture. The MsBetweenPresents data might be more what is "expected", and is also important to look at, but it is what the engine is doing and not what the end user is seeing. MsBetweenPresents is showing a screen update behavior that the end user probably won't like.

If you look over at the dropped column for the dx12 run, you'll see there are lots of dropped frames. Wondering if there is a toggle for v-sync that is on by default for dx12 (don't have the game handy).

from presentmon.

You're looking at the MsBetweenDisplayChange column, which corresponds to when frames show up on screen, not when they're produced by the game. For some reason (outside the scope of a PresentMon issue), the game is not directly scanning out, the compositor is still engaged, so frames are always displayed on VSyncs. Looking at the MsBetweenPresents column produces correct data.

from presentmon.

• MsBetweenPresents corresponds to the time that the application called Present. The app has recorded all of its rendering work. The GPU may or may not have started on this work.
• MsBetweenDisplayChange corresponds to the time that frames appeared on screen.

There are a maximum number of frames that can be queued to the system at any given time, which means that measuring MsBetweenPresents actually ends up giving you a pretty good overall idea of the performance of the system, regardless which piece is actually your bottleneck: it could be the CPU, it could be the GPU, or it could be the display (if you're using VSync).

The benefit of MsBetweenDisplayChange comes when you're dealing with windowed apps, where there's an indirection between producing a frame and whether or not it will show up, or for highlighting cases where hardware parallelism can produce poor pacing, like with SLI/CrossFire scenarios. In the multi-GPU cases, the CPU can produce two frames very quickly back-to-back while the GPU generally takes a long time. If there was only one GPU, the CPU would eventually slow down because the GPU would throttle it. With two GPUs, you end up with a tick-tock pattern, where the CPU wakes up and is able to produce two frames, and the GPUs are able to render both frames, and the display ends up barely even showing one of them.

So, in general if you're measuring application performance, you want MsBetweenPresents. Unless you're specifically looking to investigate end-user experience issues related to pacing, latency, dropped frames, etc., where the other metrics are useful.

from presentmon.

But if you look at MsBetweenPresents and ignore MsBetweenDisplayChange, you run the risk of missing a big and very noticeable performance issue, no? For whatever reason, there is something not good going on in this dx12 Deus Ex run, and looking only at MsBetweenPresents would have totally missed it.

Is there a drawback to just always using MsBetweenDisplayChange? Either way, it seems dangerous to only use MsBetweenPresents in the general case.

from presentmon.

But if you look at MsBetweenPresents and ignore MsBetweenDisplayChange, you run the risk of missing a big and very noticeable performance issue, no? For whatever reason, there is something not good going on in this dx12 Deus Ex run, and looking only at MsBetweenPresents would have totally missed it.
Is there a drawback to just always using MsBetweenDisplayChange? Either way, it seems dangerous to only use MsBetweenPresents in the general case.

Depends on what you're looking to measure -- end-user experience or application performance. If you just want app performance, then always look at MsBetweenPresents. If you care about more qualitative metrics that might affect experience, then MsBetweenDisplayChange is useful. But take a windowed app with VSync off: in a good case, MsBetweenDisplayChange should always be 0ms for frames that don't show up and 16ms for the frames that do. An instance of 33ms would indicate a noticeable hitch. But that doesn't tell you how fast the game is really running; is it 100fps? 200fps? Does that number matter? Again, it all depends on what you're looking to measure.

from presentmon.

While that's more or less accurate, it's important to be aware of whether you're talking about the application side framerate, which is what's typically measured, and is the metric tracked by MsBetweenPresents, or if you're talking about the number of frames actually reaching the display, tracked by MsBetweenDisplayChange.

Earlier Windows 10 versions had limitations which throttled application framerate in all modes except "true immediate" independent flip. More recent versions enable unthrottled application framerates when the application is composed as well, but since the compositor still uses VSync'd presents, the number of frames reaching the screen will still match the monitor refresh rate.

from presentmon.

@jenatali oops, you are right! At some point I've swithced to using MsBetweenDisplayChange metrics only and for that reason didn't notice that MsBetweenPresents numbers are fine in that particular case (shown in orange in the graph below).

But it is still somewhat strange that MsBetweenDisplayChange numbers are looking so odd in this single case of more than 100 titles I already tested using few different APIs. True, these numbers look like some sort of VSync is turned on, but I double-checked that - VSync is off, at least in game settings.

from presentmon.

@aggieNick02 it is still unclear which values to use in which case. I mean, there is very little information about it. For instance, GamersNexus (GN) in one of their reviews mentioned that:

Please note that we use onPresent to measure framerate and frametimes. Reviewers must make a decision whether to use onPresent or onDisplay when testing with PresentMon. Neither is necessarily correct or incorrect, it just comes down to the type of data the reviewer wants to work with and analyze.

but didn't clarify the matter any further, instead just stated that

For us, we look at frames on the Present.

which is not so useful.

I understand that this is somewhat off-topic to ask here for clarifications on when to use which metrics, but could anyone shed some light on that matter?

So, if I understand correctly,

• MsBetweenPresents correspond to timestamps at the beginning of the graphics pipeline, i.e. right after the game engine finished all the calculations (physics, graphics, ai, etc.) required to collect all the data that has to be sent to the GPU through API & driver to render the frame.
• MsBetweenDisplayChange correspond to timestamps at the end of the graphics pipeline, i.e. after all the data sent to the GPU were processed by it and the frame was sent to the display buffer (if not dropped for some reason).

If this is more or less correct, than I feel like MsBetweenDisplayChange and not MsBetweenPresents should be used as the overall smoothness of the animation, cause the former counts for things liek API & GPU driver overheads as well as GPU rendering time in addition to the later.

But the we can see that GN use MsBetweenPresents for some reason they do not mention explicitly and now I'm completely lost and feel like I'm missing something very important...

from presentmon.

I spent some time today and found out that enabling 'Exclusive fullscreen' in settings causes this strange behaviour but in DX12 mode only - even if VSync is turned off frames are rendered and displayed as it is actually on. 😮 But since it is the only example of such strange behaviour I found so far, I'm fairly certain that it is not PresentMon issue but rather game or/and driver one.

@jenatali @aggieNick02 many thanks for your input and clarifications!

from presentmon.

Yes, but I'd argue that it's rarely the goal to measure application performance irrespective of end-user experience. Outside of algorithm development/optimization, I'm much more concerned about experience quality: so how often and how stable the image is changing on screen (MsBetweenDisplayChange), and the how low and how stable the latency is are the primary metrics I care about.

For vsynced workloads, if the CPU/GPU are running faster than vsync MsBetweenPresents may be higher but that doesn't directly relate to experience quality, it's measuring frames that were generated but dropped (never seen by the user). There is a beneficial side-effect of dropping frames though, the frame that does end up displayed will have lower latency... so if you care more about experience quality that is a better measure of performance (IMO).

from presentmon.

Also note that MsBetweenDisplayChange is not locked to multiples of the monitor's frametime (eg. 16ms) unless the game has vsync on. More than one frame can be present on the screen at the same time, which results in tearing artifacts, but some prefer that over the vsync and the usually increased lag.

from presentmon.

According to the results of my further investigations this behaviour is common for games running in a non-exclusive DX12 mode in which they use a sort of a triple buffering via the DWM. Even if a certain game claims to support exclusive fullscreen rendering in DX12 mode (like the Deus Ex: Mankind Divided) and fullscreen optimization is disabled in game's executable properties the game might still run in a non-exclusive mode with the abovementioned triple buffering.

from presentmon.

So I saw something similar recently with Minecraft (Java edition). No matter what I tried, PresentMon (and my eyes) showed that VSync was on, even though the game and graphics card were set to force it off, and the game's internal stats overlay showed it rendering well over 60FPS.

For Minecraft, using "Change high DPI settings" to "Override high DPI scaling behavior. Scaling performed by Application" actually fixed the behavior. It's probably worth trying on Deus Ex: Mankind Divided, just to see, though the fact that it is only in DX12 that you see this behavior makes it seem less likely to help.

(You get to the setting by clicking the "Change high DPI Settings" button under "Disable fullscreen optimizations". Also I'd recommend checking task manager to make sure you've got the right executable to set the property on - sometimes games will have different shell executables for the different engine versions.)

from presentmon.

@aggieNick02 nothing works for me - I've tried myriads of options but I can't get Deus Ex: Mankind Divided running in exclusive fullscreen mode using DX12.

from presentmon.

So, my current understanding is that DX12 does not support good-old "true" (i.e. exclusive) fullscreen (EFS) rendering at all and rather uses one of the newly introduced in recent Windows versions windowed flipped modes out of which there is only one, the so-called Immediate Independent Flip (Immediate iFlip) mode, with the uncapped framerate. In all other DX12 modes the framerate is limited to a multiple of the refresh rate regardless of VSync being on or off due to DWM composition. Only in Immediate iFlip mode DWM is completely bypassed and framerate is completely unleashed exactly like in the old EFS mode (with VSync being off, of course) that is not available anymore for use with DX12. Here is a video and a blog post I found to be very informative.

My guess then is that Deus Ex: Mankind Divided simply does not support Immediate iFlip DX12 mode and thus the framerate here is limited to a multiple of the refresh rate (60 Hz in my case). Another guess is that a variable refresh rate setup will perform differently in such circumstances but I could not check that theory.

from presentmon.