<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Pekka,</div><div><br></div>> I presume you have a driver stack that relies on the opaque EGL buffers and not zwp_linux_dmabuf any time soon?<br><div>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.</div><div><br></div><div>> 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.</div><div>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.</div><div><br></div><div>Cheers,<br></div><div>Tomek</div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 23 Nov 2018 at 13:47, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 23 Nov 2018 13:07:37 +0000<br>
Tomek Bury <<a href="mailto:tomek.bury@gmail.com" target="_blank">tomek.bury@gmail.com</a>> wrote:<br>
<br>
> Hi Alexandros,<br>
> <br>
> Sorry for a delay. I've finally got an end-to-end system to test it out. It<br>
> took some time because Weston backend I wrote a while back needed serious<br>
> rework to catch up with latest changes.<br>
> <br>
> There's one thing that didn't work for me. In compositor you reject<br>
> anything that isn't a DMA buffer and then in glrenderer you put an extra<br>
> assertion. Why? All you do is use an EGL extension in order to import<br>
> external fence_fd. There's no dmabuf dependency there. As long as the EGL<br>
> implementation exposes EGL_SYNC_NATIVE_FENCE_ANDROID extension this should<br>
> "just work" (tm) for the GL renderer. It certainly did for me. CPU-based<br>
> renderers can poll() to wait.<br>
<br>
Hi Tomek,<br>
<br>
with Weston it was decided not to implement a poll() based wait at<br>
first as implementing that properly (not blocking the compositor) would<br>
be a big hassle and no-one could see the benefit of it given what<br>
clients could actually produce.<br>
<br>
Therefore the acquire fence can only apply to buffers which can be<br>
pipelined to a GPU. Mesa EGL is using zwp_linux_dmabuf, but the support<br>
could be extended to opaque EGL buffers very well. We just chose to<br>
start small and bring up the infrastructure around fences first.<br>
<br>
Restrictions on buffer types etc. can certainly be lifted in the future<br>
if there are good use cases. I presume you have a driver stack that<br>
relies on the opaque EGL buffers and not zwp_linux_dmabuf any time soon?<br>
<br>
Would anyone ever use an acquire fence with wl_shm buffers? That sounds<br>
fundamentally wrong to me as one cannot create fences to be signalled<br>
by userspace AFAIK. Therefore buffers whose wait cannot be pipelined to<br>
the GPU or the display device do not make much sense to me.<br>
<br>
> The type of buffer used is an orthogonal problem. The<br>
> EGL_WL_bind_wayland_display<br>
> extension takes care of GL clients' buffers in GL renderer, for anything<br>
> else the renderer needs to know how to get pixels and use whatever means to<br>
> put those pixels on screen.<br>
<br>
Yeah, support for opaque EGL buffers could be added, just need to think<br>
of a good wording, since acquire fences do not make sense for all<br>
buffer types. A compositor must be allowed to raise protocol errors for<br>
fence+buffer combinations it cannot use, which means that clients must<br>
know in advance what they cannot use.<br>
<br>
<br>
Thanks,<br>
pq<br>
<br>
> On Tue, 13 Nov 2018 at 09:33, Tomek Bury <<a href="mailto:tomek.bury@gmail.com" target="_blank">tomek.bury@gmail.com</a>> wrote:<br>
> <br>
> > Thanks!<br>
> ><br>
> > On Tue, Nov 13, 2018 at 9:08 AM Alexandros Frantzis <  <br>
> > <a href="mailto:alexandros.frantzis@collabora.com" target="_blank">alexandros.frantzis@collabora.com</a>> wrote:  <br>
> >  <br>
> >> On Mon, Nov 12, 2018 at 12:39:58PM +0000, Tomek Bury wrote:  <br>
> >> > On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone <<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>>  <br>
> >> wrote:  <br>
> >> >  <br>
> >> > > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>>  <br>
> >> wrote:  <br>
> >> > > > I can add that while pushing upstream, if there are no other changes<br>
> >> > > > coming.<br>
> >> > > ><br>
> >> > > > Reviewed-by: Pekka Paalanen <<a href="mailto:pekka.paalanen@collabora.co.uk" target="_blank">pekka.paalanen@collabora.co.uk</a>><br>
> >> > > ><br>
> >> > > > You have ensured that the C files generated from this revision build<br>
> >> > > > fine in Weston, right?<br>
> >> > > ><br>
> >> > > > David, Daniel, since your name is in the maintainers, can I have  <br>
> >> your  <br>
> >> > > > R-b, please?  <br>
> >> > ><br>
> >> > > The protocol is:<br>
> >> > > Reviewed-by: Daniel Stone <<a href="mailto:daniels@collabora.com" target="_blank">daniels@collabora.com</a>><br>
> >> > ><br>
> >> > > The Weston implementation looks pretty good so far, though there's no<br>
> >> > > full implementation of release yet.<br>
> >> > ><br>
> >> > > Cheers,<br>
> >> > > Daniel<br>
> >> > > _______________________________________________<br>
> >> > > wayland-devel mailing list<br>
> >> > > <a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
> >> > > <a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
> >> > >  <br>
> >> ><br>
> >> > HI Daniel,<br>
> >> ><br>
> >> > Where can I find the work-in-progress implementation? I'd like to try it<br>
> >> > out with Broadcom driver which doesn't have implicit cross-process  <br>
> >> sync. I  <br>
> >> > can add the explicit sync protocol implementation on the driver side but<br>
> >> > I'd need a reference to test it against.<br>
> >> ><br>
> >> > Cheers,<br>
> >> > Tomek  <br>
> >><br>
> >> Hi Tomek,<br>
> >><br>
> >> the WIP implementation can be found here [1]. I hope to push an update,<br>
> >> including some zwp_buffer_release_v1 correctness fixes, in the following<br>
> >> days.<br>
> >><br>
> >> Thanks,<br>
> >> Alexandros<br>
> >><br>
> >> [1] <a href="https://gitlab.freedesktop.org/wayland/weston/merge_requests/32" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/wayland/weston/merge_requests/32</a><br>
> >>  <br>
> >  <br>
<br>
</blockquote></div>