RFC for a render API to support adaptive sync and VRR

[Daniel Vetter]

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