Triple buffering, flip queue, D3D9ex, FastSync...

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
Post Reply
2mg
Posts: 21
Joined: 17 Jul 2018, 22:08

Triple buffering, flip queue, D3D9ex, FastSync...

Post by 2mg » 15 Apr 2021, 19:15

So after reading the all famous Anand article, the various guides, the Reddit flamewars, the NVidia's FastSync presentation, the Win10 Game Mode and Fullscreen Optimisations, I'm really confused.

Can someone knowledgeable spare some time and please explain how is FastSync different from Triple Buffering, and I don't mean the "pre-rendered frames = 3" queue?

Do desktop compositors work/force Triple Buffering?

How does Win7's Aero (and I presume Win10) allow frames to go above 60 for Borderless window games (isn't that only FastSync's trick)?

Where do games write if you have NVidia's Reflex, aka 0 pre-rendered frames, in DirectX games (where's the buffer)?

Why do games offer Vsync these days if they're forced into Vsync anyway since they're Borderless windows anyway?

deama
Posts: 368
Joined: 07 Aug 2019, 12:00

Re: Triple buffering, flip queue, D3D9ex, FastSync...

Post by deama » 15 Apr 2021, 20:10

2mg wrote:
15 Apr 2021, 19:15
How does Win7's Aero (and I presume Win10) allow frames to go above 60 for Borderless window games (isn't that only FastSync's trick)?

Where do games write if you have NVidia's Reflex, aka 0 pre-rendered frames, in DirectX games (where's the buffer)?

Why do games offer Vsync these days if they're forced into Vsync anyway since they're Borderless windows anyway?
-- Win 7's aero theme apply a DWM, which is the desktop compositor, it regulates stuff on the screen, in our case, it forces vsync among other things to make things look smooth, as well as allow microsoft and other developers to do some GUI stuff easier. Games can still go above 60fps, it will just sync it up later down the render queue when it hits the DWM.

-- If you have pre-rendered frames set to 0 it just passes the frames directly to GPU, if GPU is busy, then that frame is discarded, then CPU prepares another frame and gives it to the GPU, if GPU is still busy, it discards it again etc...

-- Cause Vsync can be used to cap the framerate. It can also be used to apply vsync when the game is in fullscreen.

2mg
Posts: 21
Joined: 17 Jul 2018, 22:08

Re: Triple buffering, flip queue, D3D9ex, FastSync...

Post by 2mg » 26 Apr 2021, 13:37

deama wrote:
15 Apr 2021, 20:10
-- Win 7's aero theme apply a DWM, which is the desktop compositor, it regulates stuff on the screen, in our case, it forces vsync among other things to make things look smooth, as well as allow microsoft and other developers to do some GUI stuff easier. Games can still go above 60fps, it will just sync it up later down the render queue when it hits the DWM.

-- If you have pre-rendered frames set to 0 it just passes the frames directly to GPU, if GPU is busy, then that frame is discarded, then CPU prepares another frame and gives it to the GPU, if GPU is still busy, it discards it again etc...
Sure, but what differentiates DWM's (from XP to Win 10) vsync from FastSync? They both allow frames to go above refresh rate, yet Fastsync is stuttery because it discards frames (works good only in multiples of refresh rate).

And if DWM is Triple Buffering, what kind of triple buffering is that, if not Pre-rendered queue?
deama wrote:
15 Apr 2021, 20:10
-- Cause Vsync can be used to cap the framerate. It can also be used to apply vsync when the game is in fullscreen.
AFAIK there isn't much true/real fullscreen anymore with Win10 (or D3D9ex ?), so why call it Vsync if it's just a limiter?

deama
Posts: 368
Joined: 07 Aug 2019, 12:00

Re: Triple buffering, flip queue, D3D9ex, FastSync...

Post by deama » 26 Apr 2021, 16:41

2mg wrote:
26 Apr 2021, 13:37
deama wrote:
15 Apr 2021, 20:10
-- Win 7's aero theme apply a DWM, which is the desktop compositor, it regulates stuff on the screen, in our case, it forces vsync among other things to make things look smooth, as well as allow microsoft and other developers to do some GUI stuff easier. Games can still go above 60fps, it will just sync it up later down the render queue when it hits the DWM.

-- If you have pre-rendered frames set to 0 it just passes the frames directly to GPU, if GPU is busy, then that frame is discarded, then CPU prepares another frame and gives it to the GPU, if GPU is still busy, it discards it again etc...
Sure, but what differentiates DWM's (from XP to Win 10) vsync from FastSync? They both allow frames to go above refresh rate, yet Fastsync is stuttery because it discards frames (works good only in multiples of refresh rate).

