Looking Glass - Triage

Vega reset Kernel Patch? @gnif?

Itā€™s no fix, itā€™s a workaround. The GPU still will not reset if the guest VM crashes or is hard reset.

Iā€™m having trouble getting the Windows host application to run. Everything seems to be set up correctly but when I try to run the host it exits immediately (even when passing -f), and I only ever get a blue screen in the client application.

My VM config: https://pastebin.com/xcaHw8vp

Output from the client:

$ looking-glass-client 
[I]               main.c:692  | run                            | Looking Glass ()
[I]               main.c:693  | run                            | Locking Method: Atomic
[I]               main.c:686  | try_renderer                   | Using Renderer: OpenGL
[I]               main.c:775  | run                            | Using: OpenGL
[I]              spice.c:159  | spice_connect                  | Remote: 127.0.0.1:5900
[I]               main.c:901  | run                            | Waiting for host to signal it's ready...
[I]              spice.c:367  | spice_on_common_read           | notify message: keyboard channel is insecure
[I]             opengl.c:552  | pre_configure                  | Vendor  : X.Org
[I]             opengl.c:553  | pre_configure                  | Renderer: Radeon RX Vega (VEGA10 / DRM 3.25.0 / 4.17.14-202.fc28.x86_64, LLVM 6.0.0)
[I]             opengl.c:554  | pre_configure                  | Version : 3.0 Mesa 18.0.5
[I]             opengl.c:566  | pre_configure                  | Using GL_AMD_pinned_memory

Iā€™m using A11 of both client and host, from the tagged release.

Host GPU is a Vega 56, guest is R9 290.

Have I missed something?

Unfortunatly the A11 host requires AVX extensions, ensure your libvrit CPU is set to host-passthrough. This has been fixed for later versions when they are ready.

Thanks, that looks like it was it - borrowed a CPU config block from https://github.com/gnif/LookingGlass/issues/76#issuecomment-394200128 and Iā€™m getting video in the client.

I get a hard crash loop on VM startup if I use host-passthrough, but with a custom CPU based on qemu64 with the additional instructions from the issue comment it seems happy.

Thanks again!

Iā€™ve been using looking glass for a few weeks now and its wonderful. One thing i have noticed on my probably less than optimal setup is that there is allot of stuttering when network trafic in the windows vm is high. This stuttering is most consistent and reproduce able for me when downloading steam games @25MB/s. The stuttering is probably due to the CPU usage going so high and not related to looking glass itself but iā€™ve not seen any discussion about this yet so i thought i should mention it.

Iā€™m still quite new to running windows in a vm so iā€™m going to put some effort into the network setup today so any advise is welcome. iā€™m using the rtl8139 device right now. But iā€™m sure there is more optimal alternatives available. If not, Should I buy and passtrough a network card if possible?

Use a VirtIO network device. You may also be hitting I/O issues with disk write, are you using a flat image? a disk? or COW image?

iā€™m using a dedicated SSD for the windows vm as i still want to be able to boot it whenever i need too. I will try the VirtIO device. thanks

Using the VirtIO network device seems to have fixed the stuttering issue.

Whoa there. That means my Sandy Bridge Xeon is JUST barely able to support Looking Glass. So unfortunately for X58 Xeon users, Looking Glass wonā€™t work for those machines.

For the moment, A12 has a fix for this that lowers the minimum requirements to a SSE2 capable CPU.

Okay, would be interesting to see some X5650/X5675 Xeons try to run Looking Glass on that then. Those I know will support SSE2.

The reason I ask is because the cheese grater Macs run those processors. Would be very interesting to see GPU passthrough work on that.

Hmm this looks interesting, is it something that could be of value? You said earlier that vulcan was very complex. Iā€™m just an electronics engineer so the software side is not one of my strengths.

1 Like

That looks very interesting, thanks! I will have a look in depth when I get time.

1 Like

Iā€™m not sure if this is the right place, but i didnā€™t want to make a seperate thread for this.

Can someone tell me what the expected performance penalty for PCIe Passthrough of a GPU is (with a Monitor attached or with Looking Glass)? Iā€™m juggling upgrade ideas and basically would get an Overkill 1080 just to run some games through wine that lose performance. If i could repurpose my 1050ti without (major) performance loss, a RX580 might suffice for all my Linux Gaming needs. Which would save money and give me an AMD Card for better compatibility.

Basically none. The hit comes from CPU virtualization, not the GPU.

1 Like

Thanks. That helps. I just remembered that i have a G-Sync Monitor. Now i need to look into what happens with that and an AMD Card that wonā€™t hit itā€™s 144Hz Refresh Rate. I suddenly realize what all those iOS people mean when they are talking about ā€œbeing locked in the echosystemā€ :wink:

Edit: While weā€™re at that topic, does G-Sync work with GPU Passthrough? It should from my understanding, just not with Looking Glass, Correct?

FS and GS do not work with LG, the only way to get that stuff to work IIRC is to pass through a GPU to a guest and then the guest GPU connects to the monitor and that stuff should work.

TBH Iā€™m not an expert on this stuff. you should check out the one stop shop thread.

1 Like

Thanks, iā€™ll check that, but logically it makes sense.

i am trying to setup looking glass. from following the official instructions under their websiteā€™s ā€œquickstart guideā€ this now happens when i attempt to start my VM.

error: internal error: qemu unexpectedly closed the monitor: 2018-09-01T05:38:06.979529Z qemu-system-x86_64: -object memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/looking-glass,size=33554432,share=yes: canā€™t open backing store /dev/shm/looking-glass for guest RAM: Permission denied

i have tried my google-fu for the past few days and can find no solution.