Artix Linux Forum

Hello.

I just have discussed this question with some people from Epic Games and Godot devs. Because I didn't know where is the truth. Very interesting quest.
The thing is while You can easily play Squad, Arma 3, Horizon Zero, etc with high fps, You can experience super low performance in other aspects. Like a game develop. And this is a very widespread story, not only a few people.

How to check it:
If You will try to run empty project in Godot and set it print FPS with vsync off, run it and maximize to FullScreen (I have Full HD), You could see low fps.
I've tested briefly a few distros, Devaun_XFCE_x64_Live for example. It shows 3x or even 6x(!) fps difference unlike Artix.
350 fps in completely empty default project using Artix, and 1-2 or even 3k fps using other distros. I ran it on Intel HD 620 to make it faster (NVIDIA Prime needs some workarounds to get work) so I didn't installed it.
Also I didn't checked Unreal Engine because now I work mostly with Godot engine.
It's very simple to recheck it, but I can do any tests You need. May be... even compile Unreal Engine 5 and see what it shows).

People say it can be:
1. Hardware issues
2. Drivers issues
3. Concrete distro issues

Now I now it's not about my hardware and drivers at all: games and other distros works very well!
May be it's about kernel config too and not only about 1000Hz timer. Somebody who really knows it well should give an answer.

I need to do my job, but completely don't want to change Artix on something else. So I've stuck with only 2 questions now:
- Will You fix it or You'are not interested in because of Arch anchor?
- If yes, how long it will take? It would be really nice to get some approximate dates.

Thank You.

P.S. Also I've upgraded nvidia drivers from official Artix repos and prime is completely broken. I've reinstalled nvidia.*, no luck it doesn't work after last upgrade.

What causes the differences in performance is hardware and drivers which is out of our control. According to your post, the most likely culprit is NVIDIA (hardly a unique case). It's entirely possible that NVIDIA drivers regressed at some point causing the difference (although the numbers you claimed are rather extreme) assuming everything else is mostly the same.

@Dudemanguy vs my real experience, many users experience, our tests, epic games, godot devs, not even a word about NVIDIA, BUT....

It all results in "it's just an extreme numbers", "10000% is hardware and drivers" and " It's entirely possible that NVIDIA drivers regressed at some point".

Please, before write, read a few times carefully. At least once!
I think You don't need to be interested in this post. Let's people will look at it and may be we will figure out how to fix. Or I silently will move to another distro.
It will be much simplier for me and You.

May be my English is so bad, that I mentioned NVIDIA card in tests. But I don't think so.

According to your own post, you said that you use nvidia...


Anyways, there's nothing we can do. We are not kernel or driver developers. Other distros use different versions of these things which can cause big differences. If you really have these problems, my suggestion would be to report upstream to the proper channels (good luck with NVIDIA though).

What kernel are you currently using in Artix?

@calvinh  5.17.1-artix1-1
It's the interesting question, because I've started to configure kernel. But I've took 5.16.19

Try the zen kernel in Arch extra repo. It's known to produce better FPS numbers than the stock kernel. xanmon kernel is another option, but its numbers are close to zen kernel. If you do need the performance  from the kernel, linux-clear is in AUR (better run it on a desktop than laptops.)

@calvinh
I tried to install linux-lts, but it finished the process with error. Ok I will try Zen. Thanks for the advice.

"need the performance"
Please. Read the post. I DON'T need performance from the kernel, I just need to fix this THE_BUG actually somehow and continue my work. And I must try to fix it by myself becausee of the situation with small artix team, cause I want to use this distro. That's all. Nothing more.

sudo pacman -S linux-lts linux-lts-headers

 sudo update-grub && sudo reboot

if you got an error then double check you efi partition is 512mb in size and not 256mb.  depending on your system, and how many oses you are running off the same efi partition you might could be out of space?  maybe.  never in 20 years of using linux have i ever heard a lts kernel error on installation when linux kernel was working.  it is a thing that does not happen.  post the error.

