Remote display with 3D acceleration using Wayland/Weston

[Pekka Paalanen]

On Wed, 14 Dec 2016 11:42:54 -0600
DRC <dcommander at users.sourceforge.net> wrote:

> But if you run OpenGL applications in Weston, as it is currently
> implemented, then the OpenGL applications are either GPU-accelerated or
> not, depending on the back end used.  If you run Weston nested in a
> Wayland compositor that is already GPU-accelerated, then OpenGL
> applications run in the Weston session will be GPU-accelerated as well.
> If you run Weston with the RDP back end, then OpenGL applications run in
> the Weston session will use Mesa llvmpipe instead.  I'm trying to
> understand, quite simply, whether it's possible for unmodified Wayland
> OpenGL applications-- such as the example OpenGL applications in the
> Weston source-- to take advantage of OpenGL GPU acceleration when they
> are running with the RDP back end.  (I'm assuming that whatever
> restrictions there are on the RDP back end would exist for the TurboVNC
> back end I intend to develop.)  My testing thus far indicates that this
> is not currently possible, but I need to understand the source of the
> limitation so I can understand how to work around it.  Instead, you seem
> to be telling me that the limitation doesn't exist, but I can assure you
> that it does.  Please test Weston with the RDP back end and confirm that
> OpenGL applications run in that environment are not GPU-accelerated.

Hi,

I assure you, this is a limitation of the RDP-backend itself. Nothing
outside of Weston creates this restriction.

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.

In fact, we have been thinking about adding (hardware or software)
OpenGL support to the headless backend so that we could actually run
tests on those code paths in the Weston test suite:
https://bugs.freedesktop.org/show_bug.cgi?id=83984
https://bugs.freedesktop.org/show_bug.cgi?id=83985

Since filing those bugs, I have been thinking that testing Weston's
GL-renderer should happen with the Wayland-backend. The host compositor
would be Weston with the headless backend modified to initialize
compositor-side EGL ad hoc. That way we might be able to limit all
test-only code in the headless backend.


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/20161215/d090ac3a/attachment.sig>