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 <dan...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel