Ever since I’ve been using GPU Passthrough, I’ve wanted a way to interact with the Windows VM from the Linux desktop. Whether it’s for playing the latest AAA title or working with Adobe Premiere or AutoCAD, it’s always been a dream of mine to have the ability to keep all my monitors on the Linux host and still be able to work in the Windows VM. Looking Glass makes that a reality.
Read also: A Quick and Dirty Arch Passthrough Guide
Looking Glass is an open source (GPLv2) software project that makes use of an agent running on the VM to copy the framebuffer from a VM’s display to shared memory between the VM and host machine. The use of shared memory forwards the goal of low latency display. The Creator, Geoffrey invited me to assist in testing the pre-release of the software. This gave me the ability to get an inside scoop.
Since we’re releasing Looking Glass today, I thought it would be good to share my experiences with it. When I first got into the super secret development thread, I found a wealth of information. I got right to work following their guidelines to get everything up and running. After sorting out some SELinux problems I had a functioning Looking Glass on Fedora 27.
Down to Business
When I first got the system working, I loaded up the Frameskipping Test to check latency. You’ll be pleased to know that in my first experience with Looking Glass, the host was only one frame behind the guest. This is a truly awe-inspiring accomplishment considering the pre-release status of the software.
The performance of Looking Glass left me dumbfounded while playing Overwatch. I was able to play at 1080p, 60fps with very little latency. Without using any formal test method, my eyes could notice a slight latency between the guest and host. Note that I was using a 1070 Ti in the VM and an RX 580 to power the host. One thing we’ve discovered with testing is that the AMDGPU driver is not great when it comes to latency. Geoffrey will work on this issue when he gets his hands on more AMD hardware.
Being below-average at overwatch and wanting to enjoy this new experience as much as possible, I fired up my favorite game, Mass Effect 2. During the prologue mission, I completely forgot that Looking Glass was sharing the VMs display with the Host. It’s just that smooth. I decided I would play one more mission and wound up sinking most of the evening into reliving my past. One thing that’s important to mention about Looking Glass is that it’s not only for games. Because the DXGI interface can capture the Windows 10 desktop, you can use any program you want to! To test it out, I fired up AutoCAD and loaded up a few complex models. I noticed no difference between native, bare metal performance and the visual experience was as good as any other system.
Satisfied that it’s working well, I decided to do some benchmarks. First thing I loaded up was the UFO frameskipping test. I grabbed my GoPro, set it to 120fps and aimed it at my monitors. As you can see from the image below, the Linux host is rendering frames slightly ahead of the Windows guest. This is because the client can sometimes get a frame before the guest (windows) starts waiting for vsync on the monitor, allowing the client to present faster. We’re never going to be able to get the frame on the client before the host finishes rendering it, but this is about as close as we can come.
One of the neat features of Looking Glass is the separation of the cursor from the rest of the frame. Looking Glass takes the cursor and renders it separately from the actual video data. This provides lower perceived latency in situations where latency is high. I’ve found that it does help make mouse movement feel more natural in games (when the mouse is shown) and around the desktop.
There are some issues that I’ve experienced so far, all quite jarring. Chief among them is the qemu PS2 mouse race condition. When I was playing games, I encountered an error where the mouse would stop responding. This bug is due to the way that qemu emulates PS2 devices. A multiplexer provides access to both the keyboard and mouse. When you hold down a key and move the mouse the system reads a lot of invalid scan codes. This indicates that the system is interpreting the mouse movement as keyboard input. Once this happens enough, the mouse gets out of sync and stops responding. Using the VirtIO keyboard can resolve this a certain amount.
The other main issue is one of latency and choppiness. Compositing Desktop Environments add latency. A lot of latency. On Wayland Gnome, I’ve seen almost 300 milliseconds of latency. The solution, for me, is to move from Gnome to i3. As soon as I did so, I encountered almost no perceptible latency leading to a much better experience.
Nvidia guests also require you to disable driver-side display scaling. This fixes mouse movement errors when you aren’t using relative movement mode. On top of this, AMD GPU hosts have some more latency, something I alluded to above. This has to do with the render composition pipeline.
The last issue I ran into involves the ivshmem device driver. When you update the driver in Device Manager, the VM will crash. There is a patch coming from Ladi Prosek, of Red Hat, to address this issue. Until the patch is out the crash is unavoidable. Just apply the patch and start the VM again.
All in all, looking glass is a wonderful tool with great potential. The software does what it intends to do with very few bugs, which is quite impressive for a pre-alpha system. The project has also done the service of exposing a lot of bugs in qemu, radeon, and AMDGPU. Testers have submitted bug reports to the proper channels and we are following the lists. Looking Glass has the brain trust and momentum behind it to meet and exceed its goals. I’ve got a feeling that 2018 is going to be a good year for virtualization and passthrough.
Are you excited about Looking Glass? Is there a feature you’d like to see? Let us know in the comments, we’re eager to hear from the community!
Join our discord and discuss Looking Glass with our authors and the community!
Correction: gnif, the developer of looking glass, pointed out a mistake in our reporting, issuing this statement to us in response:
“The cursor is not drawn based on the local mouse position, it’s drawn at the reported position by the guest, the drawing is split out simply so we can update the cursor without waiting for vsync. If there is cursor input lag, you will still get it just the same.”
Images courtesy Pixabay