RFC for a render API to support adaptive sync and VRR

[Harry Wentland]

On 2018-04-10 07:44 AM, Chris Wilson wrote:
> Quoting Christian König (2018-04-10 07:45:04)
>> Am 09.04.2018 um 23:45 schrieb Manasi Navare:
>>> Properties that you mentioned above that the UMD can set before kernel can enable VRR functionality
>>> *bool vrr_enable or vrr_compatible
>>> target_frame_duration_ns
>>
>> Yeah, that certainly makes sense. But target_frame_duration_ns is a bad 
>> name/semantics.
>>
>> We should use an absolute timestamp where the frame should be presented, 
>> otherwise you could run into a bunch of trouble with IOCTL restarts or 
>> missed blanks.
> 
> Hear, hear. I was disappointed not to see this be the starting point of
> the conversation. Imo, the uABI should in terms of absolutes with the
> drivers mapping that onto HW and reporting back the discrepancies.

I think it's just that some of us that work on KMD display drivers have had our work primarily guided by different use cases, such as gaming, which has then be extended to provide a better experience for video as well. We might not be as intimately aware of some of the work that's been done on video APIs and the pains involved in it but are always happy to learn and work together toward the best solution.

Harry

> -Chris
>