Re Gsync: when the Main Thread is the source....

[Noel]

1 hour ago, neumanix said:

That's how Vsync does it if a frame takes longer than what you've set Vsync lock to. For example if you lock to 60fps and achieve only 55fps, then Vsync drops to 30fps.

Not sure what's happening the background but no matter what the vsync source is major stuttering happens whenever CPU or GPU or both are unable to hit my Vsync target of 30fps.  It seems like you are saying in Gsync when I can't hit the 30fps we get tearing, instead of stuttering, yes?  

[bobcat999]

2 hours ago, Noel said:

Works here Rob w/ the latest NV GRD.  I did get fooled though because I had NVCP set to Vsync:  OFF,  rather than Per 3rd Party Application or whatever it says.

OK.  Thanks Noel.  In that case I am beginning to think simply reinstalling the slightly newer version cured it.  7.3.3 might have just required a simple reinstallation also.  It was quite a few months ago since I used it previously - many windows and graphics driver updates since then! 

[neumanix]

 

21 minutes ago, Noel said:

It seems like you are saying in Gsync when I can't hit the 30fps we get tearing, instead of stuttering, yes?  

Yes, as long as you have Vsync turned off. If on, it will lock to 15fps or 30fps intermittently when fps is fluctuating above/below 30.

[Noel]

2 hours ago, neumanix said:

Well, if the gsync interval starts at 30, then at 27fps it won't be able to sync that frame and you'll get tearing. No more nor less stuttering.

That frame will take 1000/27 = ~37ms. If you had Vsync active it will lock at 15fps, that's the next "half way down", and the frame would take ~66ms = feels more laggy.

That's how Vsync does it if a frame takes longer than what you've set Vsync lock to. For example if you lock to 60fps and achieve only 55fps, then Vsync drops to 30fps.

Vsync locked at 30fps and achieving 27fps would sync at 15fps.

Peter, does what you say agree with this:

Why use Gsync along with Vsync?

The answer is frametime variances.

“Frametime” denotes how long a single frame takes to render. “Framerate” is the totaled average of each frame’s render time within a one second period.

At 144Hz, a single frame takes 6.9ms to display (the number of which depends on the max refresh rate of the display, see here), so if the framerate is 144 per second, then the average frametime of 144 FPS is 6.9ms per frame.

In reality, however, frametime from frame to frame varies, so just because an average framerate of 144 per second has an average frametime of 6.9ms per frame, doesn’t mean all 144 of those frames in each second amount to an exact 6.9ms per; one frame could render in 10ms, the next could render in 6ms, but at the end of each second, enough will hit the 6.9ms render target to average 144 FPS per.

So what happens when just one of those 144 frames renders in, say, 6.8ms (146 FPS average) instead of 6.9ms (144 FPS average) at 144Hz? The affected frame becomes ready too early, and begins to scan itself into the current “scanout” cycle (the process that physically draws each frame, pixel by pixel, left to right, top to bottom on-screen) before the previous frame has a chance to fully display (a.k.a. tearing).

G-SYNC + V-SYNC “Off” allows these instances to occur, even within the G-SYNC range, whereas G-SYNC + V-SYNC “On” (what I call “frametime compensation” in this article) allows the module (with average framerates within the G-SYNC range) to time delivery of the affected frames to the start of the next scanout cycle, which lets the previous frame finish in the existing cycle, and thus prevents tearing in all instances.

And since G-SYNC + V-SYNC “On” only holds onto the affected frames for whatever time it takes the previous frame to complete its display, virtually no input lag is added; the only input lag advantage G-SYNC + V-SYNC “Off” has over G-SYNC + V-SYNC “On” is literally the tearing seen, nothing more.

[Cpt_Piett]

I'm trying to wrap my head around this thread, but I can't see how main thread, frame times and stuttering is relevant to G-Sync. 

• G-Sync and V-sync are both technologies to prevent tearing. Tearing occurs due to a mismatch between the GPU's render rate and the monitor refresh rate. 
• V-Sync solves this by limiting the GPU render rate to the monitor refresh rate. Or, as with MSFS, a fraction of the monitor refresh rate. 
• G-Sync offers more flexibility as the monitor refresh rate is synced to the GPU render rate. 
• G-Sync comes in three flavours - G-Sync, G-Sync compatible and G-Sync Ultimate. The latter is certified for DCI-P3 color gamut coverage and 1,000 nits max brightness with HDR.

