The fps on the client appears to be constantly lower - here’s a SS from just sitting idle in Overwatch: https://i.imgur.com/Kp6CRAq.png
A little hard to tell but the client is constantly at ~40-50fps while the game itself is much higher. Perhaps my processor is getting taxed from the CPU usage of these games; I don’t see the fps dips when running GPU benchmarks eg Heaven.
Also for the -s switch, it appears to turn off all events including window events, so things like resizing doesn’t actually re-adjust the render resolution?
Edit: mipmapping does not seem to make a difference either. Might be time to finally get a dgpu for the host…
Excellent, thanks for confirming that. Resizing seems is a problem with having spice disabled, I will fix that soon.
This is to be expected, the FPS is not the screen FPS, but the rate at which we are getting frames from the guest. If nothing has changed/updated then frames are ignored and not sent to the host.
Yup, confirmed, I will fix this.
Don’t do that… your IGP is plenty fast enough, just a few rough edges in Looking Glass.
This is to be expected, the FPS is not the screen FPS, but the rate at which we are getting frames from the guest. If nothing has changed/updated then frames are ignored and not sent to the host.
Pardon my lack of knowledge on the tech, but would it be possible to force all frames to be sent regardless of changes? I wonder if that could ‘smooth’ things out.
It actually makes things worse, it’s much cheaper CPU and GPU wise to only take the difference frames, the capture API actually directly supports this and tells us if things have changed or not.
For example, two frames are identical, the first one is just shown on the guest for that entire period instead of re-drawing when nothing has changed. During this redraw we would be busy wasting time when we could be processing other things.
The exception to this is the hardware cursor, we flush that to screen immediately.
This should be fixed now, please update to the latest version. Please be sure to update the windows host application to alpha3 also. Binary available on the website & github.
Note: I do not have a monitor capable of this resolution so I can’t verify it’s fixed, that’s up to you :).
Error starting domain: internal error: process exited while connecting to monitor: 2017-12-14T10:45:44.853770Z qemu-system-x86_64: -chardev socket,path=/home/blabla/KVMFR/ivshmem_socket,id=ivshmem: Failed to connect socket /home/blabla/KVMFR/ivshmem_socket: Connection refused
Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 89, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 125, in tmpcb
callback(*args, **kwargs)
File “/usr/share/virt-manager/virtManager/libvirtobject.py”, line 82, in newfn
ret = fn(self, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/domain.py”, line 1505, in startup
self._backend.create()
File “/usr/lib64/python2.7/site-packages/libvirt.py”, line 1062, in create
if ret == -1: raise libvirtError (‘virDomainCreate() failed’, dom=self)
libvirtError: internal error: process exited while connecting to monitor: 2017-12-14T10:45:44.853770Z qemu-system-x86_64: -chardev socket,path=/home/blabla/KVMFR/ivshmem_socket,id=ivshmem: Failed to connect socket /home/blabla/KVMFR/ivshmem_socket: Connection refused
Is qemu running as ‘qemu’ or ‘kvm’, or ‘libvirt’. You might need to check as each distro is different. I found the easiest way to make all this function without security risk is to just run the VM as your local user.
Edit /etc/libvirt/qemu.conf and set user = "blabla", and group = "blabla", restart libvirt and see how you go.
Sorry I am not going to be able to diagnose this one for you, it’s a permissions issue, you will need to look into how libvirt is launching qemu and correct for it. Later we will look at writing some guides but at the moment my focus is 100% on the Looking Glass code base.
Since this was all based on proof of concept code I used legacy OpenGL, it needs another renderer (not an update to the current one, completely separate one so we have legacy fallback) written for modern GL with VBOs. Some cards do not support legacy anymore.
Next step for me is adding Vulkan first, once that is done I will revisit OpenGL unless someone else does before me.
[I] main.c:560 | run | Looking Glass (a2-5-g2ae9b479f6-dirty)
[I] main.c:636 | run | Initialized OpenGL
[I] ivshmem.c:153 | ivshmem_connect | RAM Size : 16777216
[I] main.c:762 | run | Waiting for host to signal it's ready...
[I] main.c:766 | run | Host ready, starting session
[I] main.c:235 | renderThread | Data Format: w=1920, h=1080, s=1088, p=4352, bpp=32
[I] opengl.c:159 | lgr_opengl_configure | Vendor : Intel Open Source Technology Center
[I] opengl.c:160 | lgr_opengl_configure | Renderer: Mesa DRI Intel(R) Ivybridge Desktop
[I] opengl.c:161 | lgr_opengl_configure | Version : 3.0 Mesa 17.2.4
[E] opengl.c:97 | lgr_opengl_check_error | glTexImage2D = 1282 (invalid operation)
[E] main.c:240 | renderThread | Failed to reconfigure OpenGL
Looking for GL_ARB_buffer_storage is actually supported on here. I don’t know much about graphics programming at all, so short of stepping through gdb it’ll take me some time to figure out what’s going on.
Intel provides an implementation for Windows up to OpenGL 3.1 with Sandy Bridge CPUs and OpenGL 4.0 with Ivy Bridge CPUs. However, Intel’s Linux open-source driver developers have recently stated that they will not provide backward-compatibility on Linux.
GL_ARB_buffer_storage is 4.3, too new to be used with the Legacy API on your GPU.
Once someone (or I) write a modern OpenGL renderer into the client this will be resolved.
make sure you specify the socket path to looking-glass-client if you changed it. Also ensure the client has permission to use the socket, check the file’s permissions.
