Depends on how you use the OpenGL API. OpenGL display lists, once compiled, are extremly light on the connection. However they're also deprecreated and no longer supported in (forward compatible) OpenGL-3.3 core. But then again there's no 3.3 GLX specification.
As I understand it, when you open an OpenGL application inside Xvnc (et al) on :1, a shim is LD_PRELOADed that quietly redirects the OpenGL initialization calls so they create an offscreen buffer associated with Xorg at :0 (which is presumably sitting on a 3D-capable GPU).
Said Xorg can be displaying a black screen (or be being used for arbitrary purposes); no windows are ever displayed on it. Theoretically, avoiding compositing WMs may aid performance.
The graphics contexts should be well-contained on the host though. That the guest is leaking memory is kind of interesting.
PKG_CONFIG_PATH=/opt/virgl-0.8.1/lib/pkgconfig/ ./configure --prefix=/opt/qemu-4.2.0 --enable-spice --enable-kvm --enable-linux-aio --target-list=x86_64-softmmu --enable-sdl --enable-gtk --enable-opengl --enable-virglrenderer --extra-ldflags=-L/opt/libepoxy-1.5.4/lib/
export QEMU_PA_LATENCY_OUT=20
export QEMU_PA_SAMPLES=44100
${QEMU_BIN} -name "${NAME}" -m size=${RAM_SIZE} -machine accel=kvm -drive format=raw,aio=native,cache=none,if=virtio,file=${VMDIR}/${VM} -netdev tap,id=mynet0,ifname=${VMTAP},script=no,downscript=no -device e1000,netdev=mynet0,mac=${VMMAC} -vga virtio -display sdl,gl=on -soundhw hda -audiodev pa,id=pa1
If only I could figure out how to fix this memory leak.
Thanks for the info. I probably don't have the hardware setup to run VMs at the moment (chronically low on RAM + do not have a GPU). I will be very interested to play with this when that changes in the future.
The one question (if you notice this) I do have is: how quickly does the memory leak happen? And can just running glxgears do it?
The work VM which is typically connected to Github and work gmail needs to be restarted once every couple of days.
The play VM which would have a Chromium with a dozen tabs open can can take ~20 min to ~1 hour depending on the content in tabs.
I notice the memory leak when Sublime that I run on the host itself starts dropping key press speed ( I run "xset r rate 400 50" ). Killing VMs or restarting them makes everything go back to normal.
I've ran glxgears for ~2 hours now with no significant leak. I will probably leave it overnight to see if something as simple as it can be used as a leak example.
I'm going to speculate the key is heavy usage of GLX something that only Chromium does as I have left a desktop with an xterm running top for two days and no leaks were detected on a play vm. So it is not just virtgl in QEMU being exposed to the guest, initialized by the guest and interfaced by the guest via virtio, but actually using virgl on a host to do rendering. Maybe virtual context creation/release cycle?
P.S. I originally made this work on my super light laptop ( i7-6500U with 8G ), so you don't need a beefy rig for it although there's a bug in recent Intel GPU libraries used by mesa that sometimes lock it up. I initially attributed it to something I did but it was not:
https://github.com/qutebrowser/qutebrowser/issues/4641
kitty, alacritty, and even Chromium would sometimes lock up with intel iGPUs.
Feel free to reach out - my email address in a profile here. I check it here and there.
"Depending on the content in tabs". Might be interesting to graph the leak rate (in KB/min or MB/min) and maybe either record the screen or limit to one or two websites at a time to narrow down what causes the most issues. Besides video playback, CSS animations come to mind as a potential source of GLX acceleration caused by random/mainstream websites.
Now I'm wondering what would happen if you fired up multiple tabs with stuff from https://www.shadertoy.com/, https://experiments.withgoogle.com/collection/chrome, https://webglsamples.org/, etc >:)
Virtual context creation+release could indeed be the problem. FWIW https://github.com/cyrus-and/chrome-remote-interface makes using Chrome's remote debug protocol (to open and close tabs) utterly trivial; or you could just run multiple concurrent browsers with --user-data-dir=somewhere (probably actually much easier to work with).
Chromium aside, another potentially useful trigger may be Unity games - the last(/first/only) time I tried to fire one up my laptop (i5-3360M + HD Graphics 3000) I was scrambling for ^C^C^C while everything slowed to a crawl and the system climbed (impressively quickly) past 97°C ;) (thankfully(!) nothing froze - thanks for the Intel lockup reference), so perhaps that could be a very effective trigger.
I'll keep your email address in mind; email is a bit of a long-term sore point due to Gmail constantly slowing everything to a crawl, and I'm currently using 8GB of swap (need to close some tabs) so I replied here so I could respond in a timely manner.
It would be nice if there was a X11 "media" extension to transport encoded image streams (aka video) with server side decoding into Pixmaps, Xv or SHM buffers.
4k @32 bit color is ~3.5Gbit/sec at 60 fps or 1.6Gbit/sec for 30fps.
Modern video cards and CPUs are fast. With no optimizations I can screen grab a fully rendered X11 4k x 5 screen in ~100ms on i7-4790 CPU from a GTX 1060 ( did it yesterday when I discovered that Looking Glass does not support Linux guest). Some people that I know who are in the graphics business claim that using MIT shared memory extension they can do nearly 1000 fps for a single 4k screen.
Iperf (TCP) with no network optimization and no shared memory a-la Looking Glass between host and guest gets 2.5Gbit/sec.
Why not just do a PCI pass through to a virtualized ( or dedicated ) graphics card to guest, run an X server on it and stream raw frames from guest to host? It surely can do at least 30fps on a modern workstation or over a 10G network with no frame loss.
Because we're talking about remote desktop over low bandwidth connections. If push comes to shove you can use Xpra over dial-up.
Of course the more elegant solution then is to use some virtio based graphics pass-through driver doing all that, without running MIT-SHM screen grabber X11 clients shoving around frames. I want less kludges, not more.
I'm presuming this implies there's already a non-theoretical solution for remote desktop over high bandwidth connections ( say over 10Gbit/sec ) that would allow me to run a spinning cube at 30 frames per second at 4k without frame drops? What is it? I have been looking for one for years!
> Of course the more elegant solution then is to use some virtio based graphics pass-through driver doing all that, without running MIT-SHM screen grabber X11 clients shoving around frames. I want less kludges, not more.
That would be Looking Glass, but its author's position is (paraphrasing) "Stuff like this already exists for Linux so there's no support for a Linux guest". Alas, no one can point to it.