I have a 120Hz CX OLED panel which is G-Sync compatible. My particular panel comes with low frame rate compensation (G-Sync works properly even if the framerate drops below 20Hz). I use G-Sync as I let fps run freely and get tearing-free motion up to the TV's max refresh rate. I use RTSS (lock fps to 119) to prevent tearing above the max refresh rate (I frequently get fps higher than 120 when using DLSS3). It does nothing to prevent stuttering which is an entirely different phenomenon. 

The whole point of G-Sync is to be able to have the GPU render at any rate below the monitor's max refresh rate without tearing.

[neumanix]

14 minutes ago, Noel said:

Peter, does what you say agree with this:

Why use Gsync along with Vsync?

The answer is frametime variances.

“Frametime” denotes how long a single frame takes to render. “Framerate” is the totaled average of each frame’s render time within a one second period.

At 144Hz, a single frame takes 6.9ms to display (the number of which depends on the max refresh rate of the display, see here), so if the framerate is 144 per second, then the average frametime of 144 FPS is 6.9ms per frame.

In reality, however, frametime from frame to frame varies, so just because an average framerate of 144 per second has an average frametime of 6.9ms per frame, doesn’t mean all 144 of those frames in each second amount to an exact 6.9ms per; one frame could render in 10ms, the next could render in 6ms, but at the end of each second, enough will hit the 6.9ms render target to average 144 FPS per.

So what happens when just one of those 144 frames renders in, say, 6.8ms (146 FPS average) instead of 6.9ms (144 FPS average) at 144Hz? The affected frame becomes ready too early, and begins to scan itself into the current “scanout” cycle (the process that physically draws each frame, pixel by pixel, left to right, top to bottom on-screen) before the previous frame has a chance to fully display (a.k.a. tearing).

G-SYNC + V-SYNC “Off” allows these instances to occur, even within the G-SYNC range, whereas G-SYNC + V-SYNC “On” (what I call “frametime compensation” in this article) allows the module (with average framerates within the G-SYNC range) to time delivery of the affected frames to the start of the next scanout cycle, which lets the previous frame finish in the existing cycle, and thus prevents tearing in all instances.

And since G-SYNC + V-SYNC “On” only holds onto the affected frames for whatever time it takes the previous frame to complete its display, virtually no input lag is added; the only input lag advantage G-SYNC + V-SYNC “Off” has over G-SYNC + V-SYNC “On” is literally the tearing seen, nothing more.

Yes, I'd agree with that.

[Ianrivaldosmith]

G-sync is one of those things you have to witness. It’s an amazing tech. I couldn’t go back from it. 

[Sonosusto]

Oh wow. I have my sim locked at 30fps and have a 60hz G-sync monitor. I guess I might be doing it wrong. Should I have my Nvidia Control Panel change anything? Currently its just set to High performance but otherwise no changes.

[miker916]

all the theory in this thread is great but in practice what settings need set in MSFS & NVCP to properly utilise GSYNC

[Cpt_Piett]

9 minutes ago, miker916 said:

all the theory in this thread is great but in practice what settings need set in MSFS & NVCP to properly utilise GSYNC

In MSFS: nothing.

In NVCP:

• Main menu => "Set up G-Sync". Enable for windowed and full screen mode
• Main menu => "Manage 3D settings". Under "monitor technology", select: "G-Sync compatible"

There's also an on-screen indicator that will show when G-Sync is active. Go back to "Set up G-sync" on the main menu. Then on the top menu, display=>"g-sync compatible indicator".

[Noel]

17 hours ago, Cpt_Piett said:

I'm trying to wrap my head around this thread, but I can't see how main thread, frame times and stuttering is relevant to G-Sync. 

• G-Sync comes in three flavours - G-Sync, G-Sync compatible and G-Sync Ultimate. The latter is certified for DCI-P3 color gamut coverage and 1,000 nits max brightness with HDR.

I have a 120Hz CX OLED panel which is G-Sync compatible. My particular panel comes with low frame rate compensation (G-Sync works properly even if the framerate drops below 20Hz). I use G-Sync as I let fps run freely and get tearing-free motion up to the TV's max refresh rate. I use RTSS (lock fps to 119) to prevent tearing above the max refresh rate (I frequently get fps higher than 120 when using DLSS3). It does nothing to prevent stuttering which is an entirely different phenomenon. 

