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