bleh tempted to get this oscilloscope
http://sfbay.craigslist.org/nby/ele/4968167450.html
flood's input lag measurements
Re: flood's input lag measurements
$1flood wrote:bleh tempted to get this oscilloscope
http://sfbay.craigslist.org/nby/ele/4968167450.html
I did some testing with radeonpro and v-sync.
Triple buffering isn't working with this test, and I don't think it would make one bit of difference, because the GPU render time is nonexistent.
Edit: "Lock frame rate up to monitor's refresh rate" isn't getting forced on correctly either.
V-sync on, no framerate limiting is about 55ms latency (85hz refresh rate).
DFC does nothing at 86fps v-sync on.
The following options are all pretty much identical, which is either ~22ms or ~34ms, depending on whether this frame happens to miss the v-sync deadline:
DFC 85 with v-sync on
DFC 84 with v-sync on
So, you can save about ~25ms of average v-sync latency by adding ~12ms of variance. No idea if that's a trade worth making.
Next up: MSI afterburner.
Last edited by Sparky on 08 Apr 2015, 15:59, edited 2 times in total.
Re: flood's input lag measurements
Rivatuner(which comes with MSI afterburner) is a full frame faster than DFC when it comes to frame limiting.
Rivatuner cap at 86 does nothing with v-sync on. (56ms)
Average latency at 85 is 10ms with v-sync off.
at 85 and 84 with v-sync on, it shows the same single frame jumps that radeonpro had, but shifted down 1 frame. So instead of trading 2 frames of average latency for 1 frame of variance(compared to v-sync), you trade 3 frames of average latency for 1 frame of variance.
I guess this means DFC stalls the GPU, and rivatuner spoofs backpressure.
So, if you're going to play with v-sync, this is the way to do it.
Edit, it takes longer to make these graphs than to just run the tests:
Rivatuner cap at 86 does nothing with v-sync on. (56ms)
Average latency at 85 is 10ms with v-sync off.
at 85 and 84 with v-sync on, it shows the same single frame jumps that radeonpro had, but shifted down 1 frame. So instead of trading 2 frames of average latency for 1 frame of variance(compared to v-sync), you trade 3 frames of average latency for 1 frame of variance.
I guess this means DFC stalls the GPU, and rivatuner spoofs backpressure.
So, if you're going to play with v-sync, this is the way to do it.
Edit, it takes longer to make these graphs than to just run the tests:
Re: flood's input lag measurements
Are you suggesting these are identical because of DFC or that generally it wouldn't make a difference to cap framerate below refresh rate with vsync on, even that vsync on is the same as framerate capped at refresh rate with vsync off? Because that doesn't seem right.The following options are all pretty much identical, which is either ~22ms or ~34ms, depending on whether this frame happens to miss the v-sync deadline:
DFC 85 with v-sync on
DFC 84 with v-sync on
"Lock frame rate up to monitor's refresh rate" with v-sync off
Re: flood's input lag measurements
Ignore what I said about "lock framerate up to monitor's refresh rate". Radeonpro isn't forcing it on correctly.
DFC at 85 and 84 are both capping framerate slightly below the nominal refresh rate, so there isn't a ton of lag accumulating, but you sometimes miss the v-sync deadline.
DFC at 85 and 84 are both capping framerate slightly below the nominal refresh rate, so there isn't a ton of lag accumulating, but you sometimes miss the v-sync deadline.
Re: flood's input lag measurements
I always felt that capping framerate below refresh rate decreases vsync-induced lag, but your results are right that at least 1 up to a few frames per second will be displayed twice as they miss the sync because of fluctuation/frametime variance.
I think you should go away from external limiters though and either try to implement a cap in your test simulation or just use CS:GO. Framerates are lower, but conclusions are more useful regarding actual implementations. fps_max 84.999999 with 85Hz vsync. And maybe rivatuner cap vs. fps_max cap latency without vsync.
I think you should go away from external limiters though and either try to implement a cap in your test simulation or just use CS:GO. Framerates are lower, but conclusions are more useful regarding actual implementations. fps_max 84.999999 with 85Hz vsync. And maybe rivatuner cap vs. fps_max cap latency without vsync.
Re: flood's input lag measurements
the easiest way to detect (frames of) input lag is to make an application that draws a vertical line that follows the cursor and seeing how far behind the line lags the windows cursor
Re: flood's input lag measurements
looks like the input is being synchronized to the framerate...
are you sleeping a random number of ms between each cycle?
are you sleeping a random number of ms between each cycle?
Re: flood's input lag measurements
What you see on the graph is just google docs, won't let me make the bins any smaller with that many things to compare. I have a 1~1000 microsecond random delay after a long fixed delay. There are some long term synchronization artifacts, over the course of several seconds, but I think that's due to the difference beteen an 85fps frame cap and the 85hz refresh rate(DFC with triple buffering had a period of ~20 seconds.) Here's an example:flood wrote:looks like the input is being synchronized to the framerate...
are you sleeping a random number of ms between each cycle?
Edit: you were absolutely right, but now I'm confused by the earlier results. They weren't perfectly in synch, so why the 12ms thresholds? Why didn't it slowly ramp up then fall off a cliff, or vice versa.