It would be really nice to have support for the automatic extension-less fullscreen game scenario. Maybe you don't have to solve everything in the first implementation... So a friendly ping here! Regards //Ernst Den tis 24 apr. 2018 kl 23:58 skrev Daniel Vetter <daniel@xxxxxxxx>: > > On Tue, Apr 24, 2018 at 4:28 PM, Harry Wentland <harry.wentland@xxxxxxx> wrote: > > > > > > On 2018-04-24 08:09 AM, Daniel Vetter wrote: > >> On Mon, Apr 23, 2018 at 02:19:44PM -0700, Manasi Navare wrote: > >>> 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@xxxxxxxxxx> wrote: > >>>>>>> Michel Dänzer <michel@xxxxxxxxxxx> 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? > >> > >> As long as the any multiple of the 24/1.001 refresh rate is within the > >> officially supported refresh range rate this should work out. Maybe we'll > >> end up uploading 2x (to run at ~48Hz), maybe the kernel only uploads at > >> 24Hz. But should all be fine. > >> > > > > Would kernel driver upload 48Hz when UMD asks for 24Hz or would UMD be expected to submit double frames? > > > > If kernel driver supports frame doubling (like our DC driver) we would probably report half of monitor-reported min-refresh (or rather double of monitor-reported max frame time). > > Your driver (amdgpu) already supports frame doubling, except only for > vblank seqno instead of timestamps. Whether VRR can get down to 24Hz > or not is totally irrelevant from userspace's point of view. By > default the kernel is expected to keep display the current frame for > as long as userspace gives it a new one. There's no expectation that > userspace provides a new buffer for every vblank (whether that's a > fixed or variable refresh rate doesn't matter). > -Daniel > > > > > Harry > > > >> Ofc if we have CinemaVRR screens which don't fit this, then maybe we need > >> to figure out something ... > >> -Daniel > >> > >>> > >>> 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@xxxxxxxxxxxxxxxxxxxxx > >>>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >>>>> _______________________________________________ > >>>>> dri-devel mailing list > >>>>> dri-devel@xxxxxxxxxxxxxxxxxxxxx > >>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >>>>> > >> > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > _______________________________________________ > 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
