Return to Level1Techs.com

Looking Glass - Guides, Help and Support

iommu
lookingglass

#740

Thanks. I have VS2017 functional again. Rebuild …-host.exe looks successful (.exe was builded). Influence of changes to cpu load i’m going to post later (I’m on the road right now).

Screenshot

http://www.monitos.cz/tmp/20180524_build_LG_client_and_host.png

Older version of host ended with version missmatch warning (terminal on top of screeshot)

Backtrace (all newest from git .. client, host)
GNU gdb (Ubuntu 8.0.1-0ubuntu1) 8.0.1
Copyright (C) 2017 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...done.
(gdb) set args -a -k -s -M -d -o opengl:vsync=1 -f /hugetlbfs/looking-glass
(gdb) r
Starting program: /home/pburic/LG/client/bin/looking-glass-client -a -k -s -M -d -o opengl:vsync=1 -f /hugetlbfs/looking-glass
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[I]               main.c:695  | run                            | Looking Glass (a10-94-g5de9a8dce6)
[I]               main.c:696  | run                            | Locking Method: Atomic
[I]               main.c:689  | try_renderer                   | Using Renderer: OpenGL
[I]               main.c:778  | run                            | Using: OpenGL
[I]               main.c:897  | run                            | Waiting for host to signal it's ready...
[I]               main.c:901  | run                            | Host ready, starting session
[New Thread 0x7fffe3bff700 (LWP 4800)]
[New Thread 0x7fffdbfff700 (LWP 4801)]
[New Thread 0x7fffe33fe700 (LWP 4802)]
[I]               main.c:177  | updatePositionInfo             | client 3840x2160, guest 3840x2160, target 3840x2160, scaleX: 1.00, scaleY 1.00
[I]               main.c:177  | updatePositionInfo             | client 1024x768, guest 3840x2160, target 1024x576, scaleX: 3.75, scaleY 3.75
[W]               main.c:180  | updatePositionInfo             | Window size doesn't match guest resolution, cursor alignment may not be reliable
[I]               main.c:177  | updatePositionInfo             | client 3840x2160, guest 3840x2160, target 3840x2160, scaleX: 1.00, scaleY 1.00
[I]             opengl.c:539  | configure                      | Vendor  : NVIDIA Corporation
[I]             opengl.c:540  | configure                      | Renderer: GeForce GTX 960/PCIe/SSE2
[I]             opengl.c:541  | configure                      | Version : 4.6.0 NVIDIA 396.18
[I]             opengl.c:577  | configure                      | Using decoder: NULL
^C
Thread 1 "looking-glass-c" received signal SIGINT, Interrupt.
0x00007ffff6032bf8 in __GI___nanosleep (requested_time=0x7fffffffe070, remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:27
27	../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
(gdb) thread apply all bt

Thread 4 (Thread 0x7fffe33fe700 (LWP 4802)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007fffee2ab295 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#2  0x00007fffee2aaf23 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#3  0x00007fffed2bc8ab in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.396.18
#4  0x00007fffed2bd060 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.396.18
#5  0x00007fffed244ab3 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.396.18
#6  0x00007fffece20ebd in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.396.18
#7  0x000055555555ea4a in opengl_render (opaque=<optimized out>, window=<optimized out>) at renderers/opengl.c:411
#8  0x000055555555847e in renderThread (unused=<optimized out>) at main.c:194
#9  0x00007ffff74a275c in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#10 0x00007ffff74f8999 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#11 0x00007ffff5d427fc in start_thread (arg=0x7fffe33fe700) at pthread_create.c:465
#12 0x00007ffff606eb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7fffdbfff700 (LWP 4801)):
#0  0x00007ffff6032bf8 in __GI___nanosleep (requested_time=0x7fffdbffec70, remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:27
#1  0x00007ffff6065184 in usleep (useconds=<optimized out>) at ../sysdeps/posix/usleep.c:32
#2  0x0000555555559a9a in frameThread (unused=<optimized out>) at main.c:319
#3  0x00007ffff74a275c in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#4  0x00007ffff74f8999 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#5  0x00007ffff5d427fc in start_thread (arg=0x7fffdbfff700) at pthread_create.c:465
#6  0x00007ffff606eb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7fffe3bff700 (LWP 4800)):
#0  0x00007ffff6032bf8 in __GI___nanosleep (requested_time=0x7fffe3bfecc0, remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:27
#1  0x00007ffff6065184 in usleep (useconds=<optimized out>) at ../sysdeps/posix/usleep.c:32
#2  0x0000555555558e3a in cursorThread (unused=<optimized out>) at main.c:228
#3  0x00007ffff74a275c in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#4  0x00007ffff74f8999 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#5  0x00007ffff5d427fc in start_thread (arg=0x7fffe3bff700) at pthread_create.c:465
---Type <return> to continue, or q <return> to quit---
#6  0x00007ffff606eb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7ffff7fa2300 (LWP 4795)):
#0  0x00007ffff6032bf8 in __GI___nanosleep (requested_time=0x7fffffffe070, remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:27
#1  0x00007ffff6065184 in usleep (useconds=<optimized out>) at ../sysdeps/posix/usleep.c:32
#2  0x000055555555a854 in run () at main.c:948
#3  0x0000555555557fd9 in main (argc=10, argv=0x7fffffffe3e8) at main.c:1506

CPU load of looking-glass-client is same … 100%+.
I’m ok with that. Thanks.


#741

It seems that the NVidia driver is the cause, sleeping in glFinish. Please try running the client with -o OpengGL:preventBuffers=0.


#742

Congrats. :wink:
./looking-glass-client -a -k -s -M -d -o opengl:vsync=1 -o openGL:preventBuffer=0 -f /hugetlbfs/looking-glass

Idle GuestOS (LG minimized) … only 3%, it is half than before!

top - 23:27:28 up  6:28,  1 user,  load average: 0,43, 0,63, 0,85
Tasks: 504 total,   2 running, 328 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,4 us,  0,4 sy,  0,0 ni, 99,3 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem : 32858808 total,   161000 free, 27687500 used,  5010308 buff/cache
KiB Swap:  4891644 total,  4891644 free,        0 used.  4890076 avail Mem 

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                     
 53911 root      20   0 15,935g 145760  17096 S  18,3  0,4   4:28.28 qemu-system-x86_64 -enable+ 
 54408 root      20   0  734440 151444  77112 S   3,0  0,5   0:02.92 ./looking-glass-client -a + 
 11020 root     -51   0       0      0      0 S   1,4  0,0   0:04.22 [irq/98-nvidia]             
 11018 root      20   0  528240  86028  67640 S   0,6  0,3  11:04.42 /usr/lib/xorg/Xorg -core :+ 
 53897 pburic    20   0  594888  41468  31080 S   0,3  0,1   0:01.81 /usr/bin/xfce4-terminal -x+ 

Under load GuestOS (LG fullscreen borderless) … tearing is screenshots doing

Screenshot

http://www.monitos.cz/tmp/under_load.png


#743

Some mistery: 1st run of GuestOS are UPS ~30% higher UPS:93 versus 71

Summary

http://www.monitos.cz/tmp/1st_run_of_GuestOS.png

Is “-o opengl:vsync=1 -o opengl:preventBuffer=0” correct syntax for using more renderer opts?

Add:
UPS > 60FPS happend in fullscreen mode of 3D benchmark
UPS = 60FPS happend in windowed mode of 3D benchmark


#744

I did also notice CPU at 100% for the looking-glass-client.

This suggestion + some game specific tweaks + maybe even the recent commits seem to really optimize the UPS to a quite acceptable level

It definitely doesn’t always run at the framerate in games but 70-75UPS on a game at 90FPS with a 1440p 144Hz monitor is more than acceptable.

I had to run my display at 60hz before to keep UPS at a smooth level.


#745

Anything higher then 1200p is not supported at this time, we are hitting bandwidth limitations, the fact that it’s running so well at higher for you is just pure luck :slight_smile:

Yes, just repeat the -o switch for each. Note that I also have added a FPS limiter (new switch -K to set it, default is 200FPS) if you really want to run without vsync. Doing so improves latency at the cost of higher CPU load and tearing. If you decide to use this you should run at 2x the guests native FPS, so if the guest is running at 60FPS you should run at 120FPS for best possible latency.


#746

I saw there is debugging for the client; but how would you typically debug the host crashing? (ms debugger maybe?) I’ve had the host crash quite a bit lately, it could be the bandwidth is just insufficient for 1200p+.

Thread 1 "looking-glass-c" received signal SIGINT, Interrupt.
0x00007ffff569bf60 in nanosleep () from /lib64/libc.so.6
(gdb) thread apply all bt

Thread 2 (Thread 0x7fffe9502700 (LWP 25329)):
#0  0x00007ffff56c8801 in select () from /lib64/libc.so.6
#1  0x000055555555d14b in spice_process () at spice/spice.c:207
#2  0x00005555555585a7 in spiceThread (arg=<optimized out>) at main.c:413
#3  0x00007ffff748ed7c in ?? () from /usr/lib64/libSDL2-2.0.so.0
#4  0x00007ffff74fd119 in ?? () from /usr/lib64/libSDL2-2.0.so.0
#5  0x00007ffff53b39ea in start_thread () from /lib64/libpthread.so.0
#6  0x00007ffff56d217f in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7ffff7fa3200 (LWP 25261)):
#0  0x00007ffff569bf60 in nanosleep () from /lib64/libc.so.6
#1  0x00007ffff56c9354 in usleep () from /lib64/libc.so.6
#2  0x000055555555a34a in run () at main.c:900
#3  0x0000555555557fe9 in main (argc=5, argv=0x7fffffffdad8) at main.c:1506
(gdb) thread apply all bt

Thread 2 (Thread 0x7fffe9502700 (LWP 25329)):
#0  0x00007ffff56c8801 in select () from /lib64/libc.so.6
Backtrace stopped: Cannot access memory at address 0x7fffe9501ce8

Thread 1 (Thread 0x7ffff7fa3200 (LWP 25261)):
#0  0x00007ffff569bf60 in nanosleep () from /lib64/libc.so.6
Backtrace stopped: Cannot access memory at address 0x7fffffffd758

Above crash dump was on the client with options

global:
{
  fullScreen=true;
  showFPS=true;
  x=0;
  y=0;
}

in the config and -o opengl:preventBuffer=0 -o opengl:vsync=1 from the command line

after host appeared to stop responding. It happened a few minutes ago.

Looking for the host crash dump now as I believe it’s the host side crashing.

I apologize if this isn’t enough info. i think I’ll have to get a new bug report.

I believe the host was the issue in my case as the screen stopped responded earlier and when I restarted the client, it said it was wainting on the host.


#747

The host program will produce mini crash dumps when it crashes, you can either open them in VS2015 or upload them and I will have a look when I can.

What is the log you provided for? You have not reported a bug, and everything there looks normal.


#748

Where is your client log? What version are you running?


#749

Log from pastebin:

https://pastebin.com/ymQYWiVh

I’m not seeing a straight logfile with looking glass anywhere in my home folder.

Also regarding the possible Windows host application crash, I didn’t see a looking-glass-host.dmp as mentioned in the issue template.

I did build the host in release mode and not debug mode. That shouldn’t stop the crash dump should it?


#750

TL;DR:
I noticed that on Wayland Looking Glass’s v-sync only works on normal windows (not fullscreen, not borderless). This does not happens on a X session.

Long version:
I’ve been testing Looking Glass on an updated Arch Linux running on plasma-wayland-session on my iGPU while running Windows 10 on Nvidia GTX 960 and noticed high cpu usage on guest and host’s looking glass.

I tried to change some options and noticed that on fullscreen (-F) or borderless (-d) or forcing fullscreen (right click title bar -> More Actions -> Special Application Settings…) or disabling title bars (same as forcing fullscreen) on a Plasma Wayland Session causes Looking Glass to ignore v-sync.

The FPS display (-k) shows over 800 frames when this happens. If the Looking Glass client on host is started on a normal window it works as intended and the FPS display shows 60 FPS.

This behavior does not happens on a X session and Looking Glass always kept 60 FPS on fullscreen, borderless or normal windows.

HW info:
Host GPU: 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
Host CPU: Intel® Core™ i5-4590 CPU @ 3.30GHz
Guest GPU: 01:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1)

Host info:
Arch Linux
$ pacman -Q linux 4.16.11-1
$ pacman -Q plasma-wayland-session: 5.12.5-2
$ pacman -Q looking-glass-git a10.r86.g7a5bbb1-1 (AUR)
$ pacman -Q wayland 1.15.0-1

Host and Guest resolution:
1920x1080 @ 60 Hz

Command:
looking-glass-client -o opengl:preventBuffer=1 -o opengl:vsync=1 -s -M -F -k

Notes:
Input with evdev passthrough instead of spice.

Log:

[I]               main.c:682  | run                            | Looking Glass (a10-86-g7a5bbb1e59)
[I]               main.c:683  | run                            | Locking Method: Atomic
[I]               main.c:676  | try_renderer                   | Using Renderer: OpenGL
[I]               main.c:764  | run                            | Using: OpenGL
[I]               main.c:883  | run                            | Waiting for host to signal it's ready...
[I]               main.c:887  | run                            | Host ready, starting session
[I]               main.c:174  | updatePositionInfo             | client 1920x1080, guest 1920x1080, target 1920x1080, scaleX: 1.00, scaleY 1.00
[I]               main.c:174  | updatePositionInfo             | client 1920x1020, guest 1920x1080, target 1813x1020, scaleX: 1.06, scaleY 1.06
[W]               main.c:177  | updatePositionInfo             | Window size doesn't match guest resolution, cursor alignment may not be reliable
[I]               main.c:174  | updatePositionInfo             | client 1920x1080, guest 1920x1080, target 1920x1080, scaleX: 1.00, scaleY 1.00
[I]             opengl.c:539  | configure                      | Vendor  : Intel Open Source Technology Center
[I]             opengl.c:540  | configure                      | Renderer: Mesa DRI Intel(R) Haswell Desktop 
[I]             opengl.c:541  | configure                      | Version : 3.0 Mesa 18.0.4
[I]             opengl.c:577  | configure                      | Using decoder: NULL
[I]               main.c:174  | updatePositionInfo             | client 1920x1080, guest 1920x1080, target 1920x1080, scaleX: 1.00, scaleY 1.00

#751

Please stop asking for support when building non tagged releases, there is NO support for non tagged releases.


#752

Installing the AUR version without changes leads to this build error:

spice/spice.c: In function ‘spice_connect’:
spice/spice.c:133:3: error: ‘strncpy’ specified bound 32 equals destination size [-Werror=stringop-truncation]
   strncpy(spice.password, password, sizeof(spice.password));
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:28: .build/spice/spice.o] Error 1
make: *** Waiting for unfinished jobs....
==> ERROR: A failure occurred in build().
    Aborting...
