<div dir="ltr"><div dir="ltr"><div dir="ltr"><div> </div></div><div dir="ltr">Hi Pekka,<div> </div><div>> I suppose that applies to the opaque EGL buffers only?</div><div>Sort of. As far as I understand it, the divide is between wl_surface managed by EGL/WSI vs. wl_surface managed directly by the client application. For EGL case the wl_surface managed by EGL would be set-up more or less like this:</div><div>struct wl_egl_window *window = wl_egl_window_create(surface, w, h);</div><div>EGLDisplay dpy = eglGetPlatformDisplay(EGL_PLATFORM_WAYLAND_EXT, ...);</div><div>EGLSurface surface = eglCreatePlatformWindowSurface(dpy, config, window);</div><div>With this setup EGL becomes responsible for managing the swapchain buffers, keeping up with window resizes, sending wl_buffers to compositor when client app calls eglSwapBuffers() etc. This is how weston-simple-egl works.</div><div> > Otherwise, a client could use e.g. EGL in a different way to get dmabuf, > send those manually to the compositor and set up fences manually as > well. weston-simple-dmabuf-egl in the MR is one variant of that. Of > course, it depends on the EGL stack supporting dmabuf to begin with, so > if yours doesn't then it's not possible.</div><div>Yes, exactly. This is the example where the application manages the Wayland window directly and the EGL driver is not involved. EGL is only used to set up rendering into an off-screen buffer(s) of some description.</div><div> </div><div>In both cases the compositor receives a wl_buffer and has to figure out how to render the contents of such buffer. In both cases the wl_buffer could encapsulate dma-buf and the compositor wouldn't be able to tell whether it came directly from application (weston-simple-dmabuf-egl) or from the EGL driver (weston-simple-egl). in fact the Waylad client could choose dma-buf, prime, flink, shm, something else, regardless of how the wl_surface is managed, whether it's done directly by the application, by the EGL or Vulkan driver. And some of those wl_buffer types will be known to the compositor, some to the 3D driver and perhaps some to both. At least that's my understanding. </div><div> </div><div>Cheers,</div><div>Tomek</div><div> </div><div> </div><div> </div><div> </div></div></div></div> <div class="gmail_quote"><div dir="ltr">On Tue, 27 Nov 2018 at 08:53, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 26 Nov 2018 15:14:45 +0000 Tomek Bury <<a href="mailto:tomek.bury@gmail.com" target="_blank">tomek.bury@gmail.com</a>> wrote: > Hi Pekka, > > Yes, sorry, I was writing specifically about Weston implementation. In the > merge request from Alexandros the actual compatibility check is in the main > compositor, while compositor doesn't have enough information to decide > whether the selected renderer can handle buffer+fence combination or not. > > As for the opaque wl_buffer, that's an internal implementation detail of > Vulkan WSI or EGL so different drivers can choose to do different things > here. It's the 3D driver, and *NOT* the client application, that creates > those buffers and sends attach/damage/commit sequence to the compositor. > The 3D driver makes a decision what type of buffer to use, an EGL or Vulkan > client application doesn't have any means of accessing wl_buffer objects, > it's all hidden away. Hi Tomek, I suppose that applies to the opaque EGL buffers only? Otherwise, a client could use e.g. EGL in a different way to get dmabuf, send those manually to the compositor and set up fences manually as well. weston-simple-dmabuf-egl in the MR is one variant of that. Of course, it depends on the EGL stack supporting dmabuf to begin with, so if yours doesn't then it's not possible. However, in the fence protocol extension specification we must take all possible use cases into account. The client side of the fence extension is not exclusive to EGL implementations, and the server side is even less, because the server side implementation cannot be an EGL implementation detail. This is why I'm talking about protocol spec - the Weston implementation just reflects the spec, or at least attempts to. > On the compositor side buffers are received through one of the protocol > extensions you've mentioned. The compositor has a choice to make. It can > either probe the wl_buffer for known buffer types or leave that task to the > EGL implementation. Let's say a client-side driver uses dma-buf buffers for > its swapchain images. If the compositor knows how to handle dma-buf, it can > either directly access those buffers or it can hand them over to the > compositor-side 3D driver through > eglCreateImage(dpy, EGL_LINUX_DMA_BUF_EXT, ...). If the compositor doesn't > know the particular type of buffer, it can check if EGL can handle it > either through eglCreateImage(dpy, EGL_WAYLAND_BUFFER_WL, ...) or > eglQueryWaylandBufferWL(...). > If the client and compositor use the same 3D driver (that's the most likely > scenario) this is bound to work. In multiple-GPU configurations your > mileage may vary though. Right. A wl_buffer can be used with either EGL_WAYLAND_BUFFER_WL or as a dmabuf via EGL_LINUX_DMA_BUF, but there is no choice for a compositor to make as at most only one these can work for a given wl_buffer. > If the EGL implementation can use the type of the wl_buffer and can import > the fence fd, you're home. Having said that, I can't think of a way of > figuring out ahead of time what type of wl_buffer the client-side driver is > going to use for its swapchain and whether this particular type will be > accepted by the compositor-side driver. There is no need for the compositor to know in advance. Instead, the client must know what the compositor supports, since the client is making the decisions on buffer allocation etc. (or the decision to use EGL or Vulkan and not care about buffers explicitly, in which case the EGL/WSI implementation must know). The opaque EGL buffers already rely on using the same EGL implementation on both compositor and client, so if a compositor also exposes the fence extension, the client-side EGL implementation can be sure it can use the fence extension with the opaque EGL buffers (or if it cannot, the client-side EGL implementation already knows that because it knows the details of the compositor-side EGL implementation). That is, if we write that down in the fence extension spec. I think we should. > This is how I use it at the moment: I've written a custom Weston backend > because the code runs on top of an embedded middleware. My backend always > uses GL renderer. The GL renderer has to call eglBindWaylandDisplayWL() at > startup, and the implementation of that API in the 3D driver adds a custom > Wayland protocol extension for sharing buffers. Now the scene is set. When > a Wayland client application starts, the EGL or Vulkan WSI implementation > driver goes for that extension and bails out if unavailable. This way > swapchain buffers from EGL and Vulkan client can be used by Weston's GL > renderer without any knowledge of the embedded platform details. Yup, that is how the "opaque EGL buffer" type is supposed to work. > With regards to using fences directly by the client app, I guess it's the > same principle as drawing into the window. Either client app does > everything "by hand" or lets the Vulkan or EGL/GLES do it. If the app is in > charge, the app manages the window swap chain buffers and synchronization, > otherwise the 3D driver does it. You shouldn't allow more than one thing > managing the Wayland window at the same time. Perhaps you could use wording > similar to Vulkan WSI or EGL window surface when describing what is and > what isn't allowed when it comes to Wayland windows. Yes, we probably should have some wording that if a client is letting something like EGL to commit the buffers, it must not attempt to use the fence extension on that wl_surface itself because EGL will probably be using the extension already. Alf? Thanks, pq > On Mon, 26 Nov 2018 at 09:22, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote: > > > On Fri, 23 Nov 2018 16:26:19 +0000 > > Tomek Bury <<a href="mailto:tomek.bury@gmail.com" target="_blank">tomek.bury@gmail.com</a>> wrote: > > > > > 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. > > > > Hi Tomek, > > > > fences do not make sense to all buffer types to begin with, today. My > > objection is to allowing fencing buffer types that cannot be sent to > > the 3D driver, e.g. wl_shm which is usually copied through glTexImage2D > > and friends. We cannot ignore those in the spec language. > > > > A renderer (a compositor really, we're not talking about just Weston) > > decides what buffer types it accepts, yes. This is communicated to > > clients through which buffer factory interface globals are being > > advertised. Each type is a different protocol extension. The fence > > extension OTOH is just a single extension, and currently there is no > > protocol to negotiate which buffer types are usable with acquire > > fences. The first attempt is to define in the spec language what will > > always be supported, provided the buffer factory exists. > > > > The opaque EGL buffer type is really just one type in practise: > > compositors and clients use it through a well-known, single API: EGL. > > It does not matter that there are multiple incompatible EGL > > implementations, it all looks like just one opaque buffer type to > > compositors. I think this makes it easier to extend the fence spec > > wording to require opaque EGL buffers to be supported. > > > > Either the fence protocol spec needs to be clear on what works, or we > > need advertisement events to let clients know in advance what the > > compositor supports. A client sending a fence that the compositor > > cannot use must not be possible; compositor, client, EGL, driver, etc. > > bugs notwithstanding. > > > > Btw. I just realized that if client-side EGL uses the fence extension > > internally, that means the client app code must not attempt to add or > > request fences of its own, because the spec disallows multiple acquire > > fences and multiple release notification requests. I suppose that's > > fine? > > > > Alf, can you come up with changes to the spec wording and Weston to > > require opaque EGL buffers are supported? > > > > On one hand it is actually a little strange to couple opaque EGL > > buffers (a private, EGL implementation specific protocol interface) > > with a generic fencing extension, but maybe that is necessary because > > there is not enough compositor-side GBM and EGL API so that the EGL > > implementation could handle it all in an EGL implementation specific > > interface? > > > > > > Thanks, > > pq > > > > > On Fri, 23 Nov 2018 at 13:47, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> > > wrote: > > > > > > > On Fri, 23 Nov 2018 13:07:37 +0000 > > > > Tomek Bury <<a href="mailto:tomek.bury@gmail.com" target="_blank">tomek.bury@gmail.com</a>> 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 <<a href="mailto:tomek.bury@gmail.com" target="_blank">tomek.bury@gmail.com</a>> > > wrote: > > > > > > > > > > > Thanks! > > > > > > > > > > > > On Tue, Nov 13, 2018 at 9:08 AM Alexandros Frantzis < > > > > > > <a href="mailto:alexandros.frantzis@collabora.com" target="_blank">alexandros.frantzis@collabora.com</a>> wrote: > > > > > > > > > > > >> On Mon, Nov 12, 2018 at 12:39:58PM +0000, Tomek Bury wrote: > > > > > >> > On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone < > > <a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>> > > > > > > > > > >> wrote: > > > > > >> > > > > > > >> > > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen < > > <a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> > > > > > > > > > >> wrote: > > > > > >> > > > I can add that while pushing upstream, if there are no > > other > > > > changes > > > > > >> > > > coming. > > > > > >> > > > > > > > > >> > > > Reviewed-by: Pekka Paalanen <<a href="mailto:pekka.paalanen@collabora.co.uk" target="_blank">pekka.paalanen@collabora.co.uk</a> > > > > > > > > >> > > > > > > > > >> > > > 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 <<a href="mailto:daniels@collabora.com" target="_blank">daniels@collabora.com</a>> > > > > > >> > > > > > > > >> > > The Weston implementation looks pretty good so far, though > > > > there's no > > > > > >> > > full implementation of release yet. > > > > > >> > > > > > > > >> > > Cheers, > > > > > >> > > Daniel > > > > > >> > > _______________________________________________ > > > > > >> > > wayland-devel mailing list > > > > > >> > > <a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a> > > > > > >> > > <a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> > > > > > >> > > > > > > > >> > > > > > > >> > 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] > > <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> > > > > > >> > > > > > > > > > > > > > > > > > > </blockquote></div>