On Thu, Apr 2, 2015 at 12:35 AM, Dave Airlie <airl...@gmail.com> wrote: > So nvidia have indicated they would like to use an EGLstreams based > solution to enable wayland on their binary driver stack at some point.
As per their recent XDC talk, they sounded like they had given up on eglstreams for implementing the Wayland protocol and were planning on doing Wayland for real inside their driver. However, it did sound like they were planning on using streams for their "I can't believe it's not GBM" device abstraction. Which are you referring to here? They each come with different issues. > I'm just trying to gauge how people in mesa/wayland feel about this as > a solution, is it a solution looking for a problem, when you have > EGLstreams everything looks like a nail type situation etc For implementing Wayland, I think it's a terrible plan. It would probably work in the same sense that android's NativeWindow abstraction works; it doesn't. I've got a rather lengthy post on how one seemingly subtle design choice makes it impossible to implement Wayland correctly on top of android's abstractions: http://www.jlekstrand.net/jason/projects/wayland/wayland-android/ I haven't seen that particular issue with EGLStreams yet, but that doesn't mean there isn't one and until I see an implementation, I'm going to be skeptical. I could also go on a rant about drivers doing IPC and how it takes fewer lines of code to implement Wayland in a driver than there are lines of EGLStream spec, but I'll leave that to someone else. :-) For interfacing with KMS, I think it's similarly bad. It would work for the basics of "put image on screen" but not for the more complex use-cases. For example, a Wayland compositor wants to be able to grab frames of a client and flip them independantly as planes. How does this work with a stream? Do you get a stream from a wl_surface and then just switch to the driver handling everything and the compositor ignoring it and then switch back? Do you create a stream from a single wl_buffer? Do you have some way that you can take buffers and put them on a stream? It seems very ill-defined. I think (and this is me speculating) is that the reason nvidia wants to use streams is because their binary driver is *very* userspace-heavy. On the other hand, most of the FOSS drivers have substantial kernel components that handle buffer allocation and arbitrate between clients. For a primarily userspace driver, streams makes a lot of sense because it's all hidden in the driver and they can put it wherever they want. For a heavily userspace driver, userspace modesetting in X also makes a lot of sense... > Also if anyone has any idea if any other EGL vendors are heading down > this road, or if this is a one-company extension, ratified to KHR > because nobody objected. I can't speak to that one. --Jason _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
