G-Sync's 1ms Polling Rate: My Findings & Questions

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.
Post Reply
User avatar
jorimt
Posts: 2481
Joined: 04 Nov 2016, 10:44
Location: USA

Re: G-Sync's 1ms Polling Rate: My Findings & Questions

Post by jorimt » 12 Nov 2016, 16:44

RealNC wrote:I just want to mention another method of testing input lag. This only works for CS:GO though.

When you open the developer console, you can drag it across the screen. The console's window goes through the rendering pipe like everything else. The mouse cursor does not. CS:GO uses the hardware cursor, which is a framebuffer overlay and is not affected by vsync. It's "injected" live into the framebuffer in real-time. This is why games using a hardware cursor never have a "floaty" cursor with vsync on.

When you drag the window, the mouse cursor moves first, then the window a few frames after. With vsync off, they should move at the same time.

When you move the mouse fast enough, you can measure how many frames of input lag there are by counting how many frames it took for the window to start moving after the mouse cursor moved.
Well that's clever. Thanks!

Sure enough, G-Sync + V-Sync on without a cap, and the delay between the time the mouse cursor moves and window is dragged is even visible by eye. I'd say it's at least three frames.

The tricky part is getting an accurate reading with the in-game cap on the menu; the framerate/frametime drifts a lot. That, and there are two separate in-game caps for the menu and gameplay. Can I also use RTSS to cap, or will it destroy the process that makes this possible?

That said, by eye, it "looked" instantaneous at as high as a 143 fps in-game cap, believe it or not. Is there a way to measure this accurately with an average (photography) camera, or maybe a internal video capture method? Unfortunately, my phone (ha, sad) maxes out at 120 fps slow-mo video capture, and I doubt it would be accurate enough anyway.
(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)

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: G-Sync's 1ms Polling Rate: My Findings & Questions

Post by Sparky » 12 Nov 2016, 16:53

You can use RTSS with that technique, but it will add 1 frame of latency over an in game cap. The hardware cursor happens at the very end of the chain, after most video capture tools get the frame. Not sure if shadowplay will capture the cursor, but other tools definitely won't, they have to read the mouse position and add a cursor in themselves, or just record without a visible cursor.

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

Re: G-Sync's 1ms Polling Rate: My Findings & Questions

Post by RealNC » 12 Nov 2016, 17:14

As Sparky said, RTSS will work.

Note however, that the in-game capper, even though lower latency than external cappers, has become quite shit in recent years. It doesn't cap accurately anymore like it used to. Setting max_fps 200 for example produces a fluctuating FPS between 198 and 199. It's impossible to use it anymore to cap to, say 143.9 on 144Hz vsync. The result is just all over the place.

