search

kasmtech / KasmVNC

Modern VNC Server and client, web based and secure
GNU General Public License v2.0
3.58k stars 320 forks source link

Windows do not display properly when using the new DRI3 feature #146

Open dcommander opened 1 year ago

dcommander commented 1 year ago

Describe the bug When using the new DRI3 feature introduced in d04982125a04962ca4a6d9829b0cdad5793db324, the GNOME 3 desktop displays properly, but any windows I attempt to open (GNOME Terminal, for instance) are blank or contain nothing but junk pixels. With XFCE, I only get a white screen. I see this both with the VMWare driver under Rocky Linux 9 and the AMDGPU driver (latest version) under Rocky Linux 8. It may be reproducible with other open source drivers as well, but I have no way to test that.

System Description

NAME="Rocky Linux"
VERSION="8.7 (Green Obsidian)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.7"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Rocky Linux 8.7 (Green Obsidian)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:8:GA"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-8"
ROCKY_SUPPORT_PRODUCT_VERSION="8.7"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.7"
Linux boris 4.18.0-425.13.1.el8_7.x86_64 #1 SMP Tue Feb 21 19:25:54 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
NAME="Rocky Linux"
VERSION="9.0 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.0"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Rocky Linux 9.0 (Blue Onyx)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
ROCKY_SUPPORT_PRODUCT_VERSION="9.0"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.0"
Linux vmrh9 5.14.0-70.17.1.el9_0.x86_64 #1 SMP PREEMPT Wed Jul 13 18:23:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

KasmVNC Details

Xvnc KasmVNC 0.9 - built Mar 14 2023 18:49:32
Copyright (C) 1999-2018 KasmVNC Team and many others (see README.me)
See http://kasmweb.com for information on KasmVNC.
Underlying X server release 12011000, The X.Org Foundation

To Reproduce Steps to reproduce the behavior (for non-installation issues): Launch vncserver from KasmVNC with -hw3d -drinode /dev/dri/renderXXX, where XXX is the DRI render node ID corresponding to the installed AMDGPU or VMWare driver. Additionally pass -select-de xfce to vncserver to test XFCE instead of GNOME. Connect with the KasmVNC client.

Expected behavior Windows display properly when using the DRI3 feature.

Browser If this is a problem with the KasmVNC client, provide details about the browser you are accessing KasmVNC from.

clbr commented 1 year ago

This is an issue with the reverse path (pixmap to texture) which is used by GL compositors. I've been able to reproduce. For now, please disable compositing.

dcommander commented 1 year ago

Any update on this issue?

mmcclaskey commented 1 year ago

Yes it is fixed on the the tip of master, however, I believe there may be some high cpu utilization with the fix that we may need to take a look at. We are releasing a new version next week, so a fix will likely be post release of 1.2.0. I believe this was the initial commit, there there were fixes post this commit I believe, so look at the tip of master for current code.

https://github.com/kasmtech/KasmVNC/commit/9a14b07ba4a0bf243f6ba14a3dcf8635e69d572f

dcommander commented 1 year ago

Yeah, the window contents display properly now, but I notice a delay when typing text into a terminal window.

dcommander commented 1 year ago

Actually, scratch that. I failed to apply the new part of the X.org patch that calls xvnc_dri3_sync_textures() from DamageExtNotify(). I no longer observe the aforementioned delay. In my testing with the AMDGPU driver, DRI3 uses less CPU time than VirtualGL, but it also doesn't feel as responsive as VGL. It basically feels like VGL if you set VGL_FPS=60 and VGL_SPOIL=0 (no frame spoiling and frame-rate-limited to 60 Hz), only a bit less smooth. There is a noticeable lag between mouse interaction and rendering, even on gigabit network (which is why frame spoiling exists in VGL.) It may be possible to implement such a spoiling mechanism in Xvnc as well, by having the RFB server coalesce screen updates from DRI3 until a client is ready to receive a framebuffer update.

dcommander commented 1 year ago

I understand the issue now. Your 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.) I suspect that (a) your current implementation isn't catching all of the cases in which the pixmap might be updated, and (b) it should be possible to synchronize in a more targeted manner without a timer. Since Xvnc already hooks into every possible method by which an X client can update the framebuffer, it should be possible to extend those hooks to catch X rendering operations that might update a DRI3-created pixmap. (This will likely be the Composite() or CopyArea() method in most cases.) That would allow for more targeted synchronization, since we would know exactly which pixels were modified in the pixmap after an X rendering operation in which the pixmap was the destination drawable. (Only those pixels would need to be copied back to the GBM buffer object.) If the pixmap will be the source drawable in an X rendering operation, we would also know exactly which pixels would be involved in the operation. (Only those pixels would need to be copied from the GBM buffer object prior to the X rendering operation.) Implementing such a hook for the CopyArea() method would achieve the same result for present_copy_region() as your current code, since present_copy_region() calls the CopyArea() method.

clbr commented 1 year ago

There are way too many operations to hook, it's way too much work for little gain. Running a compositor lowers performance even in best of cases, and we're operating a remote environment where it's an easy tradeoff to remove some eye candy and gain some perf. Saves CPU as well, which is important if running on a cloud env that pays by the cpu minute.

You are correct that such an implementation would work better and more efficiently. However from Kasm's POV, DRI3 is intended for running 3d apps without a compositor. The use case of someone running a compositor is of lower priority.

fti7 commented 11 months ago

I have an similiar Issue when running kasmvnc via webtop (lscr.io/linuxserver/webtop:fedora-mate or xfce) on an Raspberry Pi 4/5. hw3d acceleration seems to work, but output is just garbage.

Compositing is disabled. Tested with mate and xfce :-(

image

clbr commented 11 months ago

I think that's a different issue, looks like a wrong stride or possibly depth. Assuming I got that right and the server is a Rpi, never heard of webtop. I don't have such a pi, but if you're able to build kasm, you could try adding some prints (ErrorF's) in dri3.c, for the depth and strides.

dcommander commented 9 months ago

I went ahead and ported Kasm's DRI3 implementation into TurboVNC 3.2 Evolving, mainly because the AMDGPU drivers require DRI3 in order to use Vulkan with GPU acceleration (whereas nVidia's Vulkan drivers do something VirtualGL-like if they detect that they're running in an X proxy.) VirtualGL is still generally faster and has a better feature set for OpenGL applications, particularly professional applications.