Blur Buster's G-SYNC 101 Series Discussion

Talk about NVIDIA G-SYNC, a variable refresh rate (VRR) technology. G-SYNC eliminates stutters, tearing, and reduces input lag. List of G-SYNC Monitors.
Bendy52
Posts: 2
Joined: 06 Jul 2017, 22:14

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by Bendy52 » 07 Jul 2017, 21:26

Thx for info.

razorhanny
Posts: 1
Joined: 09 Jul 2017, 08:00

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by razorhanny » 09 Jul 2017, 08:10

I'm sorry if I'm being stupid, but I've read on this thread that the ingame fps limiters are often imprecise, and that the msi afterburner limiter is precise to the ms. So why can't I just leave a global limit on afterburner, global Vsync on nvidia control panel and be done with it?

Based on the fact that I have an 100hz Acer X34, and afterburner is so precise, why can't I use 99fps as the global limit? When playing doom with this 99fps afterburner cap and global vsync on I'm getting a really nice experience, with no perceived difference if I cap it to this thread's recommended 97, surely I did no scientific tests, it's based on empiric evidence alone.

tl:dr Isn't msi limiter precise enough that a cap 1 fps below the monitor max will keep the game gsynced?

Thank you!

User avatar
jorimt
Posts: 2481
Joined: 04 Nov 2016, 10:44
Location: USA

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by jorimt » 09 Jul 2017, 09:21

I already answered the "precision" question in this thread:
http://forums.blurbusters.com/viewtopic ... =10#p27070

Read that post, and my following posts in that thread; they should give you your answer on the first question.

Regarding the second question, -1 FPS isn't quite enough. Whether you can personally feel that extra 1-2 frames of delay (10-20 additional ms), and only on certain frames, is the question.

If you're not comfortable capping -3 FPS below, -2 FPS is almost always enough with either RTSS or an in-game limiter. That said, -2 or -3 Hz is virtually indistinguishable from max Hz, at least at 100Hz+ refresh rates.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

User avatar
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by RealNC » 09 Jul 2017, 09:47

razorhanny wrote:Based on the fact that I have an 100hz Acer X34, and afterburner is so precise, why can't I use 99fps as the global limit?
You'd have to ask NVidia about that. We don't know. We only know that G-Sync works at its best if it has a buffer of at least 2FPS below refresh rate.

Note that the difference in input lag between 99FPS and 98FPS is 0.1ms, between 99FPS and 97FPS is 0.2ms. That's one tenth of a millisecond and two tenths of a millisecond respectively. That's so low, it's not even worth talking about :)
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

blaskovic
Posts: 4
Joined: 14 Jul 2017, 11:09

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by blaskovic » 14 Jul 2017, 11:14

Hi everyone and sorry for my English. I would like to know if my setting is perfect for G-sync. I have a Philips monitor 27 ich 144HZ with G-sync and my Setting is:

Ingame : disable V-sync

NVCP : Vertical Sync "enabled"

Riva Turner Statics Server: Framerate limit 142

Nvidia Inspector : just to force the graphic of the game (aliasing - Anisotropic,ecc)

I would like if this setting are ok. Thank you

User avatar
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by RealNC » 14 Jul 2017, 12:05

Yes, those settings should work well in most games. Sometimes you might run into a game that needs in-game vsync enabled, but overall, the majority of games work best with the settings you're using now.
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

blaskovic
Posts: 4
Joined: 14 Jul 2017, 11:09

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by blaskovic » 15 Jul 2017, 02:56

Thank you for your answer. I have just another question. Is there a possibility of a conflict with all this programs ? For example If I enable an option (for exe game) about vertical sync in NVCP as "enable" and the same option in Nvidia inspector is " Application controlled" who is the winner?

I need of nvidia inspector for graphic options (only antialiasing and anisotropic) but I don't want a conflict about G-sync with NVCP. I hope to be clear. Thank you

User avatar
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by RealNC » 15 Jul 2017, 08:38

NVCP and inspector configure the same thing. If you change something in inspector, NVCP will show the change.
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

open
Posts: 223
Joined: 02 Jul 2017, 20:46

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by open » 15 Jul 2017, 18:21

This is how the rendering process works vaguely in overwatch.

