Return to Level1Techs.com

Looking Glass - Triage

helpdesk
lookingglass

#1201

I have been dealing with some “performance” issues when using looking-glass (1440p, I know not really supported) and it was driving me insane. I am running my setup passing through everything, except mouse and keyboard (evdev for these) and expected performance to be good. I am using Q35 as it has been easier for me to dual-boot the VM.

Most games run OK, except, some times, I will see looking-glass using 30% gpu and games just slow to a crawl. Guild Wars 2 would play crappy from time to time. Also, the gpu would, randomly, go to P2 state (600mhz!)

Apparently, under some configurations, if you have the video card attached to a pcie-root-port (the proper way) nvidia driver can just go nuts and downclock the bus from gen3 to gen1 (it always stays at 16x). I have tried different power profiles, regedit hacks and only one thing worked: plug the GPU and the hdaudio straight into the pci-root bus. I have even turned optimal power and the gpu will downclock (and go to gen1 mode) properly and scale back when needed.

With this, Looking Glass is working perfectly fine at 1440p and 60 fps (1080 strix). Maximum is around 5% utilization for the looking-glass-host.

Do not use GPU-Z to verify your current pci-e speeds, the report is usually wrong. Nvidia inspector has been a little better, but I use this to verify:

#Replace 43:00.0 with bus:slot.func used by your passthrough graphics card
sudo lspci -s 43:00.0 -nvv|grep LnkS

The first line output should be something like:

LnkSta:	Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

8GT/s = gen3
5GT/s = gen2
2.5GT/s = gen1

My system always boot as G1 (I think that’s normal) but it will change later to the higher speed when gaming (or under prefer maximum performance). Using Aida64 GPGPU test, I also get close to 12000MB/s on memory test, while gen1 gives 3600MB/s…

This is definitely triggered by the driver, considering my nvme and other devices work without problem at 8x, I am not sure if this is a bug, poor implementation on qemu’s side or nvidia shenanigans.

If you are having some performance problems with looking-glass, check out your lspci output while gaming, it could be related to this. @gnif, I think this should definitely be checked before confirming performance issues.

P.S.: According to some thread on reddit, i440fx doesn’t suffer from this. I wasn’t able to test though.


#1202

If you are having the same issue I was, I found a work around.

For some reason spice has started using port 5901 instead of the default 5900 that Looking Glass is expecting.

Appending the -p 5901 flag while launching looking glass solved my issue.

Now why the port for spice changed I have no idea which is rather frustrating.


#1203

In my opinion, it might be better to use unix sockets instead of tcp ports if you like spice.


#1204

Do you know of any documentation to do this with libvirt?


#1205

I had looking glass working with a real monitor, but since moving to the dummy plug I just get the “Failed to create D3D11 device: 0x887a0004” error. I’m not really sure what to do next to troubleshoot. The ivshmem driver is installed and working, the “generic pnp monitor” shows up as attached to the video card. Does anyone have any pointers on what to check/try next?


#1206

0x887a0004 is usually a driver problem. What is your GPU? And do you have the dummy configured as the primary display? At this time Looking Glass will try to duplicate the first display only, and if it’s a virtual device instead of your GPU it will fail due to the virtual device not supporting DXGI DD.


#1207

Got kind of an interesting situation here.

Running GTX680 for host, GTX1080 for guest, and A11 build of Looking-glass for both. Host OS is Arch, guest is the latest public build of Windows 10 (1803). Resolution is set to 3440x1440 for both host and guest, and naturally, 64mb of memory was specified in libvirt.

When not using Looking-glass and just connecting a monitor, everything runs perfectly fine with no hiccups at all, but when streaming the video via Looking-glass the following occurs.
When not running games, I notice a little bit of a stutter. As soon as I launch any game, my fps drops to probably 30 average, but often much less, while the game is in focus, HOWEVER, when the game is out of focus (another window is open) it runs as fast as it can in the background (in this case it’s WoW with approximately 80fps with my current settings).

Looking-glass is started with -sF parameters. Any idea what’s up? Haven’t found anyone with a similar issue so far


#1208

This is not supported, at current anything mugh higher then 1200p has performance problems.

FPS in what? the game? Looking Glass? Native?

Logs and screenshot(s) are worth a thousand words.


#1209

I apologize, should have started with that. Additionally, I forgot to mention last time that I’m running on kernel 4.18.7 with QEMU 3.0.0 and libvirt 4.6.0.207

In-game FPS (both with a monitor connected and/or with Looking Glass, makes no difference)
1
Looking Glass UPS/FPS when game is in focus
2
Looking Glass again, but when the game is in the background
4


#1210

What are you using for audio? When WoW is backgrounded I assume it’s audio is muted/stops. If your audio is not functioning properly it directly affects timing in most DirectX titles.

Other then that, I am not sure what would cause a UPS increase while backgrounded, perhaps WoW is disabling some features while it doesn’t have focus.

The root problem you have however is your resolution is just way too high for LG at this point.


#1211

I have an external DAC connected via optical, which is passed through to the VM with the entire onboard audio controller.

Wasn’t aware of the current resolution limit until you’ve mentioned it. Wendell said in his video that a the theoretical limit is [email protected] FPS, so I hastily assumed that’s what is can currently handle. Gonna try running it at something more reasonable and report if I see any changes


#1212

Hey all,

