RFC for a render API to support adaptive sync and VRR

Fri Aug 17 10:20:06 UTC 2018

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 at ffwll.ch>:
>
> On Tue, Apr 24, 2018 at 4:28 PM, Harry Wentland <harry.wentland at amd.com> 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 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?
> >>
> >> 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 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
> >>>>>
> >>
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx