Multiple applications running very slow

TheStroyer · 2020-10-02 16:39:08

Most applications run fine, a few applications run very slow at some point.
It looks like this:
- I open the application
- It stutters while loading, but loads fine otherwise
- The first few seconds the application works fine, but after that it gets incredibly slow (1 FPS). Everything takes ages to do something
The applications where I noticed it are:
- Discord
- Steam
- Zoom (AUR)
I'm using the latest version of all these applications. I have tested them running under the latest kernel and the linux-lts kernel. I tried using the i3 window manager and lxde.
None of that made a difference.

Do you have any idea's on how to troubleshoot this. I have no idea why these applications all behave in the same weird way, even though they share no dependencies (except for nss).

I have posted some logs below.
The xorg log show something interesting in the last lines:
[ 1609.406] (EE) event11 - Logitech Wireless Mouse: client bug: event processing lagging behind by 13ms, your system is too slow

https://pastebin.com/1XGicQrX

Zod · 2020-10-02 16:43:39

I noticed those are all network applications.

You might describe your network a bit.

TheStroyer · 2020-10-02 16:58:45

I'm using wifi on my laptop. The network is very standard, I'm not sure what you want to know about it.

> cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.168.2.1

I'm pretty sure this isn't purely a network problem, because the web version of discord works perfectly. Also, an application shouldn't be slow in this way when the internet is very slow or misconfigured. They should not run at 1 FPS then.

netnoob44 · 2020-10-02 21:39:40

Arch tells me my mice and keyboard are too slow on every pc I have it installed on.
I don't think it means anything.

Last edited by netnoob44 (2020-10-02 21:39:56)

seth · 2020-10-02 21:53:16

It's an indicator for the system being unable to keep up w/ the event queue.

Since this is an optimus system, do you run those clients on the IGP or the dGPU?
Do you also use a compositor (picom) along i3?
How fast is glxgears in the same context?

TheStroyer · 2020-10-04 20:38:06

Thank you for pointing me to glxgears. Didn't think to check that. Glxgears indeed runs very slowly as well (1 FPS).
I've narrowed down the problem to my script to switch to my secondary display - found here.
When this script is ran, the laptop screen in turned off, and the secondary screen is turned on.
It seems like the xrandr commands are causing the problem. To be exact:

36.    xrandr --output eDP-1 --off

After this command is run, glxgears starts running at 1 FPS.

Also putting the two xrandr commands together:

xrandr --output HDMI-1-0 --auto --output eDP-1 --off

doesn't help.
Any idea why turning off a display make the graphics performance awful? With both displays on it works perfectly.

Last edited by TheStroyer (2020-10-04 20:39:15)

seth · 2020-10-04 20:50:45

a) get the compositor out of the way (completely, don't use picom at all for the moment nor any other compositor)
b) post the output of "xrandr -q" (w/ the external output attached)
c) do you use the nvidia driver or MESA?

This is likely because the refresh rate is "wrong" (at some point) and vsync enabled, so next we want to disable vsync and then and if see whether we can "fix" the refresh rate of the external display.

TheStroyer · 2020-10-04 22:05:18

a) I've already turned picom off to get rid of a variable. I'm just wondering, Is there another reason to not use a compositor at the moment? TBH, I don't notice any tearing now.
b) https://pastebin.com/3fSF67Qb
c) I'm using the nvidia driver (as told by lscpi -k)

It may also be useful to know that the hdmi port of my laptop is only connected to the GPU, and the internal display is connected to both cpu and GPU.

Last edited by TheStroyer (2020-10-04 22:10:07)

seth · 2020-10-05 06:15:56

Compare

__GL_SYNC_TO_VBLANK=0 glxgears
__GL_SYNC_TO_VBLANK=1 glxgears

Do you run the programs on the IGP? Does it also happen if you run on the GPU?
How exactly is the optimus(?) system (supposed to be) configured?

TheStroyer · 2020-10-05 08:22:12

The is no difference between sync to vblank on or off. Only the first 100 or so frames draw quickly, presumably because the gears aren't drawn yet.

❯ glxinfo | grep "OpenGL renderer"
OpenGL renderer string: Mesa Intel(R) UHD Graphics 630 (CFL GT2)
❯ prime-run glxinfo | grep "OpenGL renderer"
OpenGL renderer string: Quadro P1000/PCIe/SSE2

Apparantly applications are ran on the iGPU by default, which is fine to me, because I want to preserve battery life.
It's indeed configured as an optimus system right now. At least, both my dGPU and iGPU are used. I want to have it configured in such a way that the HMDI port connected to the dGPU is usable, but the battery life is still good. The battery life is most important when I'm on the go, so not connected to a secondary display.

I believe there are a few ways to achieve this:
- Use optimus-manager.
I don't really like this one, because I have to log out and in every time I want to switch.
- Use PRIME.
I believe I'm using this right now, but I don't really understand it. And apparently this isn't always working correctly.
- Bumblebee?
The wiki says there is a performance penalty with this though.
Tips on which setup is best in my case are welcome.

