Michel Dänzer <mic...@daenzer.net> writes: > Hmm, I didn't fully realize this in my reading of the draft, thanks > Matias for pointing it out! > > That the timing of frame N+1 has to be specified when submitting frame > N for presentation is odd to me TBH. While I can imagine this might be > suitable for some apps such as video players, I'm skeptical about game > engines. They would need to calculate frame time budget and choose > simulation time for frame N+1 before submitting frame N for > presentation. Is that really how game engines (want to) work?
It's not asking the application to figure this out much earlier -- the application needs to know the target time for the next frame before starting any of the frame computations, and that happens right after submitting the previous frame. The goal here is to provide the display system the timing information as soon as the application knows it, in case that helps the backend work better. > Instead, have you considered allowing the GOOGLE_display_timing > desiredPresentTime to be specified as a relative time, measured from > when the previous image of the swapchain was actually presented, > instead of as an absolute time? Could something like that also address > the motivation for VK_MESA_present_period? Yes, that would avoid the display problem. -- -keith
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
