On 2018-04-12 05:38 PM, Stéphane Marchesin wrote: > On Tue, Apr 10, 2018 at 12:37 AM, Michel Dänzer <michel@xxxxxxxxxxx> 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. > That's an interesting use-case. I don't think we have given much thought to damage rects before. Harry > Stéphane > > >> >> >> -- >> Earthling Michel Dänzer | http://www.amd.com >> Libre software enthusiast | Mesa and X developer >> _______________________________________________ >> dri-devel mailing list >> dri-devel@xxxxxxxxxxxxxxxxxxxxx >> https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
