RFC for a render API to support adaptive sync and VRR
Michel Dänzer
michel at daenzer.net
Thu Apr 12 14:57:58 UTC 2018
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
More information about the dri-devel
mailing list