RFC for a render API to support adaptive sync and VRR

[Harry Wentland]

On 2018-04-12 07:39 AM, Nicolai Hähnle wrote:
> On 12.04.2018 01:30, Cyr, Aric wrote:
>>> At least with VDPAU, video players are already explicitly specifying the
>>> target presentation time, so no changes should be required at that
>>> level. Don't know about other video APIs.
>>>
>>> The X11 Present extension protocol is also prepared for specifying the
>>> target presentation time already, the support for it just needs to be
>>> implemented.
>>
>> I'm perfectly OK with presentation time-based *API*.  I get it from a user mode/app perspective, and that's fine.  We need that feedback and would like help defining that portions of the stack.
>> However, I think it doesn't make as much sense as a *DDI* because it doesn't correspond to any hardware real or logical (i.e. no one would implement it in HW this way) and the industry specs aren't defined that way.
>> You can have libdrm or some other usermode component translate your presentation time into a frame duration and schedule it.  What's the advantage of having this in kernel besides the fact we lose the intent of the application and could prevent features and optimizations.  When it gets to kernel, I think it is much more elegant for the flip structure to contain a simple duration that says "hey, show this frame on the screen for this long".  Then we don't need any clocks or timers just some simple math and program the hardware.
> 
> There isn't necessarily an inherent advantage to having this translation in the kernel. However, we *must* do this translation in a place that is owned by display experts (i.e., you guys), because only you guys know how to actually do that translation reliably and correctly.
> 
> Since your work is currently limited to the kernel, it makes sense to do it in the kernel.

We're actively trying to change this. I want us (the display team) to eventually own anything display related across the stack, or at least closely work with the owners of those components.

> 
> If the translation doesn't happen in a place that you feel comfortable working on, we're setting ourselves up for a future where this hypothetical future UMD component will get this wrong, and there'll be a lot of finger-pointing between you guys and whoever writes that UMD, with likely little willingness to actually go into the respective other codebase to fix what's wrong. And that's a pretty sucky future.
> 

If finger-pointing happened I'd like to apologize. Again, this is something we actively try to change.

Ultimately I'm looking for a solution that works for everyone and is not owned on a SW component basis, but rather expertise basis.

Harry

> Cheers,
> Nicolai
> 
> P.S.: I'm also a little surprised that you seem to be saying that requesting a target present time is basically impossible (at least, that's kind of implied by your statement about mGPUs), and yet there's precedent for such APIs in both Vulkan and VDPAU.
> 
> 
>>
>> In short,
>>   1) We can simplify media players' lives by helping them get really, really close to their content rate, so they wouldn't need any frame rate conversion.
>>       They'll still need A/V syncing though, and variable refresh cannot solve this and thus is way out of scope of what we're proposing.
>>
>>   2) For gaming, don't even try to guess a frame duration, the driver/hardware will do a better job every time, just specify duration=0 and flip as fast as you can.
>>
>> Regards,
>>    Aric
>>
>> P.S. Thanks for the Croteam link.  Interesting, but basically nullified by variable refresh rate displays.  You won't have stuttering/microstuttering/juddering/tearing if your display's refresh rate matches the render/present rate of the game.  Maybe I should grab The Talos Principle to see how well it works with FreeSync display :)
>>
>> -- 
>> ARIC CYR
>> PMTS Software Engineer | SW – Display Technologies
>>
>>
>>
>>
>