You are not logged in.
Libreoffice: https://bugs.documentfoundation.org/sho … ?id=152911
Try to actually run picom (o the glx backend)
Offline
running "picom" in the terminal makes a smooth transition when i switch workspaces, but does not fix the tearing
ok... so libre office slow is just a bug?
do you think this could be a bug in the game? i am running an older-than-required graphics card, so maybe "bug" is a bit harsh.
Online
LO is OTR for this kind of ridiculous inefficiency, yes.
If you're looking for a lightweight, MSO-compatible office suite, have a look at https://aur.archlinux.org/packages/freeoffice (as in beer, not freedom)
As for tearing: do you still export __GL_SYNC_TO_VBLANK somewhere?
echo $__GL_SYNC_TO_VBLANK
Does glxgears show any tearing?
Offline
> echo $__GL_SYNC_TO_VBLANK
> __GL_SYNC_TO_VBLANK=1 firefox
> __GL_SYNC_TO_VBLANK=0 firefox
> echo $__GL_SYNC_TO_VBLANK
>
neither option fixes tearing in firefox
Does glxgears show any tearing?
yes
Online
nb. that firefox will by default not spawn a new process but attach to the current one, you've to make sure to "killall firefox" before starting it w/ different environment paramters.
Does "__GL_SYNC_TO_VBLANK=1" tear???
(w/o picom running)
Offline
> killall firefox
firefox: no process found
> __GL_SYNC_TO_VBLANK=1 firefox
[Parent 4124, Main Thread] WARNING: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff71a1f3b0' of type 'MaiAtkType21': 'glib warning', file /usr/src/debug/firefox/firefox-138.0.4/toolkit/xre/nsSigHandlers.cpp:201
(firefox:4124): GLib-GObject-CRITICAL **: 14:12:51.721: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff71a1f3b0' of type 'MaiAtkType21'
[Parent 4124, Main Thread] WARNING: ../glib/gobject/gsignal.c:3647: signal name 'text-remove::system' is invalid for instance '0x75ff71a1f3b0' of type 'MaiAtkType21': 'glib warning', file /usr/src/debug/firefox/firefox-138.0.4/toolkit/xre/nsSigHandlers.cpp:201
(firefox:4124): GLib-GObject-CRITICAL **: 14:12:51.729: ../glib/gobject/gsignal.c:3647: signal name 'text-remove::system' is invalid for instance '0x75ff71a1f3b0' of type 'MaiAtkType21'
[Parent 4124, Main Thread] WARNING: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff6f2d87d0' of type 'MaiAtkType21': 'glib warning', file /usr/src/debug/firefox/firefox-138.0.4/toolkit/xre/nsSigHandlers.cpp:201
(firefox:4124): GLib-GObject-CRITICAL **: 14:12:51.729: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff6f2d87d0' of type 'MaiAtkType21'
[Parent 4124, Main Thread] WARNING: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff71a7c170' of type 'MaiAtkType21': 'glib warning', file /usr/src/debug/firefox/firefox-138.0.4/toolkit/xre/nsSigHandlers.cpp:201
(firefox:4124): GLib-GObject-CRITICAL **: 14:12:51.729: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff71a7c170' of type 'MaiAtkType21'
[Parent 4124, Main Thread] WARNING: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff73007dd0' of type 'MaiAtkType21': 'glib warning', file /usr/src/debug/firefox/firefox-138.0.4/toolkit/xre/nsSigHandlers.cpp:201
(firefox:4124): GLib-GObject-CRITICAL **: 14:12:51.729: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff73007dd0' of type 'MaiAtkType21'
[Parent 4124, Main Thread] WARNING: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff6f68dc50' of type 'MaiAtkType21': 'glib warning', file /usr/src/debug/firefox/firefox-138.0.4/toolkit/xre/nsSigHandlers.cpp:201
(firefox:4124): GLib-GObject-CRITICAL **: 14:12:51.729: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff6f68dc50' of type 'MaiAtkType21'
[Parent 4124, Main Thread] WARNING: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff71a1f3b0' of type 'MaiAtkType21': 'glib warning', file /usr/src/debug/firefox/firefox-138.0.4/toolkit/xre/nsSigHandlers.cpp:201
(firefox:4124): GLib-GObject-CRITICAL **: 14:12:51.729: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff71a1f3b0' of type 'MaiAtkType21'
[Parent 4124, Main Thread] WARNING: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff6e1bfb90' of type 'MaiAtkType21': 'glib warning', file /usr/src/debug/firefox/firefox-138.0.4/toolkit/xre/nsSigHandlers.cpp:201
(firefox:4124): GLib-GObject-CRITICAL **: 14:12:51.792: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff6e1bfb90' of type 'MaiAtkType21'
[Parent 4124, Main Thread] WARNING: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff6b9d17d0' of type 'MaiAtkType21': 'glib warning', file /usr/src/debug/firefox/firefox-138.0.4/toolkit/xre/nsSigHandlers.cpp:201
(firefox:4124): GLib-GObject-CRITICAL **: 14:12:51.792: ../glib/gobject/gsignal.c:3647: signal name 'text-insert::system' is invalid for instance '0x75ff6b9d17d0' of type 'MaiAtkType21'
i think the errors show up after i view the screen tearing video on youtube, but the tearing is visible just viewing this page.
i think i'm going to submit a bug to the game, since it has been slow a lot. I'm not sure why it got better for a while when i first deleted those config files.
Online
opened a bug report
Online
Do you btw. set "gfx.webrender.compositor.force-enabled" in about:config in firefox?
Afaict it should default to software rendering?
Offline
i ordered a used rx 470.
Now I get higher fps, but I still get stuttering (i don't know if this is the same thing that was happening before or not. maybe the reason the game originally reported a higher fps, but i saw visually a much lower fps, is because there was stuttering mixed in?). I am now using mangohud, and find that while i can get 115fps with this new card, I also get a 60ms stutter frame every 2.8 seconds like clockwork. on 0ad i get a similar stutter but it's smaller and faster (every 0.3 seconds)
Edit: i do not get the "clockwork stutter" on furmark or heaven
Edit: Libre office is still atrociously slow. arch wiki for amd fixed tearing with this new gpu. I just tried the xrandr temporary solution. I haven't tried getting it permanent or telling for sure if it affects game performance.
sidenote: any suggestions on how to verify there's nothing wrong with the new (used) card?
thanks
Last edited by iith4ahm (Yesterday 00:18:08)
Online
how to verify there's nothing wrong with the new (used) card?
Run a stress test, if if melts, there was something wrong with it
For the games,
export vblank_mode=0
(Or, if we're leaving 0ad aside, "mangohud" implies steam?)
For libreoffice, you already figured that it causes severe cpu load - if this is regardless of hardware acceleration being enabled, this is simply due its inefficient code and no GPU in the world will fix some CPU hog.
Offline
Run a stress test, if if melts, there was something wrong with it
I ran furmark for like 5min, and got 70C, clock throttled down to 700Mhz, and fan was at 3000rpm (100%?). I ran heaven for like 4 cycles (20min?) and got 69C, clock throttled down to 1130Mhz, and fan was at 2700rpm. I didn't notice any artifacts, but i got a few stutters in heaven (not as frequent as in the game, and tied to specific parts of the movie, not on a timed pulse), and I am a little concerned about how fast the fans have to run to keep it cool. Maybe it needs repasting? Is this sufficient to test a used gpu, or should i be pushing it harder somehow? Could the weird 70ms frame stutters be caused by a bad gpu, or is that likely a software issue?
Edit: this guy made a comment that heaven shouldn't stutter. I do get some long frames in heaven. Is he just wrong, or does that indicate that something with my hardware or software is wrong?
Edit: nevermind the next guy answered my question.
"mangohud" implies steam?
No, i don't have steam. I just run mangohud <command to run game> from the command line
> export vblank_mode=0
> mangohud ./Beyond-All-Reason-1.2988.0.AppImage
This increased the frame rate in the lobby (they probably have vsync set up there?) but not in the game (other than making the game non-responsive to the vsync setting). It doesn't fix the clockwork stuttering, although it makes the stuttering more apparent in the lobby, since the 70ms frames stick out more when the other frames are fast.
Edit: tested with usb hub, printer, ethernet cable all disconnected, with restart, no effect
Edit: tested with xonotic and don't get the periodic lag frames. my gpu had an easy time with that. are there other games that might be worth testing that work the gpu like beyond all reason does?
Edit: maybe the next step is to swap the old gpu back in and switch all the drivers and configuration back over to nvidia, and see if i can notice this pulsing lag on the old gpu. then if i see it at least i know it's not the new gpu's fault.
Last edited by iith4ahm (Yesterday 19:36:10)
Online
Do you currently run any compositor (picom)?
Multiple monitors? (There was https://bbs.archlinux.org/viewtopic.php?id=304663 but that would not be limited to certain games)
And keep eg. https://archlinux.org/packages/?name=amdgpu_top and top running to see whether there's a bottleneck in the GPU or the CPU when the game stalls.
Offline
no compositor, one monitor, nothing obvious stands out to me with top or htop. It's just a blip - one really long frame every 2.8 seconds. I think it's too fast for top/amdgpu_top. Are there faster programs?
If vsync is off, then lots of things on the graphics card are maxed out. If vsync is on, then the only thing amdgpu_top is showing as saturated is "Activity:GFX", which alternates between 0% and 100% and in between.
edit: here is top:
going out on a whim here - could systemd be doing something weird here? like logs rolling over every 2.8 seconds? edit: just tested and systemd shows up high on the list for top even when the game doesn't run...
top - 20:30:09 up 6:26, 1 user, load average: 1.50, 1.11, 0.76
Tasks: 345 total, 2 running, 343 sleep, 0 d-sleep, 0 stopped, 0 zombie
%Cpu(s): 7.5 us, 4.1 sy, 0.0 ni, 87.0 id, 0.0 wa, 1.4 hi, 0.0 si, 0.0 st
MiB Mem : 23951.9 total, 10483.6 free, 8627.7 used, 5250.1 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 15324.2 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14328 paul 20 0 8783004 4.7g 174276 R 90.0 20.1 6:04.33 recoil-main
14145 paul 20 0 1131.3g 167708 125888 S 24.5 0.7 0:42.02 beyond-all-reas
16068 paul 20 0 10972 7124 5076 R 16.4 0.0 0:00.04 top
746 paul 20 0 1408128 108820 56576 S 8.2 0.4 1:29.47 Xorg
1126 paul 9 -11 1577080 38100 24564 S 8.2 0.2 0:33.68 pulseaudio
1 root 20 0 22332 14148 9876 S 0.0 0.1 0:01.55 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pool_workqueue_release
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-rcu_gp
5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-sync_wq
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-kvfree_rcu_r+
7 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-slub_flushwq
8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-netns
11 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H-events_hi+
14 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-mm_percpu_wq
15 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_kthread
16 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_rude_kthread
17 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_trace_kthread
18 root 20 0 0 0 0 S 0.0 0.0 0:00.18 ksoftirqd/0
19 root -2 0 0 0 0 I 0.0 0.0 0:03.27 rcu_preempt
20 root -2 0 0 0 0 S 0.0 0.0 0:00.00 rcub/0
21 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_exp_par_gp_kthread+
22 root 20 0 0 0 0 S 0.0 0.0 0:00.05 rcu_exp_gp_kthread_wor+
23 root rt 0 0 0 0 S 0.0 0.0 0:00.03 migration/0
24 root -51 0 0 0 0 S 0.0 0.0 0:00.00 idle_inject/0
25 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
26 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1
27 root -51 0 0 0 0 S 0.0 0.0 0:00.00 idle_inject/1
28 root rt 0 0 0 0 S 0.0 0.0 0:00.37 migration/1
29 root 20 0 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/1
31 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/1:0H-events_hi+
32 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2
Last edited by iith4ahm (Today 01:58:41)
Online
ok i swapped the old slow gtx 640 back in and i still get the 2.8 interval 70-100ms stutter frames.
so that's encouraging that it's not the new (used) card.
although a faulty card would have been an easy software fix
Online
would it be overreacting to reinstall arch?
edit: it was installed in 2019
edit: probably should post on reddit to see if other are having a similar issue first
Last edited by iith4ahm (Today 03:36:15)
Online
this (basically) ai generated script worked for getting high resolution of cpu usage. can see opening and closing of new tabs in firefox, for example.
import psutil
while True:
cpu_usage = psutil.cpu_percent(interval=0.02)
print(int(cpu_usage)*"x")
Didn't notice any cpu spike pattern consistent with the heartbeat stutter frames
Last edited by iith4ahm (Today 04:55:59)
Online
Consider replacing pulseaudio w/ pipewire-pulse - and you absolutely must not run pulseaudio next to pipewire, if that's currently the case.
What's the current output of "xrandr -q"?
Does changing the games/monitors resolution or refresh rate do anything wrt the stall frequency?
Offline
Based on your pulseaudio hint, I tried turning the soundtrack off. Blip went away
Still including responses to your other questions, which i made before
> xrandr -q
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384
DVI-I-0 disconnected primary (normal left inverted right x axis y axis)
DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm
1920x1080 60.00*+
1280x1024 75.02 60.02
1152x864 75.00
1024x768 75.03 60.00
800x600 75.00 60.32
640x480 75.00 59.94
HDMI-0 disconnected (normal left inverted right x axis y axis)
DVI-D-0 disconnected (normal left inverted right x axis y axis)
See also post #25 for when the monitor was plugged into the other DVI port.
Does changing the games/monitors resolution or refresh rate do anything wrt the stall frequency?
i don't think so
Last edited by iith4ahm (Today 14:37:07)
Online
Did you address the pulseaudio ./. pipewire situation properly?
Nobody uses pulseaudio anymore (and some have never…) and the clients possibly relying on libpulse can be satisfied by pipewire-pulse which is the suggested approach.
Offline