The whole point of G-Sync is to be able to have the GPU render at any rate below the monitor's max refresh rate without tearing.

I've contemplated picking up an Alienware 38" Gsync Ultimate display, but quite frankly, still, I can't see how it will improve my experience, the Gsync part, and for that matter the increased size, nor HDR.  I posed the OP because I never fully understood Gsync, and now I have a pretty clear idea what it does.  Since as you say it is unable to compensate/deal with/improve, stuttering when main or GPU is overloaded, I just don't see any point in it.   Right now, all that affects simming quality FOR ME is just that--stuttering below synced thresholds.  I don't hardly see any of this because I've adjusted settings to help prevent this.  A new CPU *might* improve this enough to consider upgrading, but even that is debatable.  It might let me put T-LOD from 100 to 150 (never going to update for this!), and perhaps allow me to install seasons which unfortunately do create stuttering in my installation (and probably others, but they don't realize it) and with respect to the rest of my settings.  Single-threaded performance is a wimpy 15% greater (Passmark) in a 13900K v my 9900K.  Just not too impressive. And it fits:  most in this an all other threads still report stuttering at complex arrival airports.

Going from fluid, nil FTV to something else so that the sim can run at higher frame rates when it can, doesn't really improve much of anything, as I see it.  For starters, where higher frame rate really comes into play, is on the ground while taxing, near the ground when flying, and that's about it.  Up in the air, once you have totally fluid flight, it's just not going to come into play.  My hardware cannot deliver much more than 30FPS in the PMDG 738 at complex terminals anyway so again--Gsync DOES NOT solve this.  Do you see my point here?  Above low levels where distance to ground objects grows, you're just not going to notice squat over what I see using any form of Vsync let alone one with nil FTV.  Shortly after takeoff as objects get farther and farther away from view out the side window of the plane in very short order the linear distance of an object, say an airport building, moves a very short distance on the screen.  This means that in the course of one second we're only moving thru 1.8 pixels per frame.  Another 60 seconds of ascent and now we're at 0.8 pixels per frame.  No can discern 1.8 pixels from 30" away from my 34" display.  If high FPS mattered as it does in some competitive games perhaps it might matter to me, but as I say, I just don't see it.

To expand on this from my experience:  I've certainly used Vsync at 60Hz/60FPS.  I did this in P3D using the Majestic Dash 8 which was ultra performance friendly.   I noticed no significant difference whatsoever when up a few thousand feet above ground.  During taxi--a slight difference, was really about it.  Perhaps I'm too focused on flying and interacting w/ the cockpit to really notice.  I'm completely convinced now what matters most is eliminating frametime variance, in terms of true smooth flight.  I'm also pretty convinced ultra high frame rates can overcome borderline FTV.

[Cpt_Piett]

16 minutes ago, Noel said:

My hardware cannot deliver much more than 30FPS in the PMDG 738 at complex terminals anyway so again--Gsync DOES NOT solve this.  Do you see my point here?

I do. I also see your point re: CPU upgrade. 

[Ianrivaldosmith]

41 minutes ago, Cpt_Piett said:

Main menu => "Set up G-Sync". Enable for windowed and full screen mode

Don’t set it for windowed mode, causes issues with other things. Just run MSFS in DX12 mode and make sure for full screen only. DX12 msfs uses DXGI flip model, so can handle it. 

[Ianrivaldosmith]

27 minutes ago, Noel said:

still, I can't see how it will improve my experience,

Try it on Amazon, test it for yourself. Don’t like it? Send it back. 
I don’t believe words can express G-Sync. It’s like me trying to explain the taste of chocolate to you, if you’ve never ever had chocolate before. 

[Ianrivaldosmith]

32 minutes ago, Noel said:

  My hardware cannot deliver much more than 30FPS in the PMDG 738 at complex terminals anyway so again--Gsync DOES NOT solve this.

It’s not supposed to solve it, but if you have g-sync ultimate you won’t have LFC kicking in at 30fps, and the whole scenario (especially using TrackIR) will be a whole lot smoother to the eye. Again, gotta see it to understand/believe it. 
 

Meanwhile, variable overdrive will ensure that the pixel response time speed is adjusted accordingly thus preventing pixel overshoot at low FPS and ghosting at high frame rates.