[Mesa-dev] [PATCH 13/14] vl/dri3: implement functions for get and set timestamp
Leo Liu
leo.liu at amd.com
Wed May 11 21:43:08 UTC 2016
On 05/11/2016 05:37 PM, Axel Davy wrote:
> On 11/05/2016 23:31, Leo Liu wrote:
>>
>>
>> On 05/11/2016 05:18 PM, Axel Davy wrote:
>>> On 11/05/2016 23:08, Leo Liu wrote:
>>>> scrn->next_msc = ((int64_t)stamp - scrn->last_ust +
>>>> scrn->ns_frame/2) /
>>>> + scrn->ns_frame + scrn->last_msc;
>>>
>>> Could you explain this calculation ?
>> ns_frame is the time for vsync in ns.
>> last_ust is time of last frame is finished presentation.
>> last_msc is msc of last frame is finished presentation.
>> stamp is player expected time for next frame to present.
>> and do the round up.
> thanks
>>>
>>> I think it may get issues if ns_frame is wrong. For example for some
>>> reason (app hidden for some frame, or monitor shut, or whatever), I
>>> think we could get two buffers getting complete event with same ust
>>> (one skipped, and one shown).
>>>
>> It works well very well so far for DRI2.
>>
>
> DRI3/Present are designed to allow more liberty for the server. It is
> expected in future version
> the window managers will handle some of the events, and it may behave
> quite different than currently.
>
> Besides DRI3/Present will likely be plugged into Xwayland (currently
> it uses the emulation code, but the extension can be implemented with
> wayland calls, I had a patch for that), and there again it is
> different behaviour.
>
> Thus I advise against having code that 'works well in practice' but
> can fail with something that is allowed in the spec.
Agreed, this is initial work. we will keep making progress.
Thanks,
Leo
>
>> Thanks,
>> Leo
>>
>>> I think the calculation should be made more robust to issues with
>>> ns_frame. Perhaps do some temporal averaging of ns_frame and ignore
>>> outliers ?
>>>
>>>
>>> Axel
>>>
>>
>
More information about the mesa-dev
mailing list