For measuring this, a video recording program with mouse cursor support would do, but it would need to be able to record 144FPS video... I don't think there's any software that can do that, even though it would be quite possible when using a low resolution :-(
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.

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

Re: G-Sync's 1ms Polling Rate: My Findings & Questions

Post by jorimt » 12 Nov 2016, 17:27

Sparky wrote:You can use RTSS with that technique, but it will add 1 frame of latency over an in game cap. The hardware cursor happens at the very end of the chain, after most video capture tools get the frame. Not sure if shadowplay will capture the cursor, but other tools definitely won't, they have to read the mouse position and add a cursor in themselves, or just record without a visible cursor.
Understood, thanks.
RealNC wrote:As Sparky said, RTSS will work.

Note however, that the in-game capper, even though lower latency than external cappers, has become quite shit in recent years. It doesn't cap accurately anymore like it used to. Setting max_fps 200 for example produces a fluctuating FPS between 198 and 199. It's impossible to use it anymore to cap to, say 143.9 on 144Hz vsync. The result is just all over the place.

For measuring this, a video recording program with mouse cursor support would do, but it would need to be able to record 144FPS video... I don't think there's any software that can do that, even though it would be quite possible when using a low resolution :-(
Is that because the in-game cap is trying to limit incoming framerate instead of frametime? Because RTSS looks like it's capping at frametime, not framerate. Correct whatever ignorance I'm exhibiting.

So video capture would work, but it would have to be at a capture rate that currently doesn't exist. The dead ends a user-end amateur enthusiast encounters, I suppose.

I suppose IF it captured the cursor, MSI Afterburner could be used with 100 or 120 fps settings and the monitor in 100 or 120 Hz mode, but that would be besides the point if I'm trying to test 144 Hz. Perhaps it would give me equivalent latency data that could be bridged by math however?

EDIT: Nope, just tested it, and with the Afterburner video capture, the cursor doesn't show up.
(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
jorimt
Posts: 2481
Joined: 04 Nov 2016, 10:44
Location: USA

Re: G-Sync's 1ms Polling Rate: My Findings & Questions

Post by jorimt » 13 Nov 2016, 11:03

@Sparky

You seem to know pretty much all there is to know about V-Sync and adjoining input latency. Maybe I've been looking at the 120-144 "G-Sync + V-Sync on" range all wrong, and making it way more complicated than it actually is.

If V-Sync at 144 Hz (or any refresh) introduces up to 3 frames of input latency (on a side note, is that number right, or can it add more less in that scenario?), then capping below it with an in-game limiter is going to reduce additional latency to nothing, right? Or can we still be seeing an additional 1-2 frames of latency, even without fully hitting the V-Sync ceiling?

I'm thinking the answer is a simple no, because even with plain old V-Sync, once you cap a couple frames below it, aren't you reducing or entirely eliminating the input latency it introduces, by prevent the buffer from over-queuing frames?

If that's the case, I would imagine it would theoretically be the same with G-Sync + V-Sync on, unless of course, again, the 1ms polling rate (and its 3-5% performance hit/tearing issues with V-Sync off) factors in.
(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)

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: G-Sync's 1ms Polling Rate: My Findings & Questions

Post by Sparky » 13 Nov 2016, 12:17

jorimt wrote: If V-Sync at 144 Hz (or any refresh) introduces up to 3 frames of input latency (on a side note, is that number right, or can it add more less in that scenario?), then capping below it with an in-game limiter is going to reduce additional latency to nothing, right?
Almost, with plain old v-sync and an in-game framerate cap you still have the random 0 to 1 frame of input lag, due to the lack of synchronization between the game and display, though g-sync should fix that.

In my testing with v-sync, you didn't need to be very far at all below the refresh rate for the framerate cap to eliminate most of the input lag (less than 0.1 fps below the refresh rate). This caused the latency to decrease slowly for 10ish seconds, then jump up by one frame when the frame deadline was missed. While if the framerate cap is 0.1fps over the refresh rate, latency would over the course of a minute or so creep up to exactly where it would be without a cap at all. You can't get them identical because the refresh rate and the framerate limiter are running on different clocks.

And in some circumstances, v-sync can add more than 3 frames of input lag, like if you're using triple buffering without dropped frames, or high flip queue depth/prerendered frames. Can also get v-sync down to about 1.5 frames of added input lag(without the stutter/frame drops caused by a framerate cap) by flushing the gpu after every frame, but that has performance consequences.

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

Re: G-Sync's 1ms Polling Rate: My Findings & Questions

Post by jorimt » 13 Nov 2016, 14:04

Okay, so the reason a framerate limit just under the V-Synced refresh causes a variable jump of up to 1 frame input latency, is because the cap is now introducing frames in uneven/offset intervals of the refresh rate, instead of even intervals without a cap.

As for there being more than 3 frames of V-Sync latency, in the G-Sync + V-Sync on case, we're probably not looking at more than 3 frames, unless of course, the user is either stupid enough to have pre-rendered frames set too high in the control panel, and/or enables in-game triple-buffering on top of the aforementioned combo (which triggers when he hits the G-Sync ceiling), or the case that the game has a high default pre-rendered frames number, and it engages triple-buffering behavior at default with V-Sync enabled.

I guess the question is (yes, I'm starting to sound like a broken record, sorry), is if G-Sync + V-Sync on is possibly mimicking the variable input latency that is introduced in the situation you described, but instead of happening only a fraction of a frame below the refresh rate, it's possible the variable latency is being introduced in our much discussed 125-142 range somehow because of the 1ms polling rate.

I did find this 2013 article from the advent of G-Sync:
http://www.anandtech.com/show/7582/nvidia-gsync-review

Whether or not the module's functions have progressed or changed since then (they probably have), I'm assuming the basics remain the same. I find this portion interesting regarding the V-Blank:
G-Sync works by manipulating the display’s VBLANK (vertical blanking interval). VBLANK is the period of time between the display rasterizing the last line of the current frame and drawing the first line of the next frame. It’s called an interval because during this period of time no screen updates happen, the display remains static displaying the current frame before drawing the next one. VBLANK is a remnant of the CRT days where it was necessary to give the CRTs time to begin scanning at the top of the display once again. The interval remains today in LCD flat panels, although it’s technically unnecessary. The G-Sync module inside the display modifies VBLANK to cause the display to hold the present frame until the GPU is ready to deliver a new one.

With a G-Sync enabled display, when the monitor is done drawing the current frame it waits until the GPU has another one ready for display before starting the next draw process. The delay is controlled purely by playing with the VBLANK interval.
Finally, regarding the module's on-board memory:
The G-Sync board itself features an FPGA and 768MB of DDR3 memory. NVIDIA claims the on-board DRAM isn’t much greater than what you’d typically find on a scaler inside a display. The added DRAM is partially necessary to allow for more bandwidth to memory (additional physical DRAM devices). NVIDIA uses the memory for a number of things, one of which is to store the previous frame so that it can be compared to the incoming frame for overdrive calculations.
Now, this could be pure ignorance coming up here, so bear with me.

From this thread, we can assume that G-Sync + V-Sync off is exposing the supposed 1ms polling rate's inability to complete the frame when the current fps isn't at least 1ms frametime under the max refresh, causing the tearing seen at the bottom of the screen. We also know that G-Sync begins scanning to the display from the very top to the bottom of the screen.

My question to you, is it possible with G-Sync + V-Sync on to use the module's on-board memory to hold frames for the fraction of time the 1ms polling rate needs to catch up in that very small, specific range of, say, 125-142, and delay the render from the top of the screen, to a little lower/higher offset (late or even early?), with the remaining section (where we see tearing instead with G-Sync + V-Sync off) being rendered/synced at a slightly slower or different rate?

I realize my description is severely under-cooked, and may be entirely flawed, but I had to put it out there. Because even if I'm a bit of an uninformed moron ( :D ), it might trigger a bigger truth that those more knowledgeable than I in these matters could gather from it.

Or, someone could perform rigorous latency tests within that 125-142 "G-Sync + V-Sync on" range, and destroy all of this "fun-filled" speculation once and for all.
(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)

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: G-Sync's 1ms Polling Rate: My Findings & Questions

Post by Sparky » 13 Nov 2016, 15:27

Say your framerate is a rock solid 140fps, g-sync on v-sync off. Does the tear at the bottom of the screen stay in the same place, and does it happen on every frame? If yes to both, there's probably nothing to worry about with using g-sync on and v-sync on at 140fps.

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

Re: G-Sync's 1ms Polling Rate: My Findings & Questions

Post by jorimt » 13 Nov 2016, 16:15

I'll do you one better than a text reply.

For the record, I'm using a Corsair Vengeance K65 compact mechanical gaming keyboard with a reported 1ms response rate, and a Razer Deathadder Chroma mouse at 800 dpi/1000 Hz on a i7-4770k/980 Ti with the Acer Predator 27" XB271HU 144 Hz (165 Hz overclockable) G-Sync monitor. Overdrive is set to normal, G-Sync mode to fullscreen only.

I captured the below footage with a Samsung Galaxy Note 3 rear camera in 120 fps slow motion @720p. Not at all optimal, but it should give you a better idea on what's happening with G-Sync + V-Sync off at a certain framerate.

For the purposes of the video, I set the monitor to 120 Hz, and the in-game cap at 118 fps:
phpBB [video]


The behavior, regardless of the native refresh, is consistent. The display stops tearing screen wide and limits itself to the bottom at 144 Hz around the 142 mark. For 100 Hz, it's around 98 fps. 165 Hz is around 162 fps.
Last edited by jorimt on 14 Nov 2016, 22:53, edited 1 time in total.
(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
lexlazootin
Posts: 1251
Joined: 16 Dec 2014, 02:57

Re: G-Sync's 1ms Polling Rate: My Findings & Questions

Post by lexlazootin » 13 Nov 2016, 17:03

I took the high speed from work a week ago to do the test because i have no idea what you're on about but i forgot the SD card and i kept on forgetting it, finally took the time to remember it and my brother is leaving for NZ today and is taking the cameras :lol:

So if someone else cares they can do it :)

Post Reply