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.


> 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 :)
>> -- 
>> PMTS Software Engineer | SW – Display Technologies
dri-devel mailing list

Reply via email to