[Mesa-dev] [PATCH 13/14] vl/dri3: implement functions for get and set timestamp

[Leo Liu]

Hi Axel,

Just clarify something you might got misunderstand on vl implementation 
perspective.

 >The present extension has something exactly to set the target ust for 
the presentation: PresentOptionUST

 >Unfortunately, while it is in the spec it looks like the option is 
totally ignored, and thus it will be totally buggy (you are supposed to 
pass ust instead of msc...).

We have to set target msc for presentation, not target ust, otherwise 
will mismatch the vsync and got tearing.
using last_ust here  is for player to get timestamp of last frame being 
presented in order for player to set new timestamp.
PresentOptionUST is to schedule next presentation at specified UST time, 
so it's not suitable here.

 >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).

I don't think this is correct scenario. in each frame(except the first 
one) we will wait to get sbc reply/or serial update to make sure 
different buffer/frame get different ust, otherwise the playback will 
drop frames and get stuttering.

 >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.

Like being said in the cover letter,  it has implemented spec for 
adapting current X sever, window mangers, and being well tested in this 
environment. And we will get into new environment like Xwayland for next 
step, if something fails and that's in the spec, definitely new spec 
will get implemented.

Thanks a lot for your commenting, that has been very helpful!

Leo


On 05/11/2016 05:43 PM, Leo Liu wrote:
>
>
> 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
>>>>
>>>
>>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev