Remote display with 3D acceleration using Wayland/Weston

[DRC]

On 12/19/16 2:48 AM, Pekka Paalanen wrote:
> Hmm, indeed, maybe it would be possible if you are imposing your own
> EGL middle-man library between the application and the real EGL library.
> 
> That's definitely a idea to look into. I cannot say off-hand why it
> would not work, so maybe it can work. :-)
> 
> To summarize, with that approach, you would have the client send only
> wl_shm buffers to the compositor, and the compositor never needs to
> touch EGL at all. It also has the benefit that the read-back cost
> (glReadPixels) is completely in the client process, so the compositor
> will not stall on it, and you don't need the stuff I explained about in
> the compositor. And you get support for the proprietary drivers!
> 
> Sorry for not realizing the "wrap libEGL.so" approach earlier.

Yes, exactly.  That is essentially how VirtualGL already works with
GLX/OpenGL, so it is a solution space I know well.  As I see it, the
advantages of implementing this at the compositor level are:

-- Automatic hardware acceleration for window managers that might need
to use OpenGL (which includes most of them these days)
-- No need to launch OpenGL applications using a wrapper script
-- Potentially the compositor could tap into GPU-based encoding methods
(NVENC, for instance) quite easily to compress the pixel updates sent to
the client.  This becomes more difficult when the pixel readback is
occurring in the OpenGL application process but the compression is
occurring in another process.

The potential advantages of an interposer are:

-- Much easier for me to develop, since this would represent basically a
subset of VirtualGL's existing functionality (the GLX interposer could
also benefit from a back end that accesses the GPU directly through EGL
rather than forwarding the GLX requests through a local X server.)
-- The readback occurs in-process, so only applications that actually
need it (OpenGL applications) are subject to that overhead, and the
design of VirtualGL makes it such that the readback of the current frame
occurs in parallel with the display of the last frame.
-- Theoretically should work with any Wayland implementation or back
end.  It goes without saying that I'm not the only one in this game.  In
the current market, there are lots of different vendors producing their
X11 proxy of choice, but all of them can use VirtualGL to add GPU
acceleration.  I don't know how the market will look with Wayland, but I
would anticipate that those same vendors will produce their own Wayland
proxies of choice as well, so there might be an advantage to retaining
VirtualGL as an independent bolt-on product.
-- That is a good point about the compositor not stalling on
glReadPixels()-- although I think I could probably mitigate that by
using PBOs rather than synchronous glReadPixels().

I know for sure that I can make the interposer approach work, and
perhaps that would be a good short-term approach to get something up and
running while the other approach is explored in more depth.