Hi!
I read your article.
What I feel are missing are just minor pesky details:
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).
Right now if frame N was submitted without VkPresentTimeMESA but frame N+1 is, 
then frame N+1 will be presented to screen ASAP.
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'
> However, I think allowing the period to be specified in frames might be> a 
> mistake, because it won't work well with variable refresh rate
The API needs to be expanded further to explain Vulkan what a 'frame' is.Is it 
the monitor's refresh rate?
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
It should also be possible to dynamically change how long a frame lasts, in 
case the GPU simply can't catch up (e.g. specifying a denominator = 240 and 
using frames when the GPU can only render at 30hz is almost the same as 
presenting ASAP i.e. the same as not using VK_MESA_present_period at all)
Specifying denominator = 0 means using the monitor's native refresh rate. If 
such concept makes no sense (e.g. VRR?) then the behavior fallbacks to some 
unspecified low value (like denominator = 240) or some other vendor-defined 
behavior.The value is unspecified because vendors will likely want to adjust 
this to an optimal value (e.g. controlled via driver settings in the Control 
Panel, defined by the Monitor manufacturer, defined by the GPU vendor, etc).
CheersMatias
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to