01[CPU]Game engine does main tasks (physics, collisions, interpreting network messages, ect...)
02[CPU]Game engine starts to que up rendering commands by sending them to the rendering thread
03[CPU]Possible delay depending on in-game frame rate limiting <<<here is where the in game frame limiter adds delay>>>
04[CPU]Game engine reads mouse / keyboard inputs and sends the final view adjustments to the rendering thread at the last second
05[CPU]Game engine starts to work on the next frame (repeat 01-04)
06[CPU]At the same time as 05, the rendering thread is now sending commands to the graphics card. The commands come in the form of directX calls.
07[CPU]DirectX calls are processed with NVIDIA/AMD drivers.
08[CPU]NVIDIA/AMD drivers now talk to the graphics card giving it commands. <<<here is where driver level frame rate limiters add delay>>>
09[GPU]GPU renders the frame and accepts new commands from the driver or does not accept new commands based on the refresh technology <<<here is where VSYNC and double/tripple buffering potentially add delay>>> <<<here is also where something like RTSS likely adds delay to control when the frame is exposed to the monitor>>>
10[MONITOR]Monitor refreshes. If GSYNC and in GSYNC hz range-refreshes about the same time as the new frame is ready. If not GSYNC monitor refreshes on its normal refresh rate and either takes a waiting VSYNC frame or reads the most recent complete frame as it scans (which possibly changes mid scan and adds a tear)


So heres how the delays can play out.

The in game frame limiter is the best way to limit in theory because it allows the mouse input to be read right before the game engine sends messages to the GPU. However the in game frame limiter does not understand how long the drivers and GPU will take to complete the frame. So if that varies then you will have to account for the variance by setting the in game frame limit lower. That way if it all of a sudden takes everything less time there will still be enough of a total delay to stay within GSYNC.

The whole pipeline itself can get backed up and add delays or fps drops in a few ways. If you have VSYNC ON then the GPU will not start to work on new commands until a monitor refresh has happened. In overwatch there are a couple possible ways this can add delay. The drivers themselves can be multithreaded. (NVIDIA drivers can work like this) This means that if the GPU isn't taking commands, then one thread of the driver is waiting for the GPU while another thread of the driver is accepting new commands from DirectX and the game. In that case, the commands being sent will be older by the time the GPU is ready for new commands, and the frame you get in the end will be older. Also the game engine of overwatch uses a multithreaded renderer. So the same type of backing up can happen here. If the DirectX calls are waiting for the driver, the game engine is still running in another thread. That game engine will que up more commands while the rendering thread is waiting and the result is that commands are qued up more. Once the drivers and the game engine hit their queing limit, the maximum delay is reached. This is why vsync off and lowering graphics settings can get rid of the floating mouse feeling. The monitor is always ready for the next frame and the GPU is faster than the CPU for each frame so commands don't back up on the CPU side waiting for the GPU accept new ones.

With NVCP limiting and GSYNC, the drivers are causing the delay and this can still make commands back up in the game engine. Advantages are that the drivers are one step closer to the monitors refresh so control is a little tighter. Disadvantages are that drivers are after the mouse input is processed, so any delay added here will be in between the mouse and the screen.

I'm unsure where RTSS applies its limits but given the reports of decent frame timing control and RTSS's focus on the monitor I believe it may be closer to the monitor.

With FAST SYNC the GPU will not wait for the monitor refresh as it would in VSYNC ON. So as far as the drivers and game engine are concerned, FAST SYNC is the same as VSYNC OFF. However on the monitors side, the monitor will only receive the most recent complete frame that was around when it started to refresh. If it refreshes right before a new frame finishes, it will continue with the old frame across its refresh, where VSYNC OFF would have switched to the newest frame mid refresh. (no tearing but the top of the screen will have a higher delay as the fps gets lower and the bottom of the screen will have a higher delay as fps gets higher when compared to VSYNC OFF)

The conclusions are pretty much what you guys already discuss here. VSYNC OFF and high fps provide the best input lag. You want the GPU to be faster PER FRAME than the CPU. This can be indicated by GPU load staying away from 100%. GSYNC can have very little difference in input lag from VSYNC OFF even when using the in game limiter.

Some other interesting conclusions are. That you might be able to set a higher in game fps limit while still staying in GSYNC range by achieving more consistent GPU rendering times. Maybe you lower the graphics settings. So the longest frame rendering time is lower and the possible variance is lower. There are some advanced conclusions but those are unlikely to work in practice.

BONUS SIDE NOTE. Using the primary graphics setting in overwatch on a lower setting reduces cpu load by doing things like reducing physics objects. And you can still have other graphics settings on high if you want.
Last edited by open on 16 Jul 2017, 12:16, edited 1 time in total.

knypol
Posts: 76
Joined: 18 Aug 2016, 03:40

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by knypol » 16 Jul 2017, 11:09

Why should I use Vsync ON with G-Sync? If i have capped 3 frames below my max refresh whats the purpose of VSYNC in Nvidia CP?

Post Reply