:: failed to build looking-glass package(s)

Removing -Werror from the Makefile compiles the package.

On this version from AUR (non-git):
$ pacman -Q looking-glass a10-1

I need to disable preventBuffer option (-o opengl:preventBuffer=0).

Resulting in this command line:
looking-glass-client -o opengl:preventBuffer=0 -o opengl:vsync=1 -s -M -F -k

Log:

[I]               main.c:676  | run                            | Looking Glass (8c8978b33b)
[I]               main.c:677  | run                            | Locking Method: Atomic
[I]               main.c:670  | try_renderer                   | Using Renderer: OpenGL
[I]               main.c:758  | run                            | Using: OpenGL
[I]               main.c:876  | run                            | Waiting for host to signal it's ready...
[I]               main.c:880  | run                            | Host ready, starting session
[I]               main.c:167  | updatePositionInfo             | client 1920x1080, guest 1920x1080, target 1920x1080, scaleX: 1.00, scaleY 1.00
[I]             opengl.c:528  | configure                      | Vendor  : Intel Open Source Technology Center
[I]             opengl.c:529  | configure                      | Renderer: Mesa DRI Intel(R) Haswell Desktop 
[I]             opengl.c:530  | configure                      | Version : 3.0 Mesa 18.0.4

I close Looking Glass right after opening since it already shows FPS higher than 900 with this build.