Note:
When I run discord with prime-run it runs smoothly, so that seems to be an issue with running on the iGPU. Here are the logs
dGPU: http://ix.io/2zMj
iGPU: http://ix.io/2zMk
In the iGPU case, there seem to be issues with unknown gl commands:

[2480:1005/095441.854856:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command

The other programs I had issues with, zoom and steam, still don't work with prime-run.

Last edited by TheStroyer (2020-10-05 08:26:15)

seth · 2020-10-05 14:14:41

The HDMI output is likely wired to the nvidia chip, try the behavior of "prime-run glxgears"
The __GL_SYNC_TO_VBLANK is for the nvidia blob, try https://wiki.archlinux.org/index.php/PR … erse_PRIME and https://wiki.archlinux.org/index.php/In … on_(VSYNC)

TheStroyer · 2020-10-06 12:39:42

I didn't try the __GL_SYNC_TO_VBLANK on the gpu last time, but it makes a big difference.
So I tried these commands now:

__GL_SYNC_TO_VBLANK = 1 prime-run glxgears
__GL_SYNC_TO_VBLANK = 0 prime-run glxgears

When I specify __GL_SYNC_TO_VBLANK = 1, I get 1 FPS, and with __GL_SYNC_TO_VBLANK = 0 I get >200 FPS. But when I close the window with it set to 0, I get an error:

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  148 ()
  Minor opcode of failed request:  1
  Resource id in failed request:  0x2200002
  Serial number of failed request:  695
  Current serial number in output stream:  696

The window closes just fine, but this should probably be looked at.

As for first link you gave, on executing the xrandr command, it logs me out and switches back to the laptop display. After logging back in and switching to the secondary display, I have the same performance as before (tested glxgears and vkcube on iGPU and dGPU).

As for the second link, it does work and gives me excellent performance (>700 FPS) on the iGPU in openGL. This solves the performance problems I had with the previously mentioned applications. Thank you for that! I don't even notice any screen tearing.

While this does solve my problems, I have a feeling that this solution will introduce other problems. For example, with the last solution I have the same X error as above. Also, glxgears runs at way more than 60 FPS. If any other applications do that it will drain my battery very quickly.
Lastly, vkcube doesn't run well on both the iGPU and the dGPU and glxgears doens't run well on the dGPU (except if solution 1 is used as well). So only openGL performance on the iGPU is improved I guess.

I have one more important thing to note. I previously mentioned it as well, but when I have both displays on, I have no problems at all. All applications run perfectly on both displays and both GPU's. I find it really weird that performence degrades once I turn off one monitor.

Last edited by TheStroyer (2020-10-06 12:40:33)

seth · 2020-10-07 22:14:03

The X11 error happens because a GLX request is send to the server for a gone window (you just closed it) - this is "normal" because X11 is an asynchronous protocol.
There is no performance degradation - all evidence suggests that the entire thing is diven by the synchronisation to the vblank interval (tearing prevention) what (likely) fails because there's no longer an output connected to the IGP and the refreshrate isn't properly relayed from the GPU.

Did you try to export __GL_SYNC_TO_VBLANK to vkcube?

If you want to limit the update interval and cannot rely on vsync (which is not its prime function) you'll have to see whether you can limit the maximum FPS in the client at hand.

TheStroyer · 2020-10-12 12:11:25

Thank you for the explanation. Is it likely an error in the nvidia driver?

Exporting __GL_SYNC_TO_VBLANK to vkcube doesn't make a difference. Does vulkan even use that variable? Using prime-run doesn't make a difference either.

Unfortunate that I can't limit the framerate outside the client. Most clients don't have that optioin, so I'll just have to hope that most clients are smart enough to limit the framerate.

Arch Linux

#1 2020-10-02 16:39:08

Multiple applications running very slow

#2 2020-10-02 16:43:39

Re: Multiple applications running very slow

#3 2020-10-02 16:58:45

Re: Multiple applications running very slow

#4 2020-10-02 21:39:40

Re: Multiple applications running very slow

#5 2020-10-02 21:53:16

Re: Multiple applications running very slow

#6 2020-10-04 20:38:06

Re: Multiple applications running very slow

#7 2020-10-04 20:50:45

Re: Multiple applications running very slow

#8 2020-10-04 22:05:18

Re: Multiple applications running very slow

#9 2020-10-05 06:15:56

Re: Multiple applications running very slow

#10 2020-10-05 08:22:12

Re: Multiple applications running very slow

#11 2020-10-05 14:14:41

Re: Multiple applications running very slow

#12 2020-10-06 12:39:42

Re: Multiple applications running very slow

#13 2020-10-07 22:14:03

Re: Multiple applications running very slow

#14 2020-10-12 12:11:25

Re: Multiple applications running very slow

Board footer