Pre-rendered Frames Testing?

[Litzner]

I have been looking for some actually hard tests of pre-rendered frames settings. The best I could find was for Overwatch where they tested Default vs 1 and the results came back negligible, where 1 beat default by less then 1ms on average. Interesting note, they found the Overwatch's built in "Reduce Buffering" on Default beat 1 with no "Reduce Buffering" by quite a bit. They didn't test 1+"Reduced Buffering" for some reason.

Link to video - https://www.youtube.com/watch?v=sITJ3V_fyv4

I am curious to see more information on pre-rendered frames, more then 1 vs default, and in a few more game engines. I am very curious to see that if some games actually preform better on Default as the game engine's buffering maybe superior? Which seems to be the case in Overwatch "Reduce Buffering". I am guessing I am going to need to mod a mouse and get my own high speed camera one of these days to truly satisfy my curiosity.

Edit: I also wanted to add, I am so curious about this because the FPS I have been playing the most of lately is very CPU dependent (98-100% usage on 4790K @ 4.7Ghz across 4 cores). Pre-rendered frames seem to really smooth out high cpu-usage games from the limited information I have seen on the subject. But again, I am likely going to have to setup my own testing solution to get a good answer.

[jorimt]

Read my "What exactly does the “Maximum pre-rendered frames” setting do again? Doesn’t it affect input lag?" and "Does the RTSS FPS limiter really “add” 1 frame of input lag?" FAQ entries here:
https://www.blurbusters.com/gsync/gsync ... ttings/15/

As well this thread concerning the subject:
viewtopic.php?f=5&t=4778

Also, some off-the-record testing in Overwatch (with Reduced Buffering enabled) related to this subject:
viewtopic.php?f=5&t=3441&start=110#p26975

While I/we don't know everything about the pre-rendered frames queue, we know/have tested enough to confirm it isn't really intended to be (and doesn't always work like) a direct input lag modifier, and its effects highly depend on the given game on the given system, as well as whether an FPS limiter is in play, and then whether the framerate is limited by the limiter (at which point the pre-rendered frames queue effectively becomes "0").

[MatrixQW]

I think it would be interesting to keep all information about this setting in the same place.
Maybe Litzner's question could be added there?
I'll post in g-sync section of this topic.

[Q83Ia7ta]

https://www.blurbusters.com/gsync/gsync ... ttings/15/

Will be nice if you will add that this setting is only for DirectX and it's value can be ignored by some (most?) games.

[jorimt]

^ I like to keep it vague when describing something I don't know 100% about, and to only share what I do know (instead of nothing at all).

But yes, that entry concerning max pre-rendered frames only applies to games that allow the NVCP to override the in-game behavior.

I thought of adding a line about how the "Maximum pre-rendered frames" setting doesn't work in every game, but then you open a Pandora's box in which the next obvious question is, "then what games don't work with it?" and "how can we tell?" and I have no clue; I can't test every PC game in existence.

The takeaway is, if you have a relatively powerful system, set it globally to "1," and forget about it. If you're really worried about this setting having an impact on input lag, try to keep your FPS above a limiter instead.

That said, if you and some others here can confirm 100% that the MPRF setting only works with DX games, I'll consider adding a line about that, but I'm not certain that's the case; even the NVCP triple buffer option has been known to work with DX games in edge cases.

[RealNC]

https://www.blurbusters.com/gsync/gsync ... ttings/15/

Will be nice if you will add that this setting is only for DirectX and it's value can be ignored by some (most?) games.

It also applies to OpenGL, from what I know. When changing this option in the NVCP, you can see in Profile Inspector that it changes two different settings; one for DX, one for GL. The NVCP keeps both in sync, but in Inspector you can change them separately.

Not sure about Vulkan.

[Litzner]

Thank you all for the information and direction. I will get reading right now.

Specifically what I am doing now is S-Sync + 100-120Hz (depending on game) Lightboost. The game I am playing most frequently is very CPU bound and capping the proc from time to time, when it does I will drop below 100fps sometimes, which messes with S-Sync and causes me to jitter. So I have been looking at ways to help it out a little, started reading about pre-rendered frames, and it looked like it may be able to help, but I couldn't find much for concrete info on its effects on input latency other then the one Overwatch video I linked.

[RealNC]

The game I am playing most frequently is very CPU bound and capping the proc from time to time, when it does I will drop below 100fps sometimes, which messes with S-Sync and causes me to jitter. So I have been looking at ways to help it out a little, started reading about pre-rendered frames, and it looked like it may be able to help, but I couldn't find much for concrete info on its effects on input latency other then the one Overwatch video I linked.

It will not help with s-sync. If the game can't maintain 100FPS@100Hz or 120FPS@120Hz at all times, s-sync will produce heavy jitter.

The only way to fix that is to tell RTSS to not apply s-sync for frames that are not fast enough. It will then tear. To do that, add:

SyncTimeout=1

in the RTSS profile file. Anyway, at least that's the plan. I'm not sure how well SyncTimeout works in general, but it's worth a try.

[Litzner]

The game I am playing most frequently is very CPU bound and capping the proc from time to time, when it does I will drop below 100fps sometimes, which messes with S-Sync and causes me to jitter. So I have been looking at ways to help it out a little, started reading about pre-rendered frames, and it looked like it may be able to help, but I couldn't find much for concrete info on its effects on input latency other then the one Overwatch video I linked.

It will not help with s-sync. If the game can't maintain 100FPS@100Hz or 120FPS@120Hz at all times, s-sync will produce heavy jitter.

The only way to fix that is to tell RTSS to not apply s-sync for frames that are not fast enough. It will then tear. To do that, add:

SyncTimeout=1

in the RTSS profile file. Anyway, at least that's the plan. I'm not sure how well SyncTimeout works in general, but it's worth a try.

That is specifically why I was looking at pre-rendered frames, which I always have set to 1. As soon as I get home tonight I am going to test it on the map I know dips down to just below 100 fps from time to time. I was just looking for pre-rendered frames measured effect on input latency, with the limited information I have found seems to vary depending on game, cpu\gpu load, etc.