Introduction and updates from NVIDIA

[James Jones]

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.

Thanks,
-James

> Cheers,
> Daniel
>