On 2018-04-12 01:39 PM, 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. One such advantage is that it doesn't require userspace to predict the future, where at least in the Vulkan case there is no information to base the prediction on. I fail to see how that can work at all. > 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. Keep in mind that the constraint is "present no earlier than", which can be satisfied e.g. by waiting for the target time to pass before programming the flip to the hardware. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
