Weird games lag compared to some distros

Froloket64 · 2021-11-12 15:09:18

About a year ago, I was using Kali as a live system and tried out launching Minecraft on it. It went like stable 50fps, which is ok for my fine-aged MacBook.
Then, I installed (on hard drive) Manjaro as a full-time system. There, some games were pretty fine (e.g. Nuclear Throne - 60-50fps), but specifically Minecraft was lagging wild. Though showing 50fps through F3, the screen was constantly stuttering and updating like 4 times/second and completely nothing helped it.
Now, I'm on a recent Arch installation and tried running Nuclear Throne, and it gives ~20fps. Haven't tried Minecraft yet, though.

I have Intel HD Graphics 3000 and latest Mesa is installed along with `xf86-video-intel`.
I also have to note, that both on my Manjaro and Arch installs, I had Xorg "TearFree" config option set to "true" (https://wiki.archlinux.org/title/intel_graphics#Tearing)

Last edited by Froloket64 (2021-11-12 15:11:11)

V1del · 2021-11-12 15:55:09

TearFree option can and will likely lead to this issue by definition of what it is and how it works. In general xf86-video-intel tends to be buggy though it might work fine on sandybridges, you'll probably want to test the modesetting driver (by removing xf86-video-intel and config files for it)

Note that a lot of the underlying ecosystems change and it's very much possible for regressions to occur in newer releases (... and minecraft will also not be the same minecraft you used to play). E.g. xf86-video-intel is in it's current state incredibly buggy with modern xorg releases which is a constelation you likely didn't have when you originally tested this on a distribution with older packages.

FWIW what's your surrounding environment, which DE/compositor if any, what's your output for

glxinfo -B

from mesa-demos

Froloket64 · 2021-11-12 16:15:50

glxinfo -B:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 3000 (SNB GT2) (0x126)
    Version: 21.2.5
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 3000 (SNB GT2)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.2.5
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 21.2.5
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 21.2.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

I use Qtile + picom (jonaburg's fork - https://aur.archlinux.org/packages/picom-jonaburg-git/ )

V1del wrote:

TearFree option can and will likely lead to this issue by definition

That is what I would have thought myself, if only not:

Froloket64 wrote:

both on my Manjaro and Arch installs, I had Xorg "TearFree" config option set to "true"

Last edited by Froloket64 (2021-11-12 16:24:10)

Froloket64 · 2021-11-12 16:23:51

Froloket64 wrote:

I use Qtile + picom (jonaburg's fork - https://aur.archlinux.org/packages/picom-jonaburg-git/)

And that's exactly what I'm using now.

V1del · 2021-11-12 16:23:55

Nuclear Throne seems like a 32bit game, lib32-mesa installed? Output of

glxinfo32 -B #lib32-mesa-demos

for comparison?

Other than that compare installed packages and versions and configuration files, xorg got a major version bump a few days ago that's likely still being held back by nature of what Manjaro is. Do you use qtile and picom in the same configuration on Manjaro? Also generally running "two" compositors like tearfree and picom is definitely counter productive.

Froloket64 · 2021-11-12 16:27:04

lib32-mesa installed from multilib-testing

glxinfo32 -B:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 3000 (SNB GT2) (0x126)
    Version: 21.2.5
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 3000 (SNB GT2)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.2.5
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 21.2.5
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 21.2.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

Froloket64 · 2021-11-12 16:30:06

V1del wrote:

qtile and picom in the same configuration on Manjaro?

Yep

V1del wrote:

compare

The problem is, I don't have Manjaro installed now. I'm now fully on Arch.

Froloket64 · 2021-11-12 16:32:33

V1del wrote:

xorg got a major version bump a few days ago

But yeah, that can be applicable, as I didn't really update often on Manjaro back in the day.

Froloket64 · 2021-11-12 16:37:34

Btw, I use Windows version of Nuclear Throne (through wine). But, again, I also did so on Manjaro.

[EDIT:]
And I'm using the same wine packages (d3compiler_47 and d3dx10_43).

Last edited by Froloket64 (2021-11-12 16:41:00)

V1del · 2021-11-12 16:41:26

So not a single of these numbers for other system is based on actual current working knowledge? How sure are you that you had the same configuration? Which versions? That's quite useless for any comparison.

Instead of playing that game, fix your setup, disable TearFree, potentially remove xf86-video-intel outright, post/check your picom config (disable the compositor while playing). Check whether there's no frequency problems, sometimes there are firmware bugs here, e.g. monitor your CPU frequencies, do you reach turbo clocks when it should? Possibly try different kernels, e.g. linux-zen has some patches to make CFS more aggressive....

Froloket64 · 2021-11-12 16:46:52

V1del wrote:

Possibly try different kernels

I'm really sorry, I somehow forgot to mention that I'm also using linux-xanmod-lts from AUR and did so on Manjaro.

V1del wrote:

fix your setup

?

Froloket64 · 2021-11-12 17:20:05

Yes, disabling everything added fps, but still the issue is here: That (picom, TearFree) was all enabled when I was playing on Manjaro and that's really weird.

seth · 2021-11-12 22:03:30

1. Stop bumping, edit your posts if nobody has replied and you want to add information
2. If you ended up using the modesetting driver on manjaro, the TearFree option was idempotent
3. You might have been using a different backend (xrender, glx, experimental) on manjaro - also picom's rounded corner implementation is very slow. Maybe you end up w/ an ARGB window, maybe you use fullscreen unredirection, maybe…

V1del wrote:

So not a single of these numbers for other system is based on actual current working knowledge? How sure are you that you had the same configuration? Which versions? That's quite useless for any comparison.

Froloket64 · 2021-11-13 06:20:40

seth wrote:

3. You might have been using a different backend (xrender, glx, experimental) on manjaro

I used experimental and use it here.

V1del wrote:

So not a single of these numbers for other system is based on actual current working knowledge? How sure are you that you had the same configuration? Which versions? That's quite useless for any comparison.

Well, I push the dots to my repo, so here I only cloned them. If you're speaking about package versions, well, I couldn't predict that this would happen, so I didn't memorise their versions. So, yes, I'm not able to give that info.

seth wrote:

If you ended up using the modesetting driver on manjaro, the TearFree option was idempotent

Sorry, not sure which one you mean by modesetting, but TearFree disabled tearing. That's for sure.

seth · 2021-11-13 07:19:17

Sorry, not sure which one you mean by modesetting

The default driver you use if xf86-video-intel isn't installed.

but TearFree disabled tearing

Or picom did … if you get only ~ half the FPS and you're double v'syncing, that'd be to nobodies surprise.

I used experimental and use it here.

So you're using the most fluctuating codebase in the compositor…

Maybe post its settings

V1del wrote:
fix your setup, disable TearFree, potentially remove xf86-video-intel outright, post/check your picom config (disable the compositor while playing). Check whether there's no frequency problems, sometimes there are firmware bugs here, e.g. monitor your CPU frequencies, do you reach turbo clocks when it should? Possibly try different kernels, e.g. linux-zen has some patches to make CFS more aggressive....
?

You're comparing measurements of A w/ imaginations about your memory on B - this isn't going anywhere. So instead focus on simply driving the performance aspect of your current installation.

https://wiki.archlinux.org/title/Improving_performance
https://gitlab.com/garuda-linux/themes- … nce-tweaks - no idea whether manjaro has sth. similar.

Froloket64 · 2021-11-14 12:12:44

Maybe post its settings

https://github.com/Froloket64/dotfiles/ … picom.conf
and vsync is off.

modesetting driver

No, xf86-video-intel WAS installed. And, anyway, if you use /etc/X11/xorg.conf.d/20-intel.conf to set TearFree, Xorg doesn't load without xf86-video-intel (says smth like "driver "intel" wasn't found")

[UPD]

So you're using the most fluctuating codebase in the compositor...

Using non-experimental doesn't help.

Last edited by Froloket64 (2021-11-14 12:17:25)

seth · 2021-11-14 14:36:23

Skip "corner-radius = 8;", it's slow AF.
Otherwise disable blurring.

If either of those does anything major, picom might have behaved differently on manjaro (eg. different fork, patch - iirc blur collided w/ the corner radius and you could only have one xor the other)

Froloket64 · 2021-11-18 13:28:03

Ok, thanks anyway, seems like the fps is quite fine now. Disabling the compositor and closing large apps helps pretty much.

Arch Linux

#1 2021-11-12 15:09:18

Weird games lag compared to some distros

#2 2021-11-12 15:55:09

Re: Weird games lag compared to some distros

#3 2021-11-12 16:15:50

Re: Weird games lag compared to some distros

#4 2021-11-12 16:23:51

Re: Weird games lag compared to some distros

#5 2021-11-12 16:23:55

Re: Weird games lag compared to some distros

#6 2021-11-12 16:27:04

Re: Weird games lag compared to some distros

#7 2021-11-12 16:30:06

Re: Weird games lag compared to some distros

#8 2021-11-12 16:32:33

Re: Weird games lag compared to some distros

#9 2021-11-12 16:37:34

Re: Weird games lag compared to some distros

#10 2021-11-12 16:41:26

Re: Weird games lag compared to some distros

#11 2021-11-12 16:46:52

Re: Weird games lag compared to some distros

#12 2021-11-12 17:20:05

Re: Weird games lag compared to some distros

#13 2021-11-12 22:03:30

Re: Weird games lag compared to some distros

#14 2021-11-13 06:20:40

Re: Weird games lag compared to some distros

#15 2021-11-13 07:19:17

Re: Weird games lag compared to some distros

#16 2021-11-14 12:12:44

Re: Weird games lag compared to some distros

#17 2021-11-14 14:36:23

Re: Weird games lag compared to some distros

#18 2021-11-18 13:28:03

Re: Weird games lag compared to some distros

Board footer