Hi, On Wed, 2015-12-09 at 17:37 +0100, Emanuele Aina wrote: > [email protected] wrote: > > > 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. > > > > Are all these problems today? How are they addressed in the > > implementation of the Wayland platform in Mesa? I assume they could > > be addressed in a similar way in libgbm. > > Yup, that's what I've been told. Mesa basically punts the problem > down > to the wl_drm API, which is totally considered an internal > implementation detail of Mesa and not exported anywhere. > > The EGL/Wayland APIs at least supposed to be portable, so they may be > even implemented by proprietary driver stacks, while wl_drm is not > meant for that.
Right. wl_drm is a very specific implementation of the Wayland EGL platform. The reason they can be addressed in the Wayland EGL platform and not libgbm is very very simple: Wayland-EGL is a general-purpose platform that is able to adapt to its surroundings. libgbm is not, and very specifically pessimises for one usecase. > > > Is "just" the the introduction of another IPC mechanism? > > > > To paraphrase, you nd up relying on the whole tractor when you just > > need the plow. > > Heh, I totally agree. :/ But I'm not sure having only the plow is > actually workable in the general case for us, as it can be hard to > make > it work without the tractor. > > My point is that the subcompositor route is an apparently safer > choice: > everybody expects it to work in every scenario: once we have in > place, > nothing prevents us from looking at the lower layers and further > streamline the code if it proves workable despite the concerns raised > so far. To be fair, having a nested compositor (not to be confused with the wl_subcompositor interface to allow subsurfaces) is surprisingly little overhead, and the complexity - we feel - is mostly necessary. Cheers, Daniel _______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
