Explain this Vsync behavior please

[2mg]

I apologize if this is the wrong part of the forum.

I'm using Deus Ex: Mankind Divided for this test.
Exclusive fullscreen, native resolution, Win7, DX11 (so no rendering thru DWM stuff).
DXMD has Vsync off, double buffer and triple buffer.
So I crank settings up (AA) to drop below 60fps and turn Double buffer Vsync on.

I expect the fps to get locked to 30fps. This doesn't happen.

Now I'd say "it's because it has some kind of adaptive vsync inbuilt and it isn't syncing anymore" - nope, it's not, because those sub 60 frames are still in sync, as there is no visible tearing (I tested it and turned Vsync off and I did get the tearing).


Can someone shed some light on why this is happening this way?
My wild guess is that it has some smart Dx11 calls via Flip Queue (dxgi) buffering?
Or the same way how RTSS won't trigger Vsync at 58 cap?

Addendum: I tried turning DXMD Vsync off/on while forcing Vsync thru Nvidia Control Panel - no effect, which I also would like to get an explanation why, because doing the same in say Unigine Heaven benchmark it actually works and limits the FPS to 30 when rendering below 60.

[RealNC]

It's hard to tell with the way frame presentation works today. It was simpler in the past. Double-buffer vsync really meant double-buffer vysnc. Now frame presentation is asynchronous (meaning no blocking even if both buffers are in use) so the FPS halving effect doesn't appear in many cases.

I'm ignorant of the details behind this, however.

However, one thing about RTSS: the reason why it's not affected is because for this to happen, the GPU has actually to exceed the maximum allowed render time (16.7ms @ 60Hz.) If the frame was rendered in time though, then this will not result in FPS halving. RTSS affects frame presentation times, not render times.

[2mg]

However, one thing about RTSS: the reason why it's not affected is because for this to happen, the GPU has actually to exceed the maximum allowed render time (16.7ms @ 60Hz.) If the frame was rendered in time though, then this will not result in FPS halving.

But 58/59 cap will cause 2/1 frames (increase frametime) to get dropped and should trigger Vsync, no? What's the difference between RTSS forcing CPU wait, and a real GPU fps drop to 59?

To make the issue worse, why doesn't that cap trigger Vsync, but say 143 cap will trigger Gsync?

RTSS affects frame presentation times, not render times.

Could you put it in layman terms please?

[Sparky]

But 58/59 cap will cause 2/1 frames (increase frametime) to get dropped and should trigger Vsync, no? What's the difference between RTSS forcing CPU wait, and a real GPU fps drop to 59?

In the context of double buffered v-sync, there are two framebuffers, one which the GPU can render into, the other which is being scanned out to the monitor. If the GPU takes longer than 1 refresh cycle to complete a frame, it will repeat the previous frame, and the late frame will sit around until the next available refresh cycle. As both framebuffers are full, either waiting for the next refresh cycle or getting scanned out to the display, the GPU doesn't have anywhere to work on the next frame, so it will sit idle until the next refresh cycle, at which point the newly completed frame will be scanned out to the display and the old one will be overwritten with the next frame.

However, if the GPU can render the frame in under 1 refresh cycle, and you use a framerate limiter somewhere upstream(game engine or RTSS), the GPU will finish 1 frame per refresh cycle, until the command buffers and such between the framerate limiter and the GPU are empty, at which point a frame will be repeated and one additional frame will be buffered(in the command buffers, not the framebuffers). This causes a sawtooth pattern in the latency graph.

One other difference is that being limited by v-sync instead of a framerate cap will cause ALL the command buffers to fill, so it increases overall latency significantly.

As for why the game isn't dropping to 30fps when you crank up the settings, it probably isn't honoring the double buffered vsync setting for some reason.

[RealNC]

But 58/59 cap will cause 2/1 frames (increase frametime) to get dropped and should trigger Vsync, no? What's the difference between RTSS forcing CPU wait, and a real GPU fps drop to 59?

Could you put it in layman terms please?

