repeated tests with max'd out video settings.
shit just got real
flood's input lag measurements
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
what's the purpose of testing capped frame rate? I thought it was already established that average input lag increases with lower frame rate.
Didn't you already measure that here?
https://docs.google.com/spreadsheets/d/ ... =293790724
Didn't you already measure that here?
https://docs.google.com/spreadsheets/d/ ... =293790724
Re: flood's input lag measurements
purpose is to make sure csgo isn't doing anything stupid, like buffering a frame even though each thread individually renders faster than the framecap.
i'm not really sure of the implications of this... i think the final conclusion could be something like: don't enable multicore unless enabling it raises your fps by >50%
i'm not really sure of the implications of this... i think the final conclusion could be something like: don't enable multicore unless enabling it raises your fps by >50%
Re: flood's input lag measurements
i think i understand what's going on
yet another one of my shitty paint drawings:
for single threaded rendering
input lag = (some offset) + [0,1/fps] + 1/fps
for multicore/mqm2
input lag = (the same offset) + [0,1/fps] + 2/fps
let's see how this fits with the data in the above image
for the single thread case where i get 500fps the input lag is distributed 3.4ms and 5.4ms.
input lag = 1.4ms + [0, 2ms] + 2ms
this offset is higher than what i'd expect but whatever
for the multithreaded case where i get 700fps the input lag is distributed between 4.3 and 5.7ms
input lag = 1.5ms + [0,1.4ms] + 2.8ms
seems to work out!
would be interesting to see how this would work with sli... fortunately i've just upgraded to a miniitx build so i have absolute no excuse to waste money on sli
so what are the implications of this for people like myself with single gpus...
0. it doesn't really matter unless your gpu is a potato
1. there's no disadvantage to multicore IF using it increases your framerate by 67% or more. this is where the average input lag of both are equal.
yet another one of my shitty paint drawings:
for single threaded rendering
input lag = (some offset) + [0,1/fps] + 1/fps
for multicore/mqm2
input lag = (the same offset) + [0,1/fps] + 2/fps
let's see how this fits with the data in the above image
for the single thread case where i get 500fps the input lag is distributed 3.4ms and 5.4ms.
input lag = 1.4ms + [0, 2ms] + 2ms
this offset is higher than what i'd expect but whatever
for the multithreaded case where i get 700fps the input lag is distributed between 4.3 and 5.7ms
input lag = 1.5ms + [0,1.4ms] + 2.8ms
seems to work out!
would be interesting to see how this would work with sli... fortunately i've just upgraded to a miniitx build so i have absolute no excuse to waste money on sli
so what are the implications of this for people like myself with single gpus...
0. it doesn't really matter unless your gpu is a potato
1. there's no disadvantage to multicore IF using it increases your framerate by 67% or more. this is where the average input lag of both are equal.
Last edited by flood on 28 Feb 2015, 04:37, edited 1 time in total.
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
I don't know anything about single threading or multicore rendering, but is GPU limited supposed to be equivalent to single threading?
(I follow most of the rest of your logic, just the starting point that I'm lost on).
and if single threaded rendering is just "regular" rendering, why is there that extra term at the end in this equation:
input lag = (some offset) + [0,1/fps] + 1/fps
(I follow most of the rest of your logic, just the starting point that I'm lost on).
and if single threaded rendering is just "regular" rendering, why is there that extra term at the end in this equation:
input lag = (some offset) + [0,1/fps] + 1/fps
Re: flood's input lag measurements
because even if the input happens right at the beginning of a frame's rendering, it still takes time to render the frame
http://i.imgur.com/9cSP1bM.png
http://i.imgur.com/9cSP1bM.png
Re: flood's input lag measurements
btw i made up the notation [x,y] to mean a uniform random variable between x and y
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
but shouldn't the last term (the part I bolded) be the length of the frame rendering time (the width of the green part)? Instead, you have it as 1/fps.flood wrote:because even if the input happens right at the beginning of a frame's rendering, it still takes time to render the frame
http://i.imgur.com/9cSP1bM.png
yep, I got this part.flood wrote:btw i made up the notation [x,y] to mean a uniform random variable between x and y
Re: flood's input lag measurements
oh in that picture the frame rendering time means from the start of cpu processing of input to when the gpu finishes drawing
i'm considering the uncapped case, where that time is equal to 1/fps
i'm considering the uncapped case, where that time is equal to 1/fps
Re: flood's input lag measurements
Cool.
Any chance you can be bothered to throw different pre-render values into the mix? I. e. pre-render 1-3 uncapped mqm 0-2 vs. pre-render 1-3 capped mqm 0-2. The pre-render setting "use application setting" would be interesting as well with differing queue modes.
I find it strange that there's more variance to the single-threaded input lag, because frame rendering times get more consistent with it (something you should maybe mention - even if the difference in input lag is insignificant, single-threaded rendering is less prone to produce microstuttering).
Any chance you can be bothered to throw different pre-render values into the mix? I. e. pre-render 1-3 uncapped mqm 0-2 vs. pre-render 1-3 capped mqm 0-2. The pre-render setting "use application setting" would be interesting as well with differing queue modes.
I find it strange that there's more variance to the single-threaded input lag, because frame rendering times get more consistent with it (something you should maybe mention - even if the difference in input lag is insignificant, single-threaded rendering is less prone to produce microstuttering).