Introduction and updates from NVIDIA

[Andy Ritger]

On Wed, Mar 23, 2016 at 11:48:01AM +0100, Daniel Vetter wrote:
> 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.

eglstreams or gbm or any other implementation aside, is it always _only_
the KMS driver that knows what the optimal configuration would be?
It seems like part of the decision could require knowledge of the graphics
hardware, which presumably the OpenGL/EGL driver is best positioned
to have.

For that aspect: would it be reasonable to execute hardware-specific
driver code in the drmModeAtomicCommit() call chain between the
application calling libdrm to make the atomic update, and the ioctl
into the kernel?  Maybe that would be a call to libgbm that dispatches to
the hardware-specific gbm backend.  However it is structured, having
hardware-specific graphics driver code execute as part of the flip
request might be one way let the graphics driver piece and the display
driver piece coordinate on hardware specifics, without polluting the
application-facing API with hardware-specifics?


> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch