On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote: > Adding dri-devel, which I should've included from the start. Top posting, because I'm lazy and was out sick ... Few observations: - Stéphane has a great point which seems to have been ignored thus far. - Where's the VK extension for this - there must be one :-) Starting with a full implementation for that (based on radv or anv or something like that) might help. - Imo if we do a conversion between the vk api and what we feed into the hw, then let's not do a midlayer mistake: That conversion should happen at the bottom, in the kernel driver, maybe assisted with some helpers. Not somewhere in-between, like in libdrm of all places! Cheers, Daniel > > 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. > > > > > > > > === 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. > > > > > > > > === 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 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
