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?
Triple buffering, flip queue, D3D9ex, FastSync...
Re: Triple buffering, flip queue, D3D9ex, FastSync...
-- 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.2mg wrote: ↑15 Apr 2021, 19:15How 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?
-- 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.
Re: Triple buffering, flip queue, D3D9ex, FastSync...
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).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...
And if DWM is Triple Buffering, what kind of triple buffering is that, if not Pre-rendered queue?
AFAIK there isn't much true/real fullscreen anymore with Win10 (or D3D9ex ?), so why call it Vsync if it's just a limiter?
Re: Triple buffering, flip queue, D3D9ex, FastSync...
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.2mg wrote: ↑26 Apr 2021, 13:37Sure, 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).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...
And if DWM is Triple Buffering, what kind of triple buffering is that, if not Pre-rendered queue?
AFAIK there isn't much true/real fullscreen anymore with Win10 (or D3D9ex ?), so why call it Vsync if it's just a limiter?
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.
Re: Triple buffering, flip queue, D3D9ex, FastSync...
Yeah, XP handled it differently, I misremebered.deama wrote: ↑26 Apr 2021, 16:41XP 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.
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)?
Re: Triple buffering, flip queue, D3D9ex, FastSync...
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.2mg wrote: ↑26 Apr 2021, 17:01Yeah, XP handled it differently, I misremebered.deama wrote: ↑26 Apr 2021, 16:41XP 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.
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)?
This is for windows 8.1 and older win 10 (18xx, maybe even 19xx), donno how they done it recently.
Re: Triple buffering, flip queue, D3D9ex, FastSync...
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
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.
Re: Triple buffering, flip queue, D3D9ex, FastSync...
FastSync is unsequenced VSYNC.2mg wrote: ↑15 Apr 2021, 19:15So 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)?
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).
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
Re: Triple buffering, flip queue, D3D9ex, FastSync...
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.
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.
Re: Triple buffering, flip queue, D3D9ex, FastSync...
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
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