G-Sync stuttering with quick fps fluctuations with V-Sync on

[lexlazootin]

Is this a extremely specific issue that effects less then 0.01% of the population? yes it is

I recently found that when you run G-Sync and V-Sync on at the same time it can causes added stuttering when fps quickly changes from 100 to 4

phpBB [video]

Watch the fluctuations happen after i adjust my fps in the top left corner.

G-Sync + V-Sync: Massive stuttering when quickly changing
G-Sync + V-Sync Off: Removed most of the stuttering
V-Sync Off: Pretty much all removed
V-Sync: Pretty much all removed

If anyone is curious we do actually use many fps binds in HL speedrunning to clip though tripmine and do numerous other tricks.

So if you have to quickly adjust your fps, make sure you have G-Sync and V-Sync off or just don't run G-Sync

[jorimt]

Very specific indeed

It's because G-SYNC + V-SYNC On, unlike V-SYNC OFF or G-SYNC + V-SYNC Off, has to time the start of the next frame to the beginning of each scanout, so in the worst case scenario, you're looking at up to an additional half frame of delay (in this context, "recovery time" from frametime spikes) when compared to the other two scenarios, thus the additional "stutter," no matter how slight.

Only thing that would fix this, is virtually no instances of frametime spikes, which is mostly possible (short of loading screens) in a game like this when you're not simulating them to show the issue off, but obviously not possible in most AAA games on current systems.

Still a better behavior/recovery time than standard double buffer V-SYNC, but it's always going to be a weakness of scanout adherence methods with variable frametimes/abrupt framerate changes.

For this very reason, it's probably a good tip for those that use G-SYNC competitively to set G-SYNC + V-SYNC Off in these very specific instances when frametime spikes are a worry, as to avoid this issue. It's gonna tear sometimes obviously, but it may be worth the trade-off, and you'll still have the benefit of G-SYNC the majority of the time.

[RealNC]

Well, some games trigger this behavior a lot. I played Lost Horizon the other day and it stutters like crazy during cutscenes or when going to different areas because of this.

Gsync takes way too long to recover from stalls.

[lexlazootin]

MB: ASUS ROG Maximus X Hero CPU: i7-8700k @4.3GHz

You have a Asus Hero and you're running 4.3?! you can push like 300watts through those VRMS.

[jorimt]

Gsync takes way too long to recover from stalls.

Yup, again, up to an additional half frame with G-SYNC + V-SYNC On (which can add up quick with frequent frametime spikes at higher frametimes) over V-SYNC OFF, but unavoidable with how the scanout works if tearing is to be avoided 100%, and still better than standalone V-SYNC. There's also always the option of G-SYNC + V-SYNC Off for problem games.

You have a Asus Hero and you're running 4.3?! you can push like 300watts through those VRMS.

Ha, yes. I have a lot of headroom.

I tried a 5GHz overclock, and can easily accomplish it, but why have 75c+ temps and constant higher voltage over a lower adaptive voltage with 40-50c temps if you gain less than two frames on average in current GPU-heavy AAA games? CSGO or the original Crysis may benefit from the single core clock bump, of course, but I don't play them enough to justify it currently.

4.3GHz on this 8700k has been more than enough for all the recent AAA games I've played (frametime performance included), and is still effectively twice as fast as my previous 4770k, which was OCed to a modest (but stable) 4.2 GHz (my 4770k didn't overclock very well).

I will begin messing with overclocks when the games I play demand it, however.

[RealNC]

Gsync takes way too long to recover from stalls.

Yup, again, up to an additional half frame with G-SYNC + V-SYNC On

Actually it takes dozens of frames to recover in some cases. It will stutter badly (~5FPS) for half a second before it resumes normal operation. The aforementioned game (Lost Horizon) triggers this constantly, as it completely freezes (0FPS) while loading the data for cutscenes, and once the cutscene starts, gsync produces a stutter-fest for half a second or so.

