Discussion in 'Videocards - NVIDIA GeForce Drivers Section' started by Tastic, Jul 16, 2012.
The truth is that it's no longer available, so deal with it.
I find 1 causes no stutters in anything, so 1 seems to be the sweet spot.
In games where 1 stutters, 2 stutters too. 3 also. In fact, the higher this is set to, the more annoying the stutter gets. 1 has the least annoying stutter characteristic. The stutter is perfectly even (high frame times, but evenly so.) With higher values, the stutter is hiccup-like. Low frame times followed by high frame times, repeat.
I'm not sure why this setting even exists on non-SLI systems. It should be 1 for everything by default.
So that gpu manufacturers can boost the performance of their products.
Some programs like MPC-HC and madvr actually need "use the 3d application setting" or your video files will be out of sync.
I have 128 frames buffered by the CPU in madvr and 24 by the GPU. Removes any chance of dropped frames and helps smooth motion do its job.
I'm new to the thread but I always thought that old 0 value meant 'defined by application'.
And for me, the value had to be:
pre-rendered frames = number of gpus -> minimal input lag but possible judder
pre-rendered frames = numbers of gpus + 1 -> smoothest gameplay
pre-rendered frames = number of gpus + 2 -> best performance
pre-rendered frames = defined by application for fine tuned well programmed games.
I have a few questions related to MPRF, V-sync and frame caps. I just spent the last few hours testing some things and was wondering how they interact/affect each other. I just did a fully clean install of the 382.53 drivers, MSIAB 4.4.0 Beta10 and RTSS 7.0.0 Beta23 and used 4 games that have built in frame rate limiters. Civ VI, DoS:EE, Borderlands 2 and Forza Horizon 3. I'm on a 60Hz screen and V-sync was always on through the in-game options. I'd been reading recently about frame latency in this thread and over at blurbusters. Here are a few of the tests I did and the results.
MPRF 3, RTSS cap at 60, in-game V-sync on = perfectly solid and stable 60/16.7 performance, game felt smooth and ran fine with a bit of noticeable input lag.
MPRF 3, RTSS off, in-game V-sync on, in-game frame rate cap at 60 = checking MSIAB graphs afterwards shows crazy variance in frame times, yet FPS remains solid at 60. Anywhere from 15.6ms to 19.4ms frame times, yet somehow the game still felt fine if not better than when using RTSS to cap.
MPRF 1, RTSS cap at 60, in-game V-sync on = again, perfectly solid and stable 60/16.7 performance in all games. Using a controller, games seemed even more responsive than when using MPRF 3.
MPRF 1, RTSS off, in-game V-sync on, in-game frame rate cap at 60 = MSIAB graphs showed the largest amount and consistency of frame rate variance yet, ranging from 14.7ms to 21.7ms. All 4 games felt most responsive and smooth even though MSIAB's graphs would lead somebody to believe it was a stutter/judder fest.
I guess my question is regarding whether or not this is normal behavior? Is there a circumstance that can be created to help test this further? This also makes me wonder what is better for games that don't have frame rate limiters built in, but that will have to wait until another day. Lastly, all tests were run using the firstname.lastname@example.orgHz resolution and at a constant GPU clock.
But they said to enable Vsync from Nvidia control panel, only if it doesn't work then use the game. cause the games has their own pacing .
That's for G-Sync. He's using a normal 60Hz monitor without g-sync, so it doesn't matter.
It's normal. Slight frame-time variance can be hidden by vsync and g-sync, since the frames need to wait for the next available monitor scanout. (The difference in the case of g-sync is that there's no penalty for missing the next available "slot", while with vsync, if the frame misses the scanout, it needs to wait the full 16.7ms for the next one.) However, in both cases, the frames cannot bypass the scanout speed of the monitor, so they are paced out smothly (unless the game outputs frames at a severely bad pace.)
Also, you're not getting the full benefit of frame capping. To eliminate pre-rendered frames you need to cap slightly below refresh. In the previous page of this thread I posted a guide on how to do that.
I've tried both in game or driver based V sync with similar/exact same results so far. True, no G sync as of now.
Here is a screenshot I just made to explain the whole thing better. This is from PCARS. The red graphs are from about an hour ago, while the green ones are from a few days ago.
Maybe there isn't a good explanation, I'm just glad that I've finally achieved the smoothness and responsiveness I've been chasing for a long time.
EDIT - So I just did the steps on the previous page regarding RTSS for Fallout 4 and it actually seems like it might be the best setup for that game. Could somebody who is using the guide from the previous page upload some MSIAB graphs after playing a game for several minutes or more?
Oh, you mean WHY frame pacing is worse with the in-game limiter compared to RTSS.
That has an easy answer. RTSS is more accurate. That's about it
I haven't seen the code of RTSS, but its behavior is consistent with a limiter that throttles the game using a busy-wait loop. This gives RTSS extremely fine timing granularity. It's accurate down to a fraction of a millisecond. It's so accurate, with vsync off, it can "freeze" the tearing line in place.
Yes, I am asking about why frame pacing can be so varied using different methods yet the game still pops out the same to my eyes. I'm guessing it has to do with traditional V-sync and the fact that I always have it on?
After reading the blurbusters stuff, I've seen how powerful and accurate RTSS is, but can it have any kind of effect when a good/great V-sync implementation exists in the game engine? Would it just be using up a few CPU cycles and adding a single frame of latency, or somehow "cleaning up" what V-sync is doing?
As for RTSS and tearing, I did actually try some V-sync off RTSS capping a while ago with several games and noticed that I could "decide" where the tear line occurred. Problem is, tearing absolutely ruins gaming for me so V-sync always stays on.
Lastly before I head to bed, I just ran a 20 minute race in PCARS in a familiar car and at a familiar track yet I had trouble controlling things. Apparently I had gotten used to the amount of latency that V-sync+RTSS@60+MPRF@3 produced, so switching to V-sync+no frame limit+MPRF@1 made it hard for me to control the near instant response/twitchiness of the car. I am going to keep experimenting tomorrow and try to create a situation where I can follow the guide on the previous page and force the game under 60FPS via DSR to see what happens with all the buffers and things not existing, versus what it does for me now.
Thanks for the help and explanations so far! I love learning this kind of stuff. :nerd: c1:
Is there a way to block/ignore entire threads?
This dead horse keeps showing up and it's annoying.
RTSS does not add latency. It LOWERS latency.
Uncapped vsync with MPRF 1 has much more lag than RTSS capped vsync. But for that to happen, the game needs to actually reach the cap. Which is why it's crucial that the cap is below the refresh rate.
Unsubscribe from the thread in your Guru3D user CP.
K. I'll probably be testing this tomorrow night. Sounds interesting.
I'm not subbed to any thread.
I just don't want to see anymore.
An anecdote came to mind reading this thread , There is a profile bit called "enable gtx 950 specific features" in nvinspector, which was added after nvidia announced a improvement for dota 2 and a few other games, that would allow the 950 to reduce input latency by skipping part of the frame buffering, No idea if works as intended with other games, but it might be worth a look.
You could just ignore it?
So I'm pretty much done testing all of this MPRF, in game versus driver V-sync, in game cap versus RTSS versus no cap, 60 versus 59.993 kind of stuff. Running the vsynctester gives me exactly 60.000 so I've gone through and changed several games to cap at 59.993 and they are running great so far. I tried to set it globally at first, but things like MPCHC and Firefox were not behaving. Is this "0.007 below" cap something that you use quite often, RealNC? Or just for rare situations? Here is a screencap from a short session of PCARS with a friend. It was perfectly smooth and responsive. No stutters, hitches or other oddities.
Here is another thing that is hard to wrap my mind around, but in practice it seems to work. I need to experiment with more games to see what happens in rare circumstances. For example, PCARS runs at 60FPS locked 99% of the time but if the random weather changes to a thunderstorm and I have more than 30 cars in a race it will hang around 50FPS for a while. Also, Blacklist seems to only have a terrible in game double buffer v-sync so when the engine has a hiccup, which it does, it will cut straight to 30FPS for a few seconds. That is incredibly jarring and I've since switched to using adaptive sync without an RTSS cap, since using the cap of 59.993 disables adaptive sync and leaves a torn image.
Never seen that before, thus never tried it. I might get around to it at some point if I'm troubleshooting a troublesome game or something.
Not clicking on things you don't wish to see? Sounds reasonable enough to me.