RFC for a render API to support adaptive sync and VRR

[Stéphane Marchesin]

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.

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