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