Blur Busters Forums

I think it's more serious than that. Right now, I highly suspect that, at least on nvidia, when you max out the GPU, you will get a rather big latency increase. The reason for that could be many things, including the driver preventing the GPU from reaching full saturation (modern GPUs in general are always kept from reaching full saturation.) So what you end up with is driver-side frame limiting. And we all know that driver-side limiting has a latency penalty.

It would be unlikely that spare thread count will have any effect on this.

Jorim did a quick test of this here:

viewtopic.php?f=5&t=3441&start=110#p26975

Uncapped had a latency penalty of up to 2 frames, with 1.5 frames penalty on average.

My theory is that this is universal. It doesn't depend on the game or free system resources or anything else like that. It only depends on whether or not you've hit maximum allowed load on the GPU. If you reach max allowed load, bam! You get a lag penalty.

This effect can be tested even without special equipment, by making sure your uncapped frame rate is in the sub-30s. You can do that by running games at 5K or so, with graphics settings maxed out. When the game runs at, say 25FPS uncapped, mouse-look is very floaty. Alt+tab to RTSS, enable a 24FPS limit, alt+tab back to the game, and voila: more responsive mouse. You can observe that without special equipment because 1 frame of reduced latency at 24FPS is 42ms, which you can easily detect when the game has mouse look (or a software-rendered mouse cursor, like the main menu of Fallout 4 or Witcher 3 with disabled hardware cursor.) Games with an internal limiter can reduce it up to 2 frames, probably more even (because OW tries harder to have low latency when uncapped anyway), and they actually become quite playable at 24FPS (you get 80-120ms lower latency). These latency time reduction values are so high that you're well outside of placebo effects: it's "mouse is floaty as f" vs "this is actually OK."

I tried several games from time to time using this method, and it seems universal: if you run uncapped and hit max GPU load, you get more lag, and RTSS can reduce it by ~1 frame, an in-game limiter by ~2 frames. What depends on game by game basis isn't whether or not you get reduced latency; it's how much of it you get. If you're trying to be competitive and get every advantage you can possibly get, it stands to reason that you would want to exploit this.

(A while ago I made a suggestion to RTSS to include an option that prevents the GPU from being maxed (by always applying a small blocking operation as if a frame limiter was active just 1FPS below what the current frame's render time was, but unfortunately nothing came of it.)

Yes, this problem appears to happen far more often when the GPU gets maxed out well before the CPU. Any savings specifically for CS:GO was not able to be measured since it is likely now CPU limited, which probably explains why it was a non-issue for that particular game -- one of the most popular eSports games. Uncapping advice certainly isn't one-size-fits-all.

It would be lovely to do more tests on what variables causes latencies during uncapped operations.

@RealNC So i need to limit my fps to max gpu load ~95% even with G-sync? Cannot understand.

MaxiJazz wrote:@RealNC So i need to limit my fps to max gpu load ~95% even with G-sync? Cannot understand.

It has nothing to do with 95%. The only important thing is that the FPS limit is reached. When it is reached, you get the least amount of latency possible. But if your FPS falls below the cap, then input lag is increased (this has nothing to do with gsync; same thing happens with vsync off gsync off.)

But, you don't need to do that. But if you do it, you should be getting a latency reduction somewhere between 1 and 2 frames.

MaxiJazz wrote:@RealNC So i need to limit my fps to max gpu load ~95% even with G-sync? Cannot understand.

If you completely max out the gpu, all the buffers before it get filled. This is the case even with v-sync off. Basically, frames pile up waiting for the GPU to work on them(number of frames that pile up depends on game). An in game framerate cap solves this, because is waiting idle for a bit before it receives a new frame, instead of the frame waiting for the GPU to be free.

I've read that an update Microsoft put out (anniversary?) may have broken gsync in some way? I think it has to do with the full screen optimization mode that is in the compatibility options. Either it has to be enabled or disabled for gsync to function properly? I've read about Microsoft messing with things of this nature but don't really know any of the technical details.

I'm running Windows 10 Version:1709 Build:16299.64 (Latest build) and i'm having zero issues with G-Sync with whatever the default option is. I'm not sure if it breaks if you touch that setting but i don't recall it breaking.

There was something about windowed mode gsync not working properly. Fullscreen-only gsync should be working fine.

Interesting. Am I the only one who experiences problems with stuttering/frame pacing on account of the Windows 7/10 compositor applying vsync to windowed applications? Does gsync override this somehow?

Unfortunately more and more applications seem to be forgoing an actual true fullscreen mode altogether, otherwise I would just use that.

Another stupid question:
If my game is CPU bound, do i need to lower frame cap to "CPU not hitting 100%" ?
For example - 144hz G-sync, CPU cant reach 141(142) fps cap, GPU is not 99%(100%).