And what precise hardware have you encountered this on? Make, model, CPU and GPU details  would greatly improve your chances I think.

sudo pacman -S hddtemp dmidecode

sudo inxi -Fxzm

@####
MSI Stealth 15M, i7-1185G7

@cat herders of linux
Thank You! I've forgot to mount it.

But yeah, I knew it was a completely stupid idea to try the lts/zen kernel. No luck. But it is a search anyway. I will continue configure 5.16.19.

Somehow zen kernel fixes nvidia driver module sign problem.

there's also always the liquorix you could try as well

[liquorix]
Server = https://liquorix.net/archlinux/$repo/$arch

So your main graphics card is an NVIDIA GeForce RTX 2060 and searching for that plus Arch Linux revealed this which sounds similar:
https://bbs.archlinux.org/viewtopic.php?id=259227 (https://bbs.archlinux.org/viewtopic.php?id=259227)
Here are some other possibly helpful links but there is a lot of documentation to look through!
https://wiki.archlinux.org/title/NVIDIA (https://wiki.archlinux.org/title/NVIDIA)
https://wiki.archlinux.org/title/NVIDIA/Troubleshooting (https://wiki.archlinux.org/title/NVIDIA/Troubleshooting)
http://us.download.nvidia.com/XFree86/Linux-x86_64/460.56/README/index.html (http://us.download.nvidia.com/XFree86/Linux-x86_64/460.56/README/index.html)
Possibly those links above are available in other languages too, like wiki.archlinux.de for example.

@######
It is only sounds similar, but it is sooooo far away from our problem and my question.
Anyway, thank You for the links, one of them actually very useful for another simple problem: nvidia.com...knownissues.html

@cat herders of linux
Thank You! Actually we have found distros (kernel configs?) which work 100% already. May be it will help, we will test it too.
This is a veeery annoying but a very interesting system floating bug and we will continue to search for the answer. But I think we will need even to dive into the code. Not a kernel hacker, other people will check it, but already dying in debugger )

And I just can't understand why people think NVIDIA is the main problem from the text. It's in the text - I've tested on Intel too. Generally on intel actually. Just read the post once. Once carefully, but almost nobody did )))
if some one interested in this, some people had this on AMD too. But intel and NVIDIA already excludes both of them from the equation so I didn't even mentioned it.
Unfortunately, this is not about to google the article with "ready to go" answer, "I know the answer it's a one more stupid thing", or NVIDIA, at all. I thought it's obvious. But may be my English has failed again. If it is, then I'm sorry.

Anyway, thank You all for trying to help I appreciate it!

The thing you are doing is so far beyond anything i have done that i probably sound like an annoying pest.  If so i apologize for that.

The linux concensus is that nvidia is to blame for not open sourcing its drivers so that qualified devs could begin to work on these annoyances.  I would tend to agree.  I suspect that the reason for it is that nvidia uses software encoding to limit what a given board can do rather than strict hardware encoding between different models.  That's always been my suspicion but then i know nothing.

Sorry for not being helpful enough.

The kernel config for your currently running kernel is found in /proc/config.gz so you can unzip it and compare it with the same file from working kernels, using a command like "diff" or something, you may need to play about with options and other file sorting commands to get a helpful output. The zen & liqorix kernels are sort of config'd in an Ubuntu style anyway I thought. If you found any suspect options (some will be obviously unrelated) then you could potentially build a kernel and try flipping them on the Artix build so it's the same. So you are saying that godot is the problem, most everything else works OK? godot might not be able to connect to your graphics card because it cannot access the relevant libs, devices, and so on. This could be a version mismatch or a path error in the godot build.
Try installing this and see if check-link-consistency -N gives any clues. (Try without the -N too if you like, it takes longer though)
universe/check-link-consistency 20220117-1 [installed]
    Checks linked files, similar to revdep-rebuild
