Improvements to VRR below-the-range/low framerate compensation.

[Kazlauskas, Nicholas]

On 4/18/19 10:24 AM, Michel Dänzer wrote:
> On 2019-04-18 5:51 a.m., Mario Kleiner wrote:
>>
>> My desired application of VRR for neuroscience/vision research
>> is to control the timing of when frames show up onscreen, e.g.,
>> to show animations at different "unconventional" framerates,
>> so i'm mostly interested in how well one can control the timing
>> between successive OpenGL bufferswaps. This is a bit different
>> from what a game wants to get out of VRR, probably closer to
>> what a movie player might want to do.
> 
> As discussed before, I expect that games which care about smooth
> animation will want to control the presentation time as well in the long
> run, so that they can make the presentation time match the simulation
> time corresponding to the frame contents.
> 
> There is already support for specifying the target presentation time in
> (at least, there might be more I'm not aware of) VDPAU, the Vulkan
> VK_GOOGLE_display_timing extension, and the X11 Present extension
> protocol (not actually implemented yet in xserver though).
> 
> Ideally, this should also be available in the kernel UAPI. That should
> allow hitting the target more accurately / reliably, and might also
> allow making better use of compensation mechanisms such as those touched
> by this series, since userspace can call into the kernel ahead of the
> target time, giving the kernel an opportunity to make adjustments earlier.
> 
> Since you have a strong use-case for this functionality, maybe you'd be
> interested in working on it?
> 
> 

This would be a good real-world userspace application that takes 
advantage of this.

There were some threads before in the original VRR RFC and patch series 
that discussion this, but I think the summary was that most people 
interested were in favor of a timestamp in nanoseconds on the CRTC.

My thoughts on the matter would be that the driver would be enforced not 
to present the frame any earlier than the timestamp given. If the driver 
isn't capable of doing that then it can return -EINVAL (ie. userspace 
asks for a really large timestamp and the driver would have to stall 
forever in order to display it).

There could still be some leeway in terms of when the frame could be 
displayed. Maybe another property could be also used to specify the 
upper bound for presentation.

I would imagine any properties created here would be optional to drivers 
to add. In hindsight, the VRR CRTC property should probably have been 
optional as well.

Nicholas Kazlauskas