-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2020-02-03 9:16 p.m., Keith Packard wrote: > "Matias N. Goldberg" <dark_syl...@yahoo.com.ar> writes: > >> I read your article. > > Thanks! > >> What I feel are missing are just minor pesky details: > > Yes, it's definitely a rough draft at best. Figuring out the right > words to make it do precisely what we want is hard, and I'm hoping > we can first figure out what we want, then figure out how to say > that precisely. > >> 1. Written as is, the frame being submitted is rounded up to >> display timing, delaying *future* frames.But there is no way to >> delay the *currently displaying frame* (i.e. the 'previous' >> frame). > > Correct. The period provided controls how long the specified frame > will be shown to the user (at a minimum). Future frames will be > delayed by at least that long. > >> Right now if frame N was submitted without VkPresentTimeMESA but >> frame N+1 is, then frame N+1 will be presented to screen ASAP. > > Correct. > >> What I'm saying is that if frame N was submitted without >> VkPresentTimeMESA, then at frame N+1 I should be able to tell >> 'keep frame N displayed for at least P nanoseconds since it was >> displayed, and *then* present frame N+1, which is the frame I am >> now submitting' > > That's not what this extension does; if you wanted frame 'N' to be > displayed for 'P' nanoseconds, then you would specify 'P' when > queuing frame 'N'.
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? 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? - -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXjlKBwAKCRBaga+Oatuy ADDxAJ49XUxG6tnAWuC/br12sORqQSBUyACgk7h1jf9fjjtMYvrkIfUnkcHwkqg= =m2sK -----END PGP SIGNATURE----- _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev