[RFC 3/3] xwayland: Add glamor egl_backend for EGLStreams

[Adam Jackson]

On Wed, 2018-02-07 at 17:07 -0500, Lyude Paul wrote:

> One of the biggest differences with this is that EGLStreams give no way
> of doing rendering directly to the allocated resources unless you are
> able to set the EGLSurface producers as the current read/draw texture
> through eglMakeCurrent(). This may work for some very simple usecases,
> however since glamor relies heavily on EGL_KHR_surfaceless_context
> there's no way we can simply use this directly as a backing for pixmaps
> since most of the time we have no surface set as current.

I think this is more a comment about how glamor is currently written.
It's true we only do eglMakeCurrent(EGL_NO_SURFACE) at the moment, but
I don't think there's an intrinsic problem with changing that. You'd
need to thread the destination pixmap through glamor_make_current (and
probably call it in more places), and fix up the few places we call
BindFramebuffer. Xwayland already wraps CreatePixmap for the gbm case
for basically the same reasons, it just happens to create a non-EGL
object.

That said, I don't think rendering to the stream would be an option
unless you could guarantee that the back buffer was preserved on swaps,
because X isn't allowed to lose pixmap contents. The streams spec makes
it sound like the color buffer is always lost on swaps though.

Given that this only enables glamor acceleration at the moment, it'd be
interesting to know if this is even a win relative to the shm transport
for, say, x11perf -copypixwin500 (preferably the full 2x2 matrix,
nvidia and nouveau, shm and glamor).

The bigger issue is whether direct rendered GL clients would even be
possible in this model. glxvnd plus lifting the loader to dix would
allow the streams stack to do "whatever it needs" to make GLX work, but
I worry it would need to wrap so much of CreatePixmap and friends that
the actual eglstreams code in Xwayland doesn't end up mattering.

- ajax