Remote display with 3D acceleration using Wayland/Weston

Christian Stroetmann stroetmann at ontolab.com
Fri Feb 24 01:20:08 UTC 2017


On the 24th of February 2017 00:51, DRC wrote:
> On 12/15/16 3:01 AM, Pekka Paalanen wrote:
>> The current RDP-backed is written to set up and use only the Pixman
>> renderer. Pixman renderer is a software renderer, and will not
>> initialize EGL in the compositor. Therefore no support for hardware
>> accelerated OpenGL gets advertised to clients, and clients fall back to
>> software GL.
>>
>> You can fix this purely by modifying libweston/compositor-rdp.c file,
>> writing the support for initializing the GL-renderer. Then you get
>> hardware accelerated GL support for all Wayland clients without any
>> other modifications anywhere.
>>
>> Why that has not been done already is because it was thought that
>> having clients using hardware OpenGL while the compositor is not cannot
>> be performant enough to justify the effort. Also, it pulls in the
>> dependency to EGL and GL libs, which are huge. Obviously your use case
>> is different and this rationale does not apply.
>>
>> The hardest part in adding the support to the RDP-backend is
>> implementing the buffer content access efficiently. RDP requires pixel
>> data in system memory so the CPU can read it, but GL-renderer has all
>> pixel data in graphics memory which often cannot be directly read by
>> the CPU. Accessing that pixel data requires a copy (glReadPixels), and
>> there is nowadays a helper: weston_surface_copy_content(), however the
>> function is not efficient and is so far meant only for debugging and
>> testing.
> I am attempting to modify the RDP backend to prove the concept that
> hardware-accelerated OpenGL is possible with a remote display backend,
> but my lack of familiarity with the code is making this very
> challenging.  It seems that the RDP backend uses Pixman both for GL
> rendering and also to maintain its framebuffer in main memory
> (shadow_surface.)  Is that correct?  If so, then it seems that I would
> need to continue using the shadow surface but use gl_renderer instead of
> the Pixman renderer, then implement my own method of transferring pixels
> from the GL renderer to the shadow surface at the end of every frame (?)
>   I've been trying to work from compositor-wayland.c as a template, but
> it's unclear how everything connects, which parts of that code I need in
> order to implement hardware acceleration, and which parts are
> unnecessary.  I would appreciate it if someone who has familiarity with
> the RDP backend could give me some targeted advice.
>

Aloha

I have not come so far some years ago but your approach sounds good. 
Basically, it is a translation of what you do with your GLX interposer 
(VirtualGL) and high-speed X proxy (TurboVNC) to Weston, which reduces 
to the handling of the buffers.

That said, I would try to get it running and then compare the speed with 
the old version running with XWindow, and also upload the code for 
review by the gurus.

Maybe a look on another compositor or the IVI shell might help you.

Regards
Christian Stroetmann


More information about the wayland-devel mailing list