If you are running from git head please note that the option parsing has changed to support per renderer options in preparation of multiple renderers in the future.
mipmap -m swtich has been relocated into the opengl renderer
vsync -v switch has been relocated into the opengl renderer
You can obtain a list of options by running, -o list for example:
./looking-glass-client -o list
Renderer Option List
OpenGL
mipmap - Enable or disable mipmapping [default: enabled]
vsync - Enable or disable vsync [default: enabled]
To use these options the format is as follows:
-o opengl:vsync=0 -o opengl:mipmap=0
All renderer names and option names are case-insensitive. Boolean (true/false) options understand the following values:
1
0
true
false
yes
no
on
off
enable
disable
As with switches, the last option will take precedence. For example, the below will have vsync enabled:
People that are having problems with low performance please checkout the latest version from GitHub and try the new OpenGL-Basic renderer I have just added. It has been reported to perform better on certain older or lower performance hardware. Be sure to run make clean before building.
To use it specify the new -g option which will force it’s use: ./looking-glass-client -g OpenGL-Basic
To confirm it is in use check the output for:
Trying forced renderer
Using Renderer: OpenGL-Basic
This was previously hard coded in but is now disabled by default.
This feature when enabled draws mouse updates to the front buffer instead of waiting for full frame updates from the guest in an attempt to achieve better mouse input synchronization with the hardware cursor on the physical GPU. However on some hardware pipelines the excessive calls to glFlush causes a GPU pipeline stall and the mouse can become “jumpy”.
The down side to this is the current frame will be re-drawn on every mouse movement even if there was not a new frame from the guest, this will mean that the frame sync with the guest can be lost and there is a higher chance of frames being dropped. To avoid dropping frames you can turn vsync off at the side effect of screen tearing, it is up to you.
To turn this back on use the command line option below appropriate depending on the renderer you are using:
-o opengl:splitmouse=1 or -o opengl-basic:splitmouse=1
If you are primarily playing games or using applications that use a software, no mouse, or a rendered mouse, and the windows desktop experience doesn’t worry you too much this feature should be enabled for best performance if you wish to retain frame sync with the guest.
You can evaluate the effects of this feature by using the MPRT test (Avoid this test if you are prone to epilepsy) while moving the cursor around.
This was previously hard coded but is now optional.
This feature when enabled (default) will ensure the video card never buffers more then one frame, this is needed to ensure the lowest latency possible as we are fed new frames from the host. This sometimes however is not desirable if the user is not playing games or using applications that require such low latency where a smoother more fluid user experience is required (ie: CAD applications). If disabled the video driver may buffer up to three frames depending on your hardware.
It is however possible to still achieve low latency with this feature turned off by also turning off vsync where a much higher frame rate will be displayed by the FPS monitor.
Please experiment to find out which combination of options work best for your particular needs and hardware.
This update is quite large as it completely changes the way that rendering is performed so as to prevent holding up the capture API on the host. It decouples the capture rate from the client’s frame rate.
Note: Due to time constraints I have not yet updated the OpenGL-Basic renderer for the new API and as such it is disabled for the moment. I plan to integrate the basic renderer into the standard one and have an option to enable the basic mode when I get some more time.
Windows application needs to be updated, see attached build
This release changes how the guest VM needs to be configured, please refer to the quickstart guide for how to configure libvirt as ivshmem-server is no longer used
I am back from my break, but due to the break I have much work to catch up on. Updates are still coming but will slow down as I do not have as much time at current.
A few things have happened in the last week though:
I finally got the TR system up and running, debugged the pci reset bug and produced a clean (non ugly) patch to fix the problem, see: https://patchwork.kernel.org/patch/10181903/
Since I now have a system with a Vega, I was able to reproduce some of the lag issues with mouse input, I just pushed in a change that partially fixes it, unfortunatly the cause is SDL2, it is calling XSync after every single call to X11_WarpMouse which is causing a backlog of X11 mouse move events.
With the latest patch to LookingGlass this is worked around for normal mouse mode, but capture mode is still affected. You can remove the calls to XSync in src/video/x11/SDL_x11mouse.c and recompile SDL to work around this problem.
I have submitted a report to the SDL developers to see about getting this fixed as per the documentation the calls to XSync are pointless anyway.
At the moment the current bottleneck is the copy performance of KVM/Qemu, it is not a looking glass or IVSHMEM problem. When the frame size exceeds 4MB (around 1200p), the VM’s memory copy performance becomes horrendous. I have been trying to get input from AMD and the Qemu devs on this problem but it seems everyone is willing to just ignore it.
Until this problem is fixed there is little that can be done.
You can prove this fault by just writing a program that just performs a simple memory -> memory copy, no IVHSHMEM, or capture.
I have been in touch with an engineer at AMD about the Vega 10 reset defect, they have assigned an engineer to the problem and are investigating. It was confirmed that it is a firmware problem with the card and can not be fixed in the kernel without help from the hardware team.
Those willing to run the unstable master version and are using AMD hardware on the client may get a substantial performance improvement as I just added GL_AMD_pinned_memory support. On my test system I am seeing a substantial improvement in frame rate.
Edit: A kernel module has also been added to allow VM->VM communication.
I am pleased to announce that VM->VM performance is now fixed, if you want to run using this method you need to load the kernel module for the IVSHMEM device otherwise your performance will be terrible.
Getting very close to an A11 release, most outstanding issues have been resolved including a License incompatibility issue with OpenSSL preventing project packaging. As such the dependencies have now changed, instead of libssl-dev you now require nettle-dev and libgmp-dev to build the current unstable version.
