flood's input lag measurements

[flood]

repeated tests with max'd out video settings.


shit just got real

[spacediver]

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

[flood]

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%

[flood]

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.

[spacediver]

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

[flood]

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

[flood]

btw i made up the notation [x,y] to mean a uniform random variable between x and y

[spacediver]

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

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.

btw i made up the notation [x,y] to mean a uniform random variable between x and y

yep, I got this part.

[flood]

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

[stirner]

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).