Compile error on DEV version using DRI3 option

[DocMAX]

Allready added -DTVNC_DRI3=1 to my PKGBUILD...

pkgname=turbovnc-git
pkgver=3.1.1.r35.gddad0148
pkgrel=1
pkgdesc="High-speed remote desktop software (development version)"
arch=('x86_64')
url="https://www.turbovnc.org/"
license=('GPL')
depends=('java-runtime' 'libx11' 'libjpeg-turbo' 'libxt' 'libxmu' 'libxi')
makedepends=('git' 'cmake' 'make' 'gcc')
provides=('turbovnc')
conflicts=('turbovnc')
source=('git+https://github.com/TurboVNC/turbovnc.git#branch=dev')
sha256sums=('SKIP')

pkgver() {
  cd "$srcdir/turbovnc"
  git describe --long --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
}

build() {
  cd "$srcdir/turbovnc"
  mkdir -p build
  cd build
  PATH=/usr/bin:$PATH
  cmake .. \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DTJPEG_INCLUDE_DIR=/usr/include \
    -DTJPEG_LIBRARY=/usr/lib/libturbojpeg.so \
    -DTVNC_DRI3=1
  make
}

package() {
  cd "$srcdir/turbovnc/build"
  make DESTDIR="$pkgdir" install
}

[dcommander]

Note that this was a compiler warning, so it was only fatal because your build apparently makes compiler warnings fatal. Also, our build system disables compiler warnings for a lot of the X.org code, including damageext.c, so I'm not sure why your build encountered the warning in the first place. Anyhow, it should be fixed now.

I saw your comment on the TigerVNC thread, but I do not work on weekends as a general rule. Issues with this project are usually addressed during normal business hours, and I am in EDT (GMT-4 at the moment.)

[DocMAX]

Confirmed, works! Thank you very much. Now i'm very exited to test it.

[dcommander]

I look forward to your feedback. I need to eventually implement the get_formats() DRI3 method, which AMD's Vulkan implementation sometimes seems to use. (In particular, the lack of a get_formats() implementation causes Xvnc to crash when launching VMWare, which by default uses Vulkan for 3D acceleration.) I also believe that I can improve upon the Pixmap-to-buffer-object synchronization mechanism, which currently occurs on a timer.

[DocMAX]

So i did some tests now. vkcube and vulkaninfo are working.
But i see flickering on my desktop. (Terminal background color flickers with desktop background)
Games seem to work (using wine with dxvk) :-).

[DocMAX]

[DocMAX]

Is it better to use the TuboVNC Viewer? Right now i use the TigerVNC client. But there is no simple TurboVNC vncviewer.exe around :-(

[dcommander]

So what was the initial problem with WINE? Note that it is better to post a follow-up comment explaining the source of the initial failure and how it was resolved rather than editing your comment. Others may learn from your experiences.

The TurboVNC Viewer is written in Java and includes an embedded JRE. Install one of our pre-built Windows packages, then use c:\program files\turbovnc\vncviewer.bat if you want to use the viewer from the command line. It will work just as well as a .exe file. It's worth trying the TurboVNC Viewer, but I doubt that it will eliminate the flickering. I suspect that the flickering is a bug in the DRI3 implementation. I will try to reproduce the issue. You're using Xfce? What is your server platform?

[DocMAX]

I didn't fix anything. It must have been some kind of input error i did. Not sure what i did and probably not worth mentioning.
But here is a video of the screen flicker in case i didn't explain well...
https://jumpshare.com/s/hhwDdXI67ouSf777niir
Also the Steam GUI is filckering like crazy.

It's Arch Linux with XFCE4 and a custom skin (Chigago95)

[dcommander]

OK, will try to repro.

[DocMAX]

Holy grail! This feature is a real game changer! I can stop using SteamLink or Sunshine Video streaming. It's already looking that good and all games run as if I were running on plain X-server. They also use the current resolution of the window, which is very nice. Great work! Can't believe you initially didn't want to implement this. Looking forward to fixing the flickering issues and optimizing the code. As I said, please check the Steam GUI. It's flickering the most here. The games, by the way, do NOT flicker. Thank you! :-)

[dcommander]

I am barely able to eek out a living by developing and maintaining this project and VirtualGL and libjpeg-turbo, so it is difficult to justify the labor necessary to implement, integrate, fix, document, and maintain a major new feature if no one is paying for that labor. As far as I know, all deployments of TurboVNC in corporations and academia, organizations that might be in a position to pay for the implementation/integration of a feature like this, use nVidia GPUs, so the feature is useless to them.

