Discussion in 'Videocards - NVIDIA GeForce Drivers Section' started by Tastic, Jul 16, 2012.
If that's with g-sync, then forcing vsync OFF helps with that.
@RealNC Thanks, could you clarify what you mean there? I am using G-Sync where my setup is:
1) G-Sync enabled for Full Screen and Windowed mode
2) Control Panel V-Sync set to ON
3) In-game V-Sync set to OFF
If I understand you correctly, you're saying that turning OFF V-Sync completely in the control panel and in-game helps with that "Checkpoint/Save point" in-game "Freezing" that can often occur?
I'd thought that in-game OFF for V-Sync with in-control-panel V-Sync ON was previously the recommended setup since it added in "Frame-Time-Compensation" or something and prevented the tearing that could still occur with G-Sync. That information could be out of date though or I could just be wrong.
If you could elaborate a bit, that would really help me out -- thanks for your comment, that's helpful -- in any case I'll try our what you're recommending.
I did notice that even with G-Sync enabled, if you force V-Sync to OFF in the nvidia control panel, G-Sync breaks entirely for the Sekiro so the only option there (with G-sync) as I understand it is basically "app controlled" or ON if one wants G-Sync to work (or use Windowed mode).
Yes, the guides recommend vsync ON in NVCP, but I now actually recommend setting it to OFF due to the stutter issue with games that have these short freezes. With vsync ON + g-sync, these freezes are worse.
Now I only recommend vsync ON if you happen to play a game where you can see tearing with g-sync.
I don't know why g-sync wouldn't work correctly with vsync OFF though. I don't have that issue. If I cap my FPS, g-sync works fine with vsync OFF.
@RealNC Thanks! That's really great to know. Those freezes/stutters drive me nuts -- for what you're recommending should I do:
1) V-Sync OFF in-game + V-Sync OFF globally in Nvidia Control Panel
2) V-Sync OFF in-game + V-Sync set to "Let the 3D Application Decide"
I've only ever tested #1 with Sekiro to try and get G-Sync to work correctly in fullscreen mode since that game forces V-Sync unless you manually turn it off in the control panel so that may be a unique case, not sure. For that case though, it did seem to disable G-Sync entirely so if that occurs for other titles, I may have to use #2 and just disable V-Sync in-game I expect. From what you're saying though, seems like that shouldn't happen though.
vsync on in nvcp, gsync on is the best way to use gsync.
then set a framecap
@Astyanax Yes, historically that's been the approach I've taken, but RealNC is saying that this can make feezing/hitches worse in some cases so he's recommending only enabling it for games that still exhibit tearing. If you go back one page to my original comment on this thread I describe some of those issues/where they can occur and G-Sync on V-Sync off + cap fps to 3 beneath refresh was proposed as a potential fix/improvement for the problems I described. I haven't tested it yet.
I use vsync OFF in NVCP. When I play a game that has tearing, I change it to ON.
In-game vsync i always set to OFF.
Thanks, that's helpful!
@RealNC Just a heads-up, I tested what you recommended in Crysis 3 and The Witcher 3 where I used 1 MPRF w/ V-Sync ON in control panel then tested again with V-Sync OFF in control panel -- all using G-Sync and capped beneath 3 beneath refresh rate.
What I did was in C3, I reran through a checkpoint and in W3 I road through a point that almost always hitches for me (coming into a town). It could just be I'm not able to really tell, but I wasn't able to tell the difference in the length of time those freezes persisted using V-Sync ON vs OFF in the control panel.
Is there a link where I could read more about what you're describing? If it actually does help with the "freezing/stutters" than I'd absolutely love to do it of course, but I'm having difficulty seeing what you're describing in action.
I did read on BlurBusters that V-Sync ON in the control panel may not even be necessary if you're capping 3 beathe refresh though: https://www.blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/15/
In their explanation of "frame time compensation" and v-sync ON in the control panel, they mentioned the case where it kicks in being when at 144 hz and the frame is delivered at 6.8 ms instead of 6.9 iirc. That shouldn't happen if you're capping at 141 though on a 144 hz monitor so i'd think you could safely disable V-Sync in the control panel and suffer no adverse affects based on that explanation. Of course I may be missing something there.
Try G-SYNC off + V-SYNC off, and run your tests again; if you're still getting stutter, then these occurrences are the type of frametime spikes that aren't being caused by syncing methods (or a lack thereof).
I only recommend G-SYNC + V-SYNC for a 100% tear-free experience. G-SYNC + V-SYNC "off" will sometimes tear, but as RealNC stated already, this can reduce elongating the duration of frametime spikes in some instances when compared to G-SYNC + V-SYNC, but it won't fully eliminate them; not even standalone V-SYNC OFF can. Basically, you have a choice of a possibly longer, tear-less stutter (G-SYNC + V-SYNC), or a shorter stutter with a tear (G-SYNC + V-SYNC "off" or standalone V-SYNC OFF).
Frametimes coming from the system and framerate limiters (yes, even RTSS) aren't perfectly stable. You need both a 141 FPS limit and the V-SYNC option enabled if you want to avoid all tearing in that range at 144Hz with G-SYNC. More info is in entries #2, #3, and #4 of my Closing FAQ in the article.
@jorimt Thanks, that's helpful! I'll test that out after work today.
Do you happen to know if a higher Max Prerendered Frame/FlipQueue value can help smooth out stutters?
I tested 1-4 and at higher values, hitching seemed to be helped out a bit, but since it did still occur I wasn't sure if it was truly an improvement.
I've heard from CruncyBiscuit that the lowest he'll go is 2 since with a value of 1 he'd said he can get what appear to be frametime spikes/frame skips.
In practice, what I experience are that -- even if I cap my framerate to what is achievable the vast majority of the time -- when my framerate dips, even by 1 -- it often manifests as a stutter. This is using G-Sync + V-Sync ON with Max Prerendered Frames set to 1.
My "mission" here is mostly to find out how I can minimize this happening or get rid of it occurring since it drives me nuts so I've been experimenting with G-Sync + V-Sync OFF with higher MPRF values, but nothing I've tried appears to resolve the issue completely (though some of these settings changes may help) -- in any case, I need to do more tests.
Are using an in-game cap or RTSS? You can try the NVidia limiter too (using Profile Inspector.) It results in about one frame more lag than RTSS, but in return it will still allow pre-rendering which can help reduce stutters. RTSS reduces lag by completely preventing pre-rendering when the cap is reached, effectively acting like MPRF 0. But this can mean that some games can stutter when they are right on the verge of the FPS cap.
As you can guess, getting the best possible setup requires different settings and tools for different games.
Oh, btw, all of this assumes that these stutters aren't there to begin with! If you DISABLE g-sync, DISABLE frame capping, and reset MPRF back to default, but you still get these stutters, then your issue isn't g-sync or MPRF or the FPS cap. The issue is that the game just stutters by default.
Using g-sync and tweaking MPRF and applying a cap is done to improve tearing, input lag and judder/micro-stutter/frame pacing. But these things can't magically fix stuttering/hitching/freezes.
@RealNC Thanks for your reply, that's helpful.
For games that have proper in-engine frame limiting, I tend to use that as in the tests I've seen, those usually have a bit less input lag when compared against RTSS (Overwatch and The Witcher 3 both allow the user to set an in-engine frame cap for example).
For games that do not have a way to cap fps in-engine, I use RTSS.
The issues I have seen with hitching/stutter seem to occur with both in-engine limiters and RTSS. I wasn't aware that RTSS prevents the flipqueue / Max prerendered frames setting from working when the cap is reached -- that's really interesting.
If I'm understanding you correctly then, that would mean that so long as one caps fps to achievable, the Max Prerendered Frames setting is irrelevant whenever you're hitting the fps cap correct? Do I have that right?
So, in that case, the MPRF setting will only come into play when you are beneath your FPS target if you're using RTSS. I wasn't aware of that previously.
You may be right that some games simply have a hitching problem -- there may not be a way around stutter upon reaching a Checkpoint in Crysis 3 for example. But, I wanted to talk with you guys about it to see if it there was something I could do about it/if the problem could be G-Sync or the flipqueue/MPRF setting.
Anyway, I'll do more tests after work, thanks for explaining all of that, that's helpful.
Yes. When the RTSS frame limiter is triggered (obviously this only happens when the FPS reaches the cap value,) RTSS blocks the game from doing any further work.So pre-rendering is also blocked. That seems to be one of the reasons why RTSS reduces input lag more than the nvidia limiter. But since the nvidia limiter seems to at least allow for 1 pre-rendered frame at least, it might actually be less prone to stutters, at the cost of somewhat higher input lag.
With Witcher 3 for example, If you configure an MPRF of 8 (Profile Inspector allows you to go that high) and disable any frame capping (both in-game and RTSS,) there's going to be a huge input lag. But as soon as you cap the FPS, and the cap is actually reached, then all of that lag disappears. It's as if MPRF was 0. If the FPS cap is not reached, however, then all those 8 frames will come back.
I forgot if the in-game limiter also prevents pre-rendering. Probably yes, it's easy to test in the same manner.
Some games just have stutter or micro-freezes in them. Those can be made worse by g-sync + vsync ON. One example of this is when opening the map or the inventory in Witcher 3. For a short moment, the game freezes rendering completely (0FPS) when the inventory/map is opened or closed. With g-sync + vsync ON, the freeze results in a longer stutter. With g-sync + vsync OFF, the stutter is much shorter.
Some other games have these 0FPS freezes in places that are normally not visible. During a transition from a black screen for example. With g-sync + vsync ON, the 0FPS freeze will result about 1 second of heavy stutter after the black screen. With g-sync + vsync OFF, this stutter will only last a few milliseconds.
This behavior can be tested, which I did with multiple games. So now IMO, g-sync + vsync OFF is the better default setting, and vsync should only be turned ON for games where you can still see some tearing (it's rare, g-sync + vsync OFF will in the majority of cases have no tearing, but with a few games you can see some temporary tearing.)
Also, a sensible FPS cap for each game also helps a lot. I never do the -3FPS cap blindly any more. I always cap my FPS to be near the average FPS I'm getting in the game I'm playing. If the game runs at about 90-110FPS most of the time, I cap to 100FPS, not 162 (I'm on a 165Hz monitor.)
@RealNC Thanks a lot for explaining all of that, that's helpful -- going off what you're saying then, I'll start using: "G-Sync ON + V-Sync forced to OFF in the control panel.
I'd prefer the occasional tear to having the "freezes"/hitches last for a discernibly longer duration.
Yes, I agree -- I find that I usually have a better experience when I can fps to what is consistently achievable.
The only thing left for me now is to figure out what to do with the MPRF setting -- since it doesn't even apply as long as you're hitting your target FPS cap, I suppose I could simply set it to default -- of course input lag drives me nuts, but if a MPRF setting of 1 is responsible for hitching than for me I suppose it's not really worth it -- question is whether or not that's actually the case though so I'll need to do more tests.
Just a thought, if it's not already present somewhere in a BlurBusters article or some such, it might be good to put out a post regarding how:
1) G-Sync + V-Sync OFF does have apparent benefits to consider (potentially reduce duration of "freezes"/hitches) VS G-Sync + V-Sync ON (the vast majority of what I've seen online unequivocally advocates for G-Sync + V-Sync ON w/ fps cap)
2) Capping your framerate with RTSS or in-engine limiters "Disables" whatever your "Max Prerendered Frames" / "FlipQueue" setting is while that cap is reached.
For #2, my understanding is that if you cap fps at 63 with RTSS, provided you don't drop beneath that 63, even if you're MPRF / FlipeQueue is set to 4+, it won't make any difference going off what RealNC said above.
My learning these things in this thread is the first I've heard of these two things and I've done a good bit of general searching via Google for example to better understand the way these settings work (there seems to be a large amount of misunderstanding regarding these sorts of things in my experience on other forums).
I just think it might be helpful for other people out there too since I doubt that #2 (and probably #1 as well) are common knowledge based on what I've been able to find online til now.
Anyway, thanks for your help and time, I appreciate it.
I'm not entirely sure about this. I guess it depends on whether the fps limiting method stalls the CPU or the GPU.
What I do know for sure is that when I use RadeonPro, Dxtory or even some in-game limiters (Trine 2 for example) to limit my frame rate just ever so slightly below my refresh rate (tearline is slowly moving from top to bottom in a calm and reliable manner, resetting at the top once every ~2.5 minutes in case of v-sync off without G-Sync/Freesync) and enable regular v-sync, MPRF (flip queue size on AMD) still has a very noticeable impact on input lag in some games. It could very well be that RTSS handles this in a different way, since it's often the fastest method resulting in the least amout of input lag, but not always the most precise (hence me still using RadeonPro to limit the frame rate in many games).
@CrunchyBiscuit I hear you -- yes, I hadn't heard of RTSS cap preventing the MPRF/FP size from applying before this thread, but RealNC seems pretty certain of it above. That's partly why I recommended putting the info out there in a more official capacity. What I'd thought before this was that MPRF/FP size still applied even when RTSS was reaching its limit but that doesn't appear to be the case going off of @RealNC 's statements above.
Yes, gotcha, so:
This could very well be true for RTSS (didn't do much in-depth tests myself due to lack of time, but I'm willing to accept @RealNC's conclusions as truth), however, it's certainly not true for in-game limiters, at least not all of them. For games based on Unreal Engine 3/4 it probably is, but not for all games/engines (I guess it depends on whether the fps limiting method stalls the CPU or the GPU, or some other variable).
I just wanted to clear that up.