"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'. > The API needs to be expanded further to explain Vulkan what a 'frame' > is.Is it the monitor's refresh rate? KHR_swapchain and EXT_display_surface_counter both mention 'vertical blanking periods'. GOOGLE_display_timing has vkGetRefreshCycleDurationGOOGLE which returns 'refreshDuration'. 'frame' is also used throughout Vulkan and seems to describe one of a sequence of images displayed to the user. Coming up with language which ties back into all of these would be helpful. > Or is it an arbitrary elapsed time defined in the form numerator and > denominator? (e.g. 60hz is numerator = 1, denominator = 60; 59.94hz is > numerator = 1001 denominator = 6000)By specifying arbitrary > definitions of a frame, it is possible to be compatible with variable > refresh rates e.g. for VRR monitors, applications may define > denominator = 240 or denominator = 120 When I talked about 'frames' in my informal description, I could have clarified that by referring to the GOOGLE_display_timing 'refreshDuration' value. I think that variable refresh rate monitors would be expected to set that to a useful value, possibly based on the nominal display period, but I don't know. I think that we'll need some more Vulkan extensions designed to expose the capabilities and limits of variable refresh rate monitors. Do we need to do that in conjunction with this extension, or can we define this extension in such a way that it should work with whatever we end up with in the future? -- -keith
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev