Skip to main content
Topic: Video drivers issue (low perfomance) (Read 1789 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: Video drivers issue (low perfomance)

Reply #15
@######
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.
Cat Herders of Linux

Re: Video drivers issue (low perfomance)

Reply #16
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.

Re: Video drivers issue (low perfomance)

Reply #17
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,
/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.

Re: Video drivers issue (low perfomance)

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

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.
No. Don't think so. You are really trying to help and this is the most valuable thing in people!

The linux concensus is that nvidia is to blame for not open sourcing its drivers
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.

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.
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 )

Re: Video drivers issue (low perfomance)

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

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.
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


Re: Video drivers issue (low perfomance)

Reply #21
@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:
Code: [Select]
../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 :

Code: [Select]
# env sh

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


Re: Video drivers issue (low perfomance)

Reply #23
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
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.

Re: Video drivers issue (low perfomance)

Reply #24
@#######
"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:
Code: [Select]
context: exec: systemd-run 

Re: Video drivers issue (low perfomance)

Reply #25
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.

Re: Video drivers issue (low perfomance)

Reply #26
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.