> From: Manasi Navare [mailto:manasi.d.navare@xxxxxxxxx] > Sent: Tuesday, April 10, 2018 17:37 > To: Wentland, Harry <Harry.Wentland@xxxxxxx> > Cc: amd-gfx mailing list <amd-gfx@xxxxxxxxxxxxxxxxxxxxx>; Daniel Vetter <daniel.vetter@xxxxxxxx>; Haehnle, Nicolai > <Nicolai.Haehnle@xxxxxxx>; Daenzer, Michel <Michel.Daenzer@xxxxxxx>; Deucher, Alexander <Alexander.Deucher@xxxxxxx>; > Koenig, Christian <Christian.Koenig@xxxxxxx>; dri-devel <dri-devel@xxxxxxxxxxxxxxxxxxxxx>; Cyr, Aric <Aric.Cyr@xxxxxxx>; Koo, > Anthony <Anthony.Koo@xxxxxxx> > Subject: Re: RFC for a render API to support adaptive sync and VRR > > On Tue, Apr 10, 2018 at 11:03:02AM -0400, Harry Wentland wrote: > > 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? > > > > I was refering to a case where the render rate is lower say 24Hz but the display rate is fixed 60Hz, that means we are pretty much > displaying the same frame > twice. But with Adaptive Sync, the display rate would be lowered to 24hz and the vertical blanking time will be stretched where > instead of drawing the > same frame twice, the system is now idle in that extra blanking time thus giving some power savings. Hi Manasi, Assuming the panel could go down to 24Hz, this would be possible. If it was a game, it'd naturally do this since the refresh rate would track the render rate. For a video where you have an adaptive sync capable player, it could request a fixed duration to achieve the same thing. Most panels do not support as low as 24Hz however, so usually in the video case at least you'd end up with say 48Hz with the driver/HW providing automatic frame doubling. > > > > > >>> > > >>> > > >>> === 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. > > Actually the way I have coded that currently is span through all the EDID modes and for each mode with the same resolution but > different refresh rates supported, create a VRR field part of drm_mode_config structure that would have > refresh_max and min. So that way we store the max and min per mode as opposed to a per crtc/connector property. Adaptive Sync spec specifies that the refresh rate range comes from the Monitor Range Descriptor and that all modes in EDID must be supported at any of those refresh rates. I'd have to check the HDMI VRR spec, but I would assume it's similar, hence the per-connector property. Per-mode is probably overkill in this case although I think I know the scenario you are referring to but it is a small old proprietary solution that no one uses and could be emulated with a correct Monitor Range Descriptor EDID quirk. > > > > 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. > > I think this range obtained from EDID monitor range descriptor should still be exposed through a property so that userspace does not > request a target frame rate beyond whats supported. Or the drm_atomic_check could fail? The problem with user space knowing this is that it doesn't know what to do with it. If you say you want 24Hz but the monitor range is 40-120Hz, should user mode not even try to request? Should it request double? triple? I think it becomes difficult because the answer could very well depend on the driver and GPU and monitor combination. I think it has to be the driver, which knows the HW capabilities, verify what is possible or not, which is why I'd suggest an drm_atomic_check failure. > Manasi - Aric _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
