Triple Buffering
-
if my monitor has 60hz and if bms drops below 60fps with vsync off, what changes between tb(or nvidia fast vsync) on or off?
Triple-buffering basically just becomes equivalent to double-buffering at that point. Viz. the monitor is asking for a new frame, but if there’s not one ready yet, it just rescans the previous frame still sitting in the front-buffer.
VRR technology like G-sync might* help in this situation? Viz. the monitor asks for a new frame, the display driver says “nothing new yet but hold on a few milliseconds” then, when the next frame finally arrives, it goes immediately to the front-buffer and the driver signals the monitor to display it.
(*I actually haven’t tested much with TB+VRR so really I have no idea if it works well or not… just stating theory of how I’d expect it to work. I’ll give a try for a while… my avg fps does sometimes dip below my refresh rate, eg. landing/taxiing at the larger airbases near large cities.)
Also, TB can act as a bit of a shock-absorber, if you’re mostly producing well above 60fps but occasionally have just 1 frame that takes longer than 16.7ms.
Some monitor tools show a metric called “p99” fps or “1% low” fps … if that number is below 60 but your avg/p90 fps is well above, say, 80, then TB’s extra backbuffer will often be able to absorb these occasional slow-frame shocks.
-
I actually haven’t tested much with TB+VRR so really I have no idea if it works well or not… just stating theory of how I’d expect it to work. I’ll give a try for a while… my avg fps does sometimes dip below my refresh rate, eg. landing/taxiing at the larger airbases near large cities.)
Just test flew the HARM training mission … with its overhead approach at Osan 27-R where, with the cities and base in view, my fps usually drops down to about 70 (consistently below my 85hz refresh rate) while, out of view, my fps stays mostly above 100.
It seems pretty smooth in both conditions and I never noticed any “transition” from the high-fps zone to low-fps zone.
So, I take back what I wrote on 2/4… I think G-sync + TB can be a worthwhile combination to try, for a middle-tier rig that is sometimes going to be producing fps above, and sometimes below, the monitor’s refresh rate.
(@TheFalcon – thanks for helping me clarify my thinking on this.)
-
Would be good to have a PDF guide with all those thing summed-up. We could even maybe add it BMS documentations ….
+1
-
V-sync OFF*. It would defeat the point … triple-buffering is all about not tearing, while not blocking on the v-blank signal from the monitor.
(*If you have Nvidia graphics, the control panel offers a setting for v-sync called ‘Fast’ which is their implementation of triple-buffering. I really like v-sync=Fast, (a) because it works in all games, and (b) it also steps out of the way when running in windowed/borderless mode which is essentially triple-buffered always courtesy of how the DWM works.)
So, to recap… two ways to enjoy triple-buffering:
-
Nvidia control panel: v-sync=off; Falcon in-game: v-sync=off, triple=ON
…then be sure to run in fullscreen-exclusive mode; borderless/window will work ok but have extra latency -
Nvidia control panel: v-sync=Fast; Falcon in-game: v-sync=off, triple=off
…then run in either windowed, borderless or fullscreen, as you prefer, with no significant difference in latency
Added to the HotList
-
-
V-sync OFF*. It would defeat the point … triple-buffering is all about not tearing, while not blocking on the v-blank signal from the monitor.
(*If you have Nvidia graphics, the control panel offers a setting for v-sync called ‘Fast’ which is their implementation of triple-buffering. I really like v-sync=Fast, (a) because it works in all games, and (b) it also steps out of the way when running in windowed/borderless mode which is essentially triple-buffered always courtesy of how the DWM works.)
So, to recap… two ways to enjoy triple-buffering:
-
Nvidia control panel: v-sync=off; Falcon in-game: v-sync=off, triple=ON
…then be sure to run in fullscreen-exclusive mode; borderless/window will work ok but have extra latency -
Nvidia control panel: v-sync=Fast; Falcon in-game: v-sync=off, triple=off
…then run in either windowed, borderless or fullscreen, as you prefer, with no significant difference in latency
So for #2, do you turn on TB in Nvidia control panel? I’m running triples (144hz Freesync) with two small (Lilliput 60hz) monitors and GSync messed thing up so it’s currently off also…
-
-
So for #2, do you turn on TB in Nvidia control panel?
From all I’ve read and been told, the setting named “Triple-buffering” in NVidia control panel applies to OpenGL apps only. (BMS is not OpenGL, so it won’t do anything for us.)
I have no idea how or why OpenGL would need a different setting, and how it behaves vs v-sync=Fast … or why Nvidia sucks so bad writing basic intelligible description text for their settings… I spent hours futzing with that setting and growing increasingly confused, before I eventually learned it did nothing for directx apps.
-
(*If you have Nvidia graphics, the control panel offers a setting for v-sync called ‘Fast’ which is their implementation of triple-buffering. I really like v-sync=Fast, (a) because it works in all games, and (b) it also steps out of the way when running in windowed/borderless mode which is essentially triple-buffered always courtesy of how the DWM works.)
From Nvidia about fast sync:
Fast sync is not supported for DirectX12 games. If a DirectX 12 game is launched with NVIDIA Control Panel Vertical Sync setting set to “Fast”, the graphics card will automatically default to Application Controlled. In general, Fast Sync is designed to benefit games that are running with very fast native render rates (3 times or more the rate of the refresh on you monitor).
3 times isn’t so practical. Even if now you can run BMS at 200 FPS, that’s because your GPU is currently hardly doing anything… so fast sync isn’t something to get used to as a problem solver WRT buffering the frames.
-
So, using Airtex’s settings (I think), it seems to have made a big difference, with no stutters, everything very smooth and responsive, and lovely to fly.
I’m using:
Nvidia - AA and Anisotropic filtering at max (64x and 16x respectively), Low Latency Mode = Ultra, Max Frame Rate = 83fps. Vsync = off, Triple Buffer = off
BMS - Triple Buffer = On, everything else at defaults.And, picking up from another thread, on my 3440x1440@60hz 34" curved diisplay, which I sit 70cm from, I have a FOV of 105 by default.
-
From Nvidia about fast sync:
…
3 times isn’t so practical. Even if now you can run BMS at 200 FPS, that’s because your GPU is currently hardly doing anything… so fast sync isn’t something to get used to as a problem solver WRT buffering the frames.Yeah I think I get where they are coming from, with that statement… all games are different tho. For a twitchy, jerky, first-person shooter experience, input-to-render latency is paramount, and smoothness can be sacrificed.
It’s definitely true, on paper, if you model the frame-ages (time from sampling input, to display on-screen) that G-sync + v-sync and LLM=Ultra is numerically best (edit: without tearing). If you’re playing Counterstrike or Call of Duty etc, that’s probably the way to go.
But for a flight sim, a sense of smoothness is equally valuable as raw input-latency… maybe more so? (Opinions may differ.)
As a metaphor, imagine driving along a perfectly smooth asphalt road… but there’s a 1-inch gap between sections of the road, every 87 yards. Mostly fast and smooth, but it’s a juttery and annoying experience overall. Vs driving along a gravel road, that is well maintained and reasonably level, but the road surface is a mix of 1/4in and 1/2in gravel… and a few 1-inch rocks strewn in.
Objectively, the asphalt road would be “smoother” on average than the gravel road. But subjectively, it would be super annoying to hit that little bump every 3 seconds… unavoidably… forever… while the gravel road would be rougher and noisier at high-frequency, but feel less bumpy and annoying overall.
That’s BMS for me. On both of my systems (old and new) there is a stutter every 87th frame… visible in PresentMon logs as a ~7ms spike in time between Present() calls, every 87th frame like clockwork. (If your avg/p90 fps is ~100 but your p99 is ~60, that’s the reason.)
The practical effect, for a flight sim, is the “snapshot” of scenery out your window is slightly delayed, every 87th frame… relative to the 86th and 88th frames. While the other 86 frames are snapshots taken at near-perfectly uniformity, within 2ms. It’s like a perfect smooth road with a bump every 87 yards.
That microstutter is still there, when running triple-buffering, but with fps cap set to around 1.4x the refresh rate, my adjacent frame-ages are sufficiently randomized, plus/minus a few milliseconds, that I never notice the occasional +7ms gap. Everything appears smoother, on average – it’s the gravel road.
In a future update, if that 87th-frame stutter were somehow taken away … then I would probably no longer recommend triple-buffering, and instead just recommend G-sync w/ fps-cap, the way blurbusters and most other forums do, for most games.
-
For me, that was an excellent analogy. Graphics has always been a bit of “Black Magic” to me but I understood that. Thanks
-
Yeah I think I get where they are coming from, with that statement… all games are different tho. For a twitchy, jerky, first-person shooter experience, input-to-render latency is paramount, and smoothness can be sacrificed.
It’s definitely true, on paper, if you model the frame-ages (time from sampling input, to display on-screen) that G-sync + v-sync and LLM=Ultra is numerically best (edit: without tearing). If you’re playing Counterstrike or Call of Duty etc, that’s probably the way to go.
But for a flight sim, a sense of smoothness is equally valuable as raw input-latency… maybe more so? (Opinions may differ.)
As a metaphor, imagine driving along a perfectly smooth asphalt road… but there’s a 1-inch gap between sections of the road, every 87 yards. Mostly fast and smooth, but it’s a juttery and annoying experience overall. Vs driving along a gravel road, that is well maintained and reasonably level, but the road surface is a mix of 1/4in and 1/2in gravel… and a few 1-inch rocks strewn in.
Objectively, the asphalt road would be “smoother” on average than the gravel road. But subjectively, it would be super annoying to hit that little bump every 3 seconds… unavoidably… forever… while the gravel road would be rougher and noisier at high-frequency, but feel less bumpy and annoying overall.
That’s BMS for me. On both of my systems (old and new) there is a stutter every 87th frame… visible in PresentMon logs as a ~7ms spike in time between Present() calls, every 87th frame like clockwork. (If your avg/p90 fps is ~100 but your p99 is ~60, that’s the reason.)
The practical effect, for a flight sim, is the “snapshot” of scenery out your window is slightly delayed, every 87th frame… relative to the 86th and 88th frames. While the other 86 frames are snapshots taken at near-perfectly uniformity, within 2ms. It’s like a perfect smooth road with a bump every 87 yards.
That microstutter is still there, when running triple-buffering, but with fps cap set to around 1.4x the refresh rate, my adjacent frame-ages are sufficiently randomized, plus/minus a few milliseconds, that I never notice the occasional +7ms gap. Everything appears smoother, on average – it’s the gravel road.
In a future update, if that 87th-frame stutter were somehow taken away … then I would probably no longer recommend triple-buffering, and instead just recommend G-sync w/ fps-cap, the way blurbusters and most other forums do, for most games.
I tried Presentmon here and ran BMS TE for a minute or so, I can’t spot any kind of stutters in present time. Log showed ~5ms for most frames, sometimes ~6ms and some rare ones gone to 7-8ms but I couldn’t make any pattern, so I’ll assume this is more or less normal behavior. Did you tried to play with Nvidia settings and see if that stutter is gone or the periodic behavior of it is changed? With my 1080 I can spot stutters every ~3-4 seconds or so if the GPU VRAM is fully utilized (even for an internal dev version that is an extreme case to fill 8GB of VRAM) and I can understand swapping may cause that, but I don’t think you can get even near that with 4.35 to fill even 2GB of VRAM.
-
The internet is flooded with upcoming ms updates that fix many game and rendering issues…
-
I tried Presentmon here and ran BMS TE for a minute or so, I can’t spot any kind of stutters in present time. Log showed ~5ms for most frames, sometimes ~6ms and some rare ones gone to 7-8ms but I couldn’t make any pattern, so I’ll assume this is more or less normal behavior. Did you tried to play with Nvidia settings and see if that stutter is gone or the periodic behavior of it is changed? With my 1080 I can spot stutters every ~3-4 seconds or so if the GPU VRAM is fully utilized (even for an internal dev version that is an extreme case to fill 8GB of VRAM) and I can understand swapping may cause that, but I don’t think you can get even near that with 4.35 to fill even 2GB of VRAM.
I’ll DM you a csv file from my PresentMon if that’s ok, so you can see what I’m talking about… just captured 5 seconds on 4.35.U1, TR #4 night ILS landing.
https://imgur.com/a/YKc6GRu
https://dmwzyqd0jibt2.cloudfront.net/FrameView_Falcon%20BMS.exe_2021_03_02T035829_Log.csvOn my upgraded rig it’s about +5ms every 87th frame. In this 5 second capture you’ll see Column N (MsBetweenPresents) is a very consistent 10-12ms, except rows 70, 157, 244, 331, 418 which spike to about 15.5ms.
This repros for me on 2 totally different desktops… different generation cpu/mobo/gpu (both Intel and Nvidia tho… and both same Windows 10).
Repros for every Nvidia and OS setting I’ve tried … both g-sync and fixed-refresh. Can’t shake it.
One weird thing I did just now notice, is that it seems somehow driven by the game’s concept of time – if I hit [capslock] to go 4x, the stutters happen every 8 frames (nb: not 22, but 8?)… enough to drop my p90 down to match my p99 which is how I noticed that effect.
But at the normal sim time rate, it seems disconnected from wall-clock time … it is always 87 frames, regardless if I’m running v-sync with monitor at 60hz (~1.4 sec) or 85hz (~1 sec) or 100hz (~0.87 sec)… or if I’m running triple-buffer with a cap of 120 (~0.725 sec)
[Edit: added links to graph and csv log file]
-
-
I’m curious, what monitor model do you have?
Aoc Agon AG352UCG
https://www.tomshardware.com/reviews/aoc-ag352ucg-curved-g-sync-gaming-monitor,5280.htmlIt’s nice but not great … a few years old now.
-
You can also play in monitor settings with overdrive set to medium. I got the CU34G2X/BK few weeks ago and I discovered a good compromise in medium to have a good ms result.
Cheers
-
-