And if DWM is Triple Buffering, what kind of triple buffering is that, if not Pre-rendered queue?
deama wrote:
15 Apr 2021, 20:10
-- Cause Vsync can be used to cap the framerate. It can also be used to apply vsync when the game is in fullscreen.
AFAIK there isn't much true/real fullscreen anymore with Win10 (or D3D9ex ?), so why call it Vsync if it's just a limiter?
XP didn't have DWM, it was introduced in either vista or win 7 ( I think vista?), and DWM in vista and win 7 (aero) was kinda crap, win 8.1 it's not that much better, but recent win 10 versions have made it better, less input lag penalty I assume.
I've no idea what you mean by fastsync, does win 10 dwm use fastsync now?
Try and think of it like this, you have 120hz monitor, but game says it's pumping out 1000fps, so what does dwm do? It takes the first 120fps, last 120fps, or just the middle 120fps, displays it properly without tearing (or at least tries to), then gets the next 120, could be beginning of 1000fps, middle, or end, or somewhere in between. So game pumps out 1000fps, but you actually just see 120fps. With DWM gone and no sync technology enabled, the latest frames get displayed first, so even if the game says it's pumping out 1000fps, you will get the last 120fps, at least from my understanding.

2mg
Posts: 21
Joined: 17 Jul 2018, 22:08

Re: Triple buffering, flip queue, D3D9ex, FastSync...

Post by 2mg » 26 Apr 2021, 17:01

deama wrote:
26 Apr 2021, 16:41
XP didn't have DWM, it was introduced in either vista or win 7 ( I think vista?), and DWM in vista and win 7 (aero) was kinda crap, win 8.1 it's not that much better, but recent win 10 versions have made it better, less input lag penalty I assume.
I've no idea what you mean by fastsync, does win 10 dwm use fastsync now?
Try and think of it like this, you have 120hz monitor, but game says it's pumping out 1000fps, so what does dwm do? It takes the first 120fps, last 120fps, or just the middle 120fps, displays it properly without tearing (or at least tries to), then gets the next 120, could be beginning of 1000fps, middle, or end, or somewhere in between. So game pumps out 1000fps, but you actually just see 120fps. With DWM gone and no sync technology enabled, the latest frames get displayed first, so even if the game says it's pumping out 1000fps, you will get the last 120fps, at least from my understanding.
Yeah, XP handled it differently, I misremebered.

Anyway, apparently Fast Sync works as "old" triple buffering, right? Always keeps one buffer open for GPU to draw, and swaps buffers to draw the latest frame.

I'm simply interested how does DWM handle Vsync - a real D3D triple buffering implementation, or just a fancy name for flip queue/render ahead (or a combo double buffer Vsync + render ahead)?

deama
Posts: 368
Joined: 07 Aug 2019, 12:00

Re: Triple buffering, flip queue, D3D9ex, FastSync...

Post by deama » 26 Apr 2021, 23:31

2mg wrote:
26 Apr 2021, 17:01
deama wrote:
26 Apr 2021, 16:41
XP didn't have DWM, it was introduced in either vista or win 7 ( I think vista?), and DWM in vista and win 7 (aero) was kinda crap, win 8.1 it's not that much better, but recent win 10 versions have made it better, less input lag penalty I assume.
I've no idea what you mean by fastsync, does win 10 dwm use fastsync now?
Try and think of it like this, you have 120hz monitor, but game says it's pumping out 1000fps, so what does dwm do? It takes the first 120fps, last 120fps, or just the middle 120fps, displays it properly without tearing (or at least tries to), then gets the next 120, could be beginning of 1000fps, middle, or end, or somewhere in between. So game pumps out 1000fps, but you actually just see 120fps. With DWM gone and no sync technology enabled, the latest frames get displayed first, so even if the game says it's pumping out 1000fps, you will get the last 120fps, at least from my understanding.
Yeah, XP handled it differently, I misremebered.

Anyway, apparently Fast Sync works as "old" triple buffering, right? Always keeps one buffer open for GPU to draw, and swaps buffers to draw the latest frame.

I'm simply interested how does DWM handle Vsync - a real D3D triple buffering implementation, or just a fancy name for flip queue/render ahead (or a combo double buffer Vsync + render ahead)?
Donno exactly how DWM handles it, but what I do know is that the input lag addition is roughly your monitor's hz + a few ms. So e.g. if you're on 120hz, DWM would add an additional 8.33ms + 2ms if you cap the framerate close to your monitor's hz. I noticed that if you don't cap it properly, it ends up going higher, I observed values going up as high as 18-25 extra ms even though framerate was higher, but I think this would more depend on the game, as some games it was 8.33ms + 2-3ms almost always, even if you uncap it.
This is for windows 8.1 and older win 10 (18xx, maybe even 19xx), donno how they done it recently.

Kaldaien
Posts: 21
Joined: 22 Jan 2020, 21:27

Re: Triple buffering, flip queue, D3D9ex, FastSync...

