[email protected] wrote: [CC'ing Daniel and Pekka who definitely know more about this stuff than me]
> > Differently from Žan's WebkitForWayland approach where he just need > > to export the handle for the final surface buffer to the WebProcess > > which would then use it as a GL render target, we need to be able > > to use the layer buffers as GL render targets in the WebProcess and > > as textures in the UIProcess. > > The rendering target is actually set up in the WebProcess, simply by > creating a gbm_surface object and using that as the native window for > the EGLSurface.[1] Ah, thanks for clearing up my confusion. :D > After the rendering and the buffer swap call, the front buffer is > locked and the information about the returned gbm_bo object is passed > to the UIProcess. > There the buffer object is imported and used as appropriate for the > backend that's been chosen.[2][3] > > > Exporting textures from the UIProcess as dmabufs and use them as > > render targets in the WebProcess is not guaranteed to work in a > > efficient manner, as the GL implementation may want to reallocate > > the storage when it wants to, e.g. to win parallelism, but export > > would prevent that. > > I guess this would still apply even with the previous clarification. > Not familiar with this though, so I honestly can't give you a > definitive answer whether the wk4wl approach falters here. > > > Also using dmabufs directly means that we should have really low- > > level per-platform knowledge as they are created with driver- > > specific ioclts. > > I don't agree. The GBM API abstracts this well enough. I see. I've been told that directly using GBM buffers may still face some subtle issues: for instance, since the display controller is often allocating out of a fixed pool, we might end up exhausting quite limited memory, and since the controller is usually more restrictive in terms of the formats it can accept, compression, memory location and other parameters if we reuse stuff from the GPU we may end up with suboptimal configurations that cause extra copies. Some implementations may even fail to allocate GBM buffers if the DRM device is not a master device, which I presume is the case for the WebProcess. Re-using the Wayland mechanisms would mean that we are guaranteed that someone else already had to deal with all these subtly annoying, hardware-specific details. :P > This is how the nested compositor implementation worked before, even > if the work was never fully finished. Compared to using the GBM > platform for rendering in the WebProcess, this approach is proven to > work for the GTK+ port. Whether it works efficiently is debatable (it > certainly wasn't efficient a few years back). What where the issues you encountered? I'm sure that dealing with two IPC mechanism will be a pain, but I fear that by going our own route may be even more painful. Do you have a pointer to the old nested compositor implementation? > Skimming the eglCreateWaylandBufferFromImageWL implementation in > Mesa, it appears this would use a dma-buf buffer wherever available > anyway. [4] I see. > > Do you see any issue with the described scenario or do you believe > > there are more simple way to accomplish this? > > As I outlined above, personally I am not that supportive of the > nested compositor approach. What's the most annoying issue you can see with the nested compositor approach? Is "just" the the introduction of another IPC mechanism? > But beyond choosing the best way to implement this, the bigger > problem is likely how to use the composition results with the > GTK+ toolkit. Wouldn't using a GdkGLContext canvas provide a satisfying answer to that? In the future the GTK+ scene graph would even provide the ability to pass through buffers straight to the main compositor to eg. have zero- copy video playback without compromising widget stacking (just like AC works in WebKit), but that's a relatively orthogonal development. > [1] > https://github.com/WebKitForWayland/webkit/blob/master/Source/WPE/Source/Graphics/GBM/RenderingBackendGBM.cpp > [2] > https://github.com/WebKitForWayland/webkit/blob/master/Source/WPE/Source/ViewBackend/DRM/ViewBackendDRM.cpp > [3] > https://github.com/WebKitForWayland/webkit/blob/master/Source/WPE/Source/ViewBackend/Wayland/ViewBackendWayland.cpp > [4] > http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_wayland.c#n765 Thanks! -- Emanuele Aina www.collabora.com _______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
