<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body bgcolor="white" lang="EN-US" link="blue" vlink="purple"> <div class="WordSection1"> From: Koenig, Christian Sent: Tuesday, April 10, 2018 11:43 <o:p></o:p> <div> Am 10.04.2018 um 17:35 schrieb Cyr, Aric:<o:p></o:p> </div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre style="margin-left:.5in">-----Original Message-----<o:p></o:p></pre> <pre style="margin-left:.5in">From: Wentland, Harry<o:p></o:p></pre> <pre style="margin-left:.5in">Sent: Tuesday, April 10, 2018 11:08<o:p></o:p></pre> <pre style="margin-left:.5in">To: Michel Dänzer <a href="mailto:michel@daenzer.net"><michel@daenzer.net></a>; Koenig, Christian <a href="mailto:Christian.Koenig@amd.com"><Christian.Koenig@amd.com></a>; Manasi Navare<o:p></o:p></pre> <pre style="margin-left:.5in"><a href="mailto:manasi.d.navare@intel.com"><manasi.d.navare@intel.com></a><o:p></o:p></pre> <pre style="margin-left:.5in">Cc: Haehnle, Nicolai <a href="mailto:Nicolai.Haehnle@amd.com"><Nicolai.Haehnle@amd.com></a>; Daniel Vetter <a href="mailto:daniel.vetter@ffwll.ch"><daniel.vetter@ffwll.ch></a>; Daenzer, Michel<o:p></o:p></pre> <pre style="margin-left:.5in"><a href="mailto:Michel.Daenzer@amd.com"><Michel.Daenzer@amd.com></a>; dri-devel <a href="mailto:dri-devel@lists.freedesktop.org"><dri-devel@lists.freedesktop.org></a>; amd-gfx mailing list <a href="mailto:amd-gfx@lists.freedesktop.org"><amd-gfx@lists.freedesktop.org></a>;<o:p></o:p></pre> <pre style="margin-left:.5in">Deucher, Alexander <a href="mailto:Alexander.Deucher@amd.com"><Alexander.Deucher@amd.com></a>; Cyr, Aric <a href="mailto:Aric.Cyr@amd.com"><Aric.Cyr@amd.com></a>; Koo, Anthony <a href="mailto:Anthony.Koo@amd.com"><Anthony.Koo@amd.com></a><o:p></o:p></pre> <pre style="margin-left:.5in">Subject: Re: RFC for a render API to support adaptive sync and VRR<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">On 2018-04-10 03:37 AM, Michel Dänzer wrote:<o:p></o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre style="margin-left:.5in">On 2018-04-10 08:45 AM, Christian König wrote:<o:p></o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre style="margin-left:.5in">Am 09.04.2018 um 23:45 schrieb Manasi Navare:<o:p></o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre style="margin-left:.5in">Thanks for initiating the discussion. Find my comments below:<o:p></o:p></pre> <pre style="margin-left:.5in">On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:<o:p></o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre style="margin-left:.5in">On 2018-04-09 03:56 PM, Harry Wentland wrote:<o:p></o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">=== A DRM render API to support variable refresh rates ===<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">In order to benefit from adaptive sync and VRR userland needs a way<o:p></o:p></pre> <pre style="margin-left:.5in">to let us know whether to vary frame timings or to target a<o:p></o:p></pre> <pre style="margin-left:.5in">different frame time. These can be provided as atomic properties on<o:p></o:p></pre> <pre style="margin-left:.5in">a CRTC:<o:p></o:p></pre> <pre style="margin-left:.5in"> * bool variable_refresh_compatible<o:p></o:p></pre> <pre style="margin-left:.5in"> * int target_frame_duration_ns (nanosecond frame duration)<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">This gives us the following cases:<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">variable_refresh_compatible = 0, target_frame_duration_ns = 0<o:p></o:p></pre> <pre style="margin-left:.5in"> * drive monitor at timing's normal refresh rate<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">variable_refresh_compatible = 1, target_frame_duration_ns = 0<o:p></o:p></pre> <pre style="margin-left:.5in"> * send new frame to monitor as soon as it's available, if within<o:p></o:p></pre> <pre style="margin-left:.5in">min/max of monitor's reported capabilities<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0<o:p></o:p></pre> <pre style="margin-left:.5in"> * send new frame to monitor with the specified<o:p></o:p></pre> <pre style="margin-left:.5in">target_frame_duration_ns<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">When a target_frame_duration_ns or variable_refresh_compatible<o:p></o:p></pre> <pre style="margin-left:.5in">cannot be supported the atomic check will reject the commit.<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> </blockquote> </blockquote> <pre style="margin-left:.5in">What I would like is two sets of properties on a CRTC or preferably on<o:p></o:p></pre> <pre style="margin-left:.5in">a connector:<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">KMD properties that UMD can query:<o:p></o:p></pre> <pre style="margin-left:.5in">* vrr_capable - This will be an immutable property for exposing<o:p></o:p></pre> <pre style="margin-left:.5in">hardware's capability of supporting VRR. This will be set by the<o:p></o:p></pre> <pre style="margin-left:.5in">kernel after<o:p></o:p></pre> <pre style="margin-left:.5in">reading the EDID mode information and monitor range capabilities.<o:p></o:p></pre> <pre style="margin-left:.5in">* vrr_vrefresh_max, vrr_vrefresh_min - To expose the min and max<o:p></o:p></pre> <pre style="margin-left:.5in">refresh rates supported.<o:p></o:p></pre> <pre style="margin-left:.5in">These properties are optional and will be created and attached to the<o:p></o:p></pre> <pre style="margin-left:.5in">DP/eDP connector when the connector<o:p></o:p></pre> <pre style="margin-left:.5in">is getting intialized.<o:p></o:p></pre> </blockquote> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">Mhm, aren't those properties actually per mode and not per CRTC/connector?<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre style="margin-left:.5in">Properties that you mentioned above that the UMD can set before kernel<o:p></o:p></pre> <pre style="margin-left:.5in">can enable VRR functionality<o:p></o:p></pre> <pre style="margin-left:.5in">*bool vrr_enable or vrr_compatible<o:p></o:p></pre> <pre style="margin-left:.5in">target_frame_duration_ns<o:p></o:p></pre> </blockquote> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">Yeah, that certainly makes sense. But target_frame_duration_ns is a bad<o:p></o:p></pre> <pre style="margin-left:.5in">name/semantics.<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">We should use an absolute timestamp where the frame should be presented,<o:p></o:p></pre> <pre style="margin-left:.5in">otherwise you could run into a bunch of trouble with IOCTL restarts or<o:p></o:p></pre> <pre style="margin-left:.5in">missed blanks.<o:p></o:p></pre> </blockquote> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">Also, a fixed target frame duration isn't suitable even for video<o:p></o:p></pre> <pre style="margin-left:.5in">playback, due to drift between the video and audio clocks.<o:p></o:p></pre> </blockquote> </blockquote> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">Why? Even if they drift, you know you want to show your 24Hz video frame for 41.6666ms and adaptive sync can ensure that with reasonable accuracy. <o:p></o:p></pre> <pre style="margin-left:.5in">All we're doing is eliminating the need for frame rate converters from the application and offloading that to hardware.<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre style="margin-left:.5in">Time-based presentation seems to be the right approach for preventing<o:p></o:p></pre> <pre style="margin-left:.5in">micro-stutter in games as well, Croteam developers have been researching<o:p></o:p></pre> <pre style="margin-left:.5in">this.<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> </blockquote> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">I'm not sure if the driver can ever give a guarantee of the exact time a flip occurs. What we have control over with our HW is frame<o:p></o:p></pre> <pre style="margin-left:.5in">duration.<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">Are Croteam devs trying to predict render times? I'm not sure how that would work. We've had bad experience in the past with<o:p></o:p></pre> <pre style="margin-left:.5in">games that try to do framepacing as that's usually not accurate and tends to lead to more problems than benefits.<o:p></o:p></pre> </blockquote> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">For gaming, it doesn't make sense nor is it feasible to know how exactly how long a render will take with microsecond precision, very coarse guesses at best. The point of adaptive sync is that it works *transparently* for the majority of cases, within the capability of the HW and driver. We don't want to have every game re-write their engine to support this, but we do want the majority to "just work".<o:p></o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">The only exception is the video case where an application may want to request a fixed frame duration aligned to the video content. This requires an explicit interface for the video app, and our proposal is to keep it simple: app knows how long a frame should be presented for, and we try to honour that.<o:p></o:p></pre> </blockquote> Well I strongly disagree on that. See VDPAU for example: <a href="https://http.download.nvidia.com/XFree86/vdpau/doxygen/html/group___vdp_presentation_queue.html#ga5bd61ca8ef5d1bc54ca6921aa57f835a"> https://http.download.nvidia.com/XFree86/vdpau/doxygen/html/group___vdp_presentation_queue.html#ga5bd61ca8ef5d1bc54ca6921aa57f835a</a> <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> [in] <o:p></o:p> <table class="MsoNormalTable" border="0" cellpadding="0" style="margin-left:.5in"> <tbody> <tr> <td style="padding:.75pt .75pt .75pt .75pt"></td> <td style="padding:.75pt .75pt .75pt .75pt"> earliest_presentation_time<o:p></o:p> </td> <td style="padding:.75pt .75pt .75pt .75pt"> The timestamp associated with the surface. The presentation queue will not display the surface until the presentation queue's current time is at least this value.<o:p></o:p> </td> </tr> </tbody> </table> </blockquote> Especially video players want an interface where they can specify when exactly a frame should show up on the display and then get the feedback when it actually was displayed.<o:p></o:p> <o:p> </o:p> That presentation time doesn’t need to come to kernel as such and actually is fine as-is completely decoupled from adaptive sync. As long as the video player provides the new target_frame_duration_ns on the flip, then the driver/HW will target the correct refresh rate to match the source content. This simply means that more often than not the video presents will align very close to the monitor’s refresh rate, resulting in a smooth video experience. For example, if you have 24Hz content, and an adaptive sync monitor with a range of 40-60Hz, once the target_frame_duration_ns is provided, driver can configure the monitor to a fixed refresh rate of 48Hz causing all video presents to be frame-doubled in hardware without further application intervention.<o:p></o:p> For video games we have a similar situation where a frame is rendered for a certain world time and in the ideal case we would actually display the frame at this world time.<o:p></o:p> <o:p> </o:p> That seems like it would be a poorly written game that flips like that, unless they are explicitly trying to throttle the framerate for some reason. When a game presents a completed frame, they’d like that to happen as soon as possible. This is why non-VSYNC modes of flipping exist and many games leverage this. Adaptive sync gives you the lower latency of immediate flips without the tearing imposed by using non-VSYNC flipping.<o:p></o:p> I mean we have the guys from Valve on this mailing list so I think we should just get the feedback from them and see what they prefer. <o:p></o:p> We have thousands of Steam games on other OSes that work great already, but we’d certainly be interested in any additional feedback. My guess is they prefer to “do nothing” and let driver/HW manage it, otherwise you exempt all existing games from supporting adaptive sync without a rewrite or update.<o:p></o:p> Regards, Christian. <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in"><o:p> </o:p></pre> <pre style="margin-left:.5in">-Aric<o:p></o:p></pre> </blockquote> <o:p> </o:p> </div> </body> </html>