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 >> >> >> >> > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
