GeDoSaTo Dynamic FPS Capping

[Glide]

Seems like an interesting approach to reducing input lag, rather than a fixed FPS cap:

http://blog.metaclassofnil.com/?p=715

[Sparky]

Is that available now? if so I'll do some testing on it.

[Glide]

Yes, the latest version should include the feature.
I did not realize the post detailing it did not link to a download: http://blog.metaclassofnil.com/?page_id=582

[Sparky]

RTSS is significantly faster, but maybe I'm just messing up some of the settings?

Refresh rate: 85.2 hz(actual)
framerate cap: 85
fpsPredictiveLimitRatio 0.9



framerate cap of 86 is off the top of the chart.(though I think I tried that with a predictivelimitratio of 0.5)
CS:GO in-game framerate cap is about 10ms better than RTSS.

[Glide]

Thanks for testing it, that's disappointing.

Looking at the CS:GO results, it seems like the GeDoSaTo tool has an additional frame of latency over RTSS, but despite that, the predictive limiting seems like it is working as intended since the difference between the two is less than 11.8ms (a full frame at 85Hz)

So if the developer can figure out where that extra frame of latency is being added, it could potentially be lower than RTSS.

[Sparky]

Thanks for testing it, that's disappointing.

Looking at the CS:GO results, it seems like the GeDoSaTo tool has an additional frame of latency over RTSS, but despite that, the predictive limiting seems like it is working as intended since the difference between the two is less than 11.8ms (a full frame at 85Hz)

So if the developer can figure out where that extra frame of latency is being added, it could potentially be lower than RTSS.

I don't think that's why the difference in latency is less than 1 full frame, I think that's just because the framerate cap is causing a pipeline stage that used to take 3ms to instead take 11.8ms.

I think the best case scenario is matching the latency of an in-game framerate cap, by spoofing the game engine into thinking you're GPU limited, when really the GPU is idle and the buffers empty. Once you get that, the next step is finding a way to measure how long a completed frame is waiting on buffer flip(v-sync), so you can set an arbitrary buffer size in milliseconds, and have the framerate limiter take the rest of the slack out of the render pipeline. I.E. low latency v-sync with no dropped frames(so long as the buffer is big enough to smooth out your frametime variance).

Sadly, I don't know enough about the OS and drivers to actually code all that, and I'm pretty sure that ideal solution would require meddling with both.

[Durante]

RTSS is significantly faster, but maybe I'm just messing up some of the settings?

Refresh rate: 85.2 hz(actual)
framerate cap: 85
fpsPredictiveLimitRatio 0.9



framerate cap of 86 is off the top of the chart.(though I think I tried that with a predictivelimitratio of 0.5)
CS:GO in-game framerate cap is about 10ms better than RTSS.

That's very interesting! How stable is the frame time in CS:GO? It might be that 0.9 is too high and you drop into a second frame most of the time. Also, how are you measuring this?

I only really tested the effectiveness in a v-sync'd scenario.

[Sparky]

RTSS is significantly faster, but maybe I'm just messing up some of the settings?

Refresh rate: 85.2 hz(actual)
framerate cap: 85
fpsPredictiveLimitRatio 0.9



framerate cap of 86 is off the top of the chart.(though I think I tried that with a predictivelimitratio of 0.5)
CS:GO in-game framerate cap is about 10ms better than RTSS.

That's very interesting! How stable is the frame time in CS:GO? It might be that 0.9 is too high and you drop into a second frame most of the time. Also, how are you measuring this?

I only really tested the effectiveness in a v-sync'd scenario.

Pretty stable, it runs over 600 fps when uncapped, at the settings I used. With the in-game cap of 85, the latency is 14ms, with an in game cap of 84 and v-sync, the latency is 21ms. The low overhead test program runs at about 4k fps on my system.

Testing methodology, I'm using an arduino micro with a photoresistor to detect a dark to light transition that happens when I move the mouse. The arduino emulates a mouse to the syatem, and measures the timings involved. I modified the USB library to put a timestamp on the usb interrupt, in order to remove the variance of the 1khz usb polling. It's very similar to flood's test setup, and there's more detail in that thread.

As for missing a deadline and dropping into a second frame, that is happening, and not just in CS:GO. It drops one extra frame every 5 seconds, which corresponds to the 0.2hz difference between the actual refresh rate and the framerate cap(which translates to about 28 microseconds per frame).

I'll re-try with a lower ratio, to see if it gets rid of that beat pattern, though you are still capping framerate a couple pipeline steps late, as shown v-sync off cap being 18ms slower than the in-game framerate cap. I think the only way to match that latency is to trick the game engine into capping the framerate for you, by spoofing backpressure.

P.S: If you're wondering why there's so much noise on that graph, that's not frametime variance, that's the random delay between the input and the next frame accepting input data.

Edit: dropping it down to 0.7 in the test program didn't get rid of the beat pattern, Graph updated.

[flood]

Seems like an interesting approach to reducing input lag

doesn't reduce input lag over the simple way of capping when vsync is off (after each frame is drawn, sleep until time is equal to integer/cap)

does reduce input lag when youre using vsync or something where there is a time difference between when the frame finishes drawing and when it's actually displayed.

[Sparky]

okay, I got it to hold sync with refresh rate by putting the framerate cap at 85.2, but average latency crept up to 33ms(average steady state). I'll see if I can get it to drift down instead of up, without losing synch.