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

[RealNC]

It also shows that Nvidia Inspector's fps limiter is adding up to 3 frames of additional latency (!!!).

The nvidia limiter enables adaptive vsync (even if you've set vsync to off), and caps the frame rate slighty above your vsync rate, so if you use that limiter, you get vsync. So no surprise there.

I still have no clue what nvidia is trying to do with that limiter... It's complete nonsense.

Unfortunately, he didn't test G-Sync + V-Sync on + an in-game fps cap, he didn't test RTSS for latency, and he only tested the cap at 142 fps.

So basically, he didn't test anything actually useful

[jorimt]

The nvidia limiter enables adaptive vsync (even if you've set vsync to off), and caps the frame rate slighty above your vsync rate, so if you use that limiter, you get vsync. So no surprise there.

I still have no clue what nvidia is trying to do with that limiter... It's complete nonsense.

Thanks, that makes way more sense. I've always avoided using it myself.

I'm sure you're aware they recently exposed "v2" Frame Rate Limiter options in Nvidia Inspector; not sure if they're at all improved though. He didn't say what version he was capping with.

There are some interesting options in Nvidia Inspector under the "Other" section called "Frame Rate Limiter 2 Control," but I can't find any detailed documentation on them.

So basically, he didn't test anything actually useful

Sadly no, though it at least further confirms some basic G-Sync behavior for the record.

[jorimt]

I found this post on another forum from earlier this year:
http://www.overclock.net/t/1597089/gsyn ... t_25177059

That guy posted a few high speed camera latency tests, including one where he tested G-Sync + V-Sync on/off (linked above), and apparently there wasn't a difference at 135 fps (I think he was using RTSS).

Not sure how much I trust the results though.

The rest of his test posts:
http://www.overclock.net/t/1597089/gsyn ... t_25094298
http://www.overclock.net/t/1597089/gsyn ... t_25101571

[Sparky]

Testing with a high speed camera is pretty tedious, so some of us use a photodiode or photoresistor and microcontroller instead. The microcontroller acts as a USB mouse, and measures the time difference between the USB input and the monitor output. It's not as visual a testing method as a high speed camera, but instead of spending an hour counting frames and getting tens of samples, you can spend a few minutes and get thousands of samples. With about $50 and some time you can make your own.

Here are a couple threads to look through:
http://forums.blurbusters.com/viewtopic.php?f=10&t=1381
http://forums.blurbusters.com/viewtopic.php?f=10&t=3005

[jorimt]

I will definitely look through those, thanks.

Is there a reason why someone with the equipment hasn't tested G-Sync combinations at this point? How difficult would it really be (time consuming, no doubt) for someone to test G-Sync in, say, CS:GO, and run G-Sync + V-Sync on with an in-game cap ranging from 120-139, and then compare that to G-Sync + V-Sync off?

As far as I know, no one has a clue what V-Sync is doing with G-Sync in that small range, and why it conceals the tearing seen at the bottom of the screen (without introducing full V-Sync behavior) that G-Sync + V-Sync off can not.

I am seriously considering building one of those devices (erm, if I'm at all capable) and testing myself. I do wish Nvidia was a little more transparent/communicative on the subject; it would have saved me lot of trouble

[Sparky]

Is there a reason why someone with the equipment hasn't tested G-Sync combinations at this point?

As far as I know, no one has a clue what V-Sync is doing with G-Sync in that small range, and why it conceals the tearing seen at the bottom of the screen (without introducing full V-Sync behavior) that G-Sync + V-Sync off can not.

Well, if I had a g-sync monitor and an nvidia video card I would have.

I am seriously considering building one of those devices (erm, if I'm at all capable) and testing myself. I do wish Nvidia was a little more transparent/communicative on the subject; it would have saved me lot of trouble

It's not particularly difficult, especially if you just duplicate what people have already built.

As far as I know, no one has a clue what V-Sync is doing with G-Sync in that small range, and why it conceals the tearing seen at the bottom of the screen (without introducing full V-Sync behavior) that G-Sync + V-Sync off can not.

Inside the VRR range, G-sync monitors have to change their refresh rate, but they don't know beforehand when a frame is going to finish, so they might have to either buffer the incoming frame until the start of the next refresh, or temporarily backpressure the GPU until the monitor can increase the rate it scans the LCD. Seems a bit weird, probably some legacy reason to do it that way instead of scanning at the maximum pixel clock and then sitting idle until the next frame arrives or a self refresh happens. Maybe something else is happening(like the instantaneous framerate is fluctuating between say 135 and 150 fps), hard to say.

[jorimt]

I have no doubt you would have tested it. Also, which of those two devices you linked to do you recommend for the purpose of testing G-Sync?

As for the VRR range, I've been thinking about G-Sync's V-Sync solution for a while now. I may be out of my depth here, but while it effectively acts like standalone V-Sync above or below the G-Sync range, is it identical, or does it have differences from plain old V-Sync? That is, is it actually G-Sync acting like V-Sync when needed, or is it just falling back on V-Sync when required?

I know one of the only difference between V-sync off and G-Sync, is that G-Sync starts the scan directly from the top of the screen, so if G-Sync + V-Sync off is exposing the presumed 1ms polling rate's inability to complete near the bottom of the screen within a certain range nearer the G-Sync ceiling, I'm assuming the only way G-Sync + V-Sync on prevents this is by somehow buffering the remaining frames near the bottom (even possible?). So, in very crude terms, could V-Sync in this range be considered a "buffer" to G-Sync?

Urg, I really wish Nvidia had technical documentation on G-Sync available (not that I could fully understand it anyway).

[Sparky]

Well, there are more than just two solutions in those threads, There are three main things that are different:

Choice of development environment: I used arduino, flood started with arduino then switched to something else. I'm not sure which development environment Oomek or flood are using, maybe Atmel Studio? Arduino is probably easiest to get into, though you have to modify some library files if you want to subtract out the random delay of USB polling from your measurement.

Which type of photodetector to use: Photodiode, photoresistor, or phototransistor. Photoresistor is probably easiest to use, though has the worst performance(Though I can get ~50 microsecond accuracy with one, which is good enough for testing g-sync.)

Whether to use an amplifier: Analog reads on the microcontroller take longer than digital reads, so you can get a bit better performance by using an opamp to give you a nice clean edge into the microcontroller.

Here's the post where I go into detail on the setup I'm currently using: http://forums.blurbusters.com/viewtopic ... =50#p22634

[RealNC]

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.

[lexlazootin]

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.

Holy shit, that's really smart.