RFC for a render API to support adaptive sync and VRR

[Michel Dänzer]

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.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer