Introduction and updates from NVIDIA

[Daniel Stone]

Hi James,

On 11 May 2016 at 21:43, James Jones <jajones at nvidia.com> wrote:
> On 05/04/2016 08:56 AM, Daniel Stone wrote:
>> Right - but as with the point I was making below, GBM _right now_ is
>> more capable than Streams _right now_. GBM right now would require API
>> additions to match EGLStreams + EGLSwitch + Streams/KMS-interop, but
>> the last two aren't written either, so. (More below.)
>
> The current behavior that enables this, where basically all Wayland buffers
> must be allocated as scanout-capable, isn't reasonable on NVIDIA hardware.
> The requirements for scanout are too onerous.

I think we're talking past each other, so I'd like to pare the
discussion down to these two sentences, and my two resultant points,
for now:

I posit that the Streams proposal you (plural) have put forward is, at
best, no better at meeting these criteria:
  - there is currently no support for direct scanout from client
buffers in Streams, so it must always pessimise towards GPU
composition
  - GBM stacks can obviously do the same: implement a no-op
gbm_bo_import, and have your client always allocate non-scanout
buffers - presto, you've matched Streams

I posit that GBM _can_ match the capability of a hypothetical
EGLStreams/EGLSwitch implementation. Current _implementations_ of GBM
cannot, but I posit that it is not a limitation of the API it exposes,
and unlike Streams, the capability can be plumbed in with no new
external API required.

These seem pretty fundamental, so ... am I missing something? :\ If
so, can you please outline fairly specifically how you think
non-Streams implementations are not capable of meeting the criteria in
your two sentences?

Cheers,
Daniel