Introduction and updates from NVIDIA

Daniel Stone daniel at
Tue May 3 16:58:02 UTC 2016

Hi James,

On 3 May 2016 at 17:29, James Jones <jajones at> 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.

> , 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 don't see how GBM could really perform any worse in such a design.


More information about the wayland-devel mailing list