Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
Hi Pekka, > I presume you have a driver stack that relies on the opaque EGL buffers and not zwp_linux_dmabuf any time soon? Yes, exactly. I've added a protocol extension for sharing those buffers and our eglCreateImage() implementation can import such buffers into the driver on the compositor end. The buffers are carried by an fd to the compositor that's the only similarity. They're not dma-buf. > Yeah, support for opaque EGL buffers could be added, just need to think of a good wording, since acquire fences do not make sense for all buffer types. Isn't that renderer's and/or backend's decision? The GL renderer can accept fence with any buffer it can send to the 3D driver, so, effectively, anything backed by available EGL image extensions. Someone may add a custom backend and/or renderer using whatever hardware or API they have at hand. A Vulkan renderer could potentially use fences with anything a Vulkan driver is capable of importing. A renderer that does the CPU wait could be useful at least for debugging. So I wouln't block the explicit sync at the compositor level based on the white list. Cheers, Tomek On Fri, 23 Nov 2018 at 13:47, Pekka Paalanen wrote: > On Fri, 23 Nov 2018 13:07:37 + > Tomek Bury wrote: > > > Hi Alexandros, > > > > Sorry for a delay. I've finally got an end-to-end system to test it out. > It > > took some time because Weston backend I wrote a while back needed serious > > rework to catch up with latest changes. > > > > There's one thing that didn't work for me. In compositor you reject > > anything that isn't a DMA buffer and then in glrenderer you put an extra > > assertion. Why? All you do is use an EGL extension in order to import > > external fence_fd. There's no dmabuf dependency there. As long as the EGL > > implementation exposes EGL_SYNC_NATIVE_FENCE_ANDROID extension this > should > > "just work" (tm) for the GL renderer. It certainly did for me. CPU-based > > renderers can poll() to wait. > > Hi Tomek, > > with Weston it was decided not to implement a poll() based wait at > first as implementing that properly (not blocking the compositor) would > be a big hassle and no-one could see the benefit of it given what > clients could actually produce. > > Therefore the acquire fence can only apply to buffers which can be > pipelined to a GPU. Mesa EGL is using zwp_linux_dmabuf, but the support > could be extended to opaque EGL buffers very well. We just chose to > start small and bring up the infrastructure around fences first. > > Restrictions on buffer types etc. can certainly be lifted in the future > if there are good use cases. I presume you have a driver stack that > relies on the opaque EGL buffers and not zwp_linux_dmabuf any time soon? > > Would anyone ever use an acquire fence with wl_shm buffers? That sounds > fundamentally wrong to me as one cannot create fences to be signalled > by userspace AFAIK. Therefore buffers whose wait cannot be pipelined to > the GPU or the display device do not make much sense to me. > > > The type of buffer used is an orthogonal problem. The > > EGL_WL_bind_wayland_display > > extension takes care of GL clients' buffers in GL renderer, for anything > > else the renderer needs to know how to get pixels and use whatever means > to > > put those pixels on screen. > > Yeah, support for opaque EGL buffers could be added, just need to think > of a good wording, since acquire fences do not make sense for all > buffer types. A compositor must be allowed to raise protocol errors for > fence+buffer combinations it cannot use, which means that clients must > know in advance what they cannot use. > > > Thanks, > pq > > > On Tue, 13 Nov 2018 at 09:33, Tomek Bury wrote: > > > > > Thanks! > > > > > > On Tue, Nov 13, 2018 at 9:08 AM Alexandros Frantzis < > > > alexandros.frant...@collabora.com> wrote: > > > > > >> On Mon, Nov 12, 2018 at 12:39:58PM +, Tomek Bury wrote: > > >> > On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone > > > >> wrote: > > >> > > > >> > > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen > > > >> wrote: > > >> > > > I can add that while pushing upstream, if there are no other > changes > > >> > > > coming. > > >> > > > > > >> > > > Reviewed-by: Pekka Paalanen > > >> > > > > > >> > > > You have ensured that the C files generated from this revision > build > > >> > > > fine in Weston, right? > > >> > > > > > >> > > > David, Daniel, since your name is in the maintainers, can I > have > > >> your > > >> > > > R-b, please? > > >> > > > > >> > > The protocol is: > > >> > > Reviewed-by: Daniel Stone > > >> > > > > >> > > The Weston implementation looks pretty good so far, though > there's no > > >> > > full implementation of release yet. > > >> > > > > >> > > Cheers, > > >> > > Daniel > > >> > > ___ > > >> > > wayland-devel mailing list > > >> > > wayland-devel@lists.freedesktop.org > > >> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > >> > > > > >> > > > >> > HI
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Fri, 23 Nov 2018 13:07:37 + Tomek Bury wrote: > Hi Alexandros, > > Sorry for a delay. I've finally got an end-to-end system to test it out. It > took some time because Weston backend I wrote a while back needed serious > rework to catch up with latest changes. > > There's one thing that didn't work for me. In compositor you reject > anything that isn't a DMA buffer and then in glrenderer you put an extra > assertion. Why? All you do is use an EGL extension in order to import > external fence_fd. There's no dmabuf dependency there. As long as the EGL > implementation exposes EGL_SYNC_NATIVE_FENCE_ANDROID extension this should > "just work" (tm) for the GL renderer. It certainly did for me. CPU-based > renderers can poll() to wait. Hi Tomek, with Weston it was decided not to implement a poll() based wait at first as implementing that properly (not blocking the compositor) would be a big hassle and no-one could see the benefit of it given what clients could actually produce. Therefore the acquire fence can only apply to buffers which can be pipelined to a GPU. Mesa EGL is using zwp_linux_dmabuf, but the support could be extended to opaque EGL buffers very well. We just chose to start small and bring up the infrastructure around fences first. Restrictions on buffer types etc. can certainly be lifted in the future if there are good use cases. I presume you have a driver stack that relies on the opaque EGL buffers and not zwp_linux_dmabuf any time soon? Would anyone ever use an acquire fence with wl_shm buffers? That sounds fundamentally wrong to me as one cannot create fences to be signalled by userspace AFAIK. Therefore buffers whose wait cannot be pipelined to the GPU or the display device do not make much sense to me. > The type of buffer used is an orthogonal problem. The > EGL_WL_bind_wayland_display > extension takes care of GL clients' buffers in GL renderer, for anything > else the renderer needs to know how to get pixels and use whatever means to > put those pixels on screen. Yeah, support for opaque EGL buffers could be added, just need to think of a good wording, since acquire fences do not make sense for all buffer types. A compositor must be allowed to raise protocol errors for fence+buffer combinations it cannot use, which means that clients must know in advance what they cannot use. Thanks, pq > On Tue, 13 Nov 2018 at 09:33, Tomek Bury wrote: > > > Thanks! > > > > On Tue, Nov 13, 2018 at 9:08 AM Alexandros Frantzis < > > alexandros.frant...@collabora.com> wrote: > > > >> On Mon, Nov 12, 2018 at 12:39:58PM +, Tomek Bury wrote: > >> > On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone > >> wrote: > >> > > >> > > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen > >> wrote: > >> > > > I can add that while pushing upstream, if there are no other changes > >> > > > coming. > >> > > > > >> > > > Reviewed-by: Pekka Paalanen > >> > > > > >> > > > You have ensured that the C files generated from this revision build > >> > > > fine in Weston, right? > >> > > > > >> > > > David, Daniel, since your name is in the maintainers, can I have > >> your > >> > > > R-b, please? > >> > > > >> > > The protocol is: > >> > > Reviewed-by: Daniel Stone > >> > > > >> > > The Weston implementation looks pretty good so far, though there's no > >> > > full implementation of release yet. > >> > > > >> > > Cheers, > >> > > Daniel > >> > > ___ > >> > > wayland-devel mailing list > >> > > wayland-devel@lists.freedesktop.org > >> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > >> > > > >> > > >> > HI Daniel, > >> > > >> > Where can I find the work-in-progress implementation? I'd like to try it > >> > out with Broadcom driver which doesn't have implicit cross-process > >> sync. I > >> > can add the explicit sync protocol implementation on the driver side but > >> > I'd need a reference to test it against. > >> > > >> > Cheers, > >> > Tomek > >> > >> Hi Tomek, > >> > >> the WIP implementation can be found here [1]. I hope to push an update, > >> including some zwp_buffer_release_v1 correctness fixes, in the following > >> days. > >> > >> Thanks, > >> Alexandros > >> > >> [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 > >> > > pgpDgo_NXdONY.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
Hi Alexandros, Sorry for a delay. I've finally got an end-to-end system to test it out. It took some time because Weston backend I wrote a while back needed serious rework to catch up with latest changes. There's one thing that didn't work for me. In compositor you reject anything that isn't a DMA buffer and then in glrenderer you put an extra assertion. Why? All you do is use an EGL extension in order to import external fence_fd. There's no dmabuf dependency there. As long as the EGL implementation exposes EGL_SYNC_NATIVE_FENCE_ANDROID extension this should "just work" (tm) for the GL renderer. It certainly did for me. CPU-based renderers can poll() to wait. The type of buffer used is an orthogonal problem. The EGL_WL_bind_wayland_display extension takes care of GL clients' buffers in GL renderer, for anything else the renderer needs to know how to get pixels and use whatever means to put those pixels on screen. Cheers, Tomek On Tue, 13 Nov 2018 at 09:33, Tomek Bury wrote: > Thanks! > > On Tue, Nov 13, 2018 at 9:08 AM Alexandros Frantzis < > alexandros.frant...@collabora.com> wrote: > >> On Mon, Nov 12, 2018 at 12:39:58PM +, Tomek Bury wrote: >> > On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone >> wrote: >> > >> > > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen >> wrote: >> > > > I can add that while pushing upstream, if there are no other changes >> > > > coming. >> > > > >> > > > Reviewed-by: Pekka Paalanen >> > > > >> > > > You have ensured that the C files generated from this revision build >> > > > fine in Weston, right? >> > > > >> > > > David, Daniel, since your name is in the maintainers, can I have >> your >> > > > R-b, please? >> > > >> > > The protocol is: >> > > Reviewed-by: Daniel Stone >> > > >> > > The Weston implementation looks pretty good so far, though there's no >> > > full implementation of release yet. >> > > >> > > Cheers, >> > > Daniel >> > > ___ >> > > wayland-devel mailing list >> > > wayland-devel@lists.freedesktop.org >> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > > >> > >> > HI Daniel, >> > >> > Where can I find the work-in-progress implementation? I'd like to try it >> > out with Broadcom driver which doesn't have implicit cross-process >> sync. I >> > can add the explicit sync protocol implementation on the driver side but >> > I'd need a reference to test it against. >> > >> > Cheers, >> > Tomek >> >> Hi Tomek, >> >> the WIP implementation can be found here [1]. I hope to push an update, >> including some zwp_buffer_release_v1 correctness fixes, in the following >> days. >> >> Thanks, >> Alexandros >> >> [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 >> > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: question about drm backend
On Fri, 23 Nov 2018 20:12:53 +0800 zou lan wrote: > Hi pekka > > I check the atomic commit part of the drm backend in weston 5.0. But I am > not sure if some vendors support one atomic commit to update many CRTCs, so Hi Nancy, in my opinion vendors really should support it. If they don't, it leaves one of the big benefits of atomic modesetting unimplemented: the ability to change multiple CRTC-connector-routings reliably. Therefore I would not want Weston to encourage the use of half-made atomic drivers. > I was wondering > if one output repaint to do one atomic commit would match the weston 5.0's > architecture if they don't support it. I think the answer it's yes, is it > right? Currently Weston does not enable atomic modesetting at all without DRM_CAP_CRTC_IN_VBLANK_EVENT. Could that be used as a flag to see if the driver can accept multi-CRTC atomic commits, or do we need to TEST_ONLY? The Linux commit 5db06a8a98f515f67446a69c57577c4c363ec65d only talks about a field being set correctly, it does not imply that the flag could be used to detect multi-CRTC commit support. Is an atomic driver that doesn't support multi-CRTC atomic commits even a thing, Daniel? > I also have another question about the function > output_repaint_timer_arm() in compositor.c, about the following comment: > /* Even if we should repaint immediately, add the minimum 1 ms delay. > * This is a workaround to allow coalescing multiple output repaints > * particularly from weston_output_finish_frame() > * into the same call, which would not happen if we called > * output_repaint_timer_handler() directly. > */ > If the vendor doesn't support commit multi outputs together, does this > increase the latency for next repaint? The latency could be larger than 1ms > if the timer event can't be > triggered immediately. It shouldn't. If one was to implement strict per-output atomic commits, it shouldn't involve re-arming the timer for each output to be repainted on the same cycle. > > If the outputs' refresh rate is not the same, is there any problem to > repaint multi outputs together? No. If the vblanks of the outputs do not coincide, then they are not put into the same repaint_begin/flush cycle. This is decided separately every time in output_repaint_timer_handler(). Each output will always repaint according to its own timings independently, but if multiple outputs happen to be ready at roughly the same time, they get into the same atomic commit. weston_output_maybe_repaint() decides if the output gets into the atomic commit right now or not. Only in rare occasions, like compositor start-up, will all outputs be forced into the same atomic commit regardless of their timings. This is used to e.g. make the CRTC-connector-routing changes reliable. Thanks, pq pgpu9_dipIyCN.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: question about drm backend
Hi pekka I check the atomic commit part of the drm backend in weston 5.0. But I am not sure if some vendors support one atomic commit to update many CRTCs, so I was wondering if one output repaint to do one atomic commit would match the weston 5.0's architecture if they don't support it. I think the answer it's yes, is it right? I also have another question about the function output_repaint_timer_arm() in compositor.c, about the following comment: /* Even if we should repaint immediately, add the minimum 1 ms delay. * This is a workaround to allow coalescing multiple output repaints * particularly from weston_output_finish_frame() * into the same call, which would not happen if we called * output_repaint_timer_handler() directly. */ If the vendor doesn't support commit multi outputs together, does this increase the latency for next repaint? The latency could be larger than 1ms if the timer event can't be triggered immediately. If the outputs' refresh rate is not the same, is there any problem to repaint multi outputs together? Thank you! Best Regards Nancy Pekka Paalanen 于2018年11月23日周五 下午6:00写道： > On Fri, 23 Nov 2018 16:22:56 +0800 > zou lan wrote: > > > Hi pekka > > > > >>do you mean users as humans or as apps? > > yes. I mean the apps. I think it's no big impact for apps. The major > > changes for weston new version is focus on libweston/drm backend. > > Hi Nancy, > > Weston and any compositor is always bound by the Wayland protocol > stability promises. The only thing where a compositor implementation > can use its own judgement is which globals it will advertise and will > it implement new versions of existing interfaces. (New versions of > interfaces as denoted by the "version" attribute in the XML are > required to be backwards-compatible.) > > So the only things you need to watch out for are: > - did the compositor stop advertising some global interface > - do you have a client that requires a global interface the compositor > has never supported yet > - do you have a client that requires a certain minimum version of an > interface that the compositor does not support yet > > > I still want to ask something about drm backend. About on_drm_input() > > function in compositor-drm.c, do this function plan to listen all CRTCs' > > pageflip/vblank event or only listen > > one primary CRTC's pageflip/vblank event? I think the repaint_flush() > want > > to do AtomicCommit for all crtcs one time, does it support commit for > each > > output just like the old > > drm backend design in weston 5.0 or latest weston architecture? > > A repaint_flush() call will do an atomic commit involving any number of > outputs (CRTCs). Which outputs happen to be included depends on the > timings of each individual output. It can and will vary on each atomic > commit. > > on_drm_input() handles all DRM events. Depending on libdrm and kernel > support, it can dispatch to page_flip_handler() or > atomic_flip_handler(). > > page_flip_handler() is only used on legacy KMS, which means it will > process an event for each drmModePageFlip() call. That is naturally per > CRTC. > > atomic_flip_handler() is only for atomic commits and will also get > called per CRTC by the kernel, not per atomic commit as a whole, and it > carries the CRTC id as an argument. It does not get called for a > TEST_ONLY atomic commit. > > Since someone probably will be hacking around in downstream, I'd would > like to offer a warning. Whatever you do, do not ever add new calls to > drmModeAtomicCommit or call anything that synchronously calls atomic > commit or the legacy KMS functions. The architecture is designed around > first collecting all the state an atomic commit needs, building the > commit, testing it first, and if the test succeeds, only then firing > the real commit. So if you want to control some new property or you > want to turn off a monitor or anything, you have to make that new thing > part of the state machinery and let the state machinery commit it for > you. Anything else will quickly spiral into an unfixable mess. > > It was a huge effort to get rid of the "immediate" libdrm KMS calls and > replace them with the atomic state machine. I recall that temporary > video mode switching and maybe even DPMS might still be not quite there > yet, because their original internal API fit really badly into the > atomic design. > > > Thanks, > pq > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: question about drm backend
On Fri, 23 Nov 2018 16:22:56 +0800 zou lan wrote: > Hi pekka > > >>do you mean users as humans or as apps? > yes. I mean the apps. I think it's no big impact for apps. The major > changes for weston new version is focus on libweston/drm backend. Hi Nancy, Weston and any compositor is always bound by the Wayland protocol stability promises. The only thing where a compositor implementation can use its own judgement is which globals it will advertise and will it implement new versions of existing interfaces. (New versions of interfaces as denoted by the "version" attribute in the XML are required to be backwards-compatible.) So the only things you need to watch out for are: - did the compositor stop advertising some global interface - do you have a client that requires a global interface the compositor has never supported yet - do you have a client that requires a certain minimum version of an interface that the compositor does not support yet > I still want to ask something about drm backend. About on_drm_input() > function in compositor-drm.c, do this function plan to listen all CRTCs' > pageflip/vblank event or only listen > one primary CRTC's pageflip/vblank event? I think the repaint_flush() want > to do AtomicCommit for all crtcs one time, does it support commit for each > output just like the old > drm backend design in weston 5.0 or latest weston architecture? A repaint_flush() call will do an atomic commit involving any number of outputs (CRTCs). Which outputs happen to be included depends on the timings of each individual output. It can and will vary on each atomic commit. on_drm_input() handles all DRM events. Depending on libdrm and kernel support, it can dispatch to page_flip_handler() or atomic_flip_handler(). page_flip_handler() is only used on legacy KMS, which means it will process an event for each drmModePageFlip() call. That is naturally per CRTC. atomic_flip_handler() is only for atomic commits and will also get called per CRTC by the kernel, not per atomic commit as a whole, and it carries the CRTC id as an argument. It does not get called for a TEST_ONLY atomic commit. Since someone probably will be hacking around in downstream, I'd would like to offer a warning. Whatever you do, do not ever add new calls to drmModeAtomicCommit or call anything that synchronously calls atomic commit or the legacy KMS functions. The architecture is designed around first collecting all the state an atomic commit needs, building the commit, testing it first, and if the test succeeds, only then firing the real commit. So if you want to control some new property or you want to turn off a monitor or anything, you have to make that new thing part of the state machinery and let the state machinery commit it for you. Anything else will quickly spiral into an unfixable mess. It was a huge effort to get rid of the "immediate" libdrm KMS calls and replace them with the atomic state machine. I recall that temporary video mode switching and maybe even DPMS might still be not quite there yet, because their original internal API fit really badly into the atomic design. Thanks, pq pgp2SMDq55eEW.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: question about drm backend
Hi pekka >>do you mean users as humans or as apps? yes. I mean the apps. I think it's no big impact for apps. The major changes for weston new version is focus on libweston/drm backend. I still want to ask something about drm backend. About on_drm_input() function in compositor-drm.c, do this function plan to listen all CRTCs' pageflip/vblank event or only listen one primary CRTC's pageflip/vblank event? I think the repaint_flush() want to do AtomicCommit for all crtcs one time, does it support commit for each output just like the old drm backend design in weston 5.0 or latest weston architecture? Thank you! Best Regards Nancy Pekka Paalanen 于2018年11月20日周二 下午10:43写道： > On Tue, 20 Nov 2018 20:32:53 +0800 > zou lan wrote: > > > Hi pekka > > > > Thank you so much to explain the drm backend details. I ask these because > > some company may implement their own drm backend, changes on interfaces > > between libweston > > and drm backend may increase the merge effort. > > > > Could I also ask is weston backward compatible from weston 2.0 to weston > > 5.0 from users. According to my study, I think there is no big impacts > for > > users, is it right? > > Hi Nancy, > > do you mean users as humans or as apps? There may have been some > changes in the command line options and weston.ini, but I think they > have generally been fairly stable. The biggest impact on app support > was probably the xdg-shell v5 era and the eventual removal of it. > > I can't really remember even 5.0 release, but I would hope the notable > changes would have been mentioned in the release announcements. > > Oh, removal of the Raspberry Pi backend, and removal of EGL support > from the fbdev-backend come to mind. I'm not actually sure if those > were before or after 2.0, it was so long ago. > > > Will AGL adopt the weston 5.0 or other weston version in their new AGL > > version sunch as AGL 7.0? > > I haven't followed AGL, so I don't know, nor do I participate there > currently. > > > Thanks, > pq > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
