On Mon, 19 Dec 2016 13:23:26 -0600 DRC <[email protected]> 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
pgp1ZHuIPTVLU.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
