Introduction and updates from NVIDIA

[Daniel Vetter]

On Tue, Mar 22, 2016 at 05:33:57PM -0700, Andy Ritger wrote:
> On Tue, Mar 22, 2016 at 09:52:21PM +0000, Daniel Stone wrote:
> > Hi,
> > 
> > On 22 March 2016 at 21:43, Daniel Vetter <daniel at ffwll.ch> wrote:
> > > On Tue, Mar 22, 2016 at 01:49:59PM +0000, Daniel Stone wrote:
> [...]
> > >> I think it's been good to have this series to push the discussion
> > >> further in more concrete terms, but unfortunately I have to say that
> > >> I'm even less convinced now than I have ever been. Sorry.
> > >
> > > Well the thing that irks me is that this isn't aiming to build a common
> > > platform. There's definitely issues with gbm/gralloc+kms+egl in upstream
> > > repos, and vendors have hacked around those in all kinds of horrible ways.
> > > But trying to fix this mess with yet another vendor-private solution just
> > > doesn't help. Instead we need to fix what is there, for everyone, instead
> > > of fragmenting more.
> > 
> > Agreed. One of the things I've been incredibly happy with is how our
> > platform has managed to stay completely generic and vendor-neutral so
> > far, and I'd love to preserve that.
> 
> I don't think you'll find any disagreement to that from NVIDIA, either.
> 
> I apologize if the EGLStreams proposal gave the impression of a
> vendor-private solution.  That wasn't the intent.  The EGLStream family
> of extensions are, after all, an open specification that any EGL vendor
> can implement.  If there are aspects of any of these EGL extensions that
> seem useful, I'd hope that Mesa would we willing to adopt them.
> 
> We (NVIDIA) clearly think EGLStreams is a good direction for expressing
> buffer sharing semantics.  In our ideal world, everyone would implement
> these extensions and Wayland compositors would migrate to using them as
> the generic vendor-neutral mechanism for buffer sharing :)
> 
> But, I'm also happy discuss ways to incrementally improve gbm.  I tried
> to address Daniel (Stone)'s questions about NVIDIA's gbm concerns.  For this:

So I guess the top level issue with eglstreams+kms that at least I see is
that if we really want to do this, we would need to terminate the
eglstream in the kernel. Since with kms really only the kernel knows why
exactly a buffer isn't the right one, and what the producer should change
to get to a more optimal setup.

But the problem is that KMS is ABI and vendor-neutral, which means all
that fancy metadata that you want to attach would need to be standardized
in some way. And we'd need to have in-kernel eglstreams. So you'd face
both the problem of getting a new primitive into upstream (dma-buf took
massive efforts, same for fences going on now). And you'd lose the benefit
of eglstreams being able to encapsulate vendor metadata.

And we need to figure out how to standardize this a bit better even
without eglstreams, so that's why I don't really understand why eglstreams
has benefits. It's clearly a nice concept if your in a world of
one-vendor-only, but that's not what KMS is aiming for really.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch