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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
