oooh gotcha. Thank you
Thanks for explanation 
I just wonder how does it works on lowest level on the client side (Linux host), does this frame pulling and displaying handle CPU or iGPU (if I have integrated it in CPU), because I think iGPU should have direct access to that memory block where are frames saved, and then it should just display it.
No, this is never the case, the texture has to be uploaded from system ram to the GPU even when it’s an iGPU
As far as I know, it works like that CPU should upload texture to GPU VRAM (if you have normal dedicated GPU), but iGPU doesn’t have dedicated VRAM as dedicated GPUs, so iGPU uses RAM as VRAM (generally), so why CPU have to copy texture from memory block (from RAM) provided by looking glass into iGPU “VRAM” (RAM)? It just looks like waste of CPU cycles. I think there could be some very good performance improvement.
Because of how the hardware and API works, it’s not possible.
A host side change just went in that might have finally resolved the capture performance issues at 4K with DXGI… please people give it a go, I am very keen to know if it has improved things.
If you would like to try it please get the host build at 21b02efb from the website under Bleeding Edge, please be sure your client is also recent (ideally the same version).
Using -K option (without any value) causes the host GPU fan speed to ramp-up @100% in no time!
Using a Radeon RX Vega64 on the host and an RTX 2080 on the guest.
Using Ubuntu 19.04 on a Ryzen 2700X.
$ gdb ./looking-glass-client
GNU gdb (Ubuntu 8.2.91.20190405-0ubuntu3) 8.2.91.20190405-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./looking-glass-client...
(gdb) set args -a -K -s
(gdb) r
Starting program: /home/maestro/Git/LookingGlass-a12/client/build/looking-glass-client -a -K -s
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[I] main.c:757 | run | Looking Glass ()
[I] main.c:758 | run | Locking Method: Atomic
[New Thread 0x7fffef206700 (LWP 9235)]
[New Thread 0x7fffee8c4700 (LWP 9236)]
[New Thread 0x7fffee0c3700 (LWP 9237)]
[New Thread 0x7fffed8c2700 (LWP 9238)]
[New Thread 0x7fffed0c1700 (LWP 9239)]
[New Thread 0x7fffec8c0700 (LWP 9240)]
[New Thread 0x7fffd7fff700 (LWP 9241)]
[New Thread 0x7fffd77fe700 (LWP 9242)]
[New Thread 0x7fffd6ffd700 (LWP 9243)]
[New Thread 0x7fffd67fc700 (LWP 9244)]
[New Thread 0x7fffd5ffb700 (LWP 9245)]
[New Thread 0x7fffd57fa700 (LWP 9246)]
[New Thread 0x7fffd4ff9700 (LWP 9247)]
[New Thread 0x7fffb3fff700 (LWP 9248)]
[New Thread 0x7fffb37fe700 (LWP 9249)]
[New Thread 0x7fffb2ffd700 (LWP 9250)]
[New Thread 0x7fffb27fc700 (LWP 9251)]
[New Thread 0x7fffb1ffb700 (LWP 9252)]
[New Thread 0x7fffb17fa700 (LWP 9253)]
[New Thread 0x7fffb0ff9700 (LWP 9254)]
[Thread 0x7fffb0ff9700 (LWP 9254) exited]
[New Thread 0x7fffb0ff9700 (LWP 9255)]
[Thread 0x7fffb0ff9700 (LWP 9255) exited]
[I] main.c:751 | try_renderer | Using Renderer: EGL
[I] main.c:824 | run | Using: EGL
[New Thread 0x7fffb0ff9700 (LWP 9257)]
[Thread 0x7fffb0ff9700 (LWP 9257) exited]
[New Thread 0x7fffb0ff9700 (LWP 9258)]
[I] spice.c:159 | spice_connect | Remote: 127.0.0.1:5900
[New Thread 0x7fff91fff700 (LWP 9259)]
[I] egl.c:351 | egl_render_startup | Vendor : X.Org
[I] egl.c:352 | egl_render_startup | Renderer: Radeon RX Vega (VEGA10, DRM 3.27.0, 5.0.0-15-generic, LLVM 8.0.0)
[I] egl.c:353 | egl_render_startup | Version : OpenGL ES 3.2 Mesa 19.0.2
[New Thread 0x7fff917fe700 (LWP 9260)]
[I] main.c:961 | run | Waiting for host to signal it's ready...
[I] spice.c:367 | spice_on_common_read | notify message: keyboard channel is insecure
[I] main.c:970 | run | Host ready, starting session
[New Thread 0x7fff90ffd700 (LWP 9261)]
[New Thread 0x7fff83fff700 (LWP 9262)]You’re running A12… please upgrade to B1-rc2 or later.
Is it backported to the fallback versions so that Win 8.1 could potentially use it? If so, I may just be testing Beta 1 (final) as a result and will try to build that specialized OBS build for further testing.
There is no “fallback versions”, all versions of LG are compatible with Win 8.1 as of A12.
Hmm. Will have to test once Beta 1 stable lands to see if 4K performance is improved.
B1-rc3 solved the problem with GPU fan speed going 100% with -K option, great!
A couple of things:
-
Had to install binutils-dev to compile latest beta versions of LG
-
looking-glass-host.exe 438e9e09 won’t automatically start when user logs in (still shows B1-rc2 according to the logs)
Using REG_SZ value (path pointing to .exe is correct) from HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run -
Mouse cursor does not always appear until you click on the Windows start button: I’m using EVDEV, could this be the issue?
-
./looking-glass-client can take from 1 to 20 seconds to display the Windows screen (random time but generally instant)
Just using -a -r arguments -
Noticed on the -n option , the description field shows ‘Aallow’ instead of ‘Allow’
This is known, see client/README.md
Correct, because it needs admin rights now. You need to setup a task via Task Scheduler to launch it with privileges. This will be documented along with B1 release
Not an issue, this is for my tracking, it states +1 for a reason.
No, it’s a cursor shape sync issue I am yet to resolve.
Again, waiting for the first frame from the new host, this needs a bit of work. Just hit the windows key or something to prompt a frame update.
Thanks, fixed.
Btw, this makes complete sense as you were disabling the fps limiter on the client, you should NOT do this, not only will it cause performance issues (GPU starved of resources), it will as you noticed consume 100% GPU, a ton of power, and on some cheaper GPUs could cause them to fry.
Rule of thumb, the FPS limiter should be 2x your screen refresh at most!, so at 60Hz for best performance you should render at 120FPS.
Excellent, thanks for the great info
For those that want to know how this was achieved I wrote a quick post over on Patreon and KoFi
3 Likes
1 Like
Oops, one more thing: after rebooting my machine, I can’t start the LG client anymore.
$ whoami
maestro
$ ./looking-glass-client -a -r
[I] main.c:963 | run | Looking Glass (B1-rc2-6-g9554e82c47+1)
[I] main.c:964 | run | Locking Method: Atomic
[I] main.c:899 | try_renderer | Using Renderer: EGL
[I] main.c:1125 | run | Using Clipboard: X11
[I] spice.c:197 | spice_connect | Remote: 127.0.0.1:5900
[E] spice.c:1306 | spice_read_nl | remote end closd connection after 12 byte(s)
[E] spice.c:795 | spice_connect_channel | failed to read SpiceLinkHeader
[E] spice.c:203 | spice_connect | connect main channel failed
[E] main.c:1175 | run | Failed to connect to spice server
[E] crash.linux.c:170 | crit_err_hdlr | ==== FATAL CRASH (B1-rc2-6-g9554e82c47+1) ====
[E] crash.linux.c:171 | crit_err_hdlr | signal 11 (Segmentation fault), address is (nil)
$ ls -l /dev/shm/looking-glass
-rw-r--r-- 1 maestro kvm 33554432 May 27 14:11 /dev/shm/looking-glass
$ cat /etc/group | grep kvm
kvm:x:108:maestro
QEMU is ran as kvm (user and group) in /etc/libvirt/qemu.confDid you change it from spice to vnc on the vm?
Actually, I don’t have any Spice server on the VM (and never had).
Hum…