3 ms·

Here's a post with some reference points, for scale. https://danluu.com/term-latency/ https://danluu.com/term-latency/

4death4 3y ago
This link is totally wrong. At least 50 ms counted is unnecessary. For instance, one frame usually takes 16 ms in a 60 fps game, but the link somehow stretched this out to 48 ms. This is trivially easy to verify. Open up a profiler and measure the time between the start of a game loop and the end of a draw call for that loop. Even in a browser it’s way faster. You can use the profiler to verify that the time between the start of input handling and render is less than 8 ms in Chrome. Sure, there is some time for the input to be handled, but nowhere near the level this link is suggesting.
- kimixa 3y ago
  Yes - that latency measurement is extremely pessimistic, and would be an example of a "badly written" game at best. For example, it's normal for both the input processing and GPU submission to be completed within one frame time - delaying it by a frame adds complexity for no benefit, if anything (as it's presumably pipelined in a thread while the next frame input is processed and gamestate updated) - that requires the entire gamestate used for rendering to be copied to ensure there aren't conflicting concurrent updates to it by the update thread. And the GPU hardware itself being (over) 2 frames behind is unusual too - many apps are only double buffered, so while one is being scanned out to display you only have one framebuffer to be looking at. That means in the example shown, the gpu is sat on it's command buffers for at least one more frame for... no reason? Triple buffering is possible, but often not the default (and there's more presentation modes like mailboxes etc. but they tend to mean you're hanging onto otherwise complete frames for less time, not more). Compositors make this a bit more complex, but they're normally very carefully designed to reduce their impact - as they're relatively predictable workloads too they are good candidates for the "delaying" mentioned above. In most "real" apps it's normal for the processing of a frame on the GPU to start concurrently with GPU command submission. Most apps do multiple render passes, and there's no reason not to start rendering those passes as soon as they're submitted. Even on deferred tiling architectures it is common to have multiple separated passes through the hardware per frame - as there's no advantage to batching them if there's no overlap and they output to different buffers. And there's also the ability to do more clever things with timing submission - working on mobile devices I know it's pretty normal in Android for the compositor to /intentionally/ delay releasing a new buffer to an app until closer to the next vsync (and scanout) depending on estimated time of render. The apps themselves can easily (Well, easily if you can have a good estimate of how long the render themselves) do this even more accurately - modern render APIs allow precise timestamps, and direct synchronization between the rendering and present queue to reduce this latency further. This is exactly the sort of thing that would be a focus for VR apps, due to them tending to be more sensitive to latency. And my understanding is that for monitors it's pretty rare for the panel to wait for the entire frame to start changing pixels - if only because it increases the BOM of the panel controller to have multiple frames in a buffer - high res 4k+ 12bit-per-channel is actually quite a bit of storage. I've seen it in some panels that try to do post processing, think TVs with "smooth motion" interpolation, but rarely on PC monitors. Some HDR variable backlight implementations also sometimes do something similar, but again tend not to be the default mode (especially on VR headset displays). And even then they probably don't take 2 whole frames to actually process then change the pixels accordingly, as many of the things actually happen concurrently.

This link is totally wrong. At least 50 ms counted is unnecessary. For instance, one frame usually takes 16 ms in a 60 fps game, but the link somehow stretched this out to 48 ms. This is trivially easy to verify. Open up a profiler and measure the time between the start of a game loop and the end of a draw call for that loop. Even in a browser it’s way faster. You can use the profiler to verify that the time between the start of input handling and render is less than 8 ms in Chrome. Sure, there is some time for the input to be handled, but nowhere near the level this link is suggesting.

kimixa 3y ago
Yes - that latency measurement is extremely pessimistic, and would be an example of a "badly written" game at best. For example, it's normal for both the input processing and GPU submission to be completed within one frame time - delaying it by a frame adds complexity for no benefit, if anything (as it's presumably pipelined in a thread while the next frame input is processed and gamestate updated) - that requires the entire gamestate used for rendering to be copied to ensure there aren't conflicting concurrent updates to it by the update thread. And the GPU hardware itself being (over) 2 frames behind is unusual too - many apps are only double buffered, so while one is being scanned out to display you only have one framebuffer to be looking at. That means in the example shown, the gpu is sat on it's command buffers for at least one more frame for... no reason? Triple buffering is possible, but often not the default (and there's more presentation modes like mailboxes etc. but they tend to mean you're hanging onto otherwise complete frames for less time, not more). Compositors make this a bit more complex, but they're normally very carefully designed to reduce their impact - as they're relatively predictable workloads too they are good candidates for the "delaying" mentioned above. In most "real" apps it's normal for the processing of a frame on the GPU to start concurrently with GPU command submission. Most apps do multiple render passes, and there's no reason not to start rendering those passes as soon as they're submitted. Even on deferred tiling architectures it is common to have multiple separated passes through the hardware per frame - as there's no advantage to batching them if there's no overlap and they output to different buffers. And there's also the ability to do more clever things with timing submission - working on mobile devices I know it's pretty normal in Android for the compositor to /intentionally/ delay releasing a new buffer to an app until closer to the next vsync (and scanout) depending on estimated time of render. The apps themselves can easily (Well, easily if you can have a good estimate of how long the render themselves) do this even more accurately - modern render APIs allow precise timestamps, and direct synchronization between the rendering and present queue to reduce this latency further. This is exactly the sort of thing that would be a focus for VR apps, due to them tending to be more sensitive to latency. And my understanding is that for monitors it's pretty rare for the panel to wait for the entire frame to start changing pixels - if only because it increases the BOM of the panel controller to have multiple frames in a buffer - high res 4k+ 12bit-per-channel is actually quite a bit of storage. I've seen it in some panels that try to do post processing, think TVs with "smooth motion" interpolation, but rarely on PC monitors. Some HDR variable backlight implementations also sometimes do something similar, but again tend not to be the default mode (especially on VR headset displays). And even then they probably don't take 2 whole frames to actually process then change the pixels accordingly, as many of the things actually happen concurrently.