VirtualGL 3.0.91 breaks VLC
ehfd opened this issue · comments
VirtualGL 3.0.91 breaks VLC when playing an mp4 file (audio works fine) after invoking the desktop environment through vglrun, segmentation fault happens no matter what. 3.0.2 doesn't.
Logs weren't so useful.
Happened all in Ubuntu 18.04 through 22.04.
I tried on both CentOS 7 and Ubuntu 22.04. Can't reproduce. Is there anything about your computing environment that might be relevant? Which GPU and driver version are you using? Which window manager?
NVIDIA 515, KDE Plasma.
KDE Plasma has a lot of known issues with VirtualGL and TurboVNC. Does this occur with GNOME or MATE or Xfce or any other WM?
Will assess. But that was a new issue not previously existing within 3.0.2.
I will potentially look for some small funding if needed.
The 3.1 series of VirtualGL introduced EGL/X11 emulation, primarily because of Firefox and Chrome. However, the implementation leaves out some EGL/X11 features (#185) that would have been hard to implement, because I didn't have the funding for them and they weren't necessary for Firefox and Chrome. Maybe one of those features is necessary for KDE.
Because my open source projects are managed on a shoestring budget, my lab is somewhat limited. I only have two nVidia GPUs at my disposal, and only one of them can use the latest nVidia drivers. The machines in which those GPUs are installed are running RHEL derivatives, so I can only test Ubuntu using a VMWare virtual machine with VMWare's graphics drivers (which redirect OpenGL to the host GPU.) Thus, it is always possible that my inability to reproduce issues like these is due to the limitations of my test environment.
Since I can't reproduce the failure, you're going to have to do some of the legwork. The first thing I would try is running the window manager without VirtualGL and then using vglrun to explicitly run VLC with VirtualGL. If you get the same results, then the next thing I would try is running a non-compositing window manager such as MATE or Xfce. These are all useful data points that will help to narrow down the source of the crash. The more we can narrow it down, the more likely it is that I will be able to find a way to reproduce it, and once I can reliably reproduce it, it is likely that I can diagnose and fix it.
My guess is that Qt tries to autodetect the availability of GLX and EGL. It probably detects that EGL/X11 is available and tries to use it. There may be an environment variable that forces the use of GLX instead (QT_OPENGL=desktop?), which may provide a temporary workaround for the problem.
Will get to it, and perhaps ask KDE devs too.
Can you please at least test whether this is reproducible with a WM other than Plasma? Since the VirtualGL 3.1 release is overdue, I would like to ascertain whether this is confined to an unsupported configuration or whether it can be reproduced in a supported configuration.
Aha. I was able to reproduce it on CentOS 7. (Turns out I was using the wrong repository, so I wasn't getting the latest version.) I will investigate.
Should be fixed now. Try the latest 3.1 post-beta build or build from source using the main branch.
Oh, you fixed it for me. Was busy. Thanks.