[Merged by Bors] - Update time by sending frame instant through a channel #4744
Conversation
|
please ignore that my stats have a higher standard deviation than in #4735. I ran the other branches too and they also had a higher standard deviation. Seems to just be weirdness of testing on different days. |
|
We’ve been discussing ways of feeding back data from the render world to the main world, especially when pipelining is fully working, and keeping the latency low as rendering of frame n will happen in parallel with simulation of frame n+1. I proposed use of channels for this where sometimes you just want to get the value back at some point, asynchronously, and other times you want to make simulation of the next frame wait on the current frame so you could have a system that blocks on receiving something over a channel. The latter serialises the pipelining again somewhat, but maybe some use cases require it. For this case, not blocking is the right choice as time measurement is such a fundamental piece, it happens after present, and if we blocked then it would basically make pipelining useless. I don’t remember how Unity solved time measurement with as pipelined renderer, I need to reread the article, but the odd thing in my mind is that if we use the presentation time for a previous frame, what does that tell us about the difference in presentation times for the previous and current frame? We’re assuming that the frame rate will be consistent. Maybe that’s the best we can do? And when we have pipelining, the time in the channel would likely be a measurement from two frames ago because we’re simulating n+1, n is being rendered and hasn’t been presented yet, and n-1 has been presented. What impact fires that have? I think this PR is probably a great step, just noting some thoughts on the end goal, and maybe they’ve already been discussed… |
I think this is right. The ideal would be to say that the current frame is going to be presented in We can also potentially get the actual presentation time from the graphics card, but this is only currently available on windows. |
|
While this is indeed a significant and welcome improvement to Bevy's timing consistency, I don't think issue #4669 should be closed by it. The problem is not "resolved" and there is still room for improvement. |
hymm
force-pushed
the
time-through-channel
branch
2 times, most recently
from
09c0335 to
f008662
Compare
hymm
force-pushed
the
time-through-channel
branch
2 times, most recently
from
a59e2b0 to
f8d8fa9
Compare
alice-i-cecile
added
the
X-Controversial
|
I used to experience a lot of stutters and timing issues but since I've been using this things have been much smoother. It's all very subjective (I have no statistics to back this up) but I'm eager to see this merged. Great work. |
alice-i-cecile
added
the
S-Ready-For-Final-Review
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
hymm
force-pushed
the
time-through-channel
branch
from
f7a8c14 to
565a9a1
Compare
There was a problem hiding this comment.
Mostly looks ok and so I only have minor requests below.
I'm still not convinced by using just a sampled point in time as the reference time for simulating and rendering the next frame which will be presented at a later point in time, but that is not a regression introduced by this PR and this PR brings other significant benefits regarding consistency.
Co-authored-by: Robert Swain <robert.swain@gmail.com>
hymm
force-pushed
the
time-through-channel
branch
from
b3b3647 to
70f66ce
Compare
|
bors r+ |
# Objective - The time update is currently done in the wrong part of the schedule. For a single frame the current order of things is update input, update time (First stage), other stages, render stage (frame presentation). So when we update the time it includes the input processing of the current frame and the frame presentation of the previous frame. This is a problem when vsync is on. When input processing takes a longer amount of time for a frame, the vsync wait time gets shorter. So when these are not paired correctly we can potentially have a long input processing time added to the normal vsync wait time in the previous frame. This leads to inaccurate frame time reporting and more variance of the time than actually exists. For more details of why this is an issue see the linked issue below. - Helps with #4669 - Supercedes #4728 and #4735. This PR should be less controversial than those because it doesn't add to the API surface. ## Solution - The most accurate frame time would come from hardware. We currently don't have access to that for multiple reasons, so the next best thing we can do is measure the frame time as close to frame presentation as possible. This PR gets the Instant::now() for the time immediately after frame presentation in the render system and then sends that time to the app world through a channel. - implements suggestion from @aevyrie from here #4728 (comment) ## Statistics  --- ## Changelog - Make frame time reporting more accurate. ## Migration Guide `time.delta()` now reports zero for 2 frames on startup instead of 1 frame.
bors
bot
changed the title
# Objective - The time update is currently done in the wrong part of the schedule. For a single frame the current order of things is update input, update time (First stage), other stages, render stage (frame presentation). So when we update the time it includes the input processing of the current frame and the frame presentation of the previous frame. This is a problem when vsync is on. When input processing takes a longer amount of time for a frame, the vsync wait time gets shorter. So when these are not paired correctly we can potentially have a long input processing time added to the normal vsync wait time in the previous frame. This leads to inaccurate frame time reporting and more variance of the time than actually exists. For more details of why this is an issue see the linked issue below. - Helps with bevyengine#4669 - Supercedes bevyengine#4728 and bevyengine#4735. This PR should be less controversial than those because it doesn't add to the API surface. ## Solution - The most accurate frame time would come from hardware. We currently don't have access to that for multiple reasons, so the next best thing we can do is measure the frame time as close to frame presentation as possible. This PR gets the Instant::now() for the time immediately after frame presentation in the render system and then sends that time to the app world through a channel. - implements suggestion from @aevyrie from here bevyengine#4728 (comment) ## Statistics  --- ## Changelog - Make frame time reporting more accurate. ## Migration Guide `time.delta()` now reports zero for 2 frames on startup instead of 1 frame.
# Objective - The time update is currently done in the wrong part of the schedule. For a single frame the current order of things is update input, update time (First stage), other stages, render stage (frame presentation). So when we update the time it includes the input processing of the current frame and the frame presentation of the previous frame. This is a problem when vsync is on. When input processing takes a longer amount of time for a frame, the vsync wait time gets shorter. So when these are not paired correctly we can potentially have a long input processing time added to the normal vsync wait time in the previous frame. This leads to inaccurate frame time reporting and more variance of the time than actually exists. For more details of why this is an issue see the linked issue below. - Helps with bevyengine#4669 - Supercedes bevyengine#4728 and bevyengine#4735. This PR should be less controversial than those because it doesn't add to the API surface. ## Solution - The most accurate frame time would come from hardware. We currently don't have access to that for multiple reasons, so the next best thing we can do is measure the frame time as close to frame presentation as possible. This PR gets the Instant::now() for the time immediately after frame presentation in the render system and then sends that time to the app world through a channel. - implements suggestion from @aevyrie from here bevyengine#4728 (comment) ## Statistics  --- ## Changelog - Make frame time reporting more accurate. ## Migration Guide `time.delta()` now reports zero for 2 frames on startup instead of 1 frame.
# Objective - The time update is currently done in the wrong part of the schedule. For a single frame the current order of things is update input, update time (First stage), other stages, render stage (frame presentation). So when we update the time it includes the input processing of the current frame and the frame presentation of the previous frame. This is a problem when vsync is on. When input processing takes a longer amount of time for a frame, the vsync wait time gets shorter. So when these are not paired correctly we can potentially have a long input processing time added to the normal vsync wait time in the previous frame. This leads to inaccurate frame time reporting and more variance of the time than actually exists. For more details of why this is an issue see the linked issue below. - Helps with bevyengine#4669 - Supercedes bevyengine#4728 and bevyengine#4735. This PR should be less controversial than those because it doesn't add to the API surface. ## Solution - The most accurate frame time would come from hardware. We currently don't have access to that for multiple reasons, so the next best thing we can do is measure the frame time as close to frame presentation as possible. This PR gets the Instant::now() for the time immediately after frame presentation in the render system and then sends that time to the app world through a channel. - implements suggestion from @aevyrie from here bevyengine#4728 (comment) ## Statistics  --- ## Changelog - Make frame time reporting more accurate. ## Migration Guide `time.delta()` now reports zero for 2 frames on startup instead of 1 frame.
Objective
Solution
Statistics
Changelog
Migration Guide
time.delta()now reports zero for 2 frames on startup instead of 1 frame.