0
$\begingroup$

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 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?

$\endgroup$
  • $\begingroup$ While I'm not sure it will help, I'm pretty sure this will be an interesting read for you: medium.com/@alen.ladavac/the-elusive-frame-timing-168f899aec92 $\endgroup$ – Karlovsky120 Jul 7 at 9:12
  • $\begingroup$ 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. $\endgroup$ – PaulHK Jul 12 at 2:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.