Remote display with 3D acceleration using Wayland/Weston

[Pekka Paalanen]

On Thu, 23 Feb 2017 17:51:24 -0600
DRC <dcommander at users.sourceforge.net> 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 (?)

That is pretty much the case, yes. I suppose you could also just let
GL-renderer maintain the framebuffer to only read it out for
transmission rather than maintaining a shadow copy, but the difference
is mostly just conceptual.

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

I cannot help with the RDP-specifics.

Since this compositor is essentially headless in the local machine, you
would want to use DRM render nodes instead of KMS nodes for accessing
the GPU. The KMS node would be reserved by any display server running
for the local monitors.

You would initialize EGL somehow to use a render node. I can't really
provide a good suggestion for an architecture off-hand, but maybe these
could help:
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_platform_device.txt
https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_platform_gbm.txt

Or any other way to get EGL initialized with a real GPU, but without an actual
display or a window system. Depending on how that works, you might be
rendering into an FBO and use glReadPixels(), or create an EGLSurface
and use glReadPixels() or something else perhaps.

Weston will need to be able to run EGL with a render node for testing
the GL-renderer on real hardware, but so far we don't have that code,
so I don't have an example.

A completely different path would be to duplicate the parts of
GL-renderer you need (access to client provided buffers) and throw away
the rest (all the rendering, damage tracking, and whatnot), initialize
EGL with a render node, and just scrape the client buffer contents
directly without composition. In this case you would be transmitting
client window contents as is, not the final composition. That might
have (bandwidth) drawbacks of its own.


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/20170224/7972e66b/attachment.sig>