Re: NV DB Vsync + RTSS limit
Posted: 05 May 2017, 09:55
Who you gonna call? The Blur Busters! For Everything Better Than 60Hz™
https://forums.blurbusters.com/
Fantastic illustration!chiaisthewei wrote:
Fantastic, it's already done. Like minds thinks alike!
Yeah that's no problem, I actually drew it from various illustrations from people in this forum anyway, because I wanted a clear idea. I don't think it's entirely correct based off comments by sparky and you.Chief Blur Buster wrote:Fantastic illustration!chiaisthewei wrote:
I believe it looks mostly correct -- except for some clarifications.
--> "Vsync On No Cap" is really "Fast Sync" or a form of triple buffering (the low-lag kind), and F-numbers should be shifted 1-left. (I think).
--> "VSYNC ON" capped to refresh rate, is regular "VSYNC ON" -- it's self-capping. Pre-capped. API's with VSYNC ON waits to flip before returning to game.
--> First row really should be called "Default VSYNC OFF Behaviour" (or something like that)
--> Fourth row really should be called "Default VSYNC ON Behaviour" (or something like that)
--> First and Fourth rows should probably become First & Second Rows, because they're the most common settings.
--> VSYNC ON can vary quite a lot. I've seen slightly lower-lag VSYNC ON occur (F-numbers shifted 1 left) and higher-lag VSYNC ON occur (F-numbers shifted 1 or 2 right -- especially with higher "Queue Depth" numbers)
--> Second row is the least accurate, but may be occuring with Borderless Windowed + Compositing + VSYNC OFF. (compositing converts VSYNC OFF to VSYNC ON look).
Other than terminology clarifications, and row #2, your graph looks correct.
Also, "Fast Sync" in full screen is similar behavior to: Borderless Windowed Mode + Windows Compositing + VSYNC OFF (which can have similar tearing-free "Fast Sync" behavior) ... However, there can be extra lag caused by compositing overhead which shifts all the F-numbers 1 refresh cycle forward (though it may not be this simple, especially with the newer low-lag Game Mode of Creator's Update)
Other readers, any errors in this diagram?
Would you like to give jorimt permission to use (recreate) this diagram in one of his GSYNC-101 Series articles?
That said, variable refresh rates and strobing (Motion Blur Reduction / ULMB / LightBoost) aren't always easy to be done simultaneously.chiaisthewei wrote:It seems like the "best" overall solution is simply variable refresh rate since that solves rendering queues, variable frame rates which is a lot likelier than stable frame rates, and smoothness of motion. But of course, that involves buying a new monitor and/or graphics card for many people who have existing systems.