RFC for a render API to support adaptive sync and VRR

[Michel Dänzer]

On 2018-04-10 07:13 PM, Cyr, Aric wrote:
>> -----Original Message-----
>> From: Michel Dänzer [mailto:michel at daenzer.net]
>> Sent: Tuesday, April 10, 2018 13:06
>> On 2018-04-10 06:26 PM, Cyr, Aric wrote:
>>> From: Koenig, Christian Sent: Tuesday, April 10, 2018 11:43
>>>
>>>> For video games we have a similar situation where a frame is rendered
>>>> for a certain world time and in the ideal case we would actually
>>>> display the frame at this world time.
>>>
>>> That seems like it would be a poorly written game that flips like
>>> that, unless they are explicitly trying to throttle the framerate for
>>> some reason.  When a game presents a completed frame, they’d like
>>> that to happen as soon as possible.
>>
>> What you're describing is what most games have been doing traditionally.
>> Croteam's research shows that this results in micro-stuttering, because
>> frames may be presented too early. To avoid that, they want to
>> explicitly time each presentation as described by Christian.
> 
> Yes, I agree completely.  However that's only truly relevant for fixed
> refreshed rate displays.

No, it also affects variable refresh; possibly even more in some cases,
because the presentation time is less predictable.


I have to leave for today, I'll look up the Croteam video on Youtube
explaining this tomorrow if nobody beats me to it.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer