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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
