<p>I've been doing some reading as to how to reduce input delay on modern computing devices. A lot of my understanding from this comes from the <a href="https://danluu.com/latency-mitigation/" rel="nofollow noreferrer">VR research paper by Carmack</a> explaining the numerous circumstances to reduce the latency between the CPU simulation/rendering -> GPU buffering -> video out stages.</p>

<p>So assuming the optimal case where we have a monitor with a ~60hz refresh rate with a simulation/render that fits in a single tick, I was wondering if software rendering bypasses the GPU buffer stage (G) shown below (but not the video out as we cant force the monitor to refresh).</p>

<pre><code>I - Input, S = Simulation, R = Render, G = Gpu buffered commands, V - Video Out
CPU:ISSSSSRRRRRR----|
GPU:                |GGGGGGGGGGG----|
VID:                |               |VVVVVVVVVVVVVVVV|
</code></pre>

<p>This would seem to trade off the need of synchronizing with GPU and GPU fencing that mentioned later at the cost of performance. I was wondering if this was accurate and a reasonable option to reduce display latency?</p>

CC BY-SA 4.0
2019-07-07T09:12:05.913Z
While I'm not sure it will help, I'm pretty sure this will be an interesting read for you: https://medium.com/@alen.ladavac/the-elusive-frame-timing-168f899aec92
Karlovsky120
CC BY-SA 4.0
2019-07-12T02:33:44.320Z
The GPU buffering step would be gone in a software renderer, but you still have latency from double buffering. If you were to render directly to the "front buffer" you could get rid of that and have latency below 1 frame, although you need to race the scan out hardware.
PaulHK
<opengl><rendering><gpu><performance>
Software Rendering Display Latency
MiloticMaster
# Software Rendering Display Latency

(Asked by: username_0 on 2019-07-04)

I've been doing some reading as to how to reduce input delay on modern computing devices. A lot of my understanding from this comes from the [VR research paper by Carmack](https://danluu.com/latency-mitigation/) explaining the numerous circumstances to reduce the latency between the CPU simulation/rendering -> GPU buffering -> video out stages.

So assuming the optimal case where we have a monitor with a ~60hz refresh rate with a simulation/render that fits in a single tick, I was wondering if software rendering bypasses the GPU buffer stage (G) shown below (but not the video out as we cant force the monitor to refresh).

```
I - Input, S = Simulation, R = Render, G = Gpu buffered commands, V - Video Out
CPU:ISSSSSRRRRRR----|
GPU:                |GGGGGGGGGGG----|
VID:                |               |VVVVVVVVVVVVVVVV|

```

This would seem to trade off the need of synchronizing with GPU and GPU fencing that mentioned later at the cost of performance. I was wondering if this was accurate and a reasonable option to reduce display latency?

**Tags:** opengl, rendering, gpu, performance

> **Comments:**
> **username_1**: While I'm not sure it will help, I'm pretty sure this will be an interesting read for you: https://medium.com/@alen.ladavac/the-elusive-frame-timing-168f899aec92  
> **username_2**: The GPU buffering step would be gone in a software renderer, but you still have latency from double buffering. If you were to render directly to the "front buffer" you could get rid of that and have latency below 1 frame, although you need to race the scan out hardware.  

---

## 0 answers