[jorimt]

Right, up to a half frame each instance/individual frame, with the "up to a half frame" value being equivalent to whatever the current frametime is; that can add up at higher frametimes, especially if there are several spikes in quick succession.

Due to the nature of the scanout, this can't really be fixed; it is a limitation of the display technology, not G-SYNC.

It can be lessened by progressively lower max scanout times on higher refresh rate displays (240Hz, 480Hz, 1000Hz, etc), but G-SYNC still requires relatively steady frametimes to function optimally.

[Chief Blur Buster]

Interesting! Frequent entry/exitting of VRR range can produce stutter side effects -- The games I play don't have that "wild fluctuations all the time" that manifests these problems, but it's certainly a niche edge case!

I am wondering if it's the nature itself -- or the nature of low framerate compensation technologies (LFC) "mispredictions" occuring (LFC works best when it can correctly predict future frametimes -- easier during consistent frame rates -- to time the redundant scanouts seamelessly away from predicted frame delivery times) -- basically mispredicted repeat-refresh-cycle scanout timings that collide with frame delivery timings. If it's LFC misprediction stutter, I wonder if disabling LFC-type features fixes these stutters?

I don't think this is a big factor (a frame delivery collision with scanout would be a 1/240sec frame delay during VSYNC ON during 240Hz -- a tiny microstutter at low framerates) and other things in the game engines are more the culprit, but I wonder if it would help this specific niche case a little. Because you say it improves with GSYNC + VSYNC OFF. So I wonder if disabling any LFC-like features would help improve this specific niche behaviour any (or not).

[jorimt]

From what I know (not everything), it's as simple as the fact that G-SYNC + V-SYNC On must wait to align frames to the top of the scanout (e.g. display complete frames starting at the beginning of the scanout), and the other two (V-SYNC OFF and G-SYNC + V-SYNC Off) do not.

So, to explain in grossly simple terms, if player input or whatever update is made during the first 1/4 of the scanout, the update is going to be reflected as quickly as possible with V-SYNC OFF and G-SYNC + V-SYNC Off (tearing), whereas G-SYNC + V-SYNC will be forced to wait that remaining 3/4 (or whatever given fraction) of the previous scanout until the next begins to display the complete frame containing that update to avoid tearing.

When severe frametime spikes hit (e.g. very high frametimes = very slow render completion time per frame), especially in quick succession, you can see where this may build up and become problematic if tearing is to be 100% prevented. EDIT: Whether this issue is caused solely by sudden dips to low framerates/high frametimes and back, or by the interaction between the sudden dips AND possible timing errors of the LFC/minimum refresh range, I'm not sure.

It's possible they could improve the response time to the VBLANK in these instances (however they are using it with G-SYNC currently), but the scanout time is always going to be the limiting factor if it is to be adhered to, especially with variable frametimes/framerates.

Double buffer V-SYNC has similar behavior to G-SYNC + V-SYNC On in these instances, but it's masked by the recurring stutter that happens in the higher range (with an fps limit just below the max refresh rate), along with the frame repetition that occurs with double buffer lock (60/30/60/30, etc) and delayed frame delivery caused by the over-queuing of buffers above the refresh rate (without an fps limit), so it is less of a contrast in those instances.

Other causes are possible (and again, my assumption is grossly simplified), but I don't know what they would be. It doesn't help that there is little to no documentation on how G-SYNC uses the VBLANK (and if it truly has a "ping" time or not), nor is there much info on the deep inner workings of the minimum refresh range.

[Wooohah]

So is this only in regards to a HUGE fluctuation in FPS such from 240 to 40?
I'm experiencing frametime spikes as well in slightly less massive differences in FPS. For example, sometimes when my FPS goes from 120 to 80, ill experience some frametime spikes, generally it looks like a light hitch.

Are frametime spikes just inherently a design flaw of Gsync when it comes to FPS drops or fluctuations in FPS?