Introduction and updates from NVIDIA

[Daniel Vetter]

On Thu, Mar 24, 2016 at 10:06:04AM -0700, Andy Ritger wrote:
> 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.

Android agrees with that and stuffs all these decisions into hwc. And I
agree that there's cases with combinations of display block, 2d engined
and 3d engine where that full-system overview is definitely necessary. But
OpenGL still doesn't look like the right place to me. Something in-between
everything else, like hwc+gralloc on android (which has its own issues)
makes a lot more sense imo in a world where you can combine things widly.

I do believe though that with just kms + sensible heuristics to allocate
surfaces to hw planes + some semi-clever fallback mechanism/hints (which
is what we currently lack) it should be possible to pull something off
without special-case vendor magic in hwc for every combination. That's
purely a conjecture though on my part, otoh no one has ever really tried
all that hard yet.

> 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?

That's essentially the hwc interface, except much less powerful (since you
have no influence on the surface->plane assignment). I think it would be
better to add hwc support to weston (there's other people asking for
that), instead of inventing a new wheel. Also, hwc and upstream atomic
seem to be converging in some of the semantic details if my gossip sources
are correct ;-)

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