Discussion in 'Videocards - NVIDIA GeForce Drivers Section' started by Tastic, Jul 16, 2012.
So that gpu manufacturers can boost the performance of their products.
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 email@example.comHz 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.
I used it for every game back when I didn't have a g-sync monitor. About 4 months ago I got a g-sync display, so I don't have to do this anymore (except when using ULMB.)
But yes, I've been using this method for many years now. I can still remember doing this back in 2013, playing Tomb Raider when it came out. It worked very well for all refresh rates. 60.007Hz and 75.007Hz with my old monitor back then, and then with 90.007Hz, 120.007Hz and 144.007Hz with a 144Hz non-gsync monitor.
I was OCing my 60Hz monitor to 75.007Hz back then. If your monitor can be convinced to do the same, you'd get extremely good results. 75FPS cap on 75.007Hz is very low vsync latency. It's a big difference compared to 60Hz.
Now with g-sync, I only use this method when playing with ULMB instead of g-sync (since you can't have both at the same time.)
Yes, that happens. The low-latency vsync method depends on a fast machine. The game needs to render frames fast enough and always hit the frame cap. If it doesn't, some games can behave badly (like a 30FPS lock in some cases.) There's not much you can do about it other than using triple buffer vsync if the game supports it. This will increase input lag though.
My solution to this back then was to throw more money at the problem (Meaning buying a faster GPU.) Then g-sync happened and it became a non-issue.
@RealNC - Thanks for all the info and help. This gives me a lot of things to think about and test. I really appreciate it! :nerd:
EDIT - A few more questions about things I noticed. Any and every game I use RTSS frame limits with results in ~90-100% CPU1 usage, whereas without it many games have much lower CPU usage on both CPU1 and all other cores. Does this have something to do with the "busy cycle" you talked about before?
Since it doesn't impact performance, it has to be. Otherwise, you would see lower average framerates when using RTSS, which doesn't seem to be the case. That means the CPU load is generated during the throttling period at which the game is blocked.