Blur Busters Forums

Which is the better option with G-Sync? Capping FPS in-game (I.e. fps_max) or with an external program like dxtory? Or in the GPU options?

dmbr wrote:Which is the better option with G-Sync? Capping FPS in-game (I.e. fps_max) or with an external program like dxtory? Or in the GPU options?

In-game is always the best.

Thanks.

Well, no... with gsync it doesnt matter....

You might as well cap it globally with rivatuner statistics server, just cuz its easier

Edmond wrote:Well, no... with gsync it doesnt matter....

You might as well cap it globally with rivatuner statistics server, just cuz its easier

Capping framerate anywhere but in game adds input latency. The further down the pipeline you cap framerate, the more input latency you add.

Sparky wrote:

Edmond wrote:Well, no... with gsync it doesnt matter....

You might as well cap it globally with rivatuner statistics server, just cuz its easier

Capping framerate anywhere but in game adds input latency. The further down the pipeline you cap framerate, the more input latency you add.

Yep. If you cap in-game the game will wait a little bit and grab newer input then send it off to be rendered. If you cap at the driver level the game will grab input right away then send it off.

Sparky wrote:

Edmond wrote: Capping framerate anywhere but in game adds input latency. The further down the pipeline you cap framerate, the more input latency you add.

If you cap ingame framerate to 10 fps, surely that adds a great deal of input lag no? (at least as measured as the time between doing something, like moving the mouse, and seeing it occur on screen)

sharknice wrote:

Sparky wrote:

Edmond wrote:Well, no... with gsync it doesnt matter....

You might as well cap it globally with rivatuner statistics server, just cuz its easier

Capping framerate anywhere but in game adds input latency. The further down the pipeline you cap framerate, the more input latency you add.

Yep. If you cap in-game the game will wait a little bit and grab newer input then send it off to be rendered. If you cap at the driver level the game will grab input right away then send it off.

That makes external capping sound superior?

spacediver wrote:

Sparky wrote:

Edmond wrote: Capping framerate anywhere but in game adds input latency. The further down the pipeline you cap framerate, the more input latency you add.

If you cap ingame framerate to 10 fps, surely that adds a great deal of input lag no? (at least as measured as the time between doing something, like moving the mouse, and seeing it occur on screen)

Yes and no, depending on what you're measuring. When a frame finishes, it includes all input data older than X milliseconds. When the user makes an input it takes Y milliseconds to see a new frame that incorporates that input.

If you are CPU limited already, an in-game framerate cap will leave X untouched, and increase Y.
If you are GPU or display limited, an in-game framerate cap will decrease X, and can decrease Y, depending how much the cap decreases your framerate, and how much queue latency you started with.

GPU framerate caps will only decrease latency if the alternative is v-sync.

I *think* I'm starting to understand.

So there is:

1) the delay between input and that input being reflected in a (buffered) frame.
2) the delay between the creation of that buffered frame, and that frame being drawn on the screen.

Now what about the server or game world simulation (dunno what the correct term is here)? Let's say it takes 100 ms for a button press to be reflected in the next available buffered frame, and another 100 ms for that frame to be displayed on my screen. In the gameworld, when does that button press occur? Is it T+100ms (where T is moment of button press)?