Tripple Buffering, Nvidia FastSync, Display Chains

Discussion in 'Architecture and Products' started by pharma, May 29, 2016.

  1. pharma

    Veteran Regular

    Joined:
    Mar 29, 2004
    Messages:
    2,888
    Likes Received:
    1,593
    Nvidia Fast Sync
     
    #1 pharma, May 29, 2016
    Last edited: May 29, 2016
  2. Alessio1989

    Regular Newcomer

    Joined:
    Jun 6, 2015
    Messages:
    580
    Likes Received:
    284
    waiting for fast-sync monitors :mrgreen:

    lolj
     
  3. ninelven

    Veteran

    Joined:
    Dec 27, 2002
    Messages:
    1,699
    Likes Received:
    117
    ?

    It works on all monitors / any refresh rate.
     
    A1xLLcqAgt0qc2RyMz0y likes this.
  4. DieH@rd

    Legend Veteran

    Joined:
    Sep 20, 2006
    Messages:
    6,084
    Likes Received:
    2,014
    FastSync enables GPU card to cache finished frames and only send the freshest one when the display is ready to show next frame. The game engine does not get throttled when rendering during any part of the work. It works best when rendering framerate is much higher than the display refresh rate.

    It will work on Maxwell&Pascal cards and any monitor.
     
    #4 DieH@rd, May 29, 2016
    Last edited: May 29, 2016
    A1xLLcqAgt0qc2RyMz0y likes this.
  5. Ext3h

    Regular Newcomer

    Joined:
    Sep 4, 2015
    Messages:
    337
    Likes Received:
    294
    And what's the difference to plain old triple-buffering with Vsync on? Either I don't understand triple buffering, or Nvidia just announced a 20 year old technique as their own invention...
     
  6. SimBy

    Regular Newcomer

    Joined:
    Jun 21, 2008
    Messages:
    502
    Likes Received:
    135
    I believe the buffer fills and backpressure causes latency again.
     
    pharma likes this.
  7. Ext3h

    Regular Newcomer

    Joined:
    Sep 4, 2015
    Messages:
    337
    Likes Received:
    294
    There is no backpressure with triple buffering. Only with plain double buffering.

    I know, the Nvidia guy presenting "Fast Sync" claimed that with triple buffering the buffers could "fill up", but that's just plain wrong. The two back buffers are flipped every time one is filled, and the outdated one is then overwritten, while the last fully rendered one may be flipped to the front. (Unless Nvidias implementation of triple-buffering was really screwed up, and their engineers actually didn't knew you had to do a back buffer flip, wrongly abusing the triple buffer as a chain instead. Not saying there aren't scenarios where you want that, but that's not what you call triple buffering.)

    But the guy also claimed that V-Sync would be defined as every rendered frame also being displayed (hint: that's not what it means, only that the front buffer flip is synchronized with refresh blank), so I wouldn't give too much on what he says.

    Buffer fills are a legit objection (at least if we consider the historic implementations), but buffer flip should actually happen via memory mapping nowadays.
     
    Kej, Malo and BRiT like this.
  8. trinibwoy

    trinibwoy Meh
    Legend

    Joined:
    Mar 17, 2004
    Messages:
    10,418
    Likes Received:
    411
    Location:
    New York
    SimBy already answered. I think with triple buffering you can still have back pressure if the card is fast enough. With Fast sync it will drop any extra frames so there's less concern about latency.

    If triple buffering also discards extra frames then there's no difference.
     
    pharma likes this.
  9. MDolenc

    Regular

    Joined:
    May 26, 2002
    Messages:
    690
    Likes Received:
    425
    Location:
    Slovenia
    GPU could render ahead creating a sequence that flip chain will have to follow (latency) even with triple buffering.
     
    CSI PC likes this.
  10. Ext3h

    Regular Newcomer

    Joined:
    Sep 4, 2015
    Messages:
    337
    Likes Received:
    294
    Yes, for Nvidia cards controlled/overridden by the "maximum pre-rendered frames" setting in the application profile. Unfortunately with an unreasonable high default, and only becomes active when also activating V-Sync, leading to the common missattribution of the resulting input lag to the V-Sync option.

    I strongly believe that all "Fast Sync" actually is, is forcing triple buffering + V-Sync, plus setting "maximum pre-rendered frames" to 0.
    Only the latter two options were exposed in the control panel before, but for <=DX11 titles, you could try to enforce triple buffering before with tools like D3DOverrider.
     
    BRiT likes this.
  11. CSI PC

    Veteran Newcomer

    Joined:
    Sep 2, 2015
    Messages:
    2,050
    Likes Received:
    844
    However this can be balanced by the TechReport article about the AMD Crimson edition drivers and when they say the following regarding Triple buffering:
    http://techreport.com/review/29357/amd-radeon-software-crimson-edition-an-overview

    TBH I think in theory Triple Buffering is great, but it is not applicable to all situations, not even sure one can say it is even applicable to most.
    Cheers
     
  12. Ext3h

    Regular Newcomer

    Joined:
    Sep 4, 2015
    Messages:
    337
    Likes Received:
    294
    Eh... what? Why are they using "triple buffering" synonymous with a 3 buffers long swap chain?
    Oh. I love it when terms are being reused like that...

    So, no, that article refers to the "other" type of triple buffering following Microsoft's terminology (render ahead), not the original one (page flip).
    Equivalent to "maximum pre-rendered frames", except that the Crimson driver doesn't expose this option.

    Got to agree with Anandtech here:
    http://www.anandtech.com/show/2794/4
     
  13. CSI PC

    Veteran Newcomer

    Joined:
    Sep 2, 2015
    Messages:
    2,050
    Likes Received:
    844
    I really should had looked at the diagram but as they said simplified I skipped them lol.
    I assumed as they referenced AMD they were not talking about the historical flip queue-render ahead (name I think Nvidia used).
    Just curious if triple buffering was enabled how did Catalyst-driver handle the flip queue in the past?
    Just wondering if this is where the historical debate about input lag is all coming from.

    My bad :)
    Edit:
    NVM.
    I see that AMD in the past recommend forcing flip queue to 1 (default is 3 which is why I was curious how it worked or if dynamic) when enable triple buffering.
    This is through RadeonPro.

    Cheers
     
    #13 CSI PC, May 30, 2016
    Last edited: May 30, 2016
  14. Ext3h

    Regular Newcomer

    Joined:
    Sep 4, 2015
    Messages:
    337
    Likes Received:
    294
    There is no triple buffering with Direct3D. The swap chain is a pure queue.

    And yes, that's most likely the reason why most gamers associate triple buffering with high latency, respectively V-sync in general, as the swap chain is only used together with V-sync.

    Even e.g. CS:GO has a "triple buffering" option, which would - following that logic - refer to an extra long flip queue, and not to actual triple buffering. Now it makes sense why there are so many complains about the poor performance of that option, and why users claim the could boost the performance of that option by enforcing "maximum pre-rendered frames", which essentially means that they just overrode the option they just activated.
    I couldn't make any sense of this before.

    But we have seen at least one example of real triple buffering on AMD hardware before, and that was DX12 version of AotS, except that the buffer flip was apparently implemented on the application side.

    Btw.: Not even Nvidias speaker knew that there are two features by the same name: https://www.youtube.com /watch?v=WpUX8ZNkn2U&t=15m20s (Breaking it to preserve the timestamp.)
     
    #14 Ext3h, May 30, 2016
    Last edited: May 30, 2016
  15. CSI PC

    Veteran Newcomer

    Joined:
    Sep 2, 2015
    Messages:
    2,050
    Likes Received:
    844
    Just to add Direct3D toolwise there was RadeonPro and still is Riva Tuner (D3DOverrider) from a more general approach to triple buffering, although I have never seen any analysis on them in this specific setup.
    Cheers
     
  16. CSI PC

    Veteran Newcomer

    Joined:
    Sep 2, 2015
    Messages:
    2,050
    Likes Received:
    844
    Coming back to the input lag with Triple Buffering.

    OK I found a site (http://www.displaylag.com/) that is measuring input lag and also using these Direct3D tools to enable triple buffering; they used a fighter "arcade game" as these are probably the most sensitive to input lag due to requirements for combo's/competitions/etc.
    At first I was not sure about the guy doing the tests, but looking further his results seem pretty accurate with his GSYNC and FreeSync; here he noticed a slight lag with GSYNC compared to VSYNC Off, and that FreeSync is slightly faster than VSYNC Off.

    Anyway there does seem to be input lag caused by triple buffering ONLY when compared to pure VSYNC off performance - which is where most of us were coming from when comparing Triple Buffering performance.
    In essence Triple Buffering causes no input lag when compared to purely VSYNC On.
    Measurements were based off 60Hz test.
    D3DOverrider I think involved Hilbert Hagedoorn who is also involved in MSI Afterburner.

    Nvidia:
    V-Sync OFF 59ms 3.5 frames
    V-Sync ON (D3DOverrider) 115ms 6.9 frames
    V-Sync ON + Triple Buffering (D3DOverrider) 120ms 7.2 frames

    AMD:
    V-Sync OFF 61ms 3.7 frames
    V-Sync ON (D3DOverrider) 106ms 6.4 frames
    V-Sync ON + Triple Buffering (D3DOverrider) 109ms 6.5 frames

    The guy does understand and also analysed flip-queue and pre-rendered frames and sets them correctly if forcing triple buffering.
    http://www.displaylag.com/reduce-input-lag-in-pc-games-the-definitive-guide/

    The tables for AMD and NVIDIA are 2/3rds of the way down and titled: Nvidia GeForce Input Lag Results (60hz): , and AMD Radeon Input Lag Results (60hz):
    Each result given in the table also has a youtube video showing 10 iterations captured to give an average.

    Looks like he also based his approach from the B3D topic:https://forum.beyond3d.com/threads/...or-available-games-read-the-first-post.44653/
    Cheers
     
    Kej, firstminion and pharma like this.
  17. CSI PC

    Veteran Newcomer

    Joined:
    Sep 2, 2015
    Messages:
    2,050
    Likes Received:
    844
    Another consideration beyond my post above that can influence this discussion.
    Fullscreen vs Windowed vs Borderless.

    This will also have further implications with regards to the discussion and context.
    Cheers
     
  18. Alessio1989

    Regular Newcomer

    Joined:
    Jun 6, 2015
    Messages:
    580
    Likes Received:
    284
    I was joking xD
     
  19. ninelven

    Veteran

    Joined:
    Dec 27, 2002
    Messages:
    1,699
    Likes Received:
    117
    One thing I don't get is this is, AFAICS, just better in every way than Vsync. So why have Vsync at all going forward, just make this the new Vsync and do away with the old...
     
  20. Ext3h

    Regular Newcomer

    Joined:
    Sep 4, 2015
    Messages:
    337
    Likes Received:
    294
    When comparing this straight to how Vsync was implemented in DX applications, there are actually a couple of differences. What typically makes Vsync so bad isn't delay for the synchronization, it's the render ahead queue stacked on top of it to preserve the GPU utilization despite Vsync. It's not wise to get rid of that though, as it also masks micro stutters (due to e.g. texture loads) quite well.

    And it's not free of downsides either, as rendering frames which are not ever going to be displayed is just a pure waste of energy. Full double buffered Vsync with only 1-2 frames rendered ahead is a pretty efficient way to conserve energy, as it also doubles as a (desired) frame rate limit. Without the downsides of setting a frame rate limit without Vsync, as that may still cause tearing. With real triple buffered Vsync, you are wasting just as much energy as without Vsync.

    If possible, the optimal solution is actually Vsync + frame pacing, as that gets you a minimal latency for the whole frame. Respectively if the frame pacing works correctly, turning Vsync on or off shouldn't make a difference (in theory!) as the present should be timed properly with the V-blank. It's pretty difficult to tune that correctly though, as every micro stutter in the render path will also cause the pacing to be thrown off.
     
    Lightman likes this.
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...