I apologize in advance if this is still a non tagged release or if I did something wrong in the process. This is the closest to “default” I can get from AUR/a10.tar.gz source.

Also this might not be related to Looking Glass itself but be an issue on the Wayland or Plasma Session side, sorry if that’s the case.

If I did something wrong on the process of testing this or am missing information I’d gladly review and test again. I hope this is useful in any way.

Thanks!


#753

At this time wayland is not tested or supported.


#754

If anyone else finds this: I’ve found that exporting SDL_VIDEODRIVER=wayland makes vsync work for my case.

Resulting in this command line:
SDL_VIDEODRIVER=wayland looking-glass-client -o opengl:preventBuffer=0 -o opengl:vsync=1 -s -M -F -k

I’m not sure if anything else or performance is affected though.


#755

Yes, I noticed the same on Kubuntu 18.04, figured it was something specific to my setup since everything worked on Debian 9 and Kubuntu 17.10.

I had to have -o preventBuffer=0 as a launch option or disable evdev passthrough (yes, it was triggering the issue).

Maybe it was my setup, maybe it’s something to do with newer version of Wayland + evdev passthrough, idk. I moved on.


#756

I believe it has to do with Mesa and more specifically Mesa 18.*. Some said that downgrading Mesa to something like version 17.3.6 fixes it as well.


#757

Hi gnif, thank you for making this technology. I recently observed something I think worth mention.

Host: Windows 10 with v2 driver and a10 host app. Host app running with NvFBC
Client: Ubuntu 16.04 with (maybe) the latest build.

I have only one 120hz 1080p display, and a dummy HDMI device that support upto 4k 120hz config. I config my windows guest to 1080p 120hz when using that dummy device.

I noticed that even with (client) vsync enabled, UPS can still exceed 120 fps, say if you move mouse around very quickly. And DOOM, which can stay between 118~120 fps when running in physical windows installation, can only reach 70 fps at most, and around 65 fps most time.

When client vsync disabled, the client reported FPS will reach a fps around 450~530, but DOOM can only run at 25~35 fps, same as client reported UPS.

DOOM is running in full-screen mode, with in-game vsync option set to “adjust”


#758

UPS = Updates per second, it has nothing to do with vsync. Cursor updates are included in this and are not related to screen refresh rate.
FPS = Frames per second, this is updates on the client, it has nothing to do with the hosts FPS. If vsync is disabled and the host is doing nothing (ie, idle on the desktop) you will still see 500+ fps.


#759

Ok, but whether client vsync is enabled clearly have impact on performance, any idea why?