I’m trying to get a Windows VM to run Fusion360 and doing alright in that respect. I currently am using libvirt, qemu, intel gvt-g, and virt-viewer. The framerate of virt-viewer is low-ish (around 30fps) but usable.
I’ve started trying Looking Glass today, and after getting the shmem stuff setup, have it working.
However, the framerate is much lower than virt-viewer. I’ve got a demo video recorded that shows native linux (firefox), virt-viewer, and Looking Glass.
Looking Glass noticably lowers the performance of the viewer (~30fps to ~10fps), and I’m not quite sure why.
Looking glass is a taxing application. To expect performance, you must have a dedicated GPU properly PCI passed-through to the VM. Your setup simply does not fit the minimum requirements. Both single GPU setups and systems that use iGPU’s are known to have major issues and I’m actually quite amazed you got anything working.
Windows resolution 1900x1200, refresh rate is 74.999hz (and is the only choice available).
CPU is i5-6600T (a few years old, not the speediest)
You mentioned cpu pinning, so I tried a small experiment:
Give VM 2 cores
Pin qemu to cores 1-2
Pin Xorg to core 3
Pin LookingGlass / virt-viewer to core 4
(I also fiddled with pinning xorg/lookingglass/virt-viewer to cores 3-4)
Rough outcome is that virt-viewer now peaks around 50fps on a webgl blob demo, and LookingGlass raises from ~10fps to ~20fps. Note that these fps numbers are as reported by the webgl demo itself, not by windows or the viewer (virt-viewer or lookingglass).
Pinning seems to help quite a bit which makes sense.
When running LookingGlass with win:showFPS set, it usually hovers around this: UPS: 20 FPS: 40
Fiddling with CRU to add a 60hz refresh rate, and I don’t notice any performance differences between ~75hz and ~60hz.
I’m actually quite amazed you got anything working.
Maybe this year is Year of Linux on the Desktop? I am also surprised I get anything working (ever) on a computer
The physical cpu has 4 cores with no hyper threading.
My assumption may have been wrong about Looking Glass? The performance claims WRT memory copies vs other graphics transfer methods, to me, should predict that looking glass is faster than other methods on the same hardware.
What I’m saying is I was expecting virt-viewer to have worse performance than looking glass, and I’m observing that, at least for my scenario, it has much better graphics performance in all scenarios I’ve tested (4 cores for the vm, 2 cores for the vm, cpu pinning, etc).
Should looking glass be faster (use less resources, etc) in this scenario?
As @gnif explained, you are starving the VM of resources. At that point it does not matter what viewing method you are trying to use as everything will bog down. spice requires less resources than LG and so will start performing better than LG. Once you throw enough resources at LG, it will outperform spice by both speed and most importantly latency by multiple factors. Copying frames from the GPU to shared memory is done in software and moves lots of data very fast. this requires substantial compute power, then on the host all this stream is copied very fast to the host GPU. there’s no compression, no lossiness and no effort to save bandwidth on account of image quality and production latency. Bandwidth is also something that you lack with the use of an iGPU instead of the classic setup of two dedicated GPUs that do not share PCIe lanes.
I think we’re glossing over a few things with broad-stroke suggestions like “starving of resources” and such.
I’ll accept that looking glass probably doesn’t work for my scenario.
it does not matter what viewing method you are trying to use as everything will bog down
Does it bog down? This isn’t my experience. Fusion360 runs quite well under qemu + virt-viewer when the vm has only two cores, especially considering the age and abilities of the hardware.
Once you throw enough resources at LG
The requirements on looking-glass.io don’t list minimum compute requirements. Any thoughts on adding some text describing this? I looked around a bit to see if there was a git repo I could send PRs to, but I didn’t find one.
I noticed that while looking-glass-client is active, the looking-glass-host process in the VM consumes a whole cpu core. I haven’t looked at the code, but I assume some of this delay is some kind of locking during the frame copies? and frame copies perhaps take so long (on my hardware?) that the overall rendering performance in the VM itself degrades?
Happy to help write/edit any suggested requirements/performance notes (cpu pinning, capacity planning a cpu core (or two?) to the frame pipeline, etc)
Because it’s in flux, LG is still Beta software and is under VERY active development.
It’s a non-obvious github logo on the bottom of the page, we don’t want non developers using the git repo directly. https://github.com/gnif/looking-glass
Correct, and as your copy is slow due to not enough CPU resources it’s stuck in a spinlock far too long. You need to give your VM more cores and observe CPU pinning requirements for LG.
