[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