I think what Chief said about that holds true and did show up in a short series of 1kfps input lag tests I performed. External frame control is not synchronized with the engine tick or vice versa, so the added interval waits by frame capping with external means fall to random points of engine activity and sometimes that will mean a frame does not start rendering even though the engine is done with all its calculations. So, added latency up to 1 interval/1 frame.
On the other hand you get more stable frame times with external means, probably because the interval is not tied to the engine and so tick time inconsistencies don't affect anything there.
flood's input lag measurements
Re: flood's input lag measurements
So there's probably room to improve on that, if you can spoof the game engine into thinking the GPU hasn't started rendering the frame yet. Basically, tricking the game engine into limiting framerate instead of slowing the GPU down to limit framerate.stirner wrote:I think what Chief said about that holds true and did show up in a short series of 1kfps input lag tests I performed. External frame control is not synchronized with the engine tick or vice versa, so the added interval waits by frame capping with external means fall to random points of engine activity and sometimes that will mean a frame does not start rendering even though the engine is done with all its calculations. So, added latency up to 1 interval/1 frame.
On the other hand you get more stable frame times with external means, probably because the interval is not tied to the engine and so tick time inconsistencies don't affect anything there.
Re: flood's input lag measurements
Yeah, I think internally the engine does everything as fast as possible, and only after a buffer swap does it hold out on initiating the next cycle, probably with some math going on to predict complexity of the next scene and get a rendering estimate.
Externally, programs just force the pipe to wait at least Xms according to the set cap after a finished frame to start working on the next.
Externally, programs just force the pipe to wait at least Xms according to the set cap after a finished frame to start working on the next.
Re: flood's input lag measurements
Something to go along with that:
With external frame capping (Inspector), +showbudget shows that Mat_ThreadedEndFrame (basically time it took to finish the frame after initializing the render) is the main framerate decider, and it's going back and forth constantly (random points of waits). With the internal cap interval time is given as "Unaccounted".
Without multicore rendering you can see where the rendering process takes longer (with multicore rendering it just throws all of that time into endframe). Swap_Buffers now is the main culprit, going back and forth as well (since buffer swap happens after the rendering finishes it's basically saying the same thing). But swap is not the only culprit there, so that's interesting. Maybe external frame caps do also slow the GPU down to make it take longer for the rendering.
Another thing supporting me in my understanding is that the internal cap is only active for the client view rendering, so when you load a map or host a local server, the engine can let the GPU free and give unlimited ressources. Server frames are done as fast as possible. With an external cap the server frame rate is equal to client frame rate as determined by the cap, and when you load a map it takes ages.
With external frame capping (Inspector), +showbudget shows that Mat_ThreadedEndFrame (basically time it took to finish the frame after initializing the render) is the main framerate decider, and it's going back and forth constantly (random points of waits). With the internal cap interval time is given as "Unaccounted".
Without multicore rendering you can see where the rendering process takes longer (with multicore rendering it just throws all of that time into endframe). Swap_Buffers now is the main culprit, going back and forth as well (since buffer swap happens after the rendering finishes it's basically saying the same thing). But swap is not the only culprit there, so that's interesting. Maybe external frame caps do also slow the GPU down to make it take longer for the rendering.
Another thing supporting me in my understanding is that the internal cap is only active for the client view rendering, so when you load a map or host a local server, the engine can let the GPU free and give unlimited ressources. Server frames are done as fast as possible. With an external cap the server frame rate is equal to client frame rate as determined by the cap, and when you load a map it takes ages.
Re: flood's input lag measurements
An alternative possibility is that external limiters simply delay the buffer swap to maintain the interval (effectively limiting framerate because the back buffer is occupied, so map load times/server frame times would be prolonged there as well).
Internal limit:
0ms start cycle 1
finishes rendering at e. g. 3ms
buffer swap
10ms start cycle 2
finishes rendering at e. g. 15ms
buffer swap 12ms after last
20ms start cycle 3
finishes at 24ms
buffer swap 9ms after last
etc. - The frame times are directly dependent on how long the engine and GPU took to finish the frame, causing more frame time variance.
Also addressed these things here: http://forums.blurbusters.com/viewtopic ... 5&start=10
Still would like to know where FRAPS measures frame times, that could help understanding the methods better.
Swap_Buffer execution time in the budget seems to actually refer to time spent writing finished frame to front buffer/video memory for the screen to grab. If the frame finishes rendering less than the set interval after the last, buffer swap is delayed artificially. Meaning that if your system is able to maintain the framerate, frame times will be very consistent at the cost of a few ms lag (up to how much faster the frame finishes before the set interval ends).Swap buffers
A lot of time in Swap Buffers is usually a fillrate problem. Be sure to run full screen and at a lower resolution to test.
Internal limit:
Frames are rendered and buffers are swapped as fast as possible, then the engine waits to initiate the next rendering process according to the set interval. For 100fps:Unaccounted
The Unaccounted bar is simply a measurement of costs that aren't included in any other category.
A common cause for a high Unaccounted bar is other applications that are running on the system in the background (e.g. a virus scanner, Winamp, Hammer). For proper measure of performance, no other programs should be running, including the Hammer editor.
Also, limiting the framerate with fps_max can also potentially contribute. If you see a huge Unaccounted bar and aren't running any other applications, the chances are that your fps_max setting is causing the engine to pause before rendering the next frame. The Showbudget panel counts this controlled delay as Unaccounted.
0ms start cycle 1
finishes rendering at e. g. 3ms
buffer swap
10ms start cycle 2
finishes rendering at e. g. 15ms
buffer swap 12ms after last
20ms start cycle 3
finishes at 24ms
buffer swap 9ms after last
etc. - The frame times are directly dependent on how long the engine and GPU took to finish the frame, causing more frame time variance.
Also addressed these things here: http://forums.blurbusters.com/viewtopic ... 5&start=10
Still would like to know where FRAPS measures frame times, that could help understanding the methods better.
Re: flood's input lag measurements
I think FRAPS goes between the game engine and the driver, at least, that's what I remember from the FCAT/frame pacing discussion last year.
Re: flood's input lag measurements
blah
breadboard contact resistances are driving me nuts
breadboard contact resistances are driving me nuts
Re: flood's input lag measurements
If the amplification is a problem, you could switch to a photoresistor. Actually, I'm going to do a bit of testing on that right now.flood wrote:blah
breadboard contact resistances are driving me nuts
Re: flood's input lag measurements
google tells me that photoresistors respond quite slowly (milliseconds) so i'm pretty sure they're not the solution
current circuit is a transimpedance amp with a 1Mohm resistor followed by a 100x non-inverting amp (op amp + 1Mohm resistor + 10k resistor).
turns out that due to contact resistances the ground of the transimpedance amp is some millivolts higher than it is elsewhere... and when that gets amplified 100x, it becomes a significant voltage. anyway that usually doesn't matter though i spent the last hour trying to figure out why the signal was so high and inconsistent in the dark.
current circuit is a transimpedance amp with a 1Mohm resistor followed by a 100x non-inverting amp (op amp + 1Mohm resistor + 10k resistor).
turns out that due to contact resistances the ground of the transimpedance amp is some millivolts higher than it is elsewhere... and when that gets amplified 100x, it becomes a significant voltage. anyway that usually doesn't matter though i spent the last hour trying to figure out why the signal was so high and inconsistent in the dark.
Re: flood's input lag measurements
Wikipedia says it takes several milliseconds for a photoresistor to detect, but that's just saturation, you start to see the change immediately. Using a photoresistor, a pot, and a LED, I was able to get down to the noise (<20 microseconds ) between turning a LED on and detecting it with the photoresistor(just adjusting the threshold).