A real FPS drop will result in the game missing the vsync deadline, and the result of that is that when the game presents the frame, the frame buffers cannot be flipped yet. The front buffer is in use (since it's being scanned out by the monitor again due to the game having missed the deadline), and the back buffer contains the frame the game just rendered. So the game just sits there, unable to do anything since no more buffers are available. Only when the buffers are finally flipped can the game go on start rendering again. The end effect is that every frame is being scanned out twice. Thus, FPS is halved.

But when frame limiting with RTSS, something different happens. The game presents the frame without missing the vsync deadline, RTSS sees the frame and it just presents it on behalf of the game. But RTSS does not return control to the game after that. It waits for the remainder of the target frametime (your configured FPS cap.) In other words, render times are the same as uncapped, but the presentation times are spaced apart according to the FPS cap value.

Trying to visualize the difference (hoping the unicode block symbol isn't screwed up), we have the below. The top bars are the GPU render times for each frame, the bottom bars are the fixed display scanout times. In the case where you get a natural FPS drop, notice how the render times are bigger than the display scanout times, and how the next render time cannot start before the next display scanout. Frame 1 missed the deadline and it cannot be displayed before frame 0 has finished scanning out. The game also can't start working on frame 2 yet, since both buffers are full and there's no buffer where frame 2 could possibly be rendered into.

Code: Select all

            1           2           3
GPU      ███████     ███████     ███████
          0     0     1     1     2     2
Display  ████  ████  ████  ████  ████  ████

So all frames are scanned out twice. Meaning FPS is cut in half.

Now in the RTSS case, if the game doesn't have FPS drops below refresh, we'll have render times that are shorter than the display scanout time. RTSS will present frames as they arrive, but will then wait. Note in this case how the frames are shifted a bit as time goes on, and only frame 3 is scanned out twice since frame 4 is shifted so much that it actually missed the vsync deadline, and thus frame 3 is displayed twice. This is what happens with a 59FPS cap on a 60Hz mode for example, where every 59 frames, you get one duplicate (and thus a hiccup/stutter.) Also notice how the distance between the end of the render time and the start of the next display scanout gets shorter and shorter as time goes on. This is why you get less and less input lag with RTSS, up to the point where one frame misses the dead line, and then you go back again in a cyclic manner:

Code: Select all

          1         2         3         4
GPU      ███       ███       ███       ███
           0       1       2       3       3
Display  ██████  ██████  ██████  ██████  ██████

[RealNC]

As for why the game isn't dropping to 30fps when you crank up the settings, it probably isn't honoring the double buffered vsync setting for some reason.

Actually I suspect a different reason for that. It's probably because of the asynchronous frame presentation in modern systems. Even when the frames took too long to render, when the game presents them, the driver (or graphics API) will not block. It will allow the game to go on and do more work. Even though no third frame buffer is available, a pre-render buffer is! So in the modern multi-threaded and asynchronous world, the thinking is probably that even if the front and back buffer are both unavailable, the game should be allowed to start sampling input and then prepare a frame (put it in the pre-render queue.) If the game actually tried to then render a frame and the front/back buffers are still unavailable, only then would the call truly block. So perhaps what happens is that the pre-render operation takes up just enough time so that by the time it's actually completed, the scanout finished, and the buffers have been flipped. Which then means the game can start rendering and there's no FPS halving. In other words, the pre-render buffer acts "just enough" like a third frame buffer to avoid FPS halving.

Since it's not possible to use an MPRF of 0, this can't be tested. Or it might be testable in a game that has a setting for "fully synchronous rendering", which some games have (I can't recall which though.)

But again, I only suspect this is what's happening. Might be wrong.

[Sparky]

As for why the game isn't dropping to 30fps when you crank up the settings, it probably isn't honoring the double buffered vsync setting for some reason.

Actually I suspect a different reason for that. It's probably because of the asynchronous frame presentation in modern systems. Even when the frames took too long to render, when the game presents them, the driver (or graphics API) will not block. It will allow the game to go on and do more work. Even though no third frame buffer is available, a pre-render buffer is! So in the modern multi-threaded and asynchronous world, the thinking is probably that even if the front and back buffer are both unavailable, the game should be allowed to start sampling input and then prepare a frame (put it in the pre-render queue.) If the game actually tried to then render a frame and the front/back buffers are still unavailable, only then would the call truly block. So perhaps what happens is that the pre-render operation takes up just enough time so that by the time it's actually completed, the scanout finished, and the buffers have been flipped. Which then means the game can start rendering and there's no FPS halving. In other words, the pre-render buffer acts "just enough" like a third frame buffer to avoid FPS halving.

Since it's not possible to use an MPRF of 0, this can't be tested. Or it might be testable in a game that has a setting for "fully synchronous rendering", which some games have (I can't recall which though.)

But again, I only suspect this is what's happening. Might be wrong.

Even double buffered v-sync that drops to half refresh rate has those buffers, but the naming convention isn't consistent. You can call them command buffers, flip queue, prerendered frames, whatever.

If a single full back buffer prevents the GPU from working, it's double buffered and v-sync will halve framerate. If it doesn't, it's triple buffering, and won't halve framerate. The main important distinction between different triple buffering implementations is those that drop frames(this causes stutter) and those that don't(tons of input lag when framerate exceeds refresh rate).

[2mg]

If a single full back buffer prevents the GPU from working, it's double buffered and v-sync will halve framerate. If it doesn't, it's triple buffering, and won't halve framerate. The main important distinction between different triple buffering implementations is those that drop frames(this causes stutter) and those that don't(tons of input lag when framerate exceeds refresh rate).

As I stated, it's Double Buffered, at least the game says so. It also has Triple Buffering, so I doubt that's in question. I'd expect no-30fps lock with triple buffering...

[Sparky]

If a single full back buffer prevents the GPU from working, it's double buffered and v-sync will halve framerate. If it doesn't, it's triple buffering, and won't halve framerate. The main important distinction between different triple buffering implementations is those that drop frames(this causes stutter) and those that don't(tons of input lag when framerate exceeds refresh rate).

As I stated, it's Double Buffered, at least the game says so. It also has Triple Buffering, so I doubt that's in question. I'd expect no-30fps lock with triple buffering...

Right, it's possible that something is overriding what you selected in game.

[2mg]

Right, it's possible that something is overriding what you selected in game.

Well, turning Vsync OFF really turns it off. BUT, I tested another game where DB Vsync really locks @ 30 and I found out that alt tabbing to desktop and back to game overrides DB and I'm guessing either starts Triple Buffering (bug/feature), or it starts passing thru DWM/Compositor (is this normal?).

So in case of DXMD, I'm unsure, because I don't alt tab and vsync off works. Could it be that DXMD, being a newer game, uses https://docs.microsoft.com/en-us/window ... provements so even while double buffered it is programmed to repeat last frame when under 60fps?