Page 16 of 44
Re: flood's input lag measurements
Posted: 26 Feb 2015, 07:37
by flood
me@esr wrote:
https://docs.google.com/spreadsheets/d/ ... =972435424
unfortunately the teensy's arduino mouse thingy acts like it has 500hz polling.
csgo multicore/mat_queue_mode tests:
https://docs.google.com/spreadsheets/d/ ... =964042784
looks like mat_queue_mode 2 raises fps by near 2x without affecting input lag at all.
mat_queue_mode 1 tends to get lower fps than mat_queue_mode 0 (though i couldn't really tell in this test, but when playing dm it drops by ~20fps when using mode 1)
wait what the fuck
this is really weird...
doesn't make any sense how fps can double AND input lag distribution looks identical
Re: flood's input lag measurements
Posted: 26 Feb 2015, 18:06
by sharknice
flood wrote:
doesn't make any sense how fps can double AND input lag distribution looks identical
Because when you use that setting it isn't getting any extra cycles of input. It is basically just rendering more frames based on data interpolation.
This is the way most multi-core rendering and SLI rendering methods work. They each render their own frame instead of working on rendering a single frame faster.
Input lag will typically be the same but it can also slightly increase input lag. This is why you should disable multi-core/SLI if you are already maxing out your displays capable frame rate.
Re: flood's input lag measurements
Posted: 26 Feb 2015, 19:02
by Sparky
flood wrote:me@esr wrote:
unfortunately the teensy's arduino mouse thingy acts like it has 500hz polling.
Odd, my arduino micro has 1khz polling, and it uses the same MCU as the teensy. You can technically change the polling interval to anything from 1 to 255ms, if you're willing to look up the USB configuration registers, or find the part of the library that sets that.
Re: flood's input lag measurements
Posted: 26 Feb 2015, 20:25
by flood
yea it's definitely not an mcu issue. i'm planning to move away from the entire arduino stack though so whatever
sharknice wrote:flood wrote:
doesn't make any sense how fps can double AND input lag distribution looks identical
Because when you use that setting it isn't getting any extra cycles of input. It is basically just rendering more frames based on data interpolation.
This is the way most multi-core rendering and SLI rendering methods work. They each render their own frame instead of working on rendering a single frame faster.
Input lag will typically be the same but it can also slightly increase input lag. This is why you should disable multi-core/SLI if you are already maxing out your displays capable frame rate.
csgo never interpolates the camera angle. when i run the test, the frame is either completely lit (looking at the bright sky) or completely dark (looking at a dark wall or the ground). it never shows anything in between.
for example suppose everything is single threaded. each frame takes 4ms to process and draw. then the fps would be 250. the time between a usb signal and the screen's response would be a random variable between 4ms and 8ms.
with two separate pipelines, each frame would still take 4ms to draw, but the pipelines are out of sync by 2ms. so the fps would be 500. but here the input lag (usb to screen) would be between 4ms and 6ms because although each frame still takes 4ms to draw, the time between when the usb data arrives and when one of the threads begins processing it is at most 2ms.
Re: flood's input lag measurements
Posted: 27 Feb 2015, 08:44
by flood
mqm means mat_queue_mode
The queue/thread mode the material system should use: -2=legacy default, -1=default, 0=synchronous single thread, 1=queued single thread, 2=queued multithreaded
remaining questions concerning this:
what if fps is capped
what if fps is gpu bound (i guess i'll need to use intel graphics for this)
Re: flood's input lag measurements
Posted: 27 Feb 2015, 19:19
by masterkaj
I see that you were planning on testing the Nvidia scaling vs display scaling input lag and am curious if you have an idea to when you will test this? It effects everyone that uses an Nvidia G-Sync monitor because it forces us to use Nvidia scaling.
Re: flood's input lag measurements
Posted: 27 Feb 2015, 21:01
by flood
tonight or next next week. or never
pretty sure it's <1ms. i don't think nvidia is stupid enough that they would buffer entire frames to scale
i think the scaling requires buffering an entire line, which corresponds to ~10us. unfortunately that's just barely below what can be measured
maybe if i scale from 640x480@60hz where each line corresponds to 30us... that should be possible to see.
Re: flood's input lag measurements
Posted: 27 Feb 2015, 22:24
by stirner
Please repeat those mmq tests with frame caps.
Really does start to look like your notion of nothing really mattering beyond framerate/refresh rate holds true though. Still interested in those VSync results (3buffer, cap below refresh) and internal vs. external frame limiters as well.
Re: flood's input lag measurements
Posted: 28 Feb 2015, 02:33
by flood
fps_max 250, uncapped fps is 480-520. similar behavior happens with all mat_queue_modes
this made me go WTF for a few minutes. the reason it looks like this is because the framerate is 250 which means frames are displayed somewhat in sync with the usb polling. this is also why the previous data looks a bit bimodal...
note to self: pick more random numbers for fps_max
Re: flood's input lag measurements
Posted: 28 Feb 2015, 02:53
by flood
at a capped fps of 283 it looks like mqm 0 gives maybe 0.1ms less input lag than mqm1 and mqm2