On 2018-04-13 12:04 PM, Daniel Vetter wrote: > 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. Good point. The intention of this very early RFC was to understand if we're sort of thinking along the same lines as the rest of the community before going ahead and prototyping something that's not going to work well in the end. The focus here was on the kernel API. We haven't done any investigation of VK, GL, or MM APIs on this yet and were hoping for some guidance on that. That guidance seems to be that from VK and MM API perspectives frame_duration doesn't cut it and we should rather pursue an absolute presentation time. Harry > - 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@xxxxxxxxxxxxxxxxxxxxx >>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >>> > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
