4 ms·

Both Nvidia (and AMD?) have options to reduce latency to like 1 frame (edit: due to render ahead queue; not total latency) in their control panels. You probably

Both Nvidia (and AMD?) have options to reduce latency to like 1 frame (edit: due to render ahead queue; not total latency) in their control panels. You probably pay for it with a bit of stutter when your system is pushed to the max - since there is no leeway buffer when frames don’t get finished in time. Display latency from LCDs are another factor - something that was completely absence on CRTs.

marginalia_nu 5y ago
That actually isn't particularly helpful. Picture the rendering process like a conveyor belt factory. This is a bit of a simplified model, GPUs are incredibly complex and things aren't quite this straightforward, but it's good enough way of reasoning about how they operate by imagining something like Factorio. First you load up a scene, and then it goes into one machine that does the first part of the rendering, then the next machine does the next part, and so on and so forth, until it arrives at the other end and is drawn on the screen. It's easy to see you can start working on the next frame while the first frame is in the second machine and that's probably in general a good idea. Reducing how many items are on the belt doesn't reduce the time it takes to go from start to finish (i.e. the latency), it still has to go through the same steps. Loading up more items on the belt at the same (probably) improves the stability of the framerate, but again it does nothing for latency. If you load up too much on the belt may cause problems, but such a condition is easy enough to determine and avoid programmatically. The frames still take the same time to go from start to finish. Bottom line is that the time between frames and the time to render a frame are disconnected, if they seem connected it's because getting a better GPU increases them both. But you could (hypothetically) render at 120 Hz refresh rate with a 30 second rendering latency.
- worrycue 5y ago
  Sorry, should have been more careful with my words. I was talking about latency due to DirectX's render ahead queue. Not total latency.
- flohofwoe 5y ago
  Having one more "spare" slot on the belt (e.g. triple- instead of double-buffering) can help to smooth over unpredictable spikes caused by other systems, but it always costs one more frame of latency even if the spare slot isn't usually needed. In game engines, long frame pipelines were all the rage in the early 2000's to distribute work across CPU cores without having to rewrite entire single-threaded systems to multithreading (so you might have a pipeline of input-, AI-, physics- and render-thread, each adding one frame of latency). But that's also when "input latency" became a problem, so game engines went away from this pipeline architecture and ran all those steps in a single frame by parallelizing within systems, but still chaining the inputs and output of those big systems together in a linear sequence (but all ideally within one frame). After that came the general task schedulers, where everything that needs to happen in one frame is split into very small tasks arranged in a dependency tree, and those small tasks are run by a general task scheduler running on a thread pool (sometimes even on the GPU). The general goal is to distribute the same work across available CPU and GPU resources, but without introducing a deep frame pipeline, and for the only reason to reduce button-to-screen latency (while still cramming as much work as possible/needed onto the CPU and GPU).
  - frankenst1 5y ago
    > Having one more "spare" slot on the belt (e.g. triple- instead of double-buffering) can help to smooth over unpredictable spikes caused by other systems, but it always costs one more frame of latency even if the spare slot isn't usually needed. This is not correct: If your application frame rate is higher than your display refresh rate, triple buffering has lower latencies than double buffering. This is due to much more frames being rendered (and most of them discarded) so that the average age of the last frame rendered before being sent to the display is much younger (but never older) as in double buffering. In terms of latency: VSYNC off < Triple Buffering < Double Buffering.
  - marginalia_nu 5y ago
    I think we are talking about different things. I'm talking about what the GPU is doing to render a scene once the CPU has handed it off to the GPU, not what the engine is doing to produce the scene. This pipeline: https://www.khronos.org/opengl/wiki/Rendering_Pipeline_Overview https://www.khronos.org/opengl/wiki/Rendering_Pipeline_Overv...
- frankenst1 5y ago
  > But you could (hypothetically) render at 120 Hz refresh rate with a 30 second rendering latency. This is an important point. A 120Hz refresh rate causes _at least_ a worst-case latency of 8ms. People often drop the "at least" or ignore that latency compounds across the pipeline.
frankenst1 5y ago
> Both Nvidia (and AMD?) have options to reduce latency to like 1 frame in their control panels. In case you are referring to pre-rendered frames, this only affects the amount of additional latency (not actual or total latency). > You probably pay for it with a bit of stutter when your system is pushed to the max - since there is no leeway buffer when frames don’t get finished in time. True, if your system is not maxed out, you can enable Triple Buffering. If your rendering framerate is higher than your display, it will discard obsolete frames and only push the most recent one to the display.
- worrycue 5y ago
  > In case you are referring to pre-rendered frames, this only affects the amount of additional latency (not actual or total latency). Yes, that. Should have been more careful with my words - i.e. I meant latency of 1 frame due to the render ahead queue.

