RFC for a render API to support adaptive sync and VRR

[Manasi Navare]

On Mon, Apr 23, 2018 at 10:40:06AM -0400, Harry Wentland wrote:
> On 2018-04-20 04:32 PM, Manasi Navare wrote:
> > On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote:
> >> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard <keithp at keithp.com> wrote:
> >>> Michel Dänzer <michel at daenzer.net> writes:
> >>>> Time-based presentation seems to be the right approach for preventing
> >>>> micro-stutter in games as well, Croteam developers have been researching
> >>>> this.
> >>>
> >>> Both the Vulkan GOOGLE_display_timing extension and X11 Present
> >>> extension offer the ability to specify the desired display time in
> >>> seconds.
> >>>
> >>> Similarly, I'd suggest that the min/max display refresh rate values be
> >>> advertised as time between frames rather than frames per second.
> > 
> > So there is a global min and max refresh rate as advertised by the monitor
> > range descriptor. That I guess can be exposed as a global range in terms of
> > min and max time between frames as a global property of the connector.
> > 
> > We dont need the per mode min and max refresh rate to be exposed right?
> 
> If I understand VRR right, with CinemaVRR acceptable refresh rates might fall outside the range advertised by the monitor. Would we
>  1) advertise 24/1.001 as a lower bound,
>  2) expect media apps to use the lower bound simply for informational purposes,
>  3) or simply not support CinemaVRR?
> 
> (1) has the added caveat that not all reported rates would be supported.
> 
> Alternatively a bit could indicate that CinemaVRR is support, but I'm not sure if user mode would need all these details.
> 
> Harry

Are there special CinemaVRR suported monitors? In that case we need to understand how those monitors
advertise the monitor range and if they have a bit in EDID that indicate they are CinemaVRR capable
as opposed to just the Adaptive Sync/VRR.
Harry, if you have one of those monitors, could you send the EDID dump for that?

Manasi

> 
> > 
> >>>
> >>> I'd also encourage using a single unit for all of these values,
> >>> preferably nanoseconds. Absolute times should all be referenced to
> >>> CLOCK_MONOTONIC.
> >>
> >> +1 on everything Keith said. I got somehow dragged in khr vk
> >> discussions around preventing micro-stuttering, and consensus seems to
> >> be that timestamps for scheduling frames is the way to go, most likely
> >> absolute ones (not everything is running Linux unfortunately, so can't
> >> go outright and claim it's guaranteed to be CLOCK_MONOTONIC).
> >> -Daniel
> > 
> > And yes I also got consensus from Mesa and media folks about using the
> > absolute timestamp for scheduling the frames and then the driver will
> > modify the vblank logic to "present no earlier than the timestamp"
> > 
> > Manasi
> > 
> >> -- 
> >> Daniel Vetter
> >> Software Engineer, Intel Corporation
> >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >