RFC for a render API to support adaptive sync and VRR

[Christian König]

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:
>> Adding dri-devel, which I should've included from the start.
>>
>> On 2018-04-09 03:56 PM, Harry Wentland wrote:
>>> === What is adaptive sync and VRR? ===
>>>
>>> Adaptive sync has been part of the DisplayPort spec for a while now and allows graphics adapters to drive displays with varying frame timings. VRR (variable refresh rate) is essentially the same, but defined for HDMI.
>>>
>>>
>>>
>>> === Why allow variable frame timings? ===
>>>
>>> Variable render times don't align with fixed refresh rates, leading to
>>> stuttering, tearing, and/or input lag.
>>>
>>> e.g. (rc = render completion, dr = display refresh)
>>>
>>> rc       B          C            D            E      F
>>> dr	A	B	C	C	D	E	F
>>>
>>>                      ^             ^
>>> 		  frame         missed
>>> 		 repeated	display
>>> 		  twice	        refresh
>>>
>>>
>>>
>>> === Other use cases of adaptive sync ====
>>>
>>> Beside the variable render case, adaptive sync also allows adjustment of refresh rates without a mode change. One such use case would be 24 Hz video.
>>>
> One of the the advantages here when the render speed is slower than the display refresh rate, since we are stretching the vertical blanking interval
> the display adapters will follow "draw fast and then go idle" approach. This gives power savings when render rate is lower than the display refresh rate.
>   
>>>
>>> === 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.

Regards,
Christian.

>
> The monitor only specifies the monitor range through EDID. Apart from this should we also need to scan the modes and check
> if there are modes that have the same pixel clock and horizontal timings but variable vertical totals?
>
> I have RFC patches for all the above mentioned. If we get a concensus/agreement on the above properties and method to check
> monitor's VRR capability, I can submit those patches atleast as RFC.
>
> Regards
> Manasi
>
>>>
>>> === Previous discussions ===
>>>
>>> https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html
>>>
>>>
>>>
>>> === Feedback and moving forward ===
>>>
>>> I'm hoping to get some feedback on this or continue the discussion on how adaptive sync / VRR might look like in the DRM ecosystem. Once there are no major concerns or objections left we'll probably start creating some patches to sketch this out a bit better and see how it looks in practice.
>>>
>>>
>>>
>>> Cheers,
>>> Harry
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>>