RFC for a render API to support adaptive sync and VRR

[Michel Dänzer]

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.


See
https://www.gdcvault.com/play/1025407/Advanced-Graphics-Techniques-Tutorial-The
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