Looking Glass slows Windows 10 to a halt

Software & Operating Systems Looking Glass
1

I am currently using an HDMI switch to switch between my CPU HDMI and GPU HDMI, along with QEMU for the Windows 10 virtual machine. I am using version B2-rc4 and when Looking Glass opens, it gets stuck on the logo screen, and if I switch to my GPU HDMI, it slows the VM down to a halt. Closing Looking Glass on my Linux machine will then resume the Windows machine and open everything that I tried to open when LG was running. Let me know if you need more information, I’m new at this.
Thank you!

Host Logs:

30018843 [I]           platform.c:329  | app_init                       | System timer resolution: 48.82 ns
30019472 [I]                app.c:444  | app_main                       | Looking Glass Host (B2-rc4-0-g969effedde)
30025420 [I]                app.c:454  | app_main                       | IVSHMEM Size     : 32 MiB
30025741 [I]                app.c:455  | app_main                       | IVSHMEM Address  : 0x2540000
30026022 [I]                app.c:456  | app_main                       | Max Pointer Size : 64 KiB
30026323 [I]                app.c:457  | app_main                       | KVMFR Version    : 2
30026613 [I]                app.c:505  | app_main                       | Max Frame Size   : 15 MiB
30026930 [I]                app.c:520  | app_main                       | Trying           : NVFBC (NVidia Frame Buffer Capture)
30036011 [I]          wrapper.cpp:88   | NvFBCInit                      | NvFBC SDK Version: 112
30196845 [I]                app.c:520  | app_main                       | Trying           : DXGI
30277918 [I]               dxgi.c:388  | dxgi_init                      | Device Descripion: NVIDIA GeForce GTX 970
30278254 [I]               dxgi.c:389  | dxgi_init                      | Device Vendor ID : 0x10de
30278514 [I]               dxgi.c:390  | dxgi_init                      | Device Device ID : 0x13c2
30278795 [I]               dxgi.c:391  | dxgi_init                      | Device Video Mem : 4043 MiB
30279075 [I]               dxgi.c:392  | dxgi_init                      | Device Sys Mem   : 0 MiB
30279332 [I]               dxgi.c:393  | dxgi_init                      | Shared Sys Mem   : 5118 MiB
30279624 [I]               dxgi.c:394  | dxgi_init                      | Feature Level    : 0xb100
30279902 [I]               dxgi.c:395  | dxgi_init                      | Capture Size     : 1920 x 1080
30280256 [I]               dxgi.c:396  | dxgi_init                      | AcquireLock      : enabled
30281421 [I]               dxgi.c:518  | dxgi_init                      | Source Format    : DXGI_FORMAT_B8G8R8A8_UNORM
30282255 [I]                app.c:542  | app_main                       | Using            : DXGI
2

Why are you using B2-rc4? Please use B2

3

I have the same problem using both B2 and B3-RC1.
Using B2 for further testing the crawling to a halt seems to be caused by excessive CPU usage by the host. Reducing the priority from high to normal yields a usable windows.

Despite the high usage no image / cursor is actually shown by the client.
Pressing ctrl-alt-del triggers a single screen update (i.e. the monitor now shows the ctrl-alt-del screen and the client shows the desktop as it was before). The Client now shows a continuously updated mouse cursor.
Exiting out of the screen triggers another single copy (i.e the monitor returns to the desktop and the client now shows the ctrl-alt-del screen.) The mouse still updates continuously.
The CPU usage keeps high all the while.

I don’t have the logs on hand but can post them if needed. (They didn’t look out of the ordinary though)

I had it working with some older versions on the same hostpc / vm but didn’t use it for several months. Most significant change since then should be changing the VM GPU from GTX 1060 to RTX 3070. I didn’t try the old version before updating to B2.

I can do further testing if needed. (I need windows binaries but compile my own linux ones. I know my way around git too.)

4

The Problem is indeed related to the CPU. Further testing (using B3-rc1-40-g32d8a47cd9 this time) showed that it works if I increase the vCPUs from 1 to 2. Both CPUS are then run on ~40% load which should in principal work on a single CPU to, if a bit slower. My guess would be some kind of inverse concurrency problem. Switching between 1 and 2 CPUs reproduces the respective behaviour.

1 Like
5

Looking Glass requires both the host and the gust to be quite powerful systems, lack of CPU time due to lack of cores and/or failure to pin them will cause issues. LG uses very few CPU resources, but if you do not give it enough CPU to keep up it backlogs and your whole system slows down.