DXGI isn’t allowed on login-screen and secure desktop screens like confirmation for admin execution of a program.
I would enable auto-login (bypassing password) and run the host application on login.
1 Like
Ah righto, will have to investigate something to auto login on this machine as I do connect remotely to my works domain controller over a VPN. Or else just keep switching monitor inputs/use PIP mode for login if that’s too insecure.
Also not sure if this is covered already but stuff like UAC prompts don’t come up? Not sure if there’s a fix or just disable it?
I am having a bit of tearing/choppy issues, its not too bad but just wondering if its maybe my hardware or something incorrectly configured. Was using unigine valley benchmark to test and noticed a bit of stutter. Maybe something on the host isn’t right?
Cheers,
They are on the Secure Desktop, please read though: https://looking-glass.hostfission.com/node/7
Working on it… turn off anti-aliasing, it doesn’t play nice with DXGI
Ah is that what’s causing it, I played around and enabled MFAA in the NVidia settings and that seems to help massively with stutter on anti-aliasing 
EDIT: It’s practically perfect now, I’m guessing this for Maxwell and newer GPUs
Is that anti-aliasing issue specific to the Unigine Valley benchmark, or is it generally a problem with all games? Asking because anti-aliasing is pretty important.
I noticed stuttering issues with AA on in Overwatch and D2, so I’d venture to guess that it’s a general issue.
Unfortunatly its across the board, hardware AA such as FXAA is fine, but old school super sampling AA seems to cause quite a substantial slowdown.
This bottleneck seems to be in either the driver or the Windows DXGI DD API, there is little we can do about it.
I deliberately turn AA off in all my games anyway, it looks gross.
Personally I really like it when the game does it right, unfortunatly most dont.
I dunno I would rather just respect that a game is a computer game and look at the jaggies rather than think my eyes are failing slowly due to lack of sharpness on objects and much worse performance. AMD cards have never been good at applying AA anyway.
AA in BF1 looks like utter trash.
Are there recommended ones now?
2 Likes
By the way. you can add the shared memory device to a libvirt domain natively without qemu args like this:
<shmem name='looking-glass'>
<model type='ivshmem-plain'/>
<size unit='M'>32</size>
<address type='pci' domain='0x0000' bus='0x0a' slot='0x02' function='0x0'/>
</shmem>
Maybe you can include that in the documentation, it might be easier for some people. It translates to the following qemu args:
-object memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/looking-glass,size=33554432,share=yes
-device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pci.10,addr=0x2``````XML
<whatever argument="youneed">
<option>
</option>
</whatever>
```
1 Like
for the problem of no display detection in the windows guest causing the resolution to default to 1024x768, it looks like a couple registry tweaks should work as an alternative to having to use a dummy connector.
i did some googling and poking around in the registry in windows 10. and it looks like HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration\ should have the relevant keys for display resolution settings for the various video out configurations windows has detected.
for me, \NOEDID_1A03_2000_0000000B_00000000_0^3B055267EA1D3037447EEC960EDDCAE3\00 looks to be the sub key for the simulated safe resolution display for when windows doesnt detect a display. it has PrimSurfSize.cx and PrimSurfSize.cy values of 1024 and 768 respectively. it also has another \00 sub key with values DwmClipBox.bottom and DwmClipBox.right that look like they’d need to be changed from 1024 and 768 respectively as well.
note: i havent tested any of this at all, just thought i’d mention it (still waiting on a good deal on an AMD card to run as my host gpu to take the plunge and ditch windows as my host OS)
edit: spun up a windows 10 VM real quick and tested those edits (started the vm headless with auto sign in enabled for the windows user, and connected to it with teamviewer) , and changing those registry values for the relevant key worked like a charm. not sure if having a separate graphics drivers installed in the guest will effect anything, but it doesnt seem like it should. someone should definitely give those tweaks a go and see if it works in a proper environment.
2 Likes
Is it normal that I got low UPS when GPU is under heavy load? For example I got 30-40FPS in Unigine Heaven but <= 10 UPS in looking glass client.
Can’t compile git head:
gcc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -DATOMIC_LOCKING -ffast-math -fdata-sections -ffunction-sections -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/spice-1 -DBUILD_VERSION='"a10-16-gbebbdc4089"' -o .build/decoders/h264.o decoders/h264.c
decoders/h264.c: In function ‘lgd_h264_initialize’:
decoders/h264.c:199:7: error: ‘VAProfileH264Baseline’ is deprecated [-Werror=deprecated-declarations]
VAProfileH264Baseline,
^~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/va/va_glx.h:28:0,
from decoders/h264.c:28:
/usr/include/va/va.h:345:5: note: declared here
VAProfileH264Baseline va_deprecated_enum = 5,
^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:31: .build/decoders/h264.o] Error 1
Edit: Removing -Werror avoids this error and it compiles (couldn’t test it yet though).
1 Like
I think the guide is off for configuring the libvirt client
All of the OS’s are showing
"https://looking-glass.hostfission.com/node/9" I remember with alpha9 it was showing separate guides for each OS
From what I have seen in playing around with it, yes because it also needs to use some of the GPU power, if you add the GPU column to task manager you’ll see the load from looking-glass-host. I can play PUBG natively on ultra at 3440x1440 and get around 90 FPS but with Looking Glass I need to drop it down to medium or high to have a playable framerate but I still see the game framerate is higher. GPU usage would be pegged at pretty much 100% on ultra even natively, it’s still pretty much 100% when I drop the quality down a bit but still pretty high and you can see the stutters, though it is playable. Of course at a lower resolution there is less usage so it would be smoother even with a high usage.
I’m not aware of any way to prioritize GPU usage like you can with CPU usage.
Here’s on high:
Here’s on ultra low just to show the difference:
also when using alpha9 I got everything to launch fine but now using alpha10 when I launch the client I get a blank screen but the mouse works fine.
I verified that the process is working and I am using the same command as I did for alpha9
./LookingGlass/client/bin/looking-glass-client -p 5901
any idea what is going on?
You might not be able to prioritize a process, but there’s things like frame rate target controll for AMD and whatever Nvidia got.
By setting the GPU to only make a certain number of frames (and I’m not talking V-sync here) you might save up some GPU resources for other things without dropping quality or resolution.
And if you set it low enough there might even be thermal headroom to boost up when those really tough scenes show up.