Direct GPU acceleration about turbovnc HOT 1 CLOSED

Kasm worked around the issue in their DRI3 implementation, but the workaround is problematic. The basic problem is that their DRI3 implementation creates pixmaps in system memory and maintains a GBM buffer object (in GPU memory) for each, so it has to synchronize the pixels between system memory and GPU memory whenever either the buffer object or the pixmap changes. (NOTE: VirtualGL's implementation of GLX_EXT_texture_from_pixmap has to do that as well, albeit on a more coarse-grained level.) It is straightforward to figure out when a buffer object should be synchronized to its corresponding DRI3-managed pixmap, because Xvnc hooks into the X11 operations that read from the pixmap (always the Composite() or CopyArea() screen methods, in my testing.) However, it is not straightforward to figure out when a DRI3-managed pixmap should be synchronized to its corresponding buffer object, because the buffer object seems to be read outside of X11. That is consistent with my own experience of how direct rendering works. It bypasses X11, which is one reason why screen scrapers don't work with GPU-accelerated 3D applications unless you scrape the screen on a timer. That is basically what Kasm's DRI3 implementation does. It maintains a list of active buffer objects and synchronizes all of them with their corresponding DRI3-managed pixmaps 60 times/second, regardless of whether the pixmaps have actually changed. As you can imagine, this creates a significant amount of performance overhead, and I am skeptical of whether it is free from compatibility issues. Irrespective of the aforementioned timer, DRI3 is capped to the screen refresh rate, which is 60 Hz in Xvnc. Thus, in my testing with the AMDGPU driver, the DRI3 implementation feels like VirtualGL if you set VGL_FPS=60 and VGL_SPOIL=0 (no frame spoiling and frame-rate-limited to 60 Hz), only less smooth. There is a noticeable lag between mouse interaction and rendering, even on a gigabit network (which is why frame spoiling exists in VGL.)

I spent 20-30 uncompensated hours trying to improve the implementation but was unable to. To the best of my understanding, it would be necessary to store pixmaps in GPU memory in order to implement DRI3 cleanly. That would require storing the whole framebuffer in GPU memory, and virtual X servers such as Xvnc cannot do that. Thus, at the moment, I do not think that this solution is appropriate for TurboVNC, since it has significant performance drawbacks relative to VirtualGL. I think that the limited resources of The VirtualGL Project are better spent improving the compatibility of VirtualGL's EGL back end or looking into a TurboVNC Wayland compositor, which could cleanly use GPU memory and potentially pass through GPU acceleration to Xwayland without the need to deal with any of this mess at the X11 level.

from turbovnc.