Originally Posted by liskawc
got only so far as the method goes, but this method is flawed. it tests the entire lag from the press of a button to the update on the screen.
That's correct, but the method is not flawed.
I actually wrote about this -- further down the article, I explain why this method of test is done, and why it's more honest than other lag tests. It tests the entire human chain lag, so it's easy to mathematically calculate the differential between VSYNC OFF latency versus GSYNC latency
, via the honest, whole chain method.It's simple, it's deterministic, it's honest, it's real-world games.
1. Run full chain test with VSYNC OFF
2. Run full chain test with GSYNC
3. Compute difference.
It was necessary to do the whole chain:
- to include whatever the display is doing (hardware-based GSYNC latency)
- to include whatever the driver is doing (software-based GSYNC latencies)
- to include whatever the game is reacting to GSYNC (software-based GSYNC latencies)
This makes the full chain method more honest and less flawed.
I do not trust most sites' hard numbers on input lag, without additional data on what part of the chain is measured, using what.
A lot of sites have not been always specific on what part of input lag chain.
- Most input lag tests uses test equipment, rather than real-world games.
- Lag relative to scanout? (Remember, top edge of screen has less lag than bottom edge of scree)
- Average lag?
- Whole button-to-pixels lag?
- Display-specific lag?
- CRT measurement method?
- SMTT measurement method?
- Leo Bodnar measurement method? (A veritable black box: Does it include HDMI transciever delay too? Does it account for the ~0.5ms-1.0ms latency of the Vertical Back Porch in the signal timings? Does it measure to 50% midpoint of pixel transition? Or measure to "first light" of a pixel?)
- Are you maeasuring lag from signal input to pixel illumation?
- Including or excluding cable lag?
- Lag from signal input to pixel illumation?
- Lag to first faint visibility of LCD pixel (early in pixel transition cycle?) Pixels don't react instantly, y'know.
- Lag to final full visibility of LCD pixel (late in pixel transition cycle?)
- And, even CRTs have input lag, if you're measuring bottom-edge input lag with a Leo Bodnar, because of the scanout delay (for framebuffered architectures).
- Sometimes it's not easily possible to measure certain parts of the chain.
- I also have a photodiode osilloscope (same as prad and TFTCentral), however, it's not suitable for real-world game testing.
- Most of the above lag tests do not measure real-world gaming.
They actually end up measuring different parts of the input lag chain, and differential measurements often is out of sync with non-differential measurements.
Also -- there is nothing primitive about high speed cameras with 1ms accuracies.
Sometimes simple, primitive & deterministic is the most honest and scientific.
- Deterministic button press (human input from hands), with <1ms error margin
- Deterministic screen reaction (output to human eyes), with <1ms error margin
Therefore, the method is not flawed, at least when compared to a lot of other lag measurement methodologies.
Or if you prefer: All lag test methods ever done in human history, are all flawed, to varying degrees, even mine is flawed. But less flawed than the other lag tests for this specific purpose: real-world real-game input lag tests
. -- It's simple as 1. Run full chain test with VSYNC OFF, 2. Run full chain test with GSYNC, and 3. Compute difference. It doesn't invalidate other lag test methods, and they are all useful for different reasons, but this is one of the most useful lag tests, because it's real-world. Future tests will include LightBoost, ULMB, VSYNC ON, and others.
I do personally believe, that this is one of the best and most honest input lag tests (real-world human, real-world game, "where it matters") that any review site on the Internet, can do, to do reliable input lag tests of any brand new, exciting "miracle voodoo technology" (such as GSYNC) so you include whatever the display is doing (hardware-based input latency) and whatever the driver is doing (software-based GSYNC latencies) and whatever the game is reacting to GSYNC (software-based GSYNC latencies). Thusly, the test is not flawed in that it doesn't miss anything in the chain that GSYNC might be influencing one way or another. Therefore, the whole-chain method is one of the best, most honest methods of measuring input lag, from a human perspective.Edited by mdrejhon - 1/16/14 at 1:10pm