RFC for a render API to support adaptive sync and VRR

[Harry Wentland]

On 2018-04-12 05:38 PM, Stéphane Marchesin wrote:
> On Tue, Apr 10, 2018 at 12:37 AM, Michel Dänzer <michel at daenzer.net> wrote:
>> On 2018-04-10 08:45 AM, Christian König wrote:
>>> Am 09.04.2018 um 23:45 schrieb Manasi Navare:
>>>> Thanks for initiating the discussion. Find my comments below:
>>>> On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
>>>>> On 2018-04-09 03:56 PM, Harry Wentland wrote:
>>>>>>
>>>>>> === A DRM render API to support variable refresh rates ===
>>>>>>
>>>>>> In order to benefit from adaptive sync and VRR userland needs a way
>>>>>> to let us know whether to vary frame timings or to target a
>>>>>> different frame time. These can be provided as atomic properties on
>>>>>> a CRTC:
>>>>>>   * bool    variable_refresh_compatible
>>>>>>   * int    target_frame_duration_ns (nanosecond frame duration)
>>>>>>
>>>>>> This gives us the following cases:
>>>>>>
>>>>>> variable_refresh_compatible = 0, target_frame_duration_ns = 0
>>>>>>   * drive monitor at timing's normal refresh rate
>>>>>>
>>>>>> variable_refresh_compatible = 1, target_frame_duration_ns = 0
>>>>>>   * send new frame to monitor as soon as it's available, if within
>>>>>> min/max of monitor's reported capabilities
>>>>>>
>>>>>> variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0
>>>>>>   * send new frame to monitor with the specified
>>>>>> target_frame_duration_ns
>>>>>>
>>>>>> When a target_frame_duration_ns or variable_refresh_compatible
>>>>>> cannot be supported the atomic check will reject the commit.
>>>>>>
>>>> What I would like is two sets of properties on a CRTC or preferably on
>>>> a connector:
>>>>
>>>> KMD properties that UMD can query:
>>>> * vrr_capable -  This will be an immutable property for exposing
>>>> hardware's capability of supporting VRR. This will be set by the
>>>> kernel after
>>>> reading the EDID mode information and monitor range capabilities.
>>>> * vrr_vrefresh_max, vrr_vrefresh_min - To expose the min and max
>>>> refresh rates supported.
>>>> These properties are optional and will be created and attached to the
>>>> DP/eDP connector when the connector
>>>> is getting intialized.
>>>
>>> Mhm, aren't those properties actually per mode and not per CRTC/connector?
>>>
>>>> Properties that you mentioned above that the UMD can set before kernel
>>>> can enable VRR functionality
>>>> *bool vrr_enable or vrr_compatible
>>>> target_frame_duration_ns
>>>
>>> Yeah, that certainly makes sense. But target_frame_duration_ns is a bad
>>> name/semantics.
>>>
>>> We should use an absolute timestamp where the frame should be presented,
>>> otherwise you could run into a bunch of trouble with IOCTL restarts or
>>> missed blanks.
>>
>> Also, a fixed target frame duration isn't suitable even for video
>> playback, due to drift between the video and audio clocks.
>>
>> Time-based presentation seems to be the right approach for preventing
>> micro-stutter in games as well, Croteam developers have been researching
>> this.
> 
> Another case that you can handle with time-based presentation but not
> with refresh-based API is the use of per-scanline flips in conjunction
> with damage rects. For example if you know that the damage rect covers
> a certain Y range, you can flip when you're outside that range if the
> time that you were given allows it. That's even independent from VRR
> displays.
> 

That's an interesting use-case. I don't think we have given much thought to damage rects before.

Harry

> Stéphane
> 
> 
>>
>>
>> --
>> Earthling Michel Dänzer               |               http://www.amd.com
>> Libre software enthusiast             |             Mesa and X developer
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel