Return to

Looking Glass Beta 2 Release Candidate 3 Tagged

Changes since RC2:

  • Fixed EGL frame ordering bug.
  • Fixed frame limiter issues.
  • Better cursor icon support on initial connect.
  • The LG client can no longer be run as root.
  • Host now reports it’s version to the client for logging and debug.
  • Client now reports host and client versions on mismatch.
  • Performance improvements to EGL.
  • New client option to capture input by default at startup.
  • Timers implemented for the linux host (now builds again).
  • SIMD implemented to improve framebuffer copy.
  • Don’t stop the host LGMP timer when restarting capture.
  • Boost GPU kernel thread priority so vsync/frame limits are not needed anymore (LG host must be run via PsExec -s -i -d for this to work)
  • OBS plugin now always fetches the most recent frame on the frame tick.
  • Improved frame sync logic in the client
  • Always use spice mouse host mode to fix issue with spice guest tools breaking mouse support.
  • LGMP submodule updated to incorporate fix that was causing random invalid timeouts.


I (Geoffrey McRae) am the primary developer behind this project and I have invested thousands of hours of development time into it.

If you like this project and find it useful and would like to help out you can support me directly using the following platforms.


This is for the client, right? Does the host benefit from the new GPU prioritization features in the new Windows builds? (since this change reminded me of that new feature in Windows)

No, this boosts the DXGI GPU Kernel Thread priority in the host application.

Ah, so it could be used in addition to GPU prioritization?

All it does is give the GPU capture thread higher priority then the foreground application, the result is the foreground application can run at 100% GPU usage without DXGI capture rates being affected. It also helps enormously with microstuttering, and the hit to GPU overall performance loss due to LG has been improved as a result.

Just to be clear, this is not the application CPU priority, or the capture thread priority, this is the Direct3D thread inside the kernel that has been spawned on behalf of LG for DXGI DD, which is why it needs to run as SYSTEM via PsExec for it to be able to set this priority.

The Windows GPU prioritization thing is supposed to help scenarios like OBS capturing at the same time, and isn’t related to CPU. Have you looked into if that helps Looking Glass further?

That is EXACTLY what this is.

I’m asking if it can be used in conjunction with this:

Or is this exactly it?

Hardware accelerated scheduling has nothing to do with capture, it will help with scheduling of everything overall. We are setting the GPU thread priority, it’s up to the schedular (hardware or software) to decide if it will obey it or not.

Also OBS uses the same method to boost it’s priority but it will fail unless it can run as the SYSTEM account also, if you are capturing under Windows with OBS I suggest you run OBS using PsExec also.

Huh, so OBS’ admin mode execution is a layman’s PsExec?

I have not looked in depth, all I know is that running OBS as Administrator is not enough on Windows 10 to allow setting the d3d kernel thread priority. A higher level of access is required which can be obtained via PsExec.

I have a service launcher for LG in the works that will remove the need for PsExec which is planned (at the latest) for Beta 3

Then you wonder why the OBS devs don’t create an additional shortcut that uses PsExec for the traditional installer, or a “restart in psexec mode” option.

Because PsExec can’t be distributed as it’s a microsoft SysInternals product. Also running as SYSTEM is far more dangerous then running as Administrator, especially for something like OBS that allows loadable plugins (do you want a browser plugin running as SYSTEM?). Right now the most secure way to get a capture like this is to use LG to capture and the LG module for OBS which will give you the best of both worlds.

1 Like

Maybe sandbox the capture component, then it communicates with user mode OBS? IDK, that’s what I think, but it might not be compatible with zero copy NVENC.

Yes to the Looking Glass to OBS on Linux host solution, but we still need zero copy on Linux for NVENC for full effectiveness. That’s not really possible with their current OpenGL implementation.

Note, here is an example of the difference it makes…

Streamed Live in OBS under linux VM->VM with 100% GPU load and encoding offloaded to a Quadro K1200 using NvENC

Since that’s OpenGL 4.5, might have been hampered by single core performance.

The next critical step is zero copy where the OBS canvas framebuffers stay on the GPU and go straight to the NVENC encoder on the Linux host. (what EposVox calls “New NVENC”)

Zero frame drops due to rendering or encoder lag, 3% cpu usage, NvENC best quality… how is that hampered?

What you are asking for requires GPU->GPU transfers, which is not possible at current without support from the GPU vendors for this feature. Zero copy for LG is never going to be a reality without such support.

I meant the actual Unigine Engine. Not Looking Glass.

And it’s not zero copy for Looking Glass, just OBS. OBS to NVENC isn’t zero copy right now on Linux.

Ah ok, in which case this is entirely off topic

And not sure how that’s the case since it was a DirectX 11 benchmark. Also OpenGL4.5 can be multithreaded, we use it in the LG client to parallaize the texture upload to the GPU (

I had a bit of extra time and decided to finish this feature off today… it’s now in bleeding edge.

This removes the need for PsExec, but please be warned it’s experimental and if it causes issues please don’t complain.

looking-glass-host.exe InstallService to install
looking-glass-host.exe UninstallService to remove


You will see two running processes for LG if you use this feature, one is the service itself that launches the LG process for the current user.