Post by Kaldaien » 10 May 2021, 15:29

2mg wrote:
15 Apr 2021, 19:15
How does Win7's Aero (and I presume Win10) allow frames to go above 60 for Borderless window games (isn't that only FastSync's trick)?
It doesn't. DXGI currently requires 2 backbuffers for every 1x refresh rate you want to render above and beyond nominal refresh. You need a driver hack like FastSync to break this limit, because 16 backbuffers (enough for 8x refresh rate) is the maximum supported :)
2mg wrote:
15 Apr 2021, 19:15
Where do games write if you have NVidia's Reflex, aka 0 pre-rendered frames, in DirectX games (where's the buffer)?
That's not at all what NVIDIA Reflex is. Reflex is about tidying up driver-level work to minimize the delay between a game engine finishing a frame and scan-out. 0 pre-rendered frames is 1) impossible and 2) a higher-level construct.

Kaldaien
Posts: 21
Joined: 22 Jan 2020, 21:27

Re: Triple buffering, flip queue, D3D9ex, FastSync...

Post by Kaldaien » 10 May 2021, 15:46

2mg wrote:
15 Apr 2021, 19:15
So after reading the all famous Anand article, the various guides, the Reddit flamewars, the NVidia's FastSync presentation, the Win10 Game Mode and Fullscreen Optimisations, I'm really confused.

Can someone knowledgeable spare some time and please explain how is FastSync different from Triple Buffering, and I don't mean the "pre-rendered frames = 3" queue?

Do desktop compositors work/force Triple Buffering?

How does Win7's Aero (and I presume Win10) allow frames to go above 60 for Borderless window games (isn't that only FastSync's trick)?

Where do games write if you have NVidia's Reflex, aka 0 pre-rendered frames, in DirectX games (where's the buffer)?
FastSync is unsequenced VSYNC.

Normally the way that VSYNC works is every screen refresh, the _oldest_ (First In First Out) completed frame is selected. FastSync just turns that on its head (Last In First Out), you can draw frames that are never displayed. There's no real concern over how long an image is displayed for (sequenced VSYNC says that each frame rendered is displayed for at least 1 Hz no matter how old is).
2mg wrote:
15 Apr 2021, 19:15
Why do games offer Vsync these days if they're forced into Vsync anyway since they're Borderless windows anyway?
This isn't true. You can set a flag in DXGI that allows tearing in windowed mode. Most shipping games come from the stoneage, however, and even though this flag is 3+ years old at this point, expect another 3 years before they start using it :P

ELK
Posts: 125
Joined: 18 Dec 2015, 02:51

Re: Triple buffering, flip queue, D3D9ex, FastSync...

Post by ELK » 12 May 2021, 05:41

You can't write to a buffer that's being read to. It causes visual glitches. This is why 2 buffers are the minimum.


assuming 60hz
Double buffer vsync
read buffer sends to display
gpu draws frame in open write buffer
if fps exceeds refresh rate gpu idles until buffer swap
if fps is less than refresh rate gpu continues drawing, and display reads from same "first" buffer (30fps@60hz)
ALL IS GOOD

Triple buffer vsync scenario
read buffer sends to display
if fps exceeds refresh rate gpu draws to "third" buffer and will idle if "both" non-read buffers are full
if fps is less than refresh rate, but previous frame was much higher fps, there may be a frame already drawn.
Display will always be shown oldest frame, but if fps drops there is a backup frame.
HELPS PREVENT 30FPS DROPS IF FPS IS NEAR 60 BUT INCREASES INPUT LAG

Fast sync / enhanced sync
read buffer is always communicating with the display my friend
meanwhile gpu draws to two open buffers like so A,B,A,B,A,B
when the display wants its next frame it reads from the buffer with the newest drawn image


I saw "first" "second" "third" "both" because they are always changing around. There is no point copying data from buffer 2 to buffer 1(read) when you can just have the display read from buffer 2.



The three buffers are being used differently in fast sync / enhanced sync then they are in triple buffered vsync.

ELK
Posts: 125
Joined: 18 Dec 2015, 02:51

Re: Triple buffering, flip queue, D3D9ex, FastSync...

Post by ELK » 12 May 2021, 06:19

I feel like I explained it poorly.

no sync
swap read buffer to write buffer when write buffer is complete [ignore monitor]

double buffer vsync
swap read buffer to write buffer IF write buffer is complete [and the monitor requests] else read from read buffer again

triple buffer vsync
swap read buffer to oldest complete buffer else read from read buffer again.
(90% of the time all buffers are going to be full and the gpu idling before the monitor asks for next frame)
*using OLDEST buffer and idling when both are full

fast sync / enhanced sync
swap read buffer to newest write buffer
*using NEWEST buffer and writing always overwrites the oldest buffer

Post Reply