Is someone able to explain how "Async" and "Back edge sync" differ? Thanks

Discussion in 'Rivatuner Statistics Server (RTSS) Forum' started by BlindBison, Apr 22, 2023.

  1. BlindBison

    BlindBison Ancient Guru

    Messages:
    2,419
    Likes Received:
    1,146
    GPU:
    RTX 3070
    I have read the description notes within RTSS several times and I think I understand the difference between "Async" and "Front edge sync", but not the difference between "Async" and "Back edge sync". As I understand it, the CPU releases a frame buffer to the GPU then the GPU does its work and releases the final completed frame to the monitor (so, CPU -> GPU -> Monitor).

    By default RTSS uses the "Async" mode and its overlay frametime calculation point is the "frame start". So RTSS is limiting the step where the CPU releases the frame buffer to the GPU and is also measuring the accuracy of that release timing. Since the GPU will still take a variable amount of time to do its work on each frame then release it immediately to the monitor in the case of G-Sync/Freesync panels I think this is why you see variation in frametime when limiting with Async mode and measuring frametime calculation point with frame presentation instead of frame start. I believe this is why the note says when using async/back edge sync "frame start" will be flat but "frame presentation" will be jittering and vice versa when using front edge sync. So far so good.

    What has me stumped is the difference between "Async" and "Back edge sync" however. The note says these two perform closely to each other and it seems both are trying to limit the framerate in terms of the CPU releasing frame buffers to the GPU. Is the difference only how they handle drops below the target framerate? Will there be no difference then so long as the set limit is maintained? Or is it that there might be some difference in frame present times? I keep re-reading the note and I'm not getting it. Thanks!
     
    Last edited: Apr 22, 2023
  2. Unwinder

    Unwinder Ancient Guru Staff Member

    Messages:
    17,199
    Likes Received:
    6,870
    Back edge sync is synchronized to a clock period ticking each <target_frametime> milliseconds. So if stutter is having a place (i.e. frametime becomes greater than <target_frametime> for some frame) it will ignore framerate limit for the next single frame to compensate stutter and sync timings to the clock period again.
    Async is not synchronized to a clock, it keeps exact time deltas between the frames fully equal to back edge sync mode when framerate is above the limit, but it allows timings to drift after stutter and don’t need to sync to anything after that. In this mode you NEVER see a frametime below the limit.
     
    BlindBison likes this.
  3. BlindBison

    BlindBison Ancient Guru

    Messages:
    2,419
    Likes Received:
    1,146
    GPU:
    RTX 3070
    Thank you, that's helpful! Apologies, but I'm still a bit confused. So, typically there will be no difference between the two assuming they reach their target limit 100% of the time if I've understood correctly. The difference then would come into play when a dip beneath the target limit occurs (e.g. an increase in frametime)?

    As I've understood it this is what would happen assuming a dip beneath the target framerate occurs:
    1) Back edge sync capped to 30 FPS (uses a clock ticking period) -> dip to 29 fps occurs (increase in frametime) for one single frame -> RTSS displays this particular frame which had an increase in frametime as quickly as possible/as quickly as it is rendered.

    What happens to the next frame following this one though? I would think it would depend on whether the framerate reaches 30 again or whether the drop to 29 fps is sustained for longer than one frame. I'm just a bit confused about what this part you stated here means: "it will ignore framerate limit for the next single frame to compensate stutter and sync timings to the clock period again." Does this mean that when a drop below the set limit (increase in frametime) occurs, RTSS just renders unconstrained (normal uncapped rendering behavior) til the frametime reaches the set limit again at which point it resynchronizes to the clock?

    2) For async capped to 30 FPS is the only difference that instead of being synchronized with a system clock RTSS instead tracks the gap/delta between frames (just not when a dip in framerate beneath the target is occurring)? Given that Async is the default I expect this is, in your view, the overall preferred way to framerate limit considering all the pros and cons.

    Thanks for your time, I'm sorry to trouble you. I could be way off, but I imagine it might be possible to both submit frames from the CPU to the GPU with precise timing and then also to have a "wait" period so that the GPU submitting the frame the monitor also has precise timings with no variation albeit with a huge amount of input lag since we're double waiting.
     
  4. BlindBison

    BlindBison Ancient Guru

    Messages:
    2,419
    Likes Received:
    1,146
    GPU:
    RTX 3070
    Love your tool by the way, thank you for the work you do on RTSS. Have had zero issues with 7.3.4 :)
     

  5. Unwinder

    Unwinder Ancient Guru Staff Member

    Messages:
    17,199
    Likes Received:
    6,870
    Imagine that you want to limit framerate to 100 fps, so your target frametime is 10ms. And you render the first 3 frames with 10ms frametime, then you suddenly have a stutter frame taking 18ms. Then you continue smooth rendering with expected target 10ms frametime again.
    For async mode, it will result in the following sequence of frametimes:

    10ms, 10ms, 10ms, 18ms, 10ms, 10ms….

    In this case the limiter simply continues keeping 10ms frametimes after stutter.

    For back edge sync mode the sequence will be slightly different:

    10ms, 10ms, 10ms, 18ms, 2ms, 10ms…

    Short 2ms frame inserted immediately after stutter is intended to compensate it and synchronize the next frames to 10ms clock period. In this case all frames are guaranteed to start at synchronous 10*N time points. For async mode timings of future frames are drifting after stutter.
     
    pegasus1 and BlindBison like this.
  6. BlindBison

    BlindBison Ancient Guru

    Messages:
    2,419
    Likes Received:
    1,146
    GPU:
    RTX 3070
    Thank you very much that’s exactly what I needed and wasn’t getting. Much appreciated!

    Since 2 ms is extremely fast to render out a frame if the subsequent frame can only be rendered in say, 5 ms, would the sequence look like this:

    10ms, 10ms, 10ms, 18ms, 5ms, 10ms…

    Or, if it can’t compensate the full time in one frame will RTSS try to over multiple frames? Something like:

    10ms, 10ms, 10ms, 18ms, 5ms, 7 ms, 10ms…

    *5 then 7 because 18 ms is 8 off the target and 5 is 5 off target in the reverse direction while 7 is 3 off the target in the reverse direction for a total of 8 over multiple frames.

    Sorry to spam you, this is very helpful to know. I’m finally getting to wrap my head around it. Since there is only one mode for “front edge sync” I assume it works more similarly to “back edge sync” with the compensation behavior as opposed to the Async mode. Your example was awesome — Async behavior makes perfect sense to me now. I wonder if the back edge sync compensation has any affect perceptually to the eye on “smoothness”. I will have to do some tests :)
     
  7. Unwinder

    Unwinder Ancient Guru Staff Member

    Messages:
    17,199
    Likes Received:
    6,870
    Neither the first nor the second variant. If the next frame takes longer than 2ms in this example, it will be aligned to the next tick aligned at 10ms boundary. So it will be 10, 10, 10, 18, 12, 10
     
    BlindBison likes this.
  8. Unwinder

    Unwinder Ancient Guru Staff Member

    Messages:
    17,199
    Likes Received:
    6,870
    And yes, front edge sync mode uses exactly the same compensation behavior as back edge sync.
     
    BlindBison likes this.
  9. BlindBison

    BlindBison Ancient Guru

    Messages:
    2,419
    Likes Received:
    1,146
    GPU:
    RTX 3070
    Thank you very much, this has been helpful
     
  10. BlindBison

    BlindBison Ancient Guru

    Messages:
    2,419
    Likes Received:
    1,146
    GPU:
    RTX 3070
    @Unwinder Out of curiosity, do you have a subjective preference for Aync vs Front Edge vs Back Edge yourself? I expect there's no hard "correct" answer as to what's best since one is juggling different pros and cons, but for many I expect Front Edge will be ruled out due to the added latency while Async/Back Edge will down to whether they like the "compensation" approach of back edge.
     
    Last edited: Apr 22, 2023

  11. BlindBison

    BlindBison Ancient Guru

    Messages:
    2,419
    Likes Received:
    1,146
    GPU:
    RTX 3070
    Sorry to keep pestering you, but for the sequence provided here (e.g. 10,10,10,18,12,10) supposing that the frame after 12 is not complete within 10 ms (e.g. there is a sustained and variable drop in FPS below the target) does the back edge sync sequence look like this:

    BE Desired: 10, 10, 10, 18, 2, 10
    BE Reality when the frame following the stutter cannot be rendered out in 2 ms: 10, 10, 10, 18, 12, 10
    BE New outcome when the frame following the 12 ms frame cannot be rendered out in 10 ms: 10, 10, 10, 18, 12, 15, 10
    Or, will back edge try again for the compensation like so: 10, 10, 10, 18, 12 (missed 2 ms compensation so drops to 10+2), 15, 5 (attempts compensation again), 10

    I guess what I find hard to wrap my head around for this is we get what seems like an inconsistent behavior if the drop persists longer than one frame and if the compensation in the other direction on the frametime graph is not fast enough to work on the frame after the stutter. So, what I mean by that is the "desired" outcomes look like the top left and bottom right graphs:
    upload_2023-4-22_12-56-0.png
    But in the bottom left example when we miss that 2 ms compensation target you actually get a longer delay on the following frame than Async would and you're not getting any compensation in the other direction on the frametime graph whatsoever. So, assuming the frame following the 18 ms spike can be sent out at 9 ms Async would deliver the frame at 10 ms and back edge would deliver it at 12. So, I mean Async is 10, 10, 10, 18, 10, 15, 10
    but Back edge is 10, 10, 10, 18, 12 (missed 2 ms compensation so we drop to 12), 15, 10. I could be way off base but I wonder if from a perceptual smoothness perspective if it would be preferable to try compensation in the opposite direction of the stutter over multiple frames with intermediate values rather than dropping all the way down to 12.

    Thank you for your time in attempting to explain this stuff to me, I've searched around and it's not very easy to find such detailed information on this sort of thing :( I really appreciate it, I know you've got a lot to do.
     
    Last edited: Apr 22, 2023
  12. RealNC

    RealNC Ancient Guru

    Messages:
    5,105
    Likes Received:
    3,380
    GPU:
    4070 Ti Super
    I don't know about Unwinder, but I assume you're using g-sync, so you should use async. In the example given above, you don't want a 2ms frame with g-sync (that would translate to 500FPS.) High frametime variation (in this came you're going from 18ms to 2ms in just one frame) should be avoided with g-sync. As nice and steady as possible is preferable.
     
    BlindBison likes this.
  13. BlindBison

    BlindBison Ancient Guru

    Messages:
    2,419
    Likes Received:
    1,146
    GPU:
    RTX 3070
    Thanks a lot that’s helpful :) It’s hard for me to really picture whether or not the human eye would see “10, 10, 10, 14, 6, 10” as being more or less smooth than “10, 10, 10, 14, 10, 10”.

    I did try some basic tests in Witcher 3 RT where I capped the framerate to be just on the cusp of what it could maintain then switched between Async and back edge. So I was trying to just barely drop the framerate. I couldn’t really tell what was placebo honestly. Even if back edge’s “compensation” approach did look somewhat smoother to the eye for whatever reason I would think the fall back when it fails (eg it can’t reach 2 ms so it does 12) would look worse than the 10 ms of Async.

    You mention the importance of g-sync for this consideration. Is the idea they when using traditional Vsync you would want the speed up/compensation effect of BE because of how camera motion is animated or something? I’m just trying to wrap my head around why such an effect would be desired. Seems like I am missing something in all this. Side note it does seem like certain in game limiters on console have a similar “back edge” type compensation in play going off comments digital foundry have made over time. But perhaps I misunderstood there as well.
     
    Last edited: Apr 22, 2023
  14. Unwinder

    Unwinder Ancient Guru Staff Member

    Messages:
    17,199
    Likes Received:
    6,870
    The only real situation when back/front edge sync modes are preferred (and even mandatory) is hybrid scanline sync mode, where you use classic framerate limiter to steer tearline position, so frames absolutely must be synchronized to a clock period equal to you display’s refresh rate. Async mode is not applicable in this specific case because drifting timings after stutter will result in drifting tearline position. For the rest usage cases default async mode is the best choice.
     
    fawfaca and BlindBison like this.
  15. Unwinder

    Unwinder Ancient Guru Staff Member

    Messages:
    17,199
    Likes Received:
    6,870
    The only purpose of compensation is to align frames back to clock period and restore synchronous timings ASAP immediately after stutter.
     
    BlindBison and The1 like this.

  16. BlindBison

    BlindBison Ancient Guru

    Messages:
    2,419
    Likes Received:
    1,146
    GPU:
    RTX 3070
    Thanks a lot, very helpful explanation
     
    Unwinder likes this.
  17. bears.are.cool

    bears.are.cool Guest

    Messages:
    1
    Likes Received:
    0
    GPU:
    4090 / 24GB
    Anyone know whether of the three modes is particularly recommended for smoothness in VR? Specifally, for MS Flight Sim. Thanks!
     
  18. BlindBison

    BlindBison Ancient Guru

    Messages:
    2,419
    Likes Received:
    1,146
    GPU:
    RTX 3070
    In general terms it seems that the default RTSS settings are optimal when all pros and cons are considered (e.g. Async mode, enable passive waiting checked which is default behavior, you can measure frametime by start or present but measuring by start will be what the limiter is actually limiting on in the async or backedge modes). Of course I'm not the most knowledgeable person for these kinds of things so if others have a different view on it perhaps they'll jump in.

    I don't have evidence to back this up other than the BattleNonSense vid briefly covering the Nvidia driver limiter, but it "seems that" their limiter works very similarly to RTSS in its default configuration in terms of frametime consistency and input delay so that's another good option depending on your preference.

    Now, some particular games may have issues with external framerate limiters or they may look smoother without being framerate limited at all (assuming VRR display). At least that's been the case in my own tests. For example I recall certain titles had nasty camera animation stutter when an external framerate limiter was used but in other cases it was the in-engine limiter with that sort of unsmooth behavior. For example, when MCC collection came out using RTSS to limit the framerate to 60 could result in occasional camera animation issues that I never saw with the in-engine limiter but then in other games like Witcher 3 DX12 using the in-engine limiter has apparent camera animation jitter on my rig whereas RTSS appeared more stable to my eye. Regrettably there's possibly not a one size fits all, just general recommendations which will usually work well. I suppose it's possible some games would look "smoother" with Front edge sync mode, but the increased input lag makes it kind of undesirable for many users.
     
    Last edited: Apr 24, 2023

Share This Page