Introduction and updates from NVIDIA

[Kristian Høgsberg]

On Tue, May 3, 2016 at 11:58 AM, James Jones <jajones at nvidia.com> wrote:
> On 05/03/2016 09:58 AM, Daniel Stone wrote:
>>
>> Hi James,
>>
>> On 3 May 2016 at 17:29, James Jones <jajones at 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