In theory, it should be possible to get access to the hardware acceleration in Xvnc. The reason we're not today is probably because it is linked up inside the DDX display driver (which we of course do not have). Considering the new Gallium3D design, we should have a look and see if we can get access to the accelerated libGL from Xvnc. It would remove the need for stuff like VirtualGL. (See also bug 1116)
Note that this solution will most likely not work with proprietary drivers.
*** Bug 2905 has been marked as a duplicate of this bug. ***
A lot has happened in this space. The Linux DRM system is splitting off the display handling from the 3D rendering, which could make it easier for us to use just the 3D part. We also have VirGL which might be possible to integrate in our stuff.
Deploying VirtualGL as a GLVND library might also be interesting as it could avoid having to wrap everything with vglrun. DRC has seen some obstacles with this though: https://github.com/VirtualGL/virtualgl/issues/18
We should probably have a look at Xvfb as well. Xvnc was originally forked from it, but it has since gotten a lot of updates, among them support for DRI3 and glamor (i.e. GPU acceleration).
The glamor PR/MR for Xvfb: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/235 It has been reverted again though: https://gitlab.freedesktop.org/xorg/xserver/-/commit/535f14656a2a42f0cca13a4264e8111300e5806d citing this issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/916
Kasm are also experimenting with 3D acceleration by enabling DRI3. I grabbed their changes and got them integrated in to standard TigerVNC here: https://github.com/CendioOssman/tigervnc/tree/dri3 It seems to work for basic things like glxgears or glxspheres in a simple environment (e.g. Xfce). It fails when I start GNOME, though, where it fails to send the proper frame buffer data to the client. But it seems like Kasm are working on that, though, as they are referring to some internal "gnome_blank" branch. Let's wait and see.
Another data point is that xrdp seems to have gotten glamor running. Some details here: https://github.com/neutrinolabs/xrdp/issues/1029
Neither the normal Xorg server nor Xwayland enable DRI3 directly. Instead, they get that support indirectly by enabling Glamor. That unfortunately means that they are poor reference implementations for us if we just want to enable DRI3. Fortunately, there are others that are annoyed by this, so there are some other attempts to look at: https://indico.freedesktop.org/event/2/contributions/60/attachments/66/107/XDC-20220-DRI3-modesetting-without-glamor.pdf https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=241e7289f25a342a457952b9b0e539c2f0b81d99 https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/945
Upstream request for this: https://github.com/TigerVNC/tigervnc/issues/1626
DRC also looked at Kasm's changes and doesn't seem too optimistic: https://github.com/TurboVNC/turbovnc/issues/373
This is now merged and released upstream: https://github.com/TigerVNC/tigervnc/pull/1771 It is also included in TurboVNC's development branch.
Nvidia is a bit of an issue here. Initially, we only thought the problem was getting applications to pick the right driver: https://github.com/TigerVNC/tigervnc/issues/1773 Unfortunately, it seems like we're just getting the software renderer from Nvidia, even with that fixed. The nouveau driver works better, but users might need/prefer the proprietary Nvidia driver. I've opened a discussion with Nvidia here: https://forums.developer.nvidia.com/t/no-opengl-or-vulkan-acceleration-in-new-tigervnc/303666/2