It would show if godot had any missing / wrong version solibs.

/proc/config.gz is enabled if CONFIG_IKCONFIG and CONFIG_IKCONFIG_PROC are enabled during the compilation (which Artix kernels do). There is a number of utilities in the gzip package which make it easier to work with files compressed with gzip. To page through a text file compressed with gzip, one can use the command zless(1), and to diff it with another file, zdiff(1). There's also z{,e,f}grep.

I use English rarely, so sorry if something is too ugly )

No. Don't think so. You are really trying to help and this is the most valuable thing in people!

Not the only NVIDIA. Many firms use GPL (of course any of licenses) code and doesn't open it. It's obvious. World is spinning like this. Actually open source is FOR THIS today. Give children stupid idea of "freedom" and piece of a code and they will work on it. Just get it. Free of charge! And they will talk something like "noo we have that freedom, look, Linus linux". Kids))) NVIDIA is just the most famous from them. Others not even talk or shows on public, ever. They are doing another stuff.

Often chips (cpu,gpu,ec,bcm,anyone) are 101% equal - there is one chip with firmware setting it up to be RTX3050 or RTX3050 Ti or 3070 (just for example!!). There are NO economical reasons to make them on a different conveyors. It's very simple. So You are right here on 121%. Also, driver today use VERY interesting techniques. Math for example is not about just 2+2, log2 (10). It can be calculated in many ways. And chips architecture makes many things different there.

CPU blocks or enables it's cores/threads. You can find 10000% equal intel CPU's with a different threads number or some features on/off. May be they burn it once on firmware install process and lock it.. nobody knows. But I believe it can be changed in runtime (and there are a few researches "says" the same).
There is a VERY powerful OS on Your motherboard and phone. It runs Your OS in a hypervisor and rules it in every single bit. Your hard reset for it is just a blink of a display. What are they doing there, God not even knows. It's possible to make a net link that not interferents with Your common network traffic. Do You understand what it means? Many famous hackers posted articles about their BIOS silently has been overwritten..many times.. it's a looong way to search the information: Linux Torv created Windows 10 and 11 kernel. WHERE ARE this articles. They were vanished from the famous news sites. You can(!) find this info. But You will die searching it. I tried to explain this to some stupid person and oh god, that was a long evening searching. So, it's a super complex top-secret things and people who faaaar away from IT and don't even heard about it says "dark theory". Like my grandma )))))

Many firms control their devices through firmware. Just look at nvidia history, holy molly... Apple today!) It's not about keyboard, bunch of chips and sites and  "wow now we have RTX4060 come and buy it!".
This information collected from ope sources about 15 years. Just my mini-interest in IT.
The world is much more complex and as a consequence interesting.. So dive in the reality )

@strajder @#######
"The kernel config...  diff... gzip"
Thank You. I'm a C++ dev in the past(?). So I know what are You talking about.

OOoohhh may be.. may be. I don't even know waht can caouse this ))) We just have some theories where to search. I'm not the first one who tries to figure it all out. Just thought "why not".. And I don't want to use systemd on another distro )

"universe/check-link-consistency"
Interesting variant. Will use it. UPDATE: Didn't helped: 1 file duplicated - OpenCL.so


How can I rebuild nvidia-dkms only for my installed custom kernel? Now I'm reinstalling it when I need it. It involves all kernels I have

https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support#Rebuild_modules

@strajder Thank You!
Can You help me with building mesa-20.3? I need now to check concrete version 20.3.5 (the last one in that branch).
But I've got the error:

../src/drm-shim/drm_shim.c:79:23: error: ‘__xstat’ undeclared here (not in a function); did you mean ‘_xstate’?

I have last updates, mesa sources from git branch 20.3 (also tried tag 20.3.5).

Configuring like 21.3 and 22.1 (build is OK) by this script :

# env sh

meson --reconfigure build64 --libdir lib64 --prefix=~/1 \
-Dbuildtype=release \
-Ddri3=true \
-Dvulkan-drivers=intel,swrast \
-Dgallium-drivers=swrast

That is a question for upstream. If I had to guess, it looks like some kind of a dependency issue.

I tried this out using nouveau, although I haven't used Godot, and couldn't understand how to run a blank project. In Devuan and XFCE (older non hw accelerated XFCE)  I got an FPS of 60 in the Godot debugger when running the "Basic Platformer" demo. Then I downloaded the current zip file Godot.
https://godotengine.org/download/linux (https://godotengine.org/download/linux)
It also gave 60 FPS just the same, although it was a newer version than the Devuan package. In Artix & Mate I got an initial reading of 145 FPS then as soon as I clicked on the window the demo was running in it went to 59 FPS. Dragging the window about the screen saw the FPS drop perhaps by 10 briefly. The version from the website did the same. So trying that same version on your various systems might tell you something. Running it from the command line could give some debug output, it also has some options you can see with "godot --help" like -d for debug and you can set the FPS but neither of those had any effect when I tried them. So it was a bit different on my 2 systems even when using the same godot binary. The game behaviour seemed identical everywhere from my subjective viewpoint. As I have a 60Hz display it can only display up to 60 FPS without dropping frames so perhaps that's relevant.

@#######
"It also gave 60 FPS just the same" It's called "Matrix VerticalSync Rate (in Hz)". Common value is 60, I have matrix with 144 Hz refresh rate.
Project Settings -> Search -> vsync off. And You will get real max fps project can give.

May be.. AUR could broke something and everything can be fixed so easily by reinstalling Artix completely.
But everyone who met this bug told me this can't help, they've to move to another hardware. Will try it now anyway.

Installing Artix into the VM. Blackscreen on resolution change artix-base-openrc-20220123-x86_64.iso (startx /bin/startplasma-x11) in VirtualBox. And sddm hangs the system. Manjaro works well. Didn't checked why. But it is in VM hope it will work better in real env.

Got the error installing smplayer:

context: exec: systemd-run 

In the last week: 2 kernel versions, 3 mesa, 2 xorg, 3 intel, 2 nvidia )

    Don't install xf86-video-intel - it KILLS all the "Intel HD Video" performance and somehow sometimes (even some fresh install iterations) can break NVIDIA too. Tested on Manjaro, Arch and Artix distros. I don't sure on 100%, but I have tested one version and it worked, but was too old. So never mind.
Sometimes You can't revert it back uninstalling intel and nvidia drivers. I don't even know why, may be it's a various versions issue.

    Sometimes, Mangohud can break some things (some games for example), try to check everything without it. But it is a seldom situation. Mangohud is a very useful thing, just use it carefully.

    Some old hidden stuff in Your home directory can help this low fps story to exist. Don't have a clue, just have deleted it all out. But it has helped only partly.

    I can play Arma 3 on Ultra settings with a stable 60 fps with vsync.
NVIDIA performance is ugly yet: 0 __GL_SYNC_TO_VBLANK=0 ~/nvidia_run.sh godot_empty_project**
gives only 1'100 fps on nvidia: Temp: 66C P0 39W Load: 94%

But at least I can continue my work now somehow on intel: it gives now 3'300 fps.
If someone know how to fix nvidia please share.

I did try after switching off the vsync setting as you suggested. In Artix I then found it started out at 145fps (it seems to be that whenever mouse focus leaves the game window) then when I went to the window it was around 345fps,and this was the case with Artix godot and the Godot godot binary.
In Devuan using the Godot godot only it started out with 450fps with no mouse focus on the game window and then was about 426fps with focus on window, but I noticed it drops a bit while other things outside the window change, ie dragging the window round the desktop.
So you might be able see a difference using Nouveau, and as this is open source it would probably be easier to debug.