On Wed, 14 Dec 2016 11:42:54 -0600 DRC <dcomman...@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
pgpNpXBFeSO0b.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
