The truth about PRE-RENDERING 0?

Thanks, so I'll keep setting it as before. Or capping to slightly below refresh rate.

I often use ingame limiters though if they seem to work all right so use even numbers. RTSS when ingame limiter isn't optimal or there isn't one.
Plus using CRU to get even 75.000 Hz gives pretty good results when capping to 75.

 

In-game limiters cannot keep sub-millisecond precision. RTSS can.

You also need to measure your real refresh rate for this to work. If you cap to even frame rates, you're only getting partial input lag reduction. By doing it correctly, your input lag is going to be between 0 and 1 frame.

Again, if you read the post I linked to, things should become clear.

 

Yes but using CRU to create an even 75 Hz means actual refresh rate is even 75.000 Hz or am I mistaken?

Ofc I should then cap to slightly below 75 fps (74.993) for best results but I've found capping to 75 when refresh rate is 75 gives satisfactory results.

The monitor default 60 Hz mode is actually 59.94 Hz.

 

If you're using CRU then the way to go is to use 75.008Hz (or somewhere near that, like 75.010 or 75.012; whatever CRU rounds it to.)

And of course test this on the refresh rate detector sites to make sure.

(This was already mentioned in the linked-to post.)

 

Right, thanks again.

 

this post is really good, a question here, what is the difference between capping refreshrate exactly 0.007 under with RTSS and vsync on + max prerender 1, compared to no vsync, but still prerender 1 and same RTSS cap ?

also, is there any point at all enabling triple buffering and or vsync AFR smoothing in nvidia inspector if capping fps to 0.007 fps under true refreshrate ?


thanks if anyone can answer this, cheers!

 

There's no point in doing this without vsync. You can just cap your FPS to whatever you want when not using vsync.

I'm not sure how frame capping affects triple buffering. TB increases input lag by 1 frame but reduces stutter if the frame rate falls below refresh rate. But whether or nor this is still true when using a frame limiter, I don't know. (Note that nvidia's TB setting only affects OpenGL and possibly Vulkan games.)

I never used SLI so I don't know much about AFR.

 

Hello, just wanted to make sure I got this set correctly. I have a 60hz monitor, oc'ed to 75 through control panel. Both test's gave me 75.002Hz, testing with 60Hz gave me 60,002Hz as well. So 75.002Hz - 0,01 = 74,992. I put 74992 in the limit line of the global file. I think it's working correctly, because I tested it with witcher 3, I have a particular save where it would always stutter few times when running foward, but this limit fixed it completely!

 

Since you've OCed, there's no need to use a fractional limit. You can just OC to 75.010Hz (or near that, like 75.011, 75.012, whatever CRU rounds to.) Then cap to 75FPS.

 

I didn't use CRU tho. For OC I used nvidia control panel by creating custom resolution, but it doesn't allow numbers after "." or "," only full numbers so I set it to 75, but after testing it with those 2 sites, the actual number is 75.002hz, so by setting framelimit to 74,992, I've done everything correctly?

 

Yes.

 

This is strange, I was doing more test's and turns out it was the vsync alone that got rid of some stutter. I disabled the vsync and framers aren't capped by rtts. I did what you said, I set :

[Framerate]
Limit=74992

and in rtts window I can see framerate limit 74992, but this value doesn't seem to work. I tried to add "." so I typed Limit=74.992 in global file and saved. The cap seems to be working, frames are locked at 74, just as rtts window shows, but idk if the framers aren't just locked at 74, and maybe rtts is ignoring numbers after dot. You said

" Too low and the trick doesn't work anymore, too high and you get repeated frames that result in "hiccups".

So i need to get this specific value to lock, but idk how to do it, rtts doesn't seem to allow it.

 

It looks like you didn't set LimitDenominator to 1000? Read the post again:

https://forums.guru3d.com/threads/the-truth-about-pre-rendering-0.365860/page-12#post-5380262

 

Yes because there is no "LimitDenominator" in my global file, here's how it looks like https://pastebin.com/TTWpHbTR


edit : nvm so you need to add this line manually? Because I just did and it seems to work. You should have mentioned that. Thought maybe this line existed in some older version of rtts back then when you posted that or something, and they removed it later on.

 

btw, now after googling that "LimitDenominator " thing, I came across few guides such as this https://www.blurbusters.com/howto-low-lag-vsync-on/ it's the exact same method as yours, but it says we could try testing it with fast sync instead of default vsync to " to allow tighter frame rate capping for the purposes of avoiding stutters." What's your opinion on this? You only mentioned standard vsync in your post.

 

ProfileTemplates/Global is where you can find the full list of settings which can then be copied over into Profile\Global if you want to change them. Goes for the Config file too as I recall.
And then there should be a setting for IntegerFramerate which if disabled should show the values as float numbers instead of integer ones so say 59.9 instead of 59 though I could be remembering it wrong how many digits it displayed.

 

Or you can just set RTSS to show the pre-defined profiles.....

 

Fast sync always resulted in some frame skipping for me. But it doesn't cost to try.

That option is configurable in the RTSS settings dialog. No need to edit profile files to get to it.

 

I see, well these last two posts really show how little I use the in-program settings and just rely on config file editing.

 

It would be actually great if some technician from nVidia or AMD read these extremely useful posts regarding to frame timing. However, looks like game developers are more aware of this rather than GPU manufacturers; or those who write the code for the drivers in this case. If you actually would go to the nVidia support chat and said something like "I am having issues with the frame time on my games, how can I correct them?" you will get a bot-like answer "update to the latest drivers" or "update your PC drivers" as if that had anything to do with it. They are clueless, its like chatting with a trained monkey.

For something like this to be added to a GPU driver or software, it would take someone who actually cared and that works for these companies or that its familar with frame times, how some games have less issues with this and how some games have lots of issues with this.

I know three methods, that depending on how game engines work, give you correct frame times:

Full screen+RivaTuner frame rate limiter.
Borderless full screen on its own gives great if not perfect frame timing. RTSS can be used to fine tune it. However, borderless full screen can make some games stutter, as I said, depends on how the game is made and how the engine of the game runs.

Windows 10, since the Creators Update, incorporates something called "Full Screen Optimizations" on each .exe it has. For games, this GREATLY corrects frame times, sometimes, perfect, RTSS level. Not all games seem to recognize them though so you still have to use RTSS or borderless full screen.

There is a fourth alternative, so far the only game that has greatly benefited from it its Ghost Recon: Wildlands. This alternative is nVidia Inspector Frame Rate Limiter V2. Using this, turning V-sync off on Wildlands, plus borderless full screen has given me a 100% smooth game experience at 60 fps with no tearing whatsoever. Please, do note that this method has only been working for me flawlessly since I updated Windows to the Spring Creators Update (build 1803). When I was using the Creators Update, the games would judder horribly using borderless full screen with no in-game v-sync and using an external fps cap, (RTSS or nVidia FRLV2). So if somebody wants to try what I mention, I think the best is to have the latest version of Windows 10. I have no idea how this would work on Windows 7 or 8, so you would have to try for yourself and see.