Blur Busters Forums

Greetings all again!

i went to test GSYNC abit more, since i was really curious what will happen at the cap. Before i go on, one thing about the method - it's quite old method (few years) that was developed for event purpose (since infinite.cz is an event company) to test video and audio latency of various setups - and we're talking about big LED screens or video walls made of seamless plasma panels, as well as different device on the way (splitters, repeaters). For that we never cared about +/- 1ms accuracy, but rather than being able to discover what is causing +50ms. Since the device is USB, i believe many of you are aware that by default, USB have 125hz polling rate, which means +/- 4ms inaccuracy caused just by USB. This wasn't fixed for the original tests, given the fact that most mouses still run at 125hz and if we're measuring button-to-pixel, i believe it's more accurate this way. 18 measures we're done for each test, result is the average.

However, given the fact that i was going to measure a lot of values, if i had to 18 tests for each, i would spend days on it. And since I'm not paid to do it, i don't really have days. So i applied the 1000Hz fix, therefore values shown below are cca. -4ms than the values posted in the original article.

First test i did was to cap the frame rate at 125 and then suddenly switch the limiter to 200fps and measure latency for each frame as well as real fps. results below.

We can see that the game was allowed to run at 200fps for some time, while increasing the lag. When we reached vsync values, the game was capped by drivers (waiting for Present() return).

I did the same test with 400fps instead of 200. The cap was reached in 8 frames.

Naturally i did a reverse test, going from 200 to 125

The values are slowly falling back to their original levels. When i limited the fps to 60, it went down to "no vsync" values in just 3 frames.

Conclusion
In my humble opinion, it looks like there are up to 3 buffers on the way, that can store frames and compensate short frame rate drops, causing variable input delays. While this looks definitively like something that is more feature than a bug - short frame rate drops can occur when a game executes a scripted sequence, does an unexpected load etc. and this feature can compensate them. Cool. However it also introduces variable input lag, which can cause problem for competitive players.

If I'm not wrong, it would be nice if we had a little bit more control about this feature, having this mode as default for smoothest movement. Second option could be to cap the game on the very first frame, keeping input lag to minimum at all times (similar to fps cap). Third option can be something similar to triple buffering - allow 2 frames in advance, while not capping frame rate at all. (I know there is a triple buffering option in nvidia drivers, tried turning it on and off, but it had no effect). The second option can be done by setting max_fps or using external frame rate cap utility (I'll to try to produce one, if i find some more spare time). I have no idea how to emulate triple buffering, when the game thinks it runs in "vsync off" mode.

EDIT: I also hope this is not an old news, these things aren't really my field.

Good work doing these measurements.

As you know about LCD scanout -- I presume you've already seen high speed video of an LCD refresh, where the pixels refresh from top edge downwards to bottom edge, in a few milliseconds (typically ~6.9ms at 144Hz). Since GSYNC does not restart the scanout or splice the refresh (tearing) in mid-scanout, it has to wait for the monitor to finish refreshing before the frame can be delivered (Present() blocks rather than returns quickly). When this happens, the buffers in many game engine can pile up because of this. When Present() stops blocking (no waiting for LCD scanout), the buffers empty themselves, and subsequent frames can present quickly.

ENiKS wrote:I have no idea how to emulate triple buffering, when the game thinks it runs in "vsync off" mode.

This can be done by running the game in windowed mode and with Windows Aero enabled. v-sync has to be disabled in the game. You get v-sync (from Aero, not from the game) *and* an uncapped frame rate (because the game thinks v-sync is disabled.) In that scenario, the game draws into a compositing buffer, and Aero picks up a frame from that buffer after every monitor vlank. This is how triple buffering would work. However, Aero is high-latency, so it doesn't help much. (I suspect it has a framebuffer queue that increases lag.)

Chief: I even remember the time when i had monochromatic crt on my table. The values are measured in upper left corner.

I checked more on this behavior, and it seems Direct3D feature called "render ahead" is responsible for this. See this function > http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Frame latency is the number of frames that are allowed to be stored in a queue before submission for rendering.

So perhaps, while graphics card fps cannot go above GSYNC, CPU can. Present() will just actually put frame into render queue and continue, temporary running at higher FPS than GPU.

RealNC - I was thinking about getting gsync to behave like triple buffering - ie when game runs at higher fps than refresh rate, frames won't go into render queue or be blocked by refresh rate, with occasional frame being discarded. Unfortunately, i haven't seen runing Aero with GSYNC (and even if it would, GSYNC will refresh according to aero, not game).

ENiKS wrote:I checked more on this behavior, and it seems Direct3D feature called "render ahead" is responsible for this. See this function > http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Frame latency is the number of frames that are allowed to be stored in a queue before submission for rendering.

So perhaps, while graphics card fps cannot go above GSYNC, CPU can. Present() will just actually put frame into render queue and continue, temporary running at higher FPS than GPU.

The render ahead queue is configurable in the NVidia control panel. In the 3D settings, it's the "Maximum pre-rendered franes" field. The default of "application controlled" usually results in 3 pre-rendered frames. You can set it to 1 to get rid of two extra frames of lag.

Q83Ia7ta wrote:For myself i found most interesting last test when display refresh set at 144hz, vsync off, gsync off.
BenQ XL2411T: 28 ms
BenQ XL2420Z: 27 ms
ASUS VG248QE: 24 ms
ASUS VG248QE(with GSYNC): 14 ms
I guess all monitors except GSYNC one connected with DVI.

What i would like to know, is if the result (14 ms) is because of DP connection or thanks to both gsync module & DP, even if gsync feature was disabled.

DisplayPort alone would not reduce input lag this much.

wait... so is the gsync modded vg248qe less laggy than the stock vg248qe? cuz on prad.de:
http://www.prad.de/new/monitore/test/20 ... sverhalten

the stock vg248qe already has sub-frame input lag.........

With gsync what is the advantage of capping to 135-138 instead of say 143?

Theoretically, none.
However, a bigger margin makes GSYNC stay low latency.

The ASUS ROG is currently in the lab for testing. Will find out if its behaviour improves upon the VG248QE. Keep tuned.