On 05/03/2016 09:58 AM, Daniel Stone wrote:
Hi James,
On 3 May 2016 at 17:29, James Jones <[email protected]> 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.
Thanks,
-James
Cheers,
Daniel
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
