Remote display with 3D acceleration using Wayland/Weston

[Pekka Paalanen]

On Mon, 19 Dec 2016 13:23:26 -0600
DRC <dcommander at users.sourceforge.net> wrote:

> 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.

Hi,

I fully agree on everything you said here. :-)


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161220/9205c491/attachment.sig>