DisplayPort has the potential to transmit refresh cycles faster than DVI and other ports. It's theoretically possible to push a 1080p refresh cycle over a single DisplayPort channel in approximately 5 milliseconds (IIRC, 1/177th of a second, to be precise).
As for their GSYNC input lag tests -- duh! -- Old news (and incomplete, too). I already found out that too. GSYNC will begin to behave as VSYNC ON when frame rates caps out to maximum. I do not believe the site tested the use of fps_max as a method of reducing input lag.
But as I already wrote, you can take advantage of GSYNC's low input lag behavior by capping the frame rate below the GSYNC maximum. By using fps_max values below GSYNC maximum, you eliminate the driver waiting for VSYNC.
The people at infinite.cz needs to point out the frame capping technique of reducing GSYNC input lag. You can take advantage of GSYNC's low input lag behavior by capping the frame rate below the GSYNC maximum. By using fps_max values below GSYNC maximum, you eliminate the driver waiting for VSYNC. Instead, the driver delivers the refresh immediately to the monitor.
1. Set your GSYNC monitor to 144Hz
2. Modify your test to run at a maximum frame rate of ~135fps
3. You will observe that input lag falls dramatically.
This is because the input lag is caused by driver waiting for the previous refresh cycle to finish before GSYNC. Same kind of issue as VSYNC ON. But if the monitor has already finished refreshing (e.g. you software-based-throttle your framerate, e.g. fps_max), the frame is delivered immediately after your input read without waiting.
There are many games with built-in configurable frame rate capping, and software-based frame rate capping eliminates the input lag caused by hardware capping (e.g. frame rate limited by via driver, frame rate limited by VSYNC ON, etc) because you did an input read, then the external factor (outside of game control) forced an input lag upon you beyond your control -- before displaying the frame. But! That's solved by building a frame rate cap into your game. If you are a game developer, you are smart if you included "fps_max" like the Source Engine. As game developer, you then successfully control the GSYNC input lag via this technique!. It solves the GSYNC input lag in my tests.
That's because game engines often do a keyboard/mouse read [input lag time begins], then renders and presents the frame (e.g. Direct3D Present()), and monitor displays frame [input lag time ends]. If the driver or monitor blocks when you attempt to display the frame, then you've got a forced input lag beyond your control. That's what happens when you let GSYNC hit maximum refresh rate. (same issue as VSYNC ON). Because it's now waiting for the previous refresh to finish first -- that's input lag! But as game developer, one can solve this, bring this into your own game applications control (if you are a game developer) simply by running at framerates slightly lower than the currently configured GSYNC maximum refresh rates. When this happens, your frames are immediately delivered (because previous frames are already fully finished refreshed, so no waiting at all), there's no blockage, no added lag, because you're not hitting the maximum. The average latency becomes equivalent to VSYNC OFF, and you get ultralow GSYNC latency with the full benefits of GSYNC fluidity with no tearing.
Therefore, infinite.cz has made a mistake by incomplete test (only testing out full frame rate). They need to display benchmark numbers during framerate-capped situations. They didn't publish that. They need to modify their input latency test to also test software-base frame rate capping, like the frame-capping capabilities currently found in several game engines now. Their software application that they used for the photodiode needs to have a configurable fps_max value, and I don't think they added that. Thus their lag testing app isn't functioning the same way as a game engine (that has a built in fps_max ability). They need to make their lag testing technique fully explained. fps_max in CS:GO essentially configures the refresh rate of a GSYNC monitor, and using fps_max during GSYNC fixes the input lag that infinite.cz is reporting.