Blur Busters Forums

RealNC wrote:Shouldn't this thread be sticky?

No, seriously, it should be sticky and always at the top. However, I can't see an option in the moderation panel.

I believe that requires admin privileges. You can send a request to the Chief.

I thought it was going to be stickied myself, but it never happened; I didn't follow-up.

Question:

I've capped my framerate at 140 fps. Most in game limiters aren't very accurate.

Although my framerate says it never goes above 140 in seeing some frametimes that exceed my refreshrate.

In using gsync + vsync. Should I cap my framerate even lower to avoid those frametimes quicker than my refreshrate to avoid an input lag penalty?

No. 142FPS cap is enough, and 141FPS is even safer. The frame time dips are a non-issue, since g-sync will display those frames at the right time to avoid tearing; not too soon (to avoid tearing) but also not too late (to avoid lag.) If the overall frame pacing of the limiter is good enough, g-sync will do an excellent job of "spacing out" the frames as needed.

The frame limiter would have to be outright abysmally bad at frame pacing for it to trigger full vsync-like behavior with g-sync at 141FPS. Not saying there aren't any such frame limiters out there, but you would be able to see that in the RTSS/Afterburner OSD. The latest beta of Afterburner can even display frame time graphs in the OSD. You can use that to verify how good the frame limiter is:

http://www.guru3d.com/news-story/downlo ... ta-12.html

RealNC wrote:No. 142FPS cap is enough, and 141FPS is even safer. The frame time dips are a non-issue, since g-sync will display those frames at the right time to avoid tearing; not too soon (to avoid tearing) but also not too late (to avoid lag.) If the overall frame pacing of the limiter is good enough, g-sync will do an excellent job of "spacing out" the frames as needed.

The frame limiter would have to be outright abysmally bad at frame pacing for it to trigger full vsync-like behavior with g-sync at 141FPS. Not saying there aren't any such frame limiters out there, but you would be able to see that in the RTSS/Afterburner OSD. The latest beta of Afterburner can even display frame time graphs in the OSD. You can use that to verify how good the frame limiter is:

http://www.guru3d.com/news-story/downlo ... ta-12.html

Im going to check out the new beta. Per rtss osd I am getting lows below the refreshrate of my monitor even at 140 fps cap. I've seen it hit in the 4 ms range actually in cs go.

I want to see it with a graph however. That's extremely useful.

With G-SYNC + V-SYNC + 141 FPS limit, 4ms frametimes would not allow it to hit or exceed the G-SYNC ceiling or cause V-SYNC-level input latency. Again, frametime is separate from framerate and refresh rate in this instance.

And usually, a fluctuating in-game limiter, CS:GO, for instance, actually caps the framerate lower than what you input; 142 limit results in 139-140 limit, etc.

With G-SYNC, we're limiting framerate, and thus refresh rate to avoid the G-SYNC ceiling. Lower frametimes don't really factor in, and frames will be delivered in the desired intervals regardless.

jorimt wrote:With G-SYNC + V-SYNC + 141 FPS limit, 4ms frametimes would not allow it to hit or exceed the G-SYNC ceiling or cause V-SYNC-level input latency. Again, frametime is separate from framerate and refresh rate in this instance.

And usually, a fluctuating in-game limiter, CS:GO, for instance, actually caps the framerate lower than what you input; 142 limit results in 139-140 limit, etc.

With G-SYNC, we're limiting framerate, and thus refresh rate to avoid the G-SYNC ceiling. Lower frametimes don't really factor in, and frames will be delivered in the desired intervals regardless.

thanks for clarifying that. It looks like I can bump my framerate up to 142 for cs go. I thought if you hit lower frametimes you are actually hitting those framerates for that frame but the average framerate is staying in tact.

I'm seeing a lot of measurements out there these days that take 1 % lows to supposedly measure frametime stability.

Yeah, with standalone, uncapped V-SYNC OFF those 1% frametime lows can make a visible difference, but with FPS-limited G-SYNC, it doesn't really matter.

Hi:
First thx for the info in this article and the job you made guys.

Nvidia did a bad job with all that Gsync and drivers shit.

i got a Gsync Aoc G2460PG screen a while ago.
i first used Nvidia driver 382.05 and i used the default NVCP settings for the G sync and everything was ok.
up untill 382.53 where i first noticed my issue which led me to this thread.

i always used frame capper for games at 141 fps.
with that driver i saw my first tearing with g sync and then i learned it should be with Vsync on in nvidia CP, which was alwyas app controlled and off in games. still was fine before that driver.

So i went ahead and used v sync in NVCP and went normal back, But a new issue appeared that every like 20 min or so a small graphical corruption occure for a mil second but i can see it clearly.

My GPU is stock and cool, i though its a driver issue but now its the same with 382.33 and 384.76.

and i tried testing g sync off and its gone.
also if i remove the frame limiter back to un capped the issue takes longer time to appear like every 45 min.

what im here to ask though is, sry English is not my main language.

If G sync and V sync were on and v sync off in game, the fps cap is required for the game to stay working with g sync.
but i can see the latency in SV_netgraph 1 in cs go that the latency is higher py 1-1.5 ms when i use a capper compared to when i leave it off and the frame hit the 144 level. which seems odd comparing what this article says.

any ideas about it and the issue with that graphic thing ?

btw: the graphic issue appears only in Source games.

Games cannot measure input latency. What you're seeing is probably just the client-server latency, which is probably affected by frame rate.

Bendy52 wrote:So i went ahead and used v sync in NVCP and went normal back, But a new issue appeared that every like 20 min or so a small graphical corruption occure for a mil second but i can see it clearly.

Without more details, I don't have a clue what the "graphical corruption" would be. Flicker? A sudden pause or halt? Artifacts? I own the game and play it with G-SYNC enabled, and I haven't noticed such an issue.

Bendy52 wrote: If G sync and V sync were on and v sync off in game, the fps cap is required for the game to stay working with g sync.
but i can see the latency in SV_netgraph 1 in cs go that the latency is higher py 1-1.5 ms when i use a capper compared to when i leave it off and the frame hit the 144 level. which seems odd comparing what this article says.

There is so much more to input lag than the syncing method used; G-SYNC is responsible for aligning rendered frames to the display's scanout, nothing more. What I covered in my article is simply one aspect of input lag. There are countless other contributors, including online games with ping, tick rate, etc.

As RealNC said, the server response could be tied to framerate, which is entirely unrelated to G-SYNC. I myself am not an expert on netcode, but you can learn more about that via Battle(non)sense's YouTube channel:
https://www.youtube.com/user/xFPxAUTh0r1ty

He covers the subject of netcode in detail.