Re: RFC for a render API to support adaptive sync and VRR

[Harry Wentland <harry.wentland-5C7GfCeVMHo@public.gmane.org>]

Adding Anthony and Aric who've been working on Freesync with DC on other OSes for a while.

On 2018-04-09 05:45 PM, Manasi Navare wrote:
> 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.

Are you talking about a use case, such as an idle desktop, where the renders are quite sporadic?

>  
>>>
>>>
>>> === 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.
> 

If we're talking about the properties from the EDID these might not necessarily align with a currently selected mode, which might have a refresh rate lower than the vrr_refresh_max, requiring us to cap it at that. In some scenarios we also might do low framerate compensation [1] where we do magic to allow the framerate to drop below the supported range.

I think if a vrr_refresh_max/min are exposed to UMD these should really be only for informational purposes, in which case it might make more sense to expose them through sysfs or even debugfs entries.

[1] https://www.amd.com/Documents/freesync-lfc.pdf

> 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
> 
> 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'm not sure about the VRR spec, but for adaptive sync we should only consider the range limits specified in the EDID and allow adaptive sync for modes within that range.

> 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.
> 

That sounds great. I wouldn't mind trying those patches and then working together to arrive at something that works for both Intel and AMD. Who knows, maybe other driver guys are interested in this as well.

Harry

> 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@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx