Blur Busters Forums

I wonder if running a fixed max clock on both would decrease latency when my game is focussed, game is fps capped due to gsync, but woukd it affect latency at all?

Its only running half the clock rate because gpu isnt saturated as much.

Tried a google search but no luck.

It might impact latency, but the impact would probably be very very small. Depends on several things, like how quickly the GPU steps up/down clock in response to load, what the framerate would be if you were gpu limited at the lower vs the higher clock, and where your framerate cap is in the render pipeline.

I can imagine scenarios where it could improve latency by up to 3.5ms(assuming 140fps cap, and 280fps uncapped framerate), and I can imagine scenarios where it hurts latency (GPU already ramping clock speeds up while working on frames and down while idle between frames, so setting fixed clock speed might cause you to hit a thermal or power limit that you wouldn't otherwise hit). I don't know whether Nvidia does this fast clock ramping, but Intel has done something like this in their CPUs.

Only way to find out for sure is to test it.

Only with games that have a capper that uses frame time prediction. The only game I know of that does this, is ezQuake, and the only external capper that does this, is Gedosato.

In all other cases, your latency is bound by your frame time cap.

RealNC wrote:Only with games that have a capper that uses frame time prediction. The only game I know of that does this, is ezQuake, and the only external capper that does this, is Gedosato.

In all other cases, your latency is bound by your frame time cap.

Even with a non-predictive frame cap, if the GPU spends less time working on a frame, then latency can be lower by that difference. Say he caps framerate at 140fps, and the GPU ramps down the clock so it takes 7ms per frame to finish working on it, if the speed of the GPU is doubled and the GPU only takes 3.5ms to finish each frame, the 3.5ms in extra idle time would be a latency improvement. The only requirement is that the framerate cap be implemented earlier in the pipeline than the GPU starting work on a frame.

Sparky wrote:Even with a non-predictive frame cap, if the GPU spends less time working on a frame, then latency can be lower by that difference. Say he caps framerate at 140fps, and the GPU ramps down the clock so it takes 7ms per frame to finish working on it, if the speed of the GPU is doubled and the GPU only takes 3.5ms to finish each frame, the 3.5ms in extra idle time would be a latency improvement. The only requirement is that the framerate cap be implemented earlier in the pipeline than the GPU starting work on a frame.

Can you elaborate on that? I don't know how that can be achieved without some amount of prediction :-/

The way I know this works, is that the limiter has to hold the current frame until 7ms have passed since the previous frame was displayed. Since the limiter doesn't know how much time the next frame needs to get rendered, input needs to be sampled before rendering the next frame. This cannot wait. You need to start rendering as soon as possible. If you wait and start rendering as late as possible, then that's a predictive frame limiter. Where exactly in the pipeline the limiter works shouldn't matter if it's not a predictive limiter, I think.

I believe basically all the frame limiters act like a gate that delays the next frame until Xms after the previous frame went through the gate. The only thing I'm aware of that delays a frame after it has finished rendering is v-sync. The main question is where the gate is. RTSS seems to cap it at the start of the flip queue/max prerendered frames. RadeonPro seems to cap it at the end of the flip queue/max prerendered frames. In game caps SHOULD cap it right before collecting input. I did do some testing on GeDoSaTo, but it didn't seem to work as described, here's that thread http://forums.blurbusters.com/viewtopic.php?f=10&t=2168. I'll put testing ezQuake framerate limits on my to-do list.