RealNC wrote:Chief Blur Buster wrote:RealNC wrote:If this is true (it seems plausible), one has to wonder how VRR copes with this.
During VRR, scan velocity is constant. For GSYNC 30-240Hz, the frames are scanned 1/240sec regardless of current framerate/refreshrate. If you lower refresh rate to 120Hz, and get a GSYNC 30-120Hz range, the frames are scanned 1/120sec regardless. Scan velocity is fixed, only the intervals between scanouts varies.
Nah, I mean the pause between scanouts gets too long.
But never mind. I forgot that VRR
already starts doubling frames (scanning them out twice or more) to prevent color loss. With very fast TN panels, this simply would start to happen sooner; usually at around 40FPS for many monitors, but super-fast panels would require that to happen even at 60FPS.
Oh yes, when the pause between scanouts become too long, another duplicate scanout occurs. Assuming the refresh recycle hasn't degraded visibly, the duplicate scanouts are virtually invisible to eyes. (Note, LCD color accuracy may degrade a percent or few, if left unrefreshed too long.)
However, you ideally want to time the repeat-refresh scanout so that the duplicate scanout doesn't hold up the next scanout if the current frame render completes shortly (e.g. a frame interval that was slightly a miss -- 1/29.9th of a second -- for a 30Hz bottom for GSYNC/FreeSync -- that scanout for a refresh cycle for a fresh frame -- will be delayed by the current now-in-progress repeat refresh cycle of the previous frame.
Solutions have been found to avoid these timing collisions of "repeat-refreshes" (of previous frame) versus "unexpectedly-slightly-too-late" (of new frame). This is called Low-Framerate Compensation. AMD did this first, but I believe GSYNC has also followed suit as it's a technologically simple add-on to extend the lower range of the VRR monitor.
Basically, it reschedules the repeat-scanouts (duplicate refresh cycles) to avoid interfering with the timing of refresh cycles with fresh scan-outs.
So if content is playing at 24 frames per second, it will time the repeat-refreshes roughly halfway between -- by running at 48Hz (with 1/48sec between scanouts). Likewise, 20fps would result in a 40Hz refresh rate (with 1/40sec between scanouts), and 17fps would result in a 34Hz refresh rate (with 1/34sec between scanouts). Basically repeat-refresh cycles are intentionally done 'early' to prevent holding up new-frame refreshes.
The repeat-refreshes don't even have to be precisely in between (as long as VRR logic is very good -- good overdrive, good inversion -- to minimize VRR artifacts). For very good VRR< the repeat refresh cycles are quite completely invisible as long as they don't fudge the timing of refresh cycles for freshly new frames.
Scanout velocity is always done at the fastet refresh cycle speed (current top end of currently configured VRR range). So if the monitor is configured to a max 144Hz VRR range -- then the repeat-refresh scanouts are always 1/144sec long each. So the repeat-refresh scanout has to begin occur at least 1/144sec earlier than the next brand new frame -- to prevent delaying the scanout for a brand new frame (Which potentially adds a microstutter caused by not being able to refresh exactly when the frame was completed).
For a 240Hz VRR monitor, it is easier to void repeat-refresh scanouts from colliding with the timing of new-refresh scanouts, because scanout is 1/240sec (only 4.1ms). So in this case a higher Hz VRR range actually makes it easier to lower the bottom end of the range via Low Framerate Compensation (and similar algorithms). Easily as low as single-digit frames per second.
Repeat-scanouts are invisible (24fps@48Hz is exactly the same looking as 24fps@24Hz) except for extremely minor artifacts such as variable-speed modulating patterns within LCD inversion test patterns (the voltage for each pixel inverts every scanout, negative->positive and positive->negative, usually in a fine-checkerboard pattern) -- see
www.testufo.com/inversion and both the Lagom/Techmind links on that. Inversion artifacts (on certain VRR displays) can modulate at varying speeds depending on the timing and frequencies of the scanouts.