Looking Glass - Triage

Aha! That is my mistake, there is an error in the documentation.

It should be:

mkdir client/build
cd client/build
cmake ../
make

Ah man, I think Iā€™m getting the same error.

kyle@pop-os:~/Downloads/LookingGlass-a11$ cd client/
kyle@pop-os:~/Downloads/LookingGlass-a11/client$ mkdir build
kyle@pop-os:~/Downloads/LookingGlass-a11/client$ cd build/
kyle@pop-os:~/Downloads/LookingGlass-a11/client/build$ cmake ../
CMake Error: The source directory "/home/kyle/Downloads/LookingGlass-a11/client" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.

wait a secā€¦ A11 doesnā€™t use cmake yet. A12 will when it is released.

Please use the following:

cd client
make
1 Like

Ok, got a different error message this time:

Package libssl was not found in the pkg-config search path.
Perhaps you should add the directory containing `libssl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libssl' found
Package openssl was not found in the pkg-config search path.
Perhaps you should add the directory containing `openssl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'openssl' found
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
cc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -DATOMIC_LOCKING -ffast-math -fdata-sections -ffunction-sections -Wfatal-errors -D USE_NETTLE  -DBUILD_VERSION='""' -o .build/spice/rsa.o spice/rsa.c
spice/rsa.c:23:10: fatal error: spice/protocol.h: No such file or directory
 #include <spice/protocol.h>
          ^~~~~~~~~~~~~~~~~~
compilation terminated.
Makefile:45: recipe for target '.build/spice/rsa.o' failed
make: *** [.build/spice/rsa.o] Error 1

Sweet, that seems to have worked! Where do I go from here?

Continue the quickstart guide, I know itā€™s a bit sparse, I do not have time to document every feature at the moment.

Should I have a looking-glass-client executable?

Yes, after running make, it will be in the bin folder.

Ah, ok, I see. Thanks for all the help. I really like what youā€™re making here. Iā€™m excited to see where it goes in the future!

Ooh! Cmake for Looking Glassā€¦ Might make things more streamlined if you wanted to build both OBS Studio and this from source. OBS Studio from what I understand relies on Cmake.

The ā€œhostā€ application or server if you wanna stay in a ā€œserver-client-modelā€ just grabs the frames and puts them in the shared memory, it is where the frames are produced. The use-case is that the frames are produced in a VM and need to be ā€œplayed backā€ on the virtualization host in cases when for example you canā€™t spare a dedicated monitor for your VM plugged in into its GPU.

What do you mean by that? The games are still run in the VM and you could play most games in there and display them via LG on the host. It certainly does have more or less overhead depending on the hosts hardware setup but there are also certain games, especially multiplayer, that forbid being played in a VM for anti-botting protection.

1 Like

Any impact on performance depending on the host GPU? e.g. would LG provide a similar visual experience on the integrated Intel HD Graphics 630 of the host from a VM that passthrough a GTX 1080Ti in the guest VM?! In other words, is it required to have both graphic cards equal in raw performance and features? Thanks

Not at all, the hostā€™s GPU can be very basic, as long as it can render a picture to the screen at your desired resolution and refresh rate, it will be good enough. All the heavy lifting is done by the guest GPU, Looking Glass (essentially) takes a screenshot of the current frame, and the host then takes that finished picture and displays it.

1 Like

Where it gets interesting at the current moment is if you want to re-capture the output and pipe it into OBS to stream to Twitch. You will require a better GPU to do that, but Iā€™m the only person in the world doing that, so for you, you should be fine with an average GPU.

V4L2 would be ABSOLUTELY AMAZING. This would remove so much of the custom coding required for a ā€œClientā€ plugin for OBS and instead just use direct V4L2 access.

Please, if you want to have this project to be able to hook into SO MUCH MORE like OBS or Kdenlive, SUPPORT this train of thought into making V4L2 a endpoint.

This also opens up different chroma formats like NV12 and I422 to be able to be used for the shared memory transfer, reducing bandwidth while being uncompressed.

No it doesnā€™t, as the capture is done raw, to use these other formats it would have to be converted from ARGB32 which will increase latency.

The bandwidth issue in the bleeding edge version for the most part has been resolved. It looks like it was a problem with the Microsoft documentation on the use of DXGI, misusing the API slightly has allowed a much higher rate of capture and transfer, along with the memcpySSE improvements that went in recently.

I am in the most bandwidth constrained situation with quad channel DDR3 memory. OBS doesnā€™t even want to do a proper screen capture at 60fps if I use itā€™s shared memory feature and limits it to 38fps in Windows 7 bare metal. Granted, recent improvements get me up to 55fps in low motion and low detail images, but still dips back down to 38 in high complexity scenes with a lot of motion.

Is this on A11 or the bleeding edge version? We can add additional capture formats in the future, but for now to keep the project moving we are sticking to ARGB32.

A11. Iā€™m going by stable releases as per your recommendation, and that my Twitch stream relies on stable code.

I wouldnā€™t call it stableā€¦ itā€™s just working :slight_smile:

Can you please give the latest version a try? Use the new continuous builds of the host application from AppVeyor. I am interested to know if others also see an improvement with these changes before I release A12.