Correct.lc155 wrote: ↑01 Jul 2020, 15:59So in practical terms, to see if I understand this correctly, given my first example:
With a 144Hz G-SYNC Compatible 38GN950, I can safely leave the monitor at 144Hz (or 160Hz with the supported OC) and, while running Dolphin, LFC will ensure G-SYNC is always activated even if the game is running at 30fps instead of 50/60. G-SYNC will also ensure that the frames are updating at the maximum possible speed instead of waiting for fixed Hz intervals, meaning that lag will be as minimal as it can possibly be, and you won't suffer from juddering in motion caused by non-integer division (such as a 24fps film running on a 60Hz monitor where it doesn't cleanly divide). As G-SYNC is taing care of all of this, changing the monitor refresh rate to be an integer division of the game (such as 120Hz for a 60Hz game) is therefore redundant and unnecessary.
Does that sound right?
The software controls the refresh cycles of a VRR monitor. Frame presentation immediately begins the refresh cycle.
For software developers, your Update() or Present() or glxxSwapBuffers() is controlling the timing of refresh cycles
The frame rate is the refresh rate, the refresh rate is the frame rate, there is no difference. 55fps looks like perfect 55Hz VSYNC ON. 75fps looks like perfect 75Hz VSYNC ON. And framerate fluctuations can go stutterless, as seen in animation at www.testufo.com/vrr
Correct.lc155 wrote: ↑01 Jul 2020, 15:59also read (I think from you) somewhere that while the implementation of LFC (and the G-SYNC module version of it I think) can have issues with stuttering at low frames, this has more to do with uneven frame pacing/timing (aka framerate is jumping all over the place and isn't stable). In short, a 30fps emulated game that is running stable should be a perfect application for smooth LFC?
LFC stutter is caused by unpredictable frame presentation colliding with a monitor that’s still busy scanning out.
The new frame needs to wait for the monitor to finish scanning out a repeat-refresh (to prevent the refresh from fading....kind of like display equivalent of a a DRAM refresh). That frame wait cycle creates a disjoint between presentation time and visibility time, creating stutter.
But if frame rate is consistent, the repeat-refresh(es) will be predictively timed successfully between frames (without timing interference)
Also a very high max Hz, such as 240Hs, means the LFC penalty is only, at worst, a 4.2ms delay. And the LFC prediction logic has wider safety margin of timing windows since the monitor is idling much longer between ultra-fast-velocity scanouts. Also, even if LFC collides with a monitor-busy, the worst case stutter-jump only 1/4 the stutter width as 60Hz. So wide VRR ranges (30Hz-240Hz) usually have no visible LFC stutter even for erratic frame rates below Hz (erratic framerate games).
Also, are you considering motion blur reduction too? See https://blurbusters.com/blur-busters-approved
Yes,lc155 wrote: ↑01 Jul 2020, 15:59I believe this was the video in question. He talks about how certain arcade games run at really esoteric framerates which result in juddering on standard displays, whereas VRR can kick in here and correct for that (as forcing old games to run at higher frame rates just results in them speeding up). It's a fairly old video now but I imagine the point remains the same.
VRR allows the emulator frame rate to be the refresh rate. There is no semantic difference between frame rate and refresh rate when inside VRR range. Problem solved.