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 > >
