[Mesa-dev] Playing with display timing -- VK_MESA_present_period

[Keith Packard]

"Matias N. Goldberg" <dark_sylinc at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20200203/0db8e44a/attachment.sig>