Suppose I know that the time taken to complete the cpu and gpu work necessary to present a frame is a total of 2ms (or any duration less than the vsync interval - total time taken. In other words, there is always some known amount of time available after the work is done).
What some games do is start work right away, after vysnc and sleep until vblank to present if possible. In fact, there is a function that lets you do this. But I want the opposite -- I want to know how long I can wait until I have to start working to present the frame (knowing in advance how long that takes. Again, assume I know this).
Is there a mechanism or function that tells me the time until the next vsync interval? I'm working to reduce input latency, and I'd rather not keep re-running the central update() loop up until draw() time if I don't have to.
What some games do is start work right away, after vysnc and sleep until vblank to present if possible. In fact, there is a function that lets you do this. But I want the opposite -- I want to know how long I can wait until I have to start working to present the frame (knowing in advance how long that takes. Again, assume I know this).
Is there a mechanism or function that tells me the time until the next vsync interval? I'm working to reduce input latency, and I'd rather not keep re-running the central update() loop up until draw() time if I don't have to.
Edited by Jesse
on
If the goal is to reduce input latency, then there is a mechanism in DXGI 1.3 (from Windows 8.1 and up) for this. It tells you when GPU is ready accept new frame for display (Present won't block). It gives you event HANDLE that you can call WaitForSingleObject function on.
More info:
https://docs.microsoft.com/en-us/...latency-with-dxgi-1-3-swap-chains
https://docs.microsoft.com/en-us/...in2-getframelatencywaitableobject
https://software.intel.com/en-us/...irect3d-12-flip-model-swap-chains
If I remember correctly, it is also mentioned in this D3D12 video: https://www.youtube.com/watch?v=E3wTajGZOsA
My understanding on this API is that you should be waiting on this handle at beginning of frame, and only then process all input events + rendering, so you can reduce input latency. Instead of classical "process input, render frame, wait vblank + present (blocking)" which gives you perceived input latency depending on how long "wait vblank" step is happening, you do "wait on frame waitable object, process input, render frame, present (won't block)" which will give less latency between "input" and "present" steps.
More info:
https://docs.microsoft.com/en-us/...latency-with-dxgi-1-3-swap-chains
https://docs.microsoft.com/en-us/...in2-getframelatencywaitableobject
https://software.intel.com/en-us/...irect3d-12-flip-model-swap-chains
If I remember correctly, it is also mentioned in this D3D12 video: https://www.youtube.com/watch?v=E3wTajGZOsA
My understanding on this API is that you should be waiting on this handle at beginning of frame, and only then process all input events + rendering, so you can reduce input latency. Instead of classical "process input, render frame, wait vblank + present (blocking)" which gives you perceived input latency depending on how long "wait vblank" step is happening, you do "wait on frame waitable object, process input, render frame, present (won't block)" which will give less latency between "input" and "present" steps.
Edited by Mārtiņš Možeiko
on
My thanks, mmozeiko!
There is a possible snag in all this. A design constraint is to enable and maintain vsync intervals of ~16ms. So being notified that a swap chain object is 'ready to present' is cause for pause. Did I just miss a vsync boundary? That's what I'm wanting to avoid in the first place! If I wait until the next frame is ready to present, have I not just added a full 16ms vsync interval latency on top of the possible inter-frame input latency?
GetFrameLatencyWaitableObject seems to be the direction I want to head in. By knowing when the intervals begin, I may be able to wait() until I'm prepared to update() + draw(), but I've been cautioned not to rely on wait() (especially sleep()).
I suppose I need to play with this swapchain technique to see how far I can take it.
There is a possible snag in all this. A design constraint is to enable and maintain vsync intervals of ~16ms. So being notified that a swap chain object is 'ready to present' is cause for pause. Did I just miss a vsync boundary? That's what I'm wanting to avoid in the first place! If I wait until the next frame is ready to present, have I not just added a full 16ms vsync interval latency on top of the possible inter-frame input latency?
GetFrameLatencyWaitableObject seems to be the direction I want to head in. By knowing when the intervals begin, I may be able to wait() until I'm prepared to update() + draw(), but I've been cautioned not to rely on wait() (especially sleep()).
I suppose I need to play with this swapchain technique to see how far I can take it.
Edited by Jesse
on