marginalia_nu 5y ago

That actually isn't particularly helpful. Picture the rendering process like a conveyor belt factory. This is a bit of a simplified model, GPUs are incredibly complex and things aren't quite this straightforward, but it's good enough way of reasoning about how they operate by imagining something like Factorio. First you load up a scene, and then it goes into one machine that does the first part of the rendering, then the next machine does the next part, and so on and so forth, until it arrives at the other end and is drawn on the screen. It's easy to see you can start working on the next frame while the first frame is in the second machine and that's probably in general a good idea. Reducing how many items are on the belt doesn't reduce the time it takes to go from start to finish (i.e. the latency), it still has to go through the same steps. Loading up more items on the belt at the same (probably) improves the stability of the framerate, but again it does nothing for latency. If you load up too much on the belt may cause problems, but such a condition is easy enough to determine and avoid programmatically. The frames still take the same time to go from start to finish. Bottom line is that the time between frames and the time to render a frame are disconnected, if they seem connected it's because getting a better GPU increases them both. But you could (hypothetically) render at 120 Hz refresh rate with a 30 second rendering latency.

worrycue 5y ago
Sorry, should have been more careful with my words. I was talking about latency due to DirectX's render ahead queue. Not total latency.
flohofwoe 5y ago
Having one more "spare" slot on the belt (e.g. triple- instead of double-buffering) can help to smooth over unpredictable spikes caused by other systems, but it always costs one more frame of latency even if the spare slot isn't usually needed. In game engines, long frame pipelines were all the rage in the early 2000's to distribute work across CPU cores without having to rewrite entire single-threaded systems to multithreading (so you might have a pipeline of input-, AI-, physics- and render-thread, each adding one frame of latency). But that's also when "input latency" became a problem, so game engines went away from this pipeline architecture and ran all those steps in a single frame by parallelizing within systems, but still chaining the inputs and output of those big systems together in a linear sequence (but all ideally within one frame). After that came the general task schedulers, where everything that needs to happen in one frame is split into very small tasks arranged in a dependency tree, and those small tasks are run by a general task scheduler running on a thread pool (sometimes even on the GPU). The general goal is to distribute the same work across available CPU and GPU resources, but without introducing a deep frame pipeline, and for the only reason to reduce button-to-screen latency (while still cramming as much work as possible/needed onto the CPU and GPU).
- frankenst1 5y ago
  > Having one more "spare" slot on the belt (e.g. triple- instead of double-buffering) can help to smooth over unpredictable spikes caused by other systems, but it always costs one more frame of latency even if the spare slot isn't usually needed. This is not correct: If your application frame rate is higher than your display refresh rate, triple buffering has lower latencies than double buffering. This is due to much more frames being rendered (and most of them discarded) so that the average age of the last frame rendered before being sent to the display is much younger (but never older) as in double buffering. In terms of latency: VSYNC off < Triple Buffering < Double Buffering.
- marginalia_nu 5y ago
  I think we are talking about different things. I'm talking about what the GPU is doing to render a scene once the CPU has handed it off to the GPU, not what the engine is doing to produce the scene. This pipeline: https://www.khronos.org/opengl/wiki/Rendering_Pipeline_Overview https://www.khronos.org/opengl/wiki/Rendering_Pipeline_Overv...
frankenst1 5y ago
> But you could (hypothetically) render at 120 Hz refresh rate with a 30 second rendering latency. This is an important point. A 120Hz refresh rate causes _at least_ a worst-case latency of 8ms. People often drop the "at least" or ignore that latency compounds across the pipeline.

frankenst1 5y ago

> Both Nvidia (and AMD?) have options to reduce latency to like 1 frame in their control panels. In case you are referring to pre-rendered frames, this only affects the amount of additional latency (not actual or total latency). > You probably pay for it with a bit of stutter when your system is pushed to the max - since there is no leeway buffer when frames don’t get finished in time. True, if your system is not maxed out, you can enable Triple Buffering. If your rendering framerate is higher than your display, it will discard obsolete frames and only push the most recent one to the display.

worrycue 5y ago
> In case you are referring to pre-rendered frames, this only affects the amount of additional latency (not actual or total latency). Yes, that. Should have been more careful with my words - i.e. I meant latency of 1 frame due to the render ahead queue.