jorma wrote: ↑05 Dec 2019, 05:14
Now this confusion is very technical and kind of unnecessary, but I just want to understand what V-SYNC actually does here.
It's not traditional, standalone "V-SYNC" during "upper" (early frame) and "lower" (late frame) frametime variations in these specific instances, but a direct function of G-SYNC that V-SYNC "Off" disables. I'm not sure how many more times or ways I can say this.
I guess I should ask, do you know the actual, technical difference between G-SYNC and V-SYNC, and why traditional V-SYNC causes input lag? Because the way you're both presenting your questions tells me you might not. This is important if you fully want to understand the difference between G-SYNC with the V-SYNC option enabled, and standalone V-SYNC.
Suffice to say, using an FPS limiter prevents the traditional form of V-SYNC input lag both with G-SYNC + V-SYNC and standalone V-SYNC. So what we're talking about here is when we're already preventing V-SYNC input lag, and what the V-SYNC option does with G-SYNC once that's off the table.
jorma wrote: ↑05 Dec 2019, 05:14
What I understand ilzed has been saying - isn't that one individual frame, which causes tearing without V-SYNC, technically out of the G-SYNC range? And in the case of that individual frame technically V-SYNC acts as it traditionally does and prevents tearing from happening.
No, it's actually out of the monitor's physical "range" to otherwise display
tear-free, which is why I call the V-SYNC option with G-SYNC frametime "compensation."
"Render" time (aka frametime) of a frame is entirely separate of display time. A frame can be rendered, fully completed, and ready to deliver to the display, and theoretically sit in the buffer forever.
In other words, the frame first has to render, which takes x amount of (frame)time, and then the display has to scan it in, which takes a separate x amount of time; a reason why most forms of sync run on a double buffer, including G-SYNC; one buffer has a frame rendering while the other buffer has an already rendered frame scanning into the display simultaneously. Once the rendered frame has completely scanned into the display in buffer A, buffer B's frame is now fully rendered and ready to start scanning in, at which point the two buffers swap positions, repeat.
With the V-SYNC option enabled, G-SYNC will sync any frame, be it too late or too early, to the display's scanout time, as to completely avoid tearing.
With the V-SYNC option disabled, G-SYNC will only sync frames that are within the display's scanout time, and let any frame that is ready too late or too early, tear.
To put it another way, both G-SYNC and any form of standalone V-SYNC use the VBLANK (the span between the previous and next frame scan) to determine the starting point of each scanout cycle, and time delivery of the frame to the beginning/top of that scanout cycle, all the way to the end/bottom of that scanout cycle as to prevent tearing, repeat.
The V-SYNC option controls in what conditions G-SYNC will adhere to the VBLANK.
jorma wrote: ↑05 Dec 2019, 05:14
Theoretically, if we would have a perfect FPS-limiter -program that would keep framerate inside the G-SYNC range in the upper limit, and a system that never freezes, so that framerate is always withing the G-SYNC range in the lower limit, then V-SYNC would be unnecessary? Theoretically.
Correct, but in that case, G-SYNC would be unnecessary, in fact, all forms of sync would be, because no frametime fluctuation means no framerate fluctuation, which effectively means an unlimited framerate that can be perfectly capped to any desired limit, and thus you could steer the tearline anywhere you'd like and keep it there permanently.
What you're suggesting is very similar to
RTSS Scanline Sync, yet that runs into the same limitations in the real world, as frametime and system performance varies at any given time, and if it drops below your limit, you'd need something like G-SYNC again to avoid tearing.
jorma wrote: ↑05 Dec 2019, 05:14
Or does V-SYNC also something else when paired with G-SYNC what I don't understand? Here's a couple of comments from jorimt that led to my confusion:
"
With G-SYNC enabled, "V-SYNC" is not "V-SYNC." It is instead (as far as can be figured) effectively a flag at the driver level that permits G-SYNC to allow itself to compensate for sudden frametime variances." (neogaf.com forums)
"
V-SYNC does do something in the G-SYNC range, which is primarily adhering to the VBLANK at all times (something that G-SYNC + V-SYNC “Off” does not do)." (G-SYNC 101 comment section)"
Again, wouldn't that individual frametime be actually out of G-SYNC range but what V-SYNC then prevents from happening?
Again, when you disable the V-SYNC option with G-SYNC, you're actually removing part of G-SYNC's core functionality. G-SYNC + V-SYNC "Off" is a still functional, but not "complete" form of G-SYNC.