On Tue, May 3, 2016 at 11:58 AM, James Jones <jajo...@nvidia.com> wrote: > On 05/03/2016 09:58 AM, Daniel Stone wrote: >> >> Hi James, >> >> On 3 May 2016 at 17:29, James Jones <jajo...@nvidia.com> wrote: >>> >>> Given Wayland is designed such that clients drive buffer allocation >> >> >> I'd just note that this isn't strictly true. I've personally >> implemented Wayland support for platforms (media playback on an >> extremely idiosyncratic platform) where server-side buffer allocation >> was required for optimal performance, and that's what was done. wl_drm >> is not exemplary for these platforms as it does not have a protocol >> concept of a swapchain, but you can add one to your own private >> protocol implementation (analagous to wl_eglstream) and it works with >> no changes required to external clients or compositors. > > > Indeed, streams blur this a bit as well. What I meant to way is that > clients drive the timing of when new buffers are available for compositing. > Perhaps the server could perform a non-destructive reallocation to avoid > this though if the cost of such an operation were not considered > prohibitive? > >>> , and I >>> tend to agree that the compositor (along with its access to drivers like >>> KMS) is the component uniquely able to optimize the scene, I think the >>> best >>> that can be achieved is a system that gravitates toward the optimal >>> solution >>> in the steady state. Therefore, it seems that KMS should optimize >>> display >>> engine resources assuming the Wayland compositor and its clients will >>> adjust >>> to meet KMS' suggestions over time, where "time" would hopefully be only >>> a >>> small number of additional frames. Streams will perform quite well in >>> such a >>> design. >> >> >> It is unfortunate that you seem to discuss 'Streams' as an abstract >> concept of a cross-process swapchain which can be infinitely adjusted >> to achieve perfection, and yet 'GBM' gets discussed as a singular >> fixed-in-time thing which has all the flaws of just one of its >> particular platform implementations. > > > I have a stronger understanding of the design direction for streams than I > do for GBM, and EGLStream is indeed intended to evolve towards the best > abstraction of a swapchain possible. My views of GBM are based on the > current API. I'm not that familiar with the Mesa implementation details. > I'd be happy to learn more about the direction the GBM API is taking in the > future, and that's half of what I was attempting to do in my > responses/questions here. > >> I don't see how GBM could really perform any worse in such a design. > > > The current GBM API is not expressive enough to support optimal buffer > allocation (at least on our hardware) in such a design.
I'm curious about the performance concern. What exactly is missing? Kristian _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
