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?

Improve this question
$\endgroup$
2
  • $\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, 2019 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, 2019 at 2:33

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Browse other questions tagged or ask your own question.