As implemented by Kasm, the feature has some drawbacks, as evidenced by the flickering and the inability to run VMWare and other issues. I am honestly not sure if I can fix the flickering, because I suspect that it is due to the fact that Pixmaps and GBM buffer objects currently have to be synchronized on a timer within Xvnc. That's because Xvnc knows when a Pixmap has changed, but it doesn't necessarily know when a buffer object has changed (because that occurs within the 3D application process.) VirtualGL, in fact, exists partly to solve that synchronization dilemma for OpenGL applications: it monitors the GLX calls from such applications so it knows when a frame has been rendered and is ready for transport. I need to spend a day digging into the issue before I know whether it is solvable, and I haven't been able to find that time yet.

I integrated the DRI3 feature into TurboVNC in the hope of gaining familiarity with it so I could formally estimate the labor necessary to fix it, but even the company that implemented the feature isn't interested in that right now. (The vast majority of their customers also use nVidia GPUs, so they can't make a business case for it any more than I can.)

I hope this sheds some light on why I can't just spend time on everything that may appeal to me on a technical level. As an independent developer, I am generally more free to set the project agenda, but I still rely on outside contributions to support that agenda. I have to wear multiple hats, including project manager and product manager and marketing. From a business point of view, the DRI3 feature is primarily marketing. If the feature can be implemented correctly, then it will probably bring more users to TurboVNC, which will improve the project's overall health and exposure. That is how I am able to justify working on it at all, but there's a limit to how much free work I can do to improve the project's health and exposure. (Frankly, AMD should be paying for it, since it benefits primarily their GPUs.)

[DocMAX]

OK, thanks for the work so far.

[dcommander]

@DocMAX Try the latest code in dev. I ported the implementation from TigerVNC 1.14 beta, which has a lot of improvements (described in f9484d2.) Hopefully it fixes the flickering. In my testing, I no longer observe any issues when using the AMDGPU drivers or the VMware drivers (in a VMware guest), and running the VMware application in the TurboVNC session now works properly except for TigerVNC/tigervnc#1772 (which can be worked around by setting VK_ICD_FILENAMES to force VMware to use the AMDGPU driver.) Let me know if you observe any other issues.

[DocMAX]

The flicker is gone. :-) Great work!
To make this more accessible, I added the turbovnc-git package to the AUR repository for Arch Linux users.
https://aur.archlinux.org/packages/turbovnc-git

[dcommander]

The TigerVNC developers did most of the work-- much to my chagrin, since I was trying to secure funding from a third party to do the work myself. Since the TigerVNC developers scooped me on it, I had to port their modifications into TurboVNC purely out of survival. The open source community will benefit by the feature being available in both VNC servers, but I missed out on potentially enough funding to sustain me for a month. This DRI3 extension will likely undercut at least part of VirtualGL's revenue stream as well, which further complicates my ability to survive as an independent open source developer. So it's a somewhat bittersweet thing for me. I'm glad that the DRI3 feature is helping the community in the near term, but it may put me out of business in the long term (which would have negative consequences on the health of libjpeg-turbo, VirtualGL, and TurboVNC.)

[DocMAX]

I'm confused about Tiger- and TurboVNC. Which one should be my daily driver?

[dcommander]

There are a plethora of X proxies these days, including some non-VNC options like Xpra and NX, but TurboVNC is the only X proxy that we (The VirtualGL Project) officially support. I am working on an article that explains the current differences between TurboVNC and TigerVNC in terms of overall project management philosophy, funding model, usage, etc. The article on TurboVNC.org, which attempted to enumerate feature differences between TurboVNC and TigerVNC, is sorely out of date.

These days, the biggest usage difference is that TurboVNC has a built-in session manager and supports multiple simultaneous sessions under the same user account. With v1.11, TigerVNC adopted a different way of launching VNC sessions that uses systemd. Thus, you can no longer have multiple simultaneous TigerVNC sessions (or a simultaneous TigerVNC session and local session) under the same user account, TigerVNC sessions must be statically assigned to X display numbers by the system administrator, and TigerVNC sessions can only be stopped and started by system administrators. Obviously I'm biased, but I much prefer TurboVNC's approach.

[dcommander]

Here is the aforementioned article:
https://turbovnc.org/About/TigerVNC