3 ms·

> X also doesn't really work if you UI is implemented with OpenGL or similar. Depends on how you use the OpenGL API. OpenGL display lists, once compiled, are e

> X also doesn't really work if you UI is implemented with OpenGL or similar. 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.

jamesfmilne 6y ago
For the stuff I'm doing (image processing), indirect GL is not an option.
- exikyut 6y ago
  What about VirtualGL? https://www.virtualgl.org/ https://www.virtualgl.org/ 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.
  - notyourday 6y ago
    I am using it with qemu to allow Linux guests to use hosts's gpu to do 3d acceleration. It works fairly well except that it seems there is a memory leak in the path somewhere because over time qemu VMs with it enabled grow over the memory allocated to them.
    - exikyut 6y ago
      Wait, how does that... ohh, you're forwarding GLX. Ha, that's awesome, I am definitely borrowing that idea :) The graphics contexts should be well-contained on the host though. That the guest is leaking memory is kind of interesting.
      - notyourday 6y ago
        This is qemu 4.2.0 configure command line that built what i needed to support this ( Debain 10's qemu did not have virgl support ). Spice did not work me, SDL did. 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/ And this is the command line to launch a guest: 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 Oh and when I say it is working "fairly well" I mean the a guest with a single vCPU runs a spinning cube with no sweat, not to mention glxgears etc. Just for a test I have done 4 guests ( one per physical core ) doing gears and spinning cube each in addition to the host itself doing spinning cube with no issue. If only I could figure out how to fix this memory leak.
        exikyut 6y ago
        Arg, only noticed your reply yesterday then the tab got buried! 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?
        notyourday 6y ago
        I'm running 32GB system with two browser VMs getting 4G each. 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 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.
- datenwolf 6y ago
  In those cases I prefer using Xpra, configured to use the regular Xorg server operating on the GPU. 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.
  - notyourday 6y ago
    Really stupid question if I may: 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.
    - datenwolf 6y ago
      > Why not just do a PCI pass through (…)? 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.
      - notyourday 6y ago
        > Because we're talking about remote desktop over low bandwidth connections. 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.

jamesfmilne 6y ago

For the stuff I'm doing (image processing), indirect GL is not an option.

exikyut 6y ago
What about VirtualGL? https://www.virtualgl.org/ https://www.virtualgl.org/ 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.
- notyourday 6y ago
  I am using it with qemu to allow Linux guests to use hosts's gpu to do 3d acceleration. It works fairly well except that it seems there is a memory leak in the path somewhere because over time qemu VMs with it enabled grow over the memory allocated to them.
  - exikyut 6y ago
    Wait, how does that... ohh, you're forwarding GLX. Ha, that's awesome, I am definitely borrowing that idea :) The graphics contexts should be well-contained on the host though. That the guest is leaking memory is kind of interesting.
    - notyourday 6y ago
      This is qemu 4.2.0 configure command line that built what i needed to support this ( Debain 10's qemu did not have virgl support ). Spice did not work me, SDL did. 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/ And this is the command line to launch a guest: 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 Oh and when I say it is working "fairly well" I mean the a guest with a single vCPU runs a spinning cube with no sweat, not to mention glxgears etc. Just for a test I have done 4 guests ( one per physical core ) doing gears and spinning cube each in addition to the host itself doing spinning cube with no issue. If only I could figure out how to fix this memory leak.
      - exikyut 6y ago
        Arg, only noticed your reply yesterday then the tab got buried! 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?
        notyourday 6y ago
        I'm running 32GB system with two browser VMs getting 4G each. 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 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.
datenwolf 6y ago
In those cases I prefer using Xpra, configured to use the regular Xorg server operating on the GPU. 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.
- notyourday 6y ago
  Really stupid question if I may: 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.
  - datenwolf 6y ago
    > Why not just do a PCI pass through (…)? 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.
    - notyourday 6y ago
      > Because we're talking about remote desktop over low bandwidth connections. 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.