RFC for a render API to support adaptive sync and VRR

Michel Dänzer michel at daenzer.net
Wed Apr 11 10:28:21 UTC 2018

On 2018-04-10 07:25 PM, Cyr, Aric wrote:
>> From: Michel Dänzer [mailto:michel at daenzer.net]
>> On 2018-04-10 07:13 PM, Cyr, Aric wrote:
>>>> From: Michel Dänzer [mailto:michel at daenzer.net]
>>>> 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.
> Yes, and that's why you don't want to do it when you have variable refresh.  The hardware in the monitor and GPU will do it for you, so why bother?
> The input to their algorithms will be noisy causing worst estimations.  If you just present as fast as you can, it'll just work (within reason).

If a frame is presented earlier than the time corresponding to the state
of the world as displayed in the frame, it results in stutter, just as
when it's presented too late.

> The majority of gamers want maximum FPS for their games, and there's quite frequently outrage at a particular game when they are limited to something lower that what their monitor could otherwise support (i.e. I don't want my game limited to 30Hz if I have a shiny 144Hz gaming display I paid good money for).

That doesn't (have to) happen.

for Croteam's talk about this at this year's GDC. It says the best API
available so far is the Vulkan extension VK_GOOGLE_display_timing, which
(among other things) allows specifying the earliest desired presentation
time via VkPresentTimeGOOGLE::desiredPresentTime . (The talk also
mentions that they previously experimented with VDPAU, because it allows
specifying the target presentation time)

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

More information about the amd-gfx mailing list