Looking Glass - Triage

Hi gnif, Here’s my segmentation fault from the last client and host builds from master using EGL

(gdb) run -s -F -k -g egl
Starting program: /home/drew/bin/looking-glass-client -s -F -k -g egl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[I]               main.c:752  | run                            | Looking Glass (a11-115-gd2b83027b4)
[I]               main.c:753  | run                            | Locking Method: Atomic
[I]               main.c:793  | run                            | Trying forced renderer
[I]               main.c:746  | try_renderer                   | Using Renderer: EGL
[New Thread 0x7fffedffe700 (LWP 18444)]
[I]               main.c:948  | run                            | Waiting for host to signal it's ready...
[I]                egl.c:387  | egl_render_startup             | Vendor  : NVIDIA Corporation
[I]                egl.c:388  | egl_render_startup             | Renderer: GeForce GTX 980 Ti/PCIe/SSE2
[I]                egl.c:389  | egl_render_startup             | Version : OpenGL ES 3.2 NVIDIA 415.18
[I]               main.c:957  | run                            | Host ready, starting session
[New Thread 0x7fffeca60700 (LWP 18445)]
[New Thread 0x7fffe6592700 (LWP 18446)]

Thread 4 "frameThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe6592700 (LWP 18446)]
0x00007ffff7776a2b in glGetUniformLocation ()
   from /usr/lib64/opengl/nvidia/lib/libGL.so.1
(gdb) bt
#0  0x00007ffff7776a2b in glGetUniformLocation ()
   from /usr/lib64/opengl/nvidia/lib/libGL.so.1
#1  0x00005555555654c5 in egl_on_frame_event (opaque=0x5555555ead00, 
    format=..., 
    data=0x7fffef07f000 "C@<\377C@<\377C@<\377C@<\377C@<\377C@<\377C@<\377C@<\377C@<\377C@<\377C@<\377C@<\377@>:\377=:6\377;84\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377"...)
    at /home/drew/src/LookingGlass/client/renderers/egl.c:310
#2  0x000055555555c606 in frameThread (unused=<optimized out>)
    at /home/drew/src/LookingGlass/client/main.c:424
#3  0x00007ffff7cb2dbc in ?? () from /usr/lib64/libSDL2-2.0.so.0
#4  0x00007ffff7d23619 in ?? () from /usr/lib64/libSDL2-2.0.so.0
#5  0x00007ffff58644f3 in start_thread () from /lib64/libpthread.so.0
#6  0x00007ffff69726df in clone () from /lib64/libc.so.6

I tried to keep it to a simple set of options in case one of them was triggering the issue.

I am kind of glad it is not happening only with me, I was going insane thinking it was something on my machine =D

Looking at the source I can not explain this failure nor can I replicate it here, would you be willing to let me remote debug the client on your system?

If so I will provide you with a public SSH key to authorize for access.

Edit: Would you also mind opening a github issue for this so that I can track it in Trello?.

Edit2: I think I found it, glGetUniformLocation was being called from a different thread to the OpenGL main context. This should be fixed now.

A series of changes were just committed to the repository that both clean up the code base and improve things. One commit in particular might have a large impact on the general smoothness of the video feed.

Previously the render thread was calculating a sleep delay to cap the frame rate. I have changed this to use the high resolution system timer to schedule an absolute wakeup time. This has two benefits:

  1. If we stutter and get behind, the render thread wont sleep and will catch up.
  2. The delay is more accurate allowing better frame sync.

I have also been able to gauge the performance impact of rendering the FPS display. I already knew that this was being done sub-optimal but now I have imperial data to prove that the FPS display causes micro stutter issues. I have added a warning to the output let people know about the issue.

This will not be fixed in A11, but it is queued up for the B2 release as the fix involves adding the code to generate and render fonts using a texture atlas.

Just woke up, I will check this when I can and report back. If it doesn’t work for some reason we can figure out a remote ssh. Thanks for the hard work.

1 Like

I wont be around until late tonight AEST, have to go and visit my brother in law who just had his first child :smiley:

1 Like

Hey! Congrats to him =D

I don’t think you need to worry about the issue anymore, your fix worked (=

Performance wise I can confirm what I saw a month ago: CPU utilization with EGL (even with 144fps @ 2560x1440) is minimal. GPU utilization is also better. Amazing work!

1 Like

Yep. Working here on the latest client master as well.

1 Like

Awesome!

Thanks, super glad to hear it, after the last few days it’s nice to get some good news!

Our trip to see our new nephew was a nightmare, had a postal worker on a push bike smash our car because “we ticked him off” by looking for a park, the idiot then rode off without providing any ID. Lost the entire day waiting for the police and dealing with them, thankfully they found the guy and charged him.

Then got home and shortly after we arrived home a lightning storm hit and a strike that was very close to us took out my managed switch, vdsl modem, UPS and gateway… sigh, one of those days.

Anyway, finally back and online, managed to cobble together some junk to get things running again in the meantime.

A12 was just released

6 Likes

Hey, just wanted to stop by and say thanks for the excellent work! I’ve been out of the game for a bit, but I’ve just downloaded and checked out A12 and it’s working pretty well from what I can see.

:smiley:

1 Like

I’ve been using the adobe creative suite in a VM flawlessly since ancient version and it makes me so happy to be able to do that. Now we just need seamless window capture and we’ll be all set lololololol

1 Like

That requires NVFBC, if I remember correctly.

But yeah, that’s on my list as well.

There is some example stuff in the amd media sdk for “remote desktop” which does window capture now too. So. That might be a thing… :smiley:

1 Like

Oh, that’s good.

Hello ! I have a small problem with the Alpha 12 of the looking glass client. The Alpha 11 from the Arch repository works perfectly, but the A12 I built myself from source tells me this when I try to start it :

[I]               main.c:757  | run                            | Looking Glass ()
[I]               main.c:758  | run                            | Locking Method: Atomic
[I]               main.c:751  | try_renderer                   | Using Renderer: EGL
[I]               main.c:824  | run                            | Using: EGL
[E]               main.c:852  | run                            | Could not create an SDL window: Couldn't find matching GLX visual
  • I also tried to build the A11 from source just in case, it is working.
  • I tried the OpenGL renderer, the problem was the same.

Do you think you could help me ?

My config :
I7 9700K
Host GPU : HD 630
Passthrough GPU : 2080 TI
Motherboard : Z390 phantom gaming ITX/AC

Please show the output of the client when you try the opengl renderer.
Also, please provide the output of: glxinfo

Ah, sorry. Here it is :

[I]               main.c:757  | run                            | Looking Glass ()
[I]               main.c:758  | run                            | Locking Method: Atomic
[I]               main.c:806  | run                            | Trying forced renderer
[I]               main.c:751  | try_renderer                   | Using Renderer: OpenGL
[E]               main.c:852  | run                            | Could not create an SDL window: Couldn't find matching GLX visual

And GLXinfo : https://pastebin.com/PbyrGfyg

This is not an OpenGL or EGL renderer issue, there is something wrong with your system. It’s failing on SDL_CreateWindow, this is likely caused by a compositor or some other issue.

Please try launching the client with export SDL_VIDEO_X11_VISUALID=, this will cause SDL to use a different visual id detection method. If this doesn’t work you may need to research why SDL can’t create a OpenGL window on your configuration.

1 Like

Great ! It worked ! Is there something I can do to troubleshoot the problem, or can i use this command on my system startup and simply use looking-glass that way ?