I think I may (?) have a solution to the screen-rearing & skipped frames problem that @gnif has been working on.
I run a lot of FEA, and when it runs it’s common for looking glass to ‘lose sync’ and the client app to exit because the FEA creates really high all-core CPU utilization. The client thinks the vm has closed so it exits. FEA really brings the machine to it’s knees!
Today it dawned on me that the looking-glass-host process (thread) in the vm is getting starved of cycles to the point of becoming unresponsive, triggering the client hang up. Experimenting, in task manager I set the looking-glass-host process priority to real-time and processor affinity to CPU-0 (avoid core hopping) and for me at least it resolves the hangup problem.
More importantly, this seems to also fix the graphics tearing & lost-frame issues. I’m back on beta-1 due to the skipped-last frame issue that later builds made worse. I’ve been just putting up with the tearing & hangup-uner-load issues but those now also seem resolved. My theory is the tearing & lost frames may be due to looking-glass-host not getting the chance to run at key times (like when other threads windows are busy painting) and missing the frame update.
The solution is easy: Just add parameters “-realtime -a 1” to the psexec64 command line that starts looking-glass-host.exe application in the vm at startup.
The result, at least on my machine (GTX1080 vm -> Intel IGP host) makes everything much, much smoother. Panning around in CAD on complex models, the shuddering & tearing is virtually gone and ghost-frames, where the last frame in a fade animation is dropped, have disappeared.
Disclaimer, YMMV: I haven’t tried this on a more recent build, nor have I tried it in any games yet. But running the host with real-time priority doesn’t seem to hurt anything since it only uses 1-2% CPU.
Can someone can test & confirm this? You can temporarily change the host priority by running task manager, go to the Details tab, scroll to looking-glass-host.exe, right click & select ‘set priority -> realtime’. I’m not sure whether setting processor affinity matters.
Impossible, the issue is an atomic out of order bug in the EGL client that should be corrected in the latest master. It’s hard to reproduce and debug, which is why this is taking some time.
Sorry, I misunderstood what issue you were referring to. Skipping frames as you discovered is always hardware dependent, however tearing is dependent on if you use vsync in the client or not.
Every now and then we get someone stating this and trying what you state. Here is why you should not do this.
A realtime task if locks WILL hang your entire session, LG already takes the highest safe priority that is possible. Microsoft restrict RT priority from being programmatically set for a very good reason. However as you have observed, FEA is taking too much time from LG, so in your case yes, bumping this up is warrented.
The LG host spawns at minimum two threads, by setting the affinity to a single core you are only allowing one of these threads to run at a time and the scheduler needs to context switch at a crazy rate. In short, you’re hampering performance.
As you state you see an improvement, it is far more likely you have a VM configuration issue, such as a failure to pin CPU threads to the correct cores, and/or failure to tell the guest it has hyperthreaded cores if you are indeed trying to use them. Also not isolating the cores for the guest and sharing them with other host tasks can cause this.
This is VERY suboptimal, IGP GPUs perform horribly in comparison to a dedicated even older GPU for LG simply because they share System RAM and as such consume the available bandwidth for memory transfers. In effect, you are adding an extra System RAM to System RAM transfer that must be done by the CPU (ie, no DMA)
And finally, the host application can not cause tearing or frame ordering issues, it’s impossible as it is not involved at all in putting the frames on screen.