I’ll go ahead and be that guy, making an account just to ask one question :sweat_smile:
I just got another gt710 so I could virtualize my linux desktop, and everything went fine. What I’m confused on is how I can get LG working guest>guest. I can’t seem to get the uio device to show up in /dev/ no matter what combination of modprobe uio, modprobe kvmfr, insmod kvmfr.ko, etc I do to try and get it working. Is there a more detailed process that I’m missing? I figured that I’d have do to something on the host to get the linux guest to be able access the shared memory, but I’m totally lost on what I need to do/add.


#1213

Finally decided to attempt to jump in on Looking Glass.

I cloned the git repo, ran cmake, ran make, and it dropped looking-glass-client in the LookingGlass git directory in my home folder, not in bin.

Here’s the entire console process:

[[email protected] client]$ cmake /home/marasm/LookingGlass/client/
-- The C compiler identification is GNU 8.1.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.4.2") 
-- Checking for modules 'sdl2;SDL2_ttf;gl;glu;egl;spice-protocol;fontconfig;x11;libconfig;nettle;hogweed'
--   Found sdl2, version 2.0.8
--   Found SDL2_ttf, version 2.0.14
--   Found gl, version 18.0.5
--   Found glu, version 9.0.0
--   Found egl, version 18.0.5
--   Found spice-protocol, version 0.12.14
--   Found fontconfig, version 2.13.0
--   Found x11, version 1.6.5
--   Found libconfig, version 1.5
--   Found nettle, version 3.4
--   Found hogweed, version 3.4
-- GMP libs: /usr/lib64/libgmp.so /usr/lib64/libgmpxx.so
-- Found GMP: /usr/include  
-- Configuring done
-- Generating done
-- Build files have been written to: /home/marasm/LookingGlass/client
[[email protected] client]$ make
Scanning dependencies of target looking-glass-client
[  7%] Building C object CMakeFiles/looking-glass-client.dir/main.c.o
[ 14%] Building C object CMakeFiles/looking-glass-client.dir/lg-renderer.c.o
[ 21%] Building C object CMakeFiles/looking-glass-client.dir/ll.c.o
[ 28%] Building C object CMakeFiles/looking-glass-client.dir/utils.c.o
[ 35%] Building C object CMakeFiles/looking-glass-client.dir/spice/rsa.c.o
[ 42%] Building C object CMakeFiles/looking-glass-client.dir/spice/spice.c.o
[ 50%] Building C object CMakeFiles/looking-glass-client.dir/decoders/null.c.o
[ 57%] Building C object CMakeFiles/looking-glass-client.dir/decoders/yuv420.c.o
[ 64%] Building C object CMakeFiles/looking-glass-client.dir/renderers/opengl.c.o
[ 71%] Building C object CMakeFiles/looking-glass-client.dir/renderers/egl.c.o
[ 78%] Building C object CMakeFiles/looking-glass-client.dir/renderers/egl_shader.c.o
[ 85%] Building C object CMakeFiles/looking-glass-client.dir/renderers/egl_texture.c.o
[ 92%] Building C object CMakeFiles/looking-glass-client.dir/renderers/egl_model.c.o
[100%] Linking C executable looking-glass-client
[100%] Built target looking-glass-client

If I just move the client to bin where it should be, will that cause any issues? Did I do something wrong? OS is Fedora 28 Workstation.


#1214

The bin directory only exists for the older Makefile build in A11, you are building from master which is unreleased and as such the documentation has not yet been updated for it.


#1215

My use case is I’d want to be using my multiple, different size and refresh rate displays with no performance impact in windows, Including 144hz gsync support.

As I’d still use the windows VM as my main desktop, and the linux side would only be used when I need to use linux, It seems like all of my problems would be solved by having the linux host send its screen to the windows guest, essentially reversing looking glass.

I see you are working on OpenGL support, I’m not going to even pretend to understand most of the code base, but from what I’ve seen it looks like it works via a DirectX screen grabbing function, which Isnt going to work on linux (I did try wine-ing it to see what would happen, I got driver install errors as expected).

Would absolutely love to see support for my usecase, as it would let me move from having windows on bare metal.


#1216

At this time, there is absolutely no incentive to port the host application to Linux, the goal of this project is to allow Linux to become your primary OS and allow access to Windows for Legacy programs.

If someone decides to write a KVMFR host for Linux, they are welcome to, but it is unlikely to ever be an official part of Looking Glass.


#1217

Yeah, I can understand that, I’ve set up a cheap Pentium second PC so I can have a Linux desktop and a windows desktop without any of the compromises that exist with running windows in a VM. Just figured I’d post it here as suggested Incase anyone felt like one hell of a challenge.


#1218

Why wouldn’t you just use the Windows subsystem for Linux for your windows box?


#1219

You could look at Newtek NDI and Spice over a LAN or Synergy for something like that. NDI is pretty low latency if setup properly.


#1220

@gnif

Not sure if I should do this here or on github, but I have been testing the last few additions you did on the master branch (I first updated it on October 4, then October 10). For both cases I started to notice some delay on frames being delivered to the client.
The way I perceive this is through mouse interaction: keep moving the mouse in circles and my movement doesn’t match what is on the screen anymore, I get up to 3 seconds of delay.
It when I stop moving the mouse, everything catches up and is synchronized again. I can usually replicate this if the mouse cursor change shape while moving it very fast in that circular movement.
Curious part is, the delay is only related to the mouse cursor plotting, I have a clock with the seconds going down and it is completely in sync between host and guest.

This is happening for me with a nvidia 1080. Let me know if you need more info or if I should open up something on github instead